软件项目管理案例：需求分析方法与文档撰写

（一）软件需求分析案例:程序员要做需求分析

你编码时会参考客户的原始需求吗，还是只会按照技术经理下达的任务安排的中指引来修改？
今天跟小组的一个开发人员聊了聊。他只会修改任务安排中明确说明的功能点，其他的不会修改。

他认为：
一、技术经理是非常熟悉系统，比开发人员要熟悉，所以技术经理明确划分出功能点后，他不会再去看客户的需求，而是根据任务安排中的修改。
二、既然技术经理已经跟客户确认了需求，开发再花时间去看需求的话，很浪费时间；开发过程中跟技术经理确认功能点，也很花时间，如果发现有遗漏功能点，可能导致延期，不能在承诺时间点发放给客户。 

对于第一点，我不建议盲目相信任务安排
1.开发要了解原始需求，才能站在客户的角度考虑问题，客户为什么要提这样的需求？
2.技术经理也有考虑不全面的时候，客户的一个小需求可能会涉及到N多功能点，任务安排中可能没有明确写完整。
3.盲目相信任务安排，不利于理解业务
对于第二点，更是开发人员的误解。我们的目标是要为客户提供满意的服务，在保证高质量的前提下，保证一定响应度地给客户提供版本。
我们第一关注的是高质量。我们非常迅速地给客户提供一个垃圾版本，完全没有意义，我们不仅伤害了客户，更深深伤了自己。
开发人员要理解客户的需求，并要跟技术经理讨论需求，可能的话，还要跟客户确认需求。

(二)软件需求分析方法总结--撰写优秀的需求

软件需求常常被写得很糟且难于遵循。清楚地阐明你的需求将使每位项目参与者获益。 需求说明总的特点 1、它们必须是正确的。 2、它们必须是可行的 3、它们必须是对项目来说是必不可少的。 4、它们必须是被标明优先次序的。 5、它们必须是不含糊的。 6、它们必须是能被证实的。 每一条需求说明的特点 1、它是完整的。 2、它是一致的。 3、它是可修改的。 4、它是可跟踪的。　 需求写作指南 撰写优秀的需求没有一个简单的公式。很大程度上，它是从过去的需求问题中得来的教训与经验。这儿有几条当你写作软件需求时应记在心上的原则： * 保持句子和段落简短。 * 从开发者的立场来看，检查需求陈述是否足够明确。 * 努力找到一个适当的粒度层次来写作。 * 检查是否有一个陈述表达了多个需求，将它们分开。 * 整个需求文档的写作都保持在一个一致的细节层次上。 * 避免陈述冗余的需求。

（三）面向对象分析法和结构化分析法

面向对象的分析：领域模型、用例图、类图、活动图、顺序图、状态图。
面向过程或称结构化的：流程图、数据字典、er图。
一什么是需求分析
需求分析是先分解，再提炼，并在这个过程中消除矛盾。

分解：
（1）业务流程为主线索的分解——SERU。目标系统——>主题域——>业务事件——>业务活动——>业务步骤。
适用于管理信息系统。
按“事”的角度进行分解，

（2）程序结构为主线索的分解结构。目标系统——>子系统——>功能模块——>子模块——>功能点。
过早的进入了程序结构，割裂了与问题域之间的联系，从而导致对问题研究不足，降低了需求的质量。
适用于问题不复杂，或者系统与问题管理性不强的情况下。

（3）基于场景的分解结构。目标系统——>关注点/功能域——>决策场景/使用场景——>决策步骤。
适用于决策支持系统、面向用户的嵌入式系统。

（4）基于数据的分解结构。目标系统——>主题域——>主题类——>企业逻辑数据类——>物理数据类。
适用于数据类项目。
提炼;
分解是自顶向下的方法，提炼是自底向上的方法。 

二、为什么要建模？
（1）可视化：帮助我们按照实际情况或按照我们需要的样式对系统进行可视化；
（2）结构或行为：提供一种详细说明系统的结构或行为的方法；
（3）给出一个指导系统构造的模板；
（4）对我们所做出的决策文档化；

三、什么是结构化分析方法，怎么用？

结构化分析方法是以数据为中心的结构化分析方法，关键点有两个：一确定有哪些数据，格式是什么，如何存储，如ER图；二是确定数据加工、处理过程，如数据流图。
在实际工作中，一般用于对工作任务分解结构、公司管理中组织结构分解。
常用的建模方法有：数据流图、ER图、数据字典。

四、什么是面向对象分析方法，怎么用？

以人、事（业务流程）的视角来分析问题。
常用的建模方法有：类图、领域模型、用例图、类图、活动图、顺序图、状态图、包图等UML中定义的模型。

五、需求分析中常用的建模工作有哪些？


（四）最近做需求分析遇到的问题及反思

书写是为了更好的思考。借Blog当个笔记本整理一下思路。

项目当前处于设计需求分析阶段，从市场及其他部门提过来需求若干条。我要做的工作就是根据这些干条条，搞清楚市场人员提出这些需求是为了解决什么问题，设计应用场景跟他们核对，看是否满足他们的要求。

在需求分析时出现的问题：

1. 包需求变换频繁，频繁删除，频繁增加。刚分析到一半被把告知该需求被砍掉了，然后又加了不少新的进来。

---》按说系统分析师应该在前面把控，不做的，做不了的，前期就该砍掉。由于该原因导致分析阶段至少1/3的工作量白做了。

2. 涉及多个项目组协作的需求，由于进度不一致无法往下分析。

---》分析了一条需求，需要和其他项目组协作，需要制定接口。沟通后发现该项目组还没有开始分析，也不清楚最终会做成什么样子，导致这边的需求分析也停下来。接纳这类需求的时候一定要考虑周边部门的开发节奏。

3. 一线的同事过于热心，包需求提的不是要求而是实现方案。

---》一线的大部分同事以前也是做技术研发出生的，提需求的时候直接就写上你要给我怎么怎么做。这个东西分析很痛苦，没有写要求是什么，为什么有这些要求。经过反复沟通才把要求明确下来，发现他的建议实现方案满足不了他的要求或者根本就是错的。

这一点系统分析师在前面也应该把关，这种需求直接打回。