Educode--头歌 《软件工程》实验作业8-需求分析

第1关：需求分析的概念和任务

任务描述

本关任务：根据所学有关软件工程中需求分析的知识，完成相关的选择题。

相关知识

为了完成本关任务，你需要掌握：1.软件工程中需求分析的基本概念以及任务，2.需求分析的方法以及标准。

需求分析
需求分析也称为软件需求分析、系统需求分析或需求分析工程等。

是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

需求分析的任务
需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。

此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。

需求分析的原则
为了促进软件研发工作的规范化、科学化，软件领域提出了许多软件开发与说明的方法，如结构化方法、原型化法、面向对象方法等。这些方法有的很相似。

在实际需求分析工作中，每一种需求分析方法都有独特的思路和表示法，基本都适用下面需求分析的基本原则：

1. 侧重表达理解问题的数据域和功能域；
   对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。
2. 需求问题应分解细化，建立问题层次结构； 可将复杂问题按具体功能、性能等分解并逐层细化、逐一分析。
3. 建立分析模型。
   模型包括各种图表，是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系，而非实现细节。由系统运行及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式。

需求分析的内容
需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。

具体分为功能性需求、非功能性需求与设计约束三个方面：

1. 功能性需求 功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。

   开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。

2. 非功能性需求 作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求和运行环境的要求。

3. 设计约束 一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。

例如，要求待开发软件必须使用 Oracle 数据库系统完成数据管理功能，运行时必须基于 Linux 环境等。

需求分析的过程
需求分析阶段的工作，可以分为四个方面：问题识别、分析与综合、制订规格说明、评审：

1. 问题识别 就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。

   这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU
   等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。

2. 分析与综合
   逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。

3. 制订规格说明书 即编制文档，描述需求的文档称为软件需求规格说明书。

注意：需求分析阶段的成果是需求规格说明书，向下一阶段提交。

4. 评审 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作，否则重新进行需求分析。

需求分析的方法
目前，软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。

从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象四个方法。

1. 功能分解方法 将新系统作为多功能模块的组合。各功能亦可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解 ——
   功能、子功能、功能接口。
2. 结构化分析方法
   结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。

此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。

3. 信息建模方法
   它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是
   E—R 图。

经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是 E-R 图，其基本要素由实体、属性和联系构成。

该方法的基本策略是从现实中找出实体，然后再用属性进行描述。

4. 面向对象的分析方法 面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。

   面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。

需求分析的特点
需求分析的特点及难点，主要体现在以下几个方面：

1. 确定问题难
   主要原因：一是应用领域的复杂性及业务变化，难以具体确定；二是用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等。
2. 需求时常变化
   软件的需求在整个软件生存周期，常会随着时间和业务而有所变化。有的用户需求经常变化，一些企业可能正处在体制改革与企业重组的变动期和成长期，其企业需求不成熟、不稳定和不规范，致使需求具有动态性。
3. 交流难以达到共识
   需求分析涉及的人事物及相关因素多，与用户、业务专家、需求工程师和项目管理员等进行交流时，不同的背景知识、角色和角度等，使交流共识较难。
4. 获取的需求难以达到完备与一致
   由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义。
5. 需求难以进行深入的分析与完善
   需求理解对不全面准确的分析，客户环境和业务流程的改变。市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施。

作答要求

根据相关知识，按照要求完成右侧选择题任务。作答完毕，通过点击“测评”，可以验证答案的正确性。

答案

第2关：需求工程

任务描述

本关任务：根据所学有关需求工程的知识，完成相关的选择题。

相关知识

为了完成本关任务，你需要掌握：1.需求工程的基本概念，2.需求工程的内容以及方法。

需求工程
需求工程是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。

需求工程覆盖了体系结构设计之前的各项开发活动，主要包括分析客户要求、对未来系统的各项功能性及非功能性需求进行规格说明，并针对不同的对象可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。

在系统开发中，需求工程往往与体系结构设计交替进行，直到分解的子问题可以单纯地由软件或硬件系统解决。软件需求工程则是对应用于纯 软件系统开发生命期中系统设计之前的第一阶段。

因此，需求工程的目标相当简单明了：确定客户需求，定义设想中系统的所有外部特征。

需求工程的方法
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上完成需求规范。

为了提高目标软件需求规格的质量，需求工程提出了以下几种方法：

• 结构化需求抽取方法

需求工程支持结构化的需求抽取过程，为需求的抽取过程提供构型未来系统的理念，提供需求抽取的线索、需求描述的框架和需求抽取方法论，明确指出需求抽取过程中所涉及的有关问题及其正确的处理方法，从而保证抽取过程的质量，并提供系统化、工程化的指南和有效的支持工具，使得需求信息的无二义性、完整性和一致性。

