需求开发与管理过程.docx
《需求开发与管理过程.docx》由会员分享，可在线阅读，更多相关《需求开发与管理过程.docx（20页珍藏版）》请在冰点文库上搜索。
需求开发与管理过程
密级：
内部公开
文档编号：
NTT_RD_XQKFYGLGC
版本号：
V1.0
需求开发与管理过程
惠州市新中新电子技术开发有限公司
编制：
生效日期：
2008年9月28日
审核：
批准：
---------------------------------------------------------------------
惠州市新中新电子技术开发有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
文件更改摘要：
日期
版本号
修订说明
修订人
审核人
批准人
2008-01-17
V0.1
创建
2008-03-25
V1.0
正式版
目 录
1.目的/方针4
2.范围4
3.术语4
4.角色与职责4
5.入口准则4
6.输入4
7.流程图4
8.主要活动5
8.1.需求获取5
8.1.1.明确需要获取的信息（What）5
8.1.2.明确所需要获取信息的来源与渠道（Where）5
8.1.3.需求获取技术（How）6
8.1.4.需求获取原始资料的记录7
8.1.5.编写用户需求说明书7
8.2.需求分析8
8.2.1.结构化分析方法8
8.2.2.基于用例的分析方法9
8.3.需求定义9
8.3.1.编写《软件需求规格说明书》9
8.3.2.标识需求10
8.3.3.定义需求的优先级10
8.4.需求确认10
8.4.1.需求评审10
8.4.2.需求承诺11
8.4.3.建立需求基线11
8.5.需求变更11
8.5.1.需求变更申请与评估12
8.5.2.需求变更的实施12
8.6.需求跟踪12
8.6.1.建立需求跟踪矩阵12
8.6.2.需求跟踪矩阵维护与使用13
9.输出13
10.出口准则13
11.引用文档13
12.使用模板13
1.目的/方针
通过定义需求开发和管理过程，规范公司软件开发项目的需求开发和管理活动，提高需求质量，从而提高软件生产率，降低开发成本，改进软件质量。
应调查用户的需求，通过需求分析工作将用户需求转化为软件需求，同时评审需求的正确性，获得需求的承诺；应控制需求的变更，并确保项目工作产品与需求的一致性。
2.范围
适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。
3.术语
术语或缩略语
解释
软件需求
在IEEE软件工程标准词汇表（1997年）中定义软件需求为：
（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面
（1）或
（2）所描述的条件或权能的文档说明。
通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
用例
是在系统中执行的一系列动作，这些动作将生成对特定参与者可见的价值结果，一个用例定义了一组用例实例
需求分析
是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。
需求分析的关键就是对问题域的研究与理解。
为了便于理解问题域，现代软件工程方法所推荐的做法就是对问题域进行抽象，将其分解为若干基本元素，然后对元素之间的关系进行建模。
4.角色与职责
角色
职责
项目经理
负责组织软件开发项目的需求分析和管理工作
需求分析师
负责需求的获取，分析以及定义
评审管理部门
接受需求评审申请，组织进行需求的评审
CM工程师
负责维护需求跟踪矩阵
5.入口准则
●项目立项
6.输入
●项目立项公告
7.流程图
图1：
需求开发与管理过程活动示意图
8.主要活动
软件需求工程包括了需求开发和需求管理两个部分，需求开发的目的是通过调查与分析，获取用户需求并定义软件需求。
需求开发的主要活动包括：
需求获取，需求分析和需求定义。
需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求管理的主要活动包括：
需求确认，需求变更和需求跟踪控制。
需求获取前应该制定《需求开发计划》。
8.1.需求获取
需求获取的目的是通过各种途径获取用户的需求信息，由于在实际工作中，大部分客户是无法完整地讲述其需求，因此需求获取是一件看似简单，做起来很难的一件事情，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。
8.1.1.明确需要获取的信息（What）
需求分析师应在需求获取前明确需要获取的需求信息，以确保在实施需求获取时有的放矢。
通常需求获取要获取的信息包括三大类：
●与问题域相关的背景信息（如业务资料，组织结构图，业务处理流程等）；
●与要求解决的问题直接相关的信息；
●用户对系统的特别期望与施加的任何约束信息。
●用户对接口的需求，包括系统内部接口，软硬件接口、软件与其他系统，用户界面。
8.1.2.明确所需获取信息的来源与渠道（Where）
需求分析师在明确了所需要获取的信息之后，应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。
需求信息的来源通常包括：
●来自客户的需求
a）旧系统的用户或客户对系统安装、使用、维护、管理等方面的需求
b）系统的潜在用户或客户对系统的需求
●竞争对手的产品优势与不足
●国家政策、业务规则以及相关行业标准
●实施产品设计所需满足的需求
●执行测试验证工作所需满足的需求
●实施系统安装、维护所需满足的需求
获取需求信息的渠道包括：
●用户或客户
●公司研发管理部门
●公司技术管理部门
●项目实施部门
●营销管理部门
●旧有系统的研发项目组
●来自项目组内
8.1.3.获取需求（How）
在明确须获取什么需求、需求的来源与获取渠道后，项目经理应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。
需求获取技术包括但不限于：
1）用户访谈
使用《用户访谈表》记录访谈内容，使用《与背景无关的一般性访谈记录表》获取一般性访谈内容。
用户访谈的形式包括结构化和非结构化两种。
结构化是指事先准备好一系列问题，有针对性地进行；非结构化是只列出一个粗略的想法，根据访谈的具体情况进行发挥。
有效的访谈需要灵活的结合这两种方法。
用户访谈具有很好的灵活性，有较广的应用范围，但实际操作时存在许多困难，例如客户经常很忙，难以获得充足的访谈时间；客户访谈需要需求分析师有很强的沟通能力，同时也要求需求分析师有足够的相关业务领域知识。
2）用户调查
用户调查是通过精心设计提问问题形成调查问卷，然后下发到相关人员手中，让他们填写答案，来获取用户需求。
用户调查的方法最大的缺点是缺乏灵活性，由于缺乏面多面的交流，所获取的信息量也比较有限。
因此在实际工作中，我们建议可以先采用用户调查的方式获取一定量的信息，然后有针对性地开展用户访谈。
3）现场观摩用户的工作流程，观察用户的实际操作
俗话说，“百闻不如一见”，对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。
4）从行业标准、规则中提取需求
如果用户要求所开发的软件产品必须满足一定的行业标准和业务规则，需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档，并与相关领域的业务专家进行业务交流来了解客户的需求。
这种方法要求需求分析师有一定的行业从业经验，能够了解行业的发展动向，这对从技术出生的需求分析师来说是一个巨大的考验。
5）文档考古
对于一些数据流比较复杂的、工作表单较多的项目，有时是难以通过说或者观察来了解需求细节的。
这个时候就可以通过对历史存在的一些文档进行研究，考古一词非常形象地说明了其主要的工作重心是通过已经填写完毕的、也就是带有数据的文件、表单、报告，获得所需的信息。
6）需求讨论会
这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。
它通过联合各个关键客户代表，分析人员，开发人员，通过有组织的会议来讨论需求。
在会议之前，应该将与讨论主体相关的材料提前分发给所有将要参加会议的人。
在会议开始之后，先针对材料所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，并在此基础上对新的解决方案进行构思，在此过程中将所有的想法、问题和不足记录下来，形成一个要点清单，作为后续需求分析的依据。
7）原型法
原型（prototype）即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。
同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。
原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。
原型的基本步骤：
1）根据客户原始需求、项目建议书、市场需求或合同要求，确定系统要做什么，即系统的边界、主要业务或功能、系统的接口；
2）根据这些需求，形成系统原型。
对于所形成的原型的基本要求包括：
●体现主要的功能；
●提供基本的界面风格；
●展示比较模糊的部分，以便于确认或进一步明确，防患于未然。
●原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。
3）进行原型评价并获取系统的需求，原型评价可以从几个方面进行：
●在公司内部演示、评审，进一步获取内部信息，并求得共识
●与用户进行演示与交流，挖掘用户需求，从而确定软件的目标和需求
4）根据原型评价的意见修改原型，直到求得共识
原型法的优点是：
１）鼓励业务管理者的积极参与；２）有助于解决业务管理者之间的差异；３）能给业务管理者一个对最终系统的直观感受；４）周期短；５）成本低；６）用户较满意。
但原型法也有缺点，主要为：
１）导致人们认为最终系统将很快产生；２）对系统操作权限的说明较弱；３）不适合于开发大系统；４）开发过程管理困难。
8.1.4.需求获取资料的保管
根据所采用的需求获取技术，在需求获取过程中将产生不同的记录和原始资料，项目组应将这些记录纳入开发库进行配置管理。
需求获取的记录与资料包括但不限于：
●用户编写的原始需求文档；
●用户填写的需求调查表；
●用户访谈的访谈纪要；
●需求研讨会的会议纪要；
●相关的政策法规文件，业务规则文件以及行业标准文件；
●需求原型。
8.1.5.编写用户需求规格说明书
在需求获取结束后，需求分析师应根据需求获取得到的记录与资料，整理编写《用户需求规格说明书》，《用户需求规格说明书》主要采用自然语言（和应用域术语）来表达用户需求，其主要内容应该包括但不局限于：
●产品介绍，描述产品的用途和开发背景；
●产品潜在的最终用户群体及其特征；
●产品应该遵循的业务规范和标准；
●产品的功能性需求；
●产品的非功能性需求。
对于工作量小于5人月的小型项目、使用了原型法获取需求的项目、没有明确的目标客户的项目、直接引用用户提供的需求说明书的项目，可以不用编制《用户需求规格说明书》。
8.2.需求分析
在完成需求获取所得到的记录与资料的分析与整理后，项目经理应组织软件的需求分析工作，建立各需求元素之间的关系，明确分配给软件的需求、需求的分类、需求的优先级等。
需求分析的方法种类繁多，但常见的需求分析方法主要是结构化分析方法和基于用例的需求分析方法。
8.2.1.结构化分析方法
结构化分析方法的主要特点是“自顶向下、逐层分解”，它把系统看作一个过程的集合体，利用图形等半形式化的描述方式表达需求，对问题进行分析，描述工具有：
●数据流图（DataFlowDiagram，DFD）：
数据流图是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即输入、输出、处理过程、数据存储。
●数据字典（DataDictionary，DD）：
数据字典技术是一种有效表达数据格式的手段，它是对所有与系统相关的数据元素的一个有组织的列表和精确、严格的定义，从而使用户和系统分析员对于输入、输出、存储成分和中间计算机有共同的理解。
●结构化语言：
结构化语言是结构化编程语言与自然语言的有机结合，可以采用顺序结构，分支机构、循环结构等机制，来说明加工的处理流程。
●判定表和判定树：
判定表是一种处理逻辑的表格表示方法，其中包括决策变量，决策变量值、参与者或公式；而判定树则使用像树枝一样的线条对过程逻辑进行图表化的描述。
判定表和判定树用来描述复杂决策逻辑，要远远优于使用结构化语言。
●实体-关系图（EntityRelationshipDiagram，E-R图）：
E-R图可以用来描述数据的存储需求，包括数据实体，数据实体的属性以及它们之间的关系等。
结构化分析方法从总体上看是一种强烈依赖数据流图的自上而下的建模方法，它不仅是需求分析计划，也是完成需求规格化的有效技术手段，使用结构化分析方法时可遵循下列活动：
1）建立系统的物理模型
首先，画出系统得数据流图，说明系统的输入、输出数据流，说明系统的数据流情况，以及经历了哪些处理过程。
在这个数据流图中，可以包括一些非计算机系统中数据流及处理过程的名称，如部门名、岗位名、报表名等。
这个过成可以帮助分析人员有效地理解业务环境。
2）建立系统的逻辑模型
在物理模型建立之后，接下来的工作就是画出相对于真实系统的等价逻辑数据流图。
将所有自然数据流图转换为等价的逻辑流。
3）划清人机界限
最后，确定在系统逻辑模型中，哪些部分将采用自动化完成，哪些部分仍然保留手工操作，从而清晰的划清系统的范围。
8.2.2.基于用例的分析方法
从定义中我们得知用例是由一组用例实例组成的，用例实例也称为“使用场景”，是用户使用系统的一个实际的、特定场景。
用例是应用程序开发中的一个关键技术，主要用来捕获系统的高层次（HighLevel）用户功能性需求。
用例分析技术是一种需求合成技术，它利用现有的需求获取技术从客户、原有系统、文档中找到需求，记录下来，然后从这些零散的需求、特性中进行整理、提炼，从而建立用例模型。
使用用例分析方法时可遵循以下步骤：
1）识别系统参与者，确定谁会直接使用该系统。
参与者是同系统交互的所有事物，该角色不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟。
2）合并需求获得用例。
找到所有参与者之后，根据需求获取所得到的用户需求，定义每个参与者希望系统做什么，参与者希望系统作的每件事将成为一个用例。
3）绘制用例图。
将所识别的参与者以及所定义的用例通过用例图的形式整理出来，以获得例模型的框架。
4）细化用例描述。
用例描述包括以下几个部分：
●用例名称；
●用例参与者；
●用自然语言对用例进行简要的描述；
●描述参与者何时使用该用例，即用例的触发条件；
●描述在一般情况下，参与者使用该用例时会发生什么事情，即用例的基本过程；
●在基本过程的基础上，考虑一些可变情况，把他们创建为扩展用例；
8.3.需求定义
需求定义的目的是根据需求获取和需求分析的结果，进一步定义软件需求，产生《软件需求规格说明书》。
8.3.1.标识需求
为了确保需求的易跟踪、易修改，需求分析师应通过需求编号的方式唯一标识每一个软件需求，明确需求的跟踪粒度，并体现于软件需求规格说明书
8.3.2.定义需求的优先级
需求分析师应确定每个需求的优先级并写入软件需求规格说明书，需求的优先级的评价标准如下：
级别定义
判断标准
采取的措施
高
满足以下任意一条时：
1）需求实现的紧急程度为特急或紧急
2）国家或行业法律法规、标准要求的，客户明确要求的,满足正常业务必须的。
对于这些需求在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现。
通常这类需求在当前版本必须实现。
中
满足以下任意一条时：
1）客户隐含要求，对正常业务影响程度不大
2）需求实现的紧急程度为中
3）支持必要的系统操作，实现这些需求将增强产品的性能，是产品最终所要求的。
这些需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，如果有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美。
低
满足以下任意一条时：
1）功能或质量上的附加功能；
2）实现这些需求会使产品更完美，若不实现也不影响产品的功能与性能，属于锦上添花；
3）需求实现的紧急程度为低；
实现或不实现均可；可以在项目组有较足够的时间时考虑这些需求的实现
优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。
一个实现这种权衡的方法是：
当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。
8.3.3.编写《软件需求规格说明书》
需求分析师在需求分析过程中根据分析步骤逐步编制形成《软件需求规格说明书》（其中《产品功能列表》可作为附件提交）。
编写需求规格说明书应遵循以下规则：
●相关的需求都得到了识别与描述，以确保需求的完整性；
●各个需求之间不冲突，算法之间不相互矛盾，以确保需求的一致性；
●正确描述系统需求，引用的资料有正规的出处，以确保需求的正确性；
●定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性；
●使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于追溯；
●确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；
●考虑了各个层次的需求，确定了需求的优先级，以确保需求的可行性。
8.4.需求确认
需求确认是指项目组和客户（或客户代表）共同对《用户需求规格说明书》或《软件需求规格说明书》进行评审，双方对需求达成共识后做出承诺。
需求确认包含两个重要工作：
“需求评审”和“需求承诺”。
8.4.1.需求评审
应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。
需求评审的方式分为“技术评审会议”与“组内评审”两种。
项目组根据需求分析的进展情况，采用“组内评审”的方式分阶段对需求分析的阶段成果进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。
组内评审要求：
●评审组长：
项目经理；
●评审组成员：
需求分析师、系统分析师、测试工程师，适当邀请组外专家参与；
●输入：
《软件需求规格说明书》初稿，《用户需求规格说明书》
●输出：
会议纪要
●检查单：
需求评审检查单
当需要召开技术评审会议时，由项目组向评审管理部门提出需求技术评审申请，由评审管理部门组织按“技术评审会议”的方式实施需求评审。
技术评审会议要求如下：
●评审组织部门：
评审管理部门
●评审组成员：
a）项目组代表
b）测试组代表
c）公司的技术专家与业务专家
d）客户服务部门代表
e）客户或客户代表
f）系统关联组代表
g）QA工程师
●输入：
软件需求规格说明书以及相关文档
●输出：
评审报告
●检查单：
需求评审检查单
关于“组内评审”、“技术评审会议”的要求详见《评审规程》。
8.4.2.需求承诺
项目经理将评审通过的《软件需求规格说明书》提交给客户（或客户代表）、系统关联项目组进行确认，确认的方式可以是以下方式之一：
●直接签字：
由承诺方在评审报告上直接签字或盖章确认
●邮件方式：
由项目经理将《软件需求规格说明书》与评审报告通过邮件发送给接收方，并明确确认通过的准则（如：
如果在一周内未予以回复则默认为确认通过）；
●发送会议纪要函：
如果承诺方参加了评审会议并在会上达成了共识，则可以编制会议纪要在纪要中描述参加评审的人员、评审的结论等，并通过纪要函的方式发送给承诺方。
8.4.3.建立需求基线
项目的软件需求规格说明书经过评审与确认后，应根据《配置管理过程》的要求建立需求基线。
8.5.需求变更
对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免的。
这主要有以下几种原因：
1.软件所应用的外部环境发生变化；
2.随着用户对软件的熟悉和应用，又提出新的需求；
3.项目组进行需求分析时未能彻底分析用户的需求，或分析错误；
4.用户在开始时不能很全面的知道所需软件的功能。
8.5.1.需求变更申请
项目组外的需求变更由变更申请人通过填写《需求变更申请单》向项目组提出进行；项目组内部的需求变更通过《软件变更申请单》提出。
8.5.2.需求变更的实施
项目组根据《变更管理规程》中的要求实施变更。
在变更完成后，若需要发布新的需求基线，项目组应根据《配置管理过程》中“基线发布”的要求重新建立需求基线，并通知相关的人员。
8.6.需求跟踪
对一个软件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都被实现，且项目的其它工作产品与需求保持一致。
因此，一个比较好的方法就是建立一种需求双向跟踪机制。
双向跟踪即：
●正向跟踪：
当发生需求变更时，通过从需求向后追溯到下游相关工作产品，可分析出这些关联项是否需要变更，从而达到追溯的目的；
●逆向跟踪。
通过从下游工作产品回溯到需求，可分析需求是否得到满足，从而达到回溯的目的。
进行需求双向跟踪的一个简单的方法是建立一个映射，从需求到设计，从设计到编码，以及从编码到测试用例，把每个需求都映射到对应的位置。
这个映射可以用需求跟踪矩阵来实现。
8.6.1.建立需求跟踪矩阵
当《软件需求规格说明书》通过评审之后，项目经理应组织根据确定的需求跟踪的粒度编制《需求跟踪矩阵》。
项目经理指定人员对需求跟踪矩阵进行个人复查，确保跟踪粒度合理、跟踪项适用。
8.6.2.需求跟踪矩阵的维护与使用
随着软件设计、编码、以及测试开发的不断推进，项目经理应指定专人在项目的各个阶段产品形成时，将相关的信息填入需求跟踪矩阵，建立阶段工作产品与需求的对应关系，并由项目经理指定人员对其完整、正确、一致性进行确认。
对于已纳入需求跟踪矩阵的相关工作产品产生的变更，则由CM工程师在每次变更完成后根据变更修改需求跟踪矩阵的对应关系，在每个里程碑时由项目经理指定人员负责对跟踪矩阵的完整、正确、一致性进行确认。
在项目实施过程中，项目组可以利用需求跟踪矩阵实施相关的控制，如：
●利用需求跟踪矩阵，审核所有定
升级会员 