软件需求与需求管理

软件需求与需求管理

内容

软件发展的三个时期软件生存期过程软件开发软件需求需求工程需求变更及其控制CMM2级需求管理关键过程域

一、软件发展的三个时期

表一

时期年代阶段涉及注重主要使用语言标准模型初期50-60程序设计点编程技巧ALGOLFORTRANCOBOLBASIC

中期70-80软件开发线结构化模块化PASCALGB8566软件开发规范瀑布原型现代90-软件过程面过程能力C,C++JAVAVB、VCISO/IEC12207软件生存期过程ISO9000螺旋CMM二、软件生存期过程

ISO/IEC12207信息技术－软件生存期过程

基本过程支持过程组织过程软件生存期过程图1-1

供应过程开发过程运行过程基本过程获取过程维护过程⑴⑵⑶⑷⑸图1-2质量保证过程验证过程确认过程支持过程配置管理过程联合评审过程审核过程文档编制过程问题解决过程图1-3⑹⑺⑻⑼⑽⑾⑿⒀基础设施过程改进过程培训过程组织过程管理过程图1-4⒃

⒂

⒁⒄

三、软件开发

1.计算机系统

人员硬件软件数据传输机构执行机构（剧作家、导演）（舞台剧本演员道具）图2计算机系统2.软件开发过程：活动－任务

⑴系统需求分析⑵系统结构设计⑶软件需求分析 建立软件需求 评价软件需求 联合评审 ⑷软件结构设计 ⑸软件详细设计 ⑹软件编码和测试 ⑺软件集成⑻软件鉴定测试⑼系统集成⑽系统鉴定测试⑾软件安装⑿软件验收支持

软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题3．当前软件开发项目的特点

――规模大：

LOC 1万几十万

HP 激光打印驱动软件4万110万

――复杂

――质量要求高 满足客户需求和期望 客户满意度统计――开发和维护成本 缺陷后期发现返工成本

――延误交付期四、软件需求

1. 系统需求分析

软件系统需求(1)系统需求分配软件工程组硬件系统需求(2)其它成分系统需求(n)软件需求客户最终用户系统工程组图3系统需求分配2.软件需求

⑴

定义（IEEE-STD-610）用户为解决某个问题、或为实现某一目标，要求软件必须满足的条件或能力。⑵软件需求的三个层次业务需求

用户需求

功能需求和非功能需求

非功能需求过程需求：交付需求，实现需求，遵循的标准性能需求：速度，容量，可靠性外部需求：互操作性，伦理性，机密性，安全性，使用要求

业务需求业务说明使用实例用户需求功能需求约束条件非功能需求软件需求规格说明图4软件需求的层次⑶质量功能展开（QFD－QualityFunctionDevelopment）

客户需求

常规需求：客户明确提出期望需求：并未明确提出的潜在需求，不言而喻的需求兴奋需求：客户未想到，若实现客户感到意外⑷ 分配需求的实例系统需求ACCS应能使汽车保持在预期车速的2KMH范围内行驶分配给硬件的需求硬件应能使车速在规定的精确度1.5KMH范围内分配给软件的需求软件应能在车速超出预期车速0.5KMH时给硬件加/减速命令软件需求软件应能：读入当前车速值计算当前车速与预期车速之差若差值0.5KMH给出加/减速命令图5汽车限速系统ACCS的需求分配3．CMM2级

关键过程域需求管理（KPARM）中对软件需求的解释：

分配需求（allocatedrequirements）：

分配给软件的系统需求

（1）分配需求包括：――影响和确定软件项目活动的非技术性需求（在合同条款中规定），如：要交付的产品交付日期里程碑――软件的技术需求，如：最终用户、操作人员、支持或集成的功能性能需求设计约束条件编程语言界面需求――用于确认软件产品满足分配需求的验收准则（2）分配需求应当是：以软件来实现是可行的，而且是适合的；已得到清晰而正确的阐述；相互之间是一致的；可以测试的。同时，分配需求应当：被管理和控制（如必要可纳入软件配置管理）是制定软件开发计划SDP的基础是制定软件需求的基础

（3）与分配需求相关的组：软件评估组系统工程组系统测试组软件质量保证组SQA合同管理组文档支持组