• 系统化的需求建模方法

需求工程支持系统化的需求建模过程和途径，为软件需求模型提供预定义的语义解释和预定义的语义约束，支持需求提供者和系统开发者从语义上正确地理解所获得需求信息的含义，使得需求提供者可以正确地判断当前已提供的需求信息是否真正表达了他们自己的意图，也使得系统开发者可以了解自己对需求提供者所提供需求信息的理解程度。

• 形式化的需求验证技术

形式化的验证技术是在形式化需求模型基础之上进一步保证需求信息正确性的手段。 它采用精确的数学语言来表达需求模型，并借助于数学推导的手段, 使得需求模型中含糊的、不完整的、矛盾的以及无法实现的表述能够被准确地发现, 从而尽早得到纠正。

形式化需求验证技术一般分为3类，分别是代数方法、基于模型的方法和基于进程代数的方法，它们分别适用于描述和分析不同类型的软件系统。

形式化需求验证技术的作用分为两个方面: 一方面是验证需求提供者的意图可满足性 (即需求模型的有效性)；另一方面是验证需求模型的可实现性 (即需求模型的正确性)，这一点使得形式化需求验证技术和一般的形式化方法得以区别开来。

形式化需求验证的意义在于：如果方法被正确使用的话，对于特定的语义是有充分定义的。

需求工程的阶段
综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：

1. 需求获取

通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

2. 需求建模

为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

3. 形成需求规格

生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

4. 需求验证

以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性；

5. 需求管理

支持系统的需求演进，如需求变化和可跟踪性问题。

需求工程的内容

• 需求获取阶段

需求获取首先需要的是技术的支持，其次，在需求获取工作中主要涉及了3个至关重要的因素：应搜集什么信息；从什么来源中搜集信息；用什么机制或技术搜集信息。

再次，需求获取的开始，代表着软件项目正式开始实施，正所谓万事开头难。综合上述3个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。

在工作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通，挖掘系统最终用户的真正需求，把握需求的方向。在需求获取调研会中首先对需求获取方法作了验证。现行的需求获取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。各种需求获取方法各有利弊。

• 需求分析阶段

需求分析与需求获取是密切相关的，需求获取是需求分析的基础，需求分析是需求获取的直接表现，两者相互促进，相互制约。

需求分析与需求获取的不同主要在于需求分析是在已经了解承建方的实际的客观的较全面的业务及相关信息的基础上，结合软、硬件实现方案，并做出初步的系统原型给承建方做演示。承建方则通过原型演示来体验业务流程的合理化、准确性、易用性。同时，用户还要通过原型演示及时地发现并提出其中存在的问题和改进意见和方法。

• 文档编写阶段

需求开发的最终成果是，在对所要开发的产品达成共识后，所编写的具体的文档。需求文档是在需求获取和需求分析两个阶段任务结束时生成的，所以文档要包含所有需求。

在此阶段先要从软件工程和文档管理的角度出发依据相关的标准审核需求文档内容，确定需求文档内容是否完整。对需求文档中存留问题进行修改的工作。

• 需求确认阶段

需求确认主要是针对《需求规格说明书》的评审，保证需求符合优秀需求成熟的特征，并且符合好的需求规格说明的特征。

在需求确认阶段需要保证以下几点：

① 软件需求规格说明正确描述了预期的满足各方涉众需求的系统能力和特征；

② 从系统需求、业务规则或其他来源中正确的推导出软件需求；

③ 需求是完整的、高质量的；

④ 需求的表示在所有地方都是一致的；

⑤ 需求为继续进行产品设计和构造提供充分的基础。

• 需求跟踪阶段

需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据需求文档进行开发，建立与维护“需求——设计——编程——测试”之间的一致性，确保所有工作成果符合用户需求。

需求跟踪是一项需要进行大量手工劳动的任务，在系统开发和维护的过程中一定要随时对跟踪联系链信息进行更新。需求跟踪能力的好坏会直接影响产品质量，降低维护成本，容易实现复用，同时，需求跟踪还需要建设方的大力支持。

• 需求复用阶段

在软件项目实施过程中，许多不同项目间存在着许多相似的需求，尤其是类型相同的项目在不同的用户群众的实施中，需求的相似性就更加明显、更加普遍了。

有了需求复用，建设方就能快速的形成一个需求的原型，这样，后期的需求工作只需要在此原型的基础上进行修改、扩充和完善即可，大大提高了需求分析的工作进度。所以，对于需求的复用就需要加以重视。

