创建数据字典
?数据字典是对系统用到的所存数据项和结构的定义，以确保开发人员使用统一的数据定义。
>在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。 用例说明
■用例说明（UseCase Explanation)是对功能用例图中的用例做出的说 明。在用例说明中，需要描述用例的编号、名称、参与者和用例的功能 以及交互过程。（说明文本格式目前尚未统一，下表仅供参考。)
名称。名称无疑应该表明用户的意图或用例的用途，如“研究班招生”。
标识符[可选]。唯一标识符，如\，在项目的其他元素（如类模型） 中可用它表引用这个用例。 说明。概述用例的几句话。
参与者[可选]。与此用例相关的参与者列表。尽管这则信息包含在用例本身 中，但在没有用例图时，它有助于增加对该用例的理解。
状态、[可选]。指示、用例的状态，通常为以下几种之一：进行中、等待审查、 通过華i或菜通过帝查。
频手。参与者访A7此用例的频率。这是一个自由式问题，如用户每次录访问一 次戒每月一次。
前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之 if得到满足。
后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成 以后得到满足。 需求规约
软件需求规约是分析任务的最终产物，通过建立完整的信息描述、 详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标 准，给出对目标软件的各种需求。 需求规约遵循如下原则：
⑴.从现实中分离功能，即描述要“做什么”而不是“怎样实现”。
(2).要求使用面向处理的规约语言，讨论来自环境的各种剌激可能导致系统做出什 么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。
(3).如果被开发软件系统规模很小，那么整个系统也包括在规格说明的描述之中。 ⑷.规约必须包括系统运行环境。
⑶.规约必须是一个认识模型，而不是设计或实现的模型。
(6).规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，巳提出 的解决方案是否都能满足规约。
(7).规约必须允许不完备性并允许扩充。
⑶.规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改 时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造，以便能 够很容易地加入和删去一些段落。
26
软件需求规约的一种典型格式 1引言
1.1需求规格说明的目的 1.2软件产品的作用范围 1.3定义、同义词与缩写 1.4参考文献
1.5需求规格说明概览 2 一般性描述
2.1产品与其环境之间的关联 2.2产品功能 23用户特征 2.4限制与约束
2.5假设与前提条件
〇软件需求规约〈模板 3特殊需求
3.1功能或巧■为需求 3.1.1功能或行为需求1 3.1.1.1 引言 3.1.1.2 输入
3.1.1.3处理过程描迷 3.1.1.4 输出
3.1.2功能或巧■为需求2 3.1.n功能或行为需求n 3.2外部界面需求 3.2.1用户界面 3.2.2硬件界面 3.2.3故件界面 3.3性能需求 3.4设计约束
3.4.1标准化约東 3.4.2硬件约東 3.5属性
3.5.1可用性 3.5.2安全性 3.5.3可维护性 3.5.4可移植性 3.6其它需求
3.6.1数据库需求 3.6.2用户操作需求 3.6.3工作场地需求
27
软件(产品）需求说明书 1.引言
/. /項目筒介 12编写说明 !. 3参考资料 2.目标 2. 1概述 2. 2此务@标
2. 2. ； ,# B标 2. 2. 2此务@标 2. 2. 3羅制性因案 3.软件功能结构 3. /较件包结构图 3.2致件包的说明 4.软件功能规约 < ；概述
4.2软件包的用例模g 4,3用例规约分析说明 5软件功能限制因素 5.；概迷
5.2非功能需求 5.3设计约東需求 6.风险分析
6. !软件S餘的主要风竣 6. 2风殓的处理策4、 7.遗留问题
评审——同行或专家评审确认需求规格说明书 需求评审目的是要确保需求能够反映用户的意愿 ?评审人员评审时往往需要检查以下内容： 1.系统定义的目标是否与用户的要求一致；
2.系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确 地反映了用户要求；
3.被开发项目的数据流与数据结构是否确定且充足；
4.主要功能是否已包括在规定的软件范围之内，是否都己充分说明； 5.设计的约束条件或限制条件是否符合实际； 6.开发的技术风险是什么；
7.是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。
28
^ 需求验证的方法
几种需求验证的基本万法。 ? 1)自查法
>自查法由需求分析人员对自己所确定的用例需求进行审核和验证，纠正需求中存在的问题。自查法又可以分为多种具体方法。第一种是小组审查法，即由一名分析人员向开发小组中其他人员介绍用例需求,小组中的成员进行提问，由介绍人进行解答。 ? 2)专家审查法
>专家审查法是指聘请业务领域、用例、政策、法律等方面的专家对用例需求进行审查。 ? 3)用户审查法
>分析人员可以把〇用例需求说明书〈提交给用户，有条件时可以同时编写一份针对此需求的〇用户使用说明书〈并提交给用户，用户找出不满意或认为不能实现的需求，双方再对这些有争议的需求进行讨论，最后达成一致认识。 ? 4)原型法
>原型法是对存在的有争议或拿不准的需求，通过建立原型进行验证，以确定需求的正确性。
需求移交的目的：
(1)形成甲乙双方的工程实施技术合同 (2)确定了施工团队的施工方案、依据 (3)达成了多方公认的验收依据、标准
需求管理 1 29
变更控制 版本控制 需求跟踪 ?建议变?确定需?定义对其它 更 求文 ?分析影档的版本 需求的链接 态 响 ?作出决?确定需?定义对其它 ?跟踪需求的 策 求条 ?交流 目的版本 系统元素的 每一个状态 ?合并 ?确定需接链 求体 ?测量需系的版本 ?需求文档跟 求的 稳定性 踪 变更控制 需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。
虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因： ? (1)、范围没有圈定就开始细化 ? (2)、没存指定需求的基线 ? (3)、没存良好的软件结构适应变化 版本控制
版本控制透过文档控制（documentation control )记录程序各个模组的改动，并为每次改动编上序号。
?这种方法是工程图（engineering drawings)维护(maintenance)的标准做法，
它伴随着工程图从图的诞生一直到图的定型。
? 一种简单的版木控制形式，例如，赋给图的初版二个版本等级“A”。当做了第一次改
变后，版木等级改为“B”，以此类推等等。. 需求体系的版本
今天，越来越多的公司采用迭代或增量开发模式。为了降低风险，将开发过程分为多个增量部分可以加快整个开发过程。
?每个阶段结束后，是不是要将整个项目的文档做一个快照呢？通常是需要的，那此时的项目基线也就是我们这里说的需求体系的版木。
?需求体系的版木包含自需求而来的多个相关文档，此时的版本管理不仅应将这些文档打上统一的基线，并且将该组文档之间的追踪关系也进行基线化的管理。 需求变更决策七步法
需求变更决策过程可分为七步： ?第一变更申请。 步:
?第二技术评审。 步:
?第三评价对工期步: 的影响
1 需求状态跟踪 ?定义需求状 30