五、需求工程

1．需求工程＝需求开发＋需求管理

获取需求分析需求定义需求验证需求需求变更控制需求跟踪需求状态跟踪需求文档版本控制需求开发需求管理需求工程图6需求工程的构成用户/系统市场管理者初始需求变更的需求获取,分析,定义,验证需求控制需求变更需求规格说明项目环境需求开发需求管理图7需求开发与需求管理2．需求开发

（1）获取需求确定目标用户、服务对象明确用户代表用户培训了解实际业务和业务需求（2）分析需求分清功能需求、性能需求、使用需求……必要性可行性（3）定义需求编写软件需求规格说明（SRS）作用要求：完整、正确、可行、无歧意、可验证形式：图、表、文字（4）验证需求联合评审

六、需求变更1、难于完全避免初始需求变更的需求对问题的初始理解对问题的新理解时间图8需求的变更2、需求变更原因分析

单纯的用户因素

市场形势变化

系统因素

工作环境和要求变化

需求开发的缺陷

★

需求分析、定义和评审不充分

★

与用户沟通不畅

3、需求变更对软件开发的影响

⑴

使变更前开发工作和成果失效

⑵

返工成为被迫采取的对策

⑶

工作量及资源投入的增加使开发成本提高

⑷

项目完成时间后延

4、需求变更失控可能导致的后果

⑴

未受控的需求

变更引起需求

和实现不一致

需求文档V1系统实现V1系统实现V2需求变更⑵

受控的需求变更使需求和实现一致

图7未受控及受控的需求变更

需求文档V1需求文档V2系统实现V1系统实现V2需求变更5.降低需求变更风险的策略

⑴与用户充分沟通★与用户共同明确确定的需求的意义

项目开发工作项目开发组织用户*产品后续开发工作的基础*产品维护工作的重要参考*对用户的承诺*关系到项目开发工作的投入、交付期和产品质量*关系到能否如期获得所需的产品*作为合同的附件，关系到双方的权益*是产品验收的依据★向用户说明需求不确切或频繁变更对开发工作的冲击★使用户理解过多变更最终对用户不利

⑵

与用户共同确定需求，作为合同附件，签字生效

⑶

合同中含有对需求变更的条款

⑷

采用原型方法开发，或螺旋模型开发

⑸

项目计划中适当留有余地（时间进度、人力投入、费用等）

⑹

严格实施变更控制

七、需求变更控制要求1．变更控制的策略（1）所有需求变更必须遵循需求变更控制规程实施变更。（2）需求变更提出后是否被接受，应由专门的组织―变更控制委员会（CCB－ChangeControlBoard）审查决定。（3）不得以任何理由删除和修改需求变更的原始文件。（4）应将已接受的需求变更通知到所有相关人员。（5）已接受的需求变更应能追溯到批准的变更请求。（6）对项目的需求赋予状态属性，以利于需求变更的控制。

2．需求变更影响的控制

按CMM2级RMKPA的要求，由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作：识别评价风险分析编制文档制定计划传达给受影响的小组和人员跟踪直至结束3．变更控制的步骤

（1）提出变更请求（2）审理变更请求，进行变更影响评估。评估内容包括：变更所需人力投入变更对原计划安排的影响估计变更引起的成本增加（3）批准变更请求（4）取得用户的认可（5）修订项目计划（6）实施变更（7）验证变更

批准提出变更请求变更影响评估评审评估报告审批用户认可修订项目计划实施变更验证变更结束拒绝修正图10需求变更控制流程八、需求变更控制实施

1．需求变更请求（1）内容申请号变更说明变更类别影响分析变更请求状态变更请求日期

（2）需求变更请求实例（表三）

项目名：XYZ变更申请号11日期：23Feb1998变更说明IS-41分析器对CDMA的支持影响分析对CDMA的配置模块和分析器无影响TDMA码可复用受影响的模块是：――CGAAPP模块，需对IS-41单独进行规范性分析――CDMAPP01模块（a）

TRIS41R01按TRCDMARS41R01复制（b）

使用纯虚拟对TRCDMAR01建立（c）