对于需求复用，首要责任就是要提取可复用的需求，对需求复用的理解和扩充。其次就是要保证需求复用不存在冲突。

• 变更控制阶段

需求变更在软件项目开发中是不可避免的。无休止的需求变更只会造成各种资源无休止的浪费，但是其中也不乏有许多是必要的、合理的需求变更。

对于需求变更，首先是要尽量及早的发现，以避免更大的损失。其次，是要采取相应的、合理的变更管理制度和流程，这样同样可以降低需求变更带来的风险。

• 版本控制阶段

版本控制是管理需求规格说明和其他项目文档必不可少的一个方面，也是需求变更文档化管理的最有效办法。可以详细记录发生需求变更的需求文档版本的版本，发生变更的原因，变更发生的控制记录，并对变更后的需求文档进行唯一版本号的标识。使得每个成员都能及时访问最新版本的需求文档。

实施版本控制的基础是需求基线，所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。需求基线的确定可以保证项目的涉众各方可以对发布的产品中希望具有的功能和属性有一个一致的理解。

作答要求

根据相关知识，按照要求完成右侧选择题任务。作答完毕，通过点击“测评”，可以验证答案的正确性。

参考资料

《CMMI 3级软件过程改进方法与规范》

答案

第3关：需求变更

任务描述

本关任务：根据所学有关需求变更的知识，完成相关的选择题。

相关知识

为了完成本关任务，你需要掌握：1.需求变更的原因，2.控制需求变更的流程

需求变更的原因
需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在 IT 项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。

虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因：

1. 范围没有圈定就开始细化

细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。

当细化到一定程度后并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。如原来是手工添人的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。

2. 没有指定需求的基线

需求的基线是指是否容许需求变更的分界线。随着项目的进展，需求的基线也在变化。

是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少），其过程如下：变更请求 → 比较基线 → 变更实现。

3. 没有良好的软件结构适应变化

组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。但适应变化必须遵循一些原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。

如果业务逻辑封装好了则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户满意度。

如何控制需求变更
按照现代项目管理的概念，一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。

为了将项目变更的影响降到最小，就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生变化等。进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。

下面是在不同阶段中对需求变更的控制方法：

1. 项目启动阶段的变更预防

对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。

对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子就越少。如果需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候千万不能手软，这并非要可以赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。

相对于需求来讲，什么 WBS 、风险管理、计划进度都是次要的，只要需求做好了就会一帆风顺。

2. 项目实施阶段的需求变更

成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。

项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点：

1. 需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条，需求变，软件开发的投入也要变。

2. 需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

3. 小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。

4. 精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。

5. 注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来时项目的各方各得其所。

6. 项目收尾阶段的总结

能力的提高往往不是从成功的经验中来，而是从失败的教训中来。许多项目经理不注重经验教训总结和积累。即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。

事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。

需求变更的处理流程
因为现实世界的软件系统可能有不同的严格程度和复杂性，所以事先预言所有的相关需求是不可能的。

系统原计划的操作环境会改变，用户的需求会改变，甚至系统的角色也有可能改变。实现和测试系统的行为可能导致对正解决的问题产生新的理解和洞察，这种新的认识就有可能导致需求变更。

需求变更既然不可避免，那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分为以下步骤：提出变更 → 变更评估 → 实施变更。

• 提出变更

CMM 提出“分配需求的变更被复审，并加入到软件项目中来”，其关键是在需求发生变更时，没有必要马上把这些变更付诸于软件开发工作之中。实际上，坚持把需求变更付诸开发努力，企业就会形成一种混乱且不稳定的氛围，进而严重破坏项目的控制和管理。

• 变更评估

需求管理关键过程试图通过把分配需求的变更囤积到可管理的组中，等到开发工作允许的时候再引入相应的方法，避免产生这种混乱的氛围。结果，需求管理创建了一个隔绝开发工作与所有真实的、潜在无序的、来自于客户的变更。这个缓冲器允许真实的变更被注意、记录、追踪，同时开发工作又不会因此而被扰乱。

开发项目应该周期性地暂停来吸收最新的需求变更积累。此时，所有的计划、设计、行为都根据刚刚吸收的需求变更的影响进行更新。

• 实施变更

需求变更的控制当然与项目管理范畴之外的纯技术因素息息相关，比如面向对象的分析、面向对象的设计、面向对象的编码方式等等。但所有技术的发展趋势都是一样，那就是为了使变更管理变得更容易。

