03软件需求.ppt

* * * 可跟踪性：你应能将一个软件与其原始材料相对应，如分配需求等。也能够将软件需求与HLD、LLD，测试用例、代码，用于构造实现和验证需求的测试相对应。 可跟踪性强调需求的划分粒度，AR-SRS-设计，应该是逐级细化。每个需求点应控制在代码行200行左右，测试例3-5个的规模。 * 举个例子，用户要做一个会计电算化系统，有一条需求是打印资产负债表，用户方的会计最初的想法是在屏幕上显示一个表，他们把数据填进去，然后在该公司专用的报表单上打印出来，设计方分析用户的业务流程后发现，数据在凭证输入的时候已经有了，没有必要由用户输入，但用户用的报表专用纸太软，没有办法用打印机打印，建议直接按样式打印到普通打印纸上。用户同意接受这种修改，但要求，打印结果必须在颜色上也与专用的报表单一致。设计人员把这些东西写入初期需求定义，但在做DEMO的时候发现，他们打算选用的报表输出工具的日期项不能输出为中文，他们向用户提出，希望允许用yyyy-mm-dd的方式输出日期，用户觉得可以接受，但要求格式为yyyymmdd…… * * 强调RTM应同需求文档一同提交评审，便于跟踪AR是否全部在SRS中实现了。 * * * * * 需求逐步实现的中间环节需要跟踪 * * * 从这个图当中，重点讲：需求跟踪的时机。 下面是各阶段时间点的一个说明： 在SOW Review完成并签发后，就可以将分配需求写入需求跟踪矩阵的分配需求列表页面，最迟也要在SRS Review前完成，即与SRS需求点列表以及分配需求到SRS需求的跟踪一起进行。需求跟踪活动的结果（RTM）作为SRS Review的输入。 在以后的设计、编码阶段，每当完成一个工作产品（STP、HLD、ITP、LLD、UTP、CODE）时，在其Review前，都要把需求跟踪矩阵作为当 前工作产品Review的一个输入，以便及时验证需求是否遗漏，避免需求遗漏带来的无谓返工，和返工后缺少有效的Review。 最后在ST结束时，要使用需求跟踪矩阵对每个系统测试用例是否通过进行跟踪，以便完成从分配需求到系统测试整个开发周期的端到端的跟踪。 * 需求跟踪的编号尽量能够表达出需求的含义，并将跟踪编号写在章节号的后面，便于刷新到目录中，并通过目录就能够完成需求跟踪过程 SRS是需求的标志； PI是项目信息(可选)； 编号中FI字段用于简要描述该需求的特性。 启发学员思考为什么需求跟踪不能直接使用文档章节号： 使用章节号，一旦新增章节，编号必须全部调整。 * DocType为文档类型，其值可以是HLD、LLD或SD（概要设计和详细设计合为一篇文档的情况） ContentType为文档内容分类，其值有：MOD（模块）、PCS(进程)、DAT（数据）、MIB(管理信息库)、DB(数据库)、START(启动)、CLOSE（关闭） SubType为可选项，对个别ContentType适用，他们之间的关系如下表所示。 ID为序号，由001开始等。 * * 需求变更：大师说：没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。“ 任何对分配需求的需求变更，必须以变更申请表的提出。 更改请求(CR)可由客户或项目组成员启动。不管是由谁启动，均由项目组成员填写更改请求表格 任何与工作产品相关的变更都可当作缺陷，通过缺陷跟踪电子流提交。缺陷跟踪电子流的操作，请参照软件缺陷跟踪规程。 CR的状态包括“已提交”、“已批准”、“已拒绝”、“挂起”、“已验证”及“关闭”。 该填写CR的项目组成员应是CR的提交人，提交人要确保提供了充分的信息。可能时，提交人应提供一个推荐的解决方案。 提交人提交CR给CMO，CMO保存CR，从1开始以连续的号码为CR编号，并在CR中把状态标记为“已提交”。 CMO把CR发给CCB进行签发。 CCB将定期或者事件驱动地召开CCB会议评估变更请求, 需要时可从其他人/组获得帮助。对于分配需求的变更申请，CCB会议是必须的；对于以缺陷跟踪电子流提交的变更申请，CCB会议是可选的。 进行影响分析时应参考需求跟踪矩阵。 会议期间，也需要邀请其他受影响的组（ 如测试组）。 CCB 确保任何必需的工作任务书修正已经过客户同意。 根据评估的结果，不同的变更级别将由相应的CCB人员负责进行裁决, 做出接受或拒绝该请求的决断。 CMO负责保存CCB会议纪要。 如果CR 已授权，CCB把CR发给相关项目组成员去实现，CMO把更改状态更新为“已接受”。CMO也要把该CR转发给提交人。 如果CR被拒绝，CCB记录拒绝原因，并把CR发送给CMO。CMO把CR状态更新为“已拒绝”，并返回给提交人。 一旦CCB批准了变更，CMO就会将配置项（包括