ActualCallModeManager并重新定义――SILVER06GUIAPP++模块：在资源表中加入IS-41工作量5人日计划时间无需重大变动状态将并入新的CDMA软件包2．需求变更累积影响的跟踪

（1）需求变更累积影响跟踪的意义和作法累积影响变更累积表（2）需求变更累积表实例（表四）

表四

需求变更累积表

需求变更号需求变更时间变更说明工作量状态118/2规定使用情况统计322/2结束2演示期用户阻塞2未结束3演示期用户强迫退出2未结束418/2用户信息归档527/2结束5演示期关闭窗口1未结束6演示期保存扩展数并在需要时恢复10未结束7演示期能够在特定节点启动2未结束8演示期删除时列出所有节点1未结束918/2注释（建立删除批准修改等）10未结束1023/2PENETCONFIG――支持netconfig格式10未结束1123/2IS-41分析器――IS-41分析器对CDMA的支持51/3结束总计513．需求控制流

（1）需求状态及其演变软件需求在后继阶段开发工作中将逐步展开，加以实现。在不同的开发阶段软件需求以不同的形式进行着状态的演变。例如：――需求阶段――从获取的需求到定义的需求――建议阶段――制定出项目计划以后演化为承诺的需求――设计阶段――设计工作完成并在验收后成为设计的需求――编码阶段――完成编码和单元测试后成为实现的需求――测试阶段――完成确认测试后成为完成的需求

开发阶段需求状态需求建议设计编码测试获取定义承诺设计实现完成图11生存期各阶段需求状态的演变九、可追溯性管理

1．需求可追溯性与需求变更控制随着开发工作的进展需求将逐步扩展和演化各个开发阶段的工作产品之间存在的继承关系可追溯性矩阵2．可追溯性管理的目标使每一项需求均能追溯到前后继承关系的脉络清晰可见3．两类不同的追溯（1）向前追溯（2）向后追溯

4．可追溯性矩阵

（1）矩阵的作用

可防止遗漏为评审提供方便便于进行变更影响追踪、分析和检查（2）矩阵的建立与维护（3）矩阵的应用完整性检验――考察有无需求遗漏的情况――有无冗余代码――检查所有性能需求是否已被测试用例测试――对集成测试计划和系统测试计划进行交互检查需求变更控制――需求变更后相关的工作产品受影响的部分应随之变更――更新需求规格说明，同时要更新追溯矩阵――每增加一项需求，应在追溯矩阵中得到体现

表五

追溯矩阵实例

12345678需求号需求描述概要设计文档索引号对应的设计(功能,结构,数据库)实现(程序,类,继承类)单元测试用例集成/系统测试用例验收测试用例1.1.2利用收集的数据实现亮点的实时集成5.3.2数据采集与亮度控制器接口PB405数据采集#12#46#11CICS203亮点控制器启动#1#47#11十、CMM2级

RMKPA

需求管理（RM－RequirementsManagement）是CMM2级的第1个关键过程域。需求管理的目的是要在客户和将处理客户需求的软件项目之间形成共同的理解。这种共同理解应该体现在：客户需求的文档和对客户需求的控制中使项目的计划、产品和活动都应与需求一致

2级RMSPPSPTOSSMSQASCM目标G1G2约定能力活动测量验证C1Ab1Ab2Ab3Ab4Ac1Ac2Ac3M1V1V2V3图13RMKPA结构1．目标与活动

目标1：分配给软件的系统需求应是受控的，以利建立软件工程和管理的基线活动1：在分配需求被纳入软件项目之前，软件工程组应对其进行评审目标2：软件计划、产品和活动要与分配给软件的系统需求保持一致活动2：软件工程组将分配需求作为软件计划、工作产品和活动的基础活动3：评审对分配需求的变更，并将变更纳入软件项目2．约定与能力

约定1：项目要遵循一个书面的组织方针来管理分配给软件的系统需求能力1：为每个项目规定分析系统需求并将其分配给硬件、软件和其它系统成分的职责能力2：编制分配需求文档能力3：为管理分配需求提供足够的资源和资金能力4：软件工程组人员和与软件相关的其它组人员要接受培训，以利于完成他们的需求管理活动

3．测量与验证

测