上图是需求工程的组成部分，从图中可以看出，需求工程划分为两个部分：需求开发和需求管理。需求开发又分为需求获取（Elicitation）、需求分析（Analysis）、编写规约（Specification）和需求验证（Validation）。需求管理又分为基线管理、变更管理、需求跟踪。
下面我将分别介绍一下上面各个主要组成部分主要的工作内容，以便那些不熟悉需求的人员读后能够从总体上把握需求所涉及的工作内容。
需求开发
需求开发活动包括以下几个方面：
- 确定产品所期望的用户分类。
- 获取每类用户的需求。
- 了解实际用户任务和目标以及这些任务所支持的业务需求。
- 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
- 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
- 了解相关质量属性的重要性。
- 商讨实施优先级的划分。
- 将所收集的用户需求编写成规格说明和模型。
- 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。
实际工作中很难一次性得到完全正确的需求，所以以上步骤并不是严格顺序执行到底的，它是一个不断反复的过程。这些步骤也不是完全顺序的，很可能需要迭代的进行。基于项目的产品需求开发过程可能如下图所示：
在软件开发过程中，当你想了解具体需求时，有些客户会说没有时间，这时需要和客户建立一种合作关系，具体来说：
客户权利：
1. 要求分析人员使用符合客户语言习惯的表达。
2. 要求分析人员了解客户系统的业务及目标。
3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。
4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。
5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。
6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。
7. 描述产品使其具有易用、好用的特性。
8. 可以调整需求，允许重用已有的软件组件。
9. 当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估。
10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。
客户义务：
1. 给分析人员讲解业务及说明业务方面的术语等专业问题。
2. 抽出时间清楚地说明需求并不断完善。
3. 当说明系统需求时，力求准确详细。
4. 需要时要及时对需求做出决策。
5. 要尊重开发人员的成本估算和对需求的可行性分析。
6. 对单项需求、系统特性或使用实例划分优先级。
7. 评审需求文档和原型。
8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。
9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。
10. 尊重需求工程中开发人员采用的流程（过程）。
下面就需求开发每个活动进行简单介绍：
需求获取
在《软件需求的三个层次》中介绍了三个层次的需求，在需求获取中，这些需求都是我们需要获取的，我们需要收集问题域的描述，要求解决的问题列表，以及了解系统的行为或约束。
信息来源
- 客户（实际的和潜在的）
- 用户（实际的和潜在的）
- 已有系统及其文档
- 领域专家
- 相关技术标准和法规
获取技术
- 阅读背景资料
- 用户访谈、调研
- 需求讨论会
- 现场观摩
需求分析
需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。
- 不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析
- 交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台
- 分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材
编写规约
- 规格说明书是对需求分析结果的文档化过程
- 需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离
- 为需求规约定义统一的格式是一个很重要的工作
- 规约内容必须严谨、正确、无歧义
需求验证
需求管理
需求管理活动包括：
- 定义需求基线（迅速制定需求文档的主体）。
- 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。
- 以一种可控制的方式将需求变更融入到项目中。
- 使当前的项目计划与需求一致。
- 估计变更需求所产生影响并在此基础上协商新的承诺（约定）。
- 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。
- 在整个项目过程中跟踪需求状态及其变更情况。
扫一扫
2079
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
