分享我眼中的乙方软件开发方法论

本人是搞需求的，老被甲方蹂躏，写下甲方的工作方法泄愤，没人看就不写后面模块的了

软件开发生命周期框架

1. 项目立项
2. 需求分析
3. 技术设计
4. 系统架构
5. 系统测试
6. 用户验收测试
7. 上线实施
8. 项目结项

需求分析的目标

1. 获取真实、完整、具体的需求
2. 从多家咨询公司获得High level design，同时寻求UX设计公司做出UX design，大老板sign off
3. 项目经理定义Statement of work，大老板sign off
4. 甲方BA写出BRS，部门老大sign off
5. 乙方写出FRS，开发开干，然后甲方改个天昏地暗
6. 项目“成功”交付，大老板sign off（内心OS: 这个真是我当年签的/li>

需求分析的活动
1.锤炼需求
从所有干系人处获得功能、非功能需求，并标准化

2.“管理”需求变更，呵呵
有效管理需求变更，建立映射文档并记录变更影响
提醒大家各个版本最好给一堆人签字，并且告诉他们“小朋友们，只能看xx天哦，然后就不能改了哦。”当然小朋友们肯定不会听话的

3.评估并划分需求的优先度
相信我，在一段时间内只放入固定规模的需求只会提高所有人的效率并且达到乙方长命百岁的效果。
尽早识别并排除自相矛盾的需求，以最小化其影响

4.评估对其他用户/系统的影响并做出建议
建议就是用文件sftp传，不要搞太多最后没有人搞得清的“全聚合”接口

5.根据需求，绘制架构图
之前，架构师都必须旁听所有需求，而且给客户之前你要用120%的精力注意他有没有做多、做少。
和所有干系人和行业专家一起审阅该设计，你永远不知道甲方有什么离奇的人工数据处理流程

6.寻求需求文档的签字
a.所有干系人都必须好好看过，千万别给他们时间太紧
b.签字这个基线版本，以后要改就用拖的，不会要命的、画蛇添足的新功能的变更永远排在最后
相信我，甲方会感谢你的这个方法，很多变更，他们后面自己就想通不想要了
c.事实上的所有者签字,比如某部门领导，或者大老板。