因此，不论在项目变更控制中采取什么方法、策略，对于项目本身的变化一定要时时洞悉，处处留意，只有这样才能从真正意义上对项目进行很好的变更控制。

作答要求

根据相关知识，按照要求完成右侧选择题任务。作答完毕，通过点击“测评”，可以验证答案的正确性。

参考资料

如何做好需求变更

答案

第4关：需求规格说明

任务描述

本关任务：根据所学有关需求规格说明的知识，完成知相关的选择题。

相关知识

为了完成本关任务，你需要掌握：1.需求规格说明的作用，2.软件需求规格说明书的内容和标准。

软件需求说明
软件需求说明书，又称为软件规格说明书，是分析员在需求分析阶段需要完成的文档，是软件需求分析的最终结果。

它的作用主要是：作为软件人员与用户之间事实上的技术合同说明；作为软件人员下一步进行设计和编码的基础；作为测试和验收的依据。

SRS 必须用统一格式的文档进行描述，为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，也可以根据项目特点和软件开发小组的特点对标准进行适当的改动，形成自己的模板。软件需求说明主要包括引言、任务概述、需求规定、运行环境规定和附录等内容。

软件需求说明书应该完整、一致、精确、无二义性，同时又要简明、易懂、易修改。由于软件需求说明书最终要得到开发者和用户双方的认可，所以用户要能看得懂，并且还能发现和指出其中的错误，这对于保证软件系统的质量有很大的作用。这就要求需求说明书尽可能少用或不用计算机领域的概念和术语。

需求说明书的功能
需求说明书是由开发人员经需求分析后形成的软件文档，是对需求分析工作的全面总结。

其作用有以下几点：

1. 便于用户、分析人员和软件设计人员进行理解和交流；
   用户通过需求规格说明书在分析阶段即可初步判定目标软件能否满足其原来的期望，设计人员则将需求规格说明书作为软件设计的基本出发点。
2. 支持目标软件系统的确认；
   在软件的测试阶段，根据需求说明书中确定的可测试标准设计测试用例，确认软件是否满足需求说明书中规定的功能和性能等。
3. 控制系统进化过程。 在需求分析完成之后，如果用户追加需求，那么需求说明书将用于确定是否为新需求。

需求说明书的内容
软件需求说明书的内容应包含如下几部分内容：

• 概述

  • 说明开发软件系统的目的、意义和背景

• 说明用户的特点、约束

• 需求说明

• 功能说明，逐项列出各功能需求的序号、名称和简要说明

• 性能说明，说明处理速度、响应时间、精度等

• 输入输出要求、数据管理要求

• 故障处理要求

• 数据描述

数据流图·数据字典

接口说明

运行环境规定

说明软件运行所需的硬件设备

说明软件运行所需的系统软件和软件工具

限制

说明软件开发在成本、进度、设计和实现方面的限制。
需求说明书的衡量标准
完整性
每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。不遗漏任何必要的需求信息，即目标软件的所有功能、性能、设计约束，以及所有的可能情况下的预期行为，均完整地体现在需求说明书中。

正确性
每一项需求都必须准确地陈述其要开发的功能。需求说明书中的功能、性能等描述与用户对软件的期望相一致。

可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性
对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。另外，需求说明书的各部分之间不能相互矛盾。

可验证性
需求说明书中的任意一项需求，都存在技术和经济上可行的手段进行验证和确认。

可修改性
需求说明书的格式和组织方式应该保证能够比较容易地增、删和修改，并使修改后的需求说明书能够软较好地保持其他各项属性。

可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，使每项需求与用户的原始需求连起来，并为后续开发和其他文档引用这些需求项提供便利。这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。

作答要求

根据相关知识，按照要求完成右侧选择题任务。作答完毕，通过点击“测评”，可以验证答案的正确性。

参考资料

如何写好需求规格说明书

答案

第5关：需求管理

任务描述

本关任务：根据所学有关需求管理的知识，完成相关的选择题。

相关知识

为了完成本关任务，你需要掌握：1.需求管理的基本概念，2.需求管理的流程和任务。

需求管理
需求管理（ Requirement management ）是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。

一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。

不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。

需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。

需求管理能够确证：

• 我们确知客户的需求是什么（质量）；
• 满足客户需求的最佳解决办法（统一性）。

著名学者 Crosby 对于质量的定义是"同需求保持统一"。从这个意义上说，需求管理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。需求管理本就是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。

需求管理流程
需求管理可细分为如下几个流程：

• 问题分析

问题分析可以通过了解问题及涉众的最初需要，并提出高层解决方案来实现。它是为找出"隐藏在问题之后的问题"而进行的推理和分析。

问题分析期间，将对"什么是面临实际问题"和"谁是涉众"等问题达成一致。而且，您还要从业务角度界定解决方案，以及制约该解决方案的因素。您应该已经对项目进行过商业理由分析，这将便于您更好地预计能从构建中的项目中得到多少投资回报。

• 理解涉众

需求来自各个方面。比如来自客户，合作伙伴，最终用户或是某领域的专家。您需要掌握如何准确判断需求应来源于哪方面，如何接近这些来源并从中获取信息。

提供这些信息主要出处的个人在本项目中称为涉众。如果您正在开发一个在您公司内部使用的信息系统，那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。通常讨论将在业务模型这一级上展开，而不是在系统这一级上展开。如果正在开发一个要在市场上出售的产品，那么您可以充分调动营销人员，以便更好地了解该市场中用户的需要。

获取需要的活动可使用这样一些技巧：访谈，集体讨论，概念原型设计，问卷调查和竞争性分析等。获取结果可能是一份图文并茂的请求或需要列表，并按相互之间的优先级列出。

• 定义系统

定义系统指的是解释涉众需求，并整理为对要构建系统的意义明确的说明。

在系统定义的初期要确定以下内容：需求构成，文档格式，语言形式，需求的具体程度（需求量及详细程度），需求的优先级和预计工作量（不同人在不同的实践中通常对这两项内容的看法大不相同），技术和管理风险以及最初规模。

系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。

• 项目规模

为使项目高效运作，应仔细根据所有涉众的需求确定优先级，并对项目规模进行管理。有的开发人员仅仅重视所谓的"复活节彩蛋"（即开发人员感兴趣或觉得有挑战性的特性），而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面，这已使太多的项目蒙受损失。

为确保尽早解决或降低项目中的风险，应以递增的方式开发系统。要慎重选择需求，以确保每次增加都能缓解项目中的已知风险。要达到目的，您需要和项目的涉众协商每次迭代的范围。通常，这要求具备管理项目各个阶段的期望结果的良好技能。

除了控制开发过程本身，您还需控制需求的来源，并控制项目可交付工件的外观。改进系统定义系统的详细定义应能让涉众理解，同意并认可。它不仅需要具备所有功能，而且应符合法律或法规上的要求，符合可用性，可靠性，性能，可支持性和可维护性。感觉构建过程复杂的系统就应该有复杂的定义，这是一种常见的错误看法。这会给解释项目和系统的目的造成困难。人们可能印象深刻，但他们会因不甚理解而无法给出建议。应该致力于了解您制作的系统说明文档的读者。您可能常会发现需要为不同的读者准备不同的说明文档。

我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法，它常与简单的可视化原型结合使用。用例有助于为需求提供一个环境，利用它可生动地说明系统使用的方式。

系统详细定义的另一个构件是说明系统采用的测试方式。测试计划及要执行测试的定义将会说明要核实哪些系统功能。

• 需求变更

定义需求时无论怎样谨慎小心，也总会有可变因素。变更的需求之所以变得难以管理，不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性，而且也因为对某个需求的变更很可能影响到其他需求。

应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线，确定需要追踪的重要依赖关系，建立相关项之间的可追踪性，以及变更控制等活动。

需求管理的任务
可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处于变化之中的。

需求管理需要完成的任务包括：

• 明确需求并达成共识；
• 建立关联；
• 根据不同需求设计相应解决办法；
• 进行系统优化；
• 提出设计方案；
• 监控和解决可能出现的问题以及需要做出的改变；
• 控制不同开发任务的开展；
• 对最终产品做出评测；
• 监控可能出现的重复开发；
• 提出项目实施时间表；
• 确定最终用户界面。

有时候我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。

“需求之需求”正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。

下面介绍前述内容没有涉及到的几点：

• 需求共识

首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的"用户"泛指在实际应用环境中每一位可能使用最终产品的人。如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。

需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。

我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。

• 系统优化

任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。

面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。

• 方案设计

明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。

• 方案修改

方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。如果我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判断。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。

• 任务划分

一个大的开发项目可能涉及20−30组不同的开发队伍，人员包括技术工程师、软件工程师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。

主持一个大项目的开发并不是件容易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。

不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。

• 产品测试

需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。

这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。

• 重复开发

对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。

方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。

作答要求

根据相关知识，按照要求完成右侧选择题任务。作答完毕，通过点击“测评”，可以验证答案的正确性。

参考资料

产品经理如何进行需求管理

答案