需求工程培训课件

1、需求工程培训课件1、领域分析的概念、领域分析的概念 软件工程要处理两类工程：软件工程要处理两类工程：1面向用户的业务过程工程面向用户的业务过程工程2面向市场的产品工程面向市场的产品工程 见以下图见以下图 领域领域(domain)，就是指解决问题的范围，从最高层的角度，就是指解决问题的范围，从最高层的角度业务域描述系统。业务域描述系统。 系统分析可以发生在许多不同的抽象层次：系统分析可以发生在许多不同的抽象层次： 在业务或企业级层次，可定义描述模拟整个业务的功能、结构在业务或企业级层次，可定义描述模拟整个业务的功能、结构和行为的模型；和行为的模型； 在应用层次，建模着重于特定的用户需求。在应用层

2、次，建模着重于特定的用户需求。 2企业企业业务域业务域业务域业务域信息系统信息系统过程需求过程需求信息战略方案信息战略方案全局视图全局视图业务域分析领业务域分析领域视图域视图系统分析与设系统分析与设计建模计建模构造与集成构造与集成业务过程工程层次业务过程工程层次3完整产品完整产品软件软件能力能力功能功能过程需求过程需求 产品需求全局产品需求全局视图视图 构件工程构件工程领域视图领域视图分析与设计分析与设计建模建模构造与集成构造与集成产品工程层次产品工程层次数据数据行为行为硬件硬件4 Firesmith对软件领域分析的定义是：对软件领域分析的定义是：领域分析指特定应用领域中公共需求的领域分析指特

3、定应用领域中公共需求的标识、分析和规约，即发现或创立那些标识、分析和规约，即发现或创立那些可广泛应用的对象，其目的使它们在应可广泛应用的对象，其目的使它们在应用域中多个工程间能被复用。领域分析用域中多个工程间能被复用。领域分析的角色是设计和建造可复用构件类似的角色是设计和建造可复用构件类似于制造环境中工具制造者的角色，它于制造环境中工具制造者的角色，它们被很多相似但不一定是相同的应用开们被很多相似但不一定是相同的应用开发的人所使用。发的人所使用。 Lethbridge的定义是：领域分析是的定义是：领域分析是软件工程师了解背景信息的过程。为了软件工程师了解背景信息的过程。为了理解问题并在需求分析

4、和软件工程过程理解问题并在需求分析和软件工程过程的其他阶段作出合理的决策，软件工程的其他阶段作出合理的决策，软件工程师必须了解使用该类软件的一般性商业师必须了解使用该类软件的一般性商业和技术领域中足够的信息。和技术领域中足够的信息。5 2、领域分析过程的活动、领域分析过程的活动 1定义被调查的领域中感兴趣的项定义被调查的领域中感兴趣的项 从业务域、系统类型或产品范畴中别离出感从业务域、系统类型或产品范畴中别离出感兴趣的兴趣的“项。项。 感兴趣的项包括：现存的应用软件的规约、设计感兴趣的项包括：现存的应用软件的规约、设计和代码，支持软件如和代码，支持软件如GUI或数据库访问构件以及或数据库访问构

5、件以及和领域相关的构件库以及测试案例。和领域相关的构件库以及测试案例。 2对从领域中抽取出来的项进行分类并建对从领域中抽取出来的项进行分类并建立分类层次。立分类层次。6 3收集领域中应用系统的代表性样本。收集领域中应用系统的代表性样本。 4分析样本中的每个应用分析样本中的每个应用 标识候选的每个可复用对象。标识候选的每个可复用对象。 指明对象被标识为可复用的理由。指明对象被标识为可复用的理由。 定义对象的适应性。定义对象的适应性。 估算在领域中复用这些对象的应估算在领域中复用这些对象的应用的百分率。用的百分率。 使用配置管理技术控制这些对象。使用配置管理技术控制这些对象。 5为对象开发分析模型

6、。为对象开发分析模型。7 3、领域分析的价值、领域分析的价值 领域分析除了为软件复用奠定根底外，还为领域分析除了为软件复用奠定根底外，还为较低抽象层次的一般的系统分析带来如下好处：较低抽象层次的一般的系统分析带来如下好处： 快速开发。有助于集中精力关注最重要的问题，快速开发。有助于集中精力关注最重要的问题，更有效地与相关人员进行交流，可以更快确实定需更有效地与相关人员进行交流，可以更快确实定需求。求。 优化系统。了解领域的细节有助于保证所采纳的优化系统。了解领域的细节有助于保证所采纳的解决方案更有效地解决用户的问题。会少犯错误，知解决方案更有效地解决用户的问题。会少犯错误，知道应该遵循那些规程

7、和标准。领域分析给出一个应用道应该遵循那些规程和标准。领域分析给出一个应用领域的总体视图，会引导出更好的抽象从而改进设计。领域的总体视图，会引导出更好的抽象从而改进设计。 有了领域知识，就可以洞察新兴趋势及进有了领域知识，就可以洞察新兴趋势及进一步开发的时机，有助于创立适应性更强的系统。一步开发的时机，有助于创立适应性更强的系统。 了解通用性和特殊性，有助于创立出具有更了解通用性和特殊性，有助于创立出具有更好的可重用性和更宽的销售市场的软件。好的可重用性和更宽的销售市场的软件。8 专家提出，没有坚实的领域分析，任何重大的软件工程都不应该进行。对应用领域的深入理解能极大的提高成功的几率。许多非常

8、成功的软件产品的开发人员以前都在业务领域工作过段时间，对实际需要有着深切的感受。 一旦对领域有了真正的理解，就可进行某一个工程或产品的需求分析，包括定义待解决的问题以及开发什么软件来解决它。然而，领域分析永远也不应该结束：开发人员有责任在开发过程中不断增进他们的理解，后续版本的系统扩充通常需要对子领域进行进一步的领域分析。91、需求、需求requirements的概念的概念 1需求的定义需求的定义 Jones 定义为用户所需要的软件必须到达的目标定义为用户所需要的软件必须到达的目标和能力。和能力。Lethbridge定义为需求是关于系统将要完成定义为需求是关于系统将要完成什么工作的一段描述，它

9、们必须经过所有相关人员的什么工作的一段描述，它们必须经过所有相关人员的认可，其目的是彻底的解决用户的问题。认可，其目的是彻底的解决用户的问题。 需求是一段需求是一段描述：意思是每个需求是相对短描述：意思是每个需求是相对短小简明的一段信息，表现为一个事实。它可以是一小简明的一段信息，表现为一个事实。它可以是一段话或用各种图表示。一组需求的集合成为需求文段话或用各种图表示。一组需求的集合成为需求文档。档。 关于系统将要完成什么工作关于系统将要完成什么工作：需求描述了：需求描述了系统应当完成的任务，不描述系统将如何实现。系统应当完成的任务，不描述系统将如何实现。 必须经过所有相关人员的认可必须经过所

10、有相关人员的认可：意指需求必：意指需求必须经过评审，才能成为正式的需求。须经过评审，才能成为正式的需求。 其目的是彻底的解决用户的问题。有助于解决用其目的是彻底的解决用户的问题。有助于解决用户的问题，该需求才有存在的价值。户的问题，该需求才有存在的价值。10业务需求业务需求工程范工程范围文档围文档用户需求用户需求用例文用例文档档功能需求功能需求质量属性质量属性其他非功能其他非功能需求需求设计约束设计约束需求规需求规约约非功能需求非功能需求系统需求系统需求需求组成的全景图需求组成的全景图2需求的组成需求的组成对系统、产品高层次对系统、产品高层次的目标要求。的目标要求。用户使用产品必须用户使用产品

11、必须要完成的任务要完成的任务11 其中：其中： 业务需求：反映组织机构和客户对系统、产品高层次的目标要求。业务需求：反映组织机构和客户对系统、产品高层次的目标要求。 用户需求：用户需求：从用户使用的角度给出需求的描述。从用户使用的角度给出需求的描述。 如一个小型超市需要一个商品的查询系统。如一个小型超市需要一个商品的查询系统。 业务需求：进货人员需要查询商品库存以便保证及时业务需求：进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以便结账；经理需进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。要查询商品的销售及盈利情况。 用户需求用户需求:

12、:这三类用户怎样去查询系统，查询哪些信息，还需这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。要哪些操作。12 系统需求：从系统或技术的角度描述为实现业务需求和用户需求系统需求：从系统或技术的角度描述为实现业务需求和用户需求而提供的效劳以及所受到的约束。而提供的效劳以及所受到的约束。 功能性需求：描述系统应该做什么，即为用户和其它系统完成功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能。的功能。 非功能性需求：产品必须具备的属性或品质。非功能性需求：产品必须具备的属性或品质。 设计约束：设计与实现必须遵循的标准、约束条件。如运设计约束：设计与实现必须遵循的标准、约束条件。如

13、运行平台、协议、选择的技术、编程语言和工具等。行平台、协议、选择的技术、编程语言和工具等。3需求的描述需求的描述 自然语言、结构化语言、自然语言、结构化语言、PDL 图形化表示使用图形化表示使用Rational Rose、Microsoft Visio、Enterprise Architect等工具等工具 数学描述形式化语言描述数学描述形式化语言描述132、需求工程过程、需求工程过程 需求工程是一个包括创立和维持系统需求文档所必需的一需求工程是一个包括创立和维持系统需求文档所必需的一切活动的过程。它包含了如下活动：切活动的过程。它包含了如下活动： 系统可行性研究、需求获取和分析、需求描述和文档

14、编写、系统可行性研究、需求获取和分析、需求描述和文档编写、需求有效性验证、需求管理管理需求工程的变更。需求有效性验证、需求管理管理需求工程的变更。可行性研究可行性研究需求获取和需求获取和分析分析需求描述需求描述需求有效性需求有效性验证验证可行性研究可行性研究报告报告系统模型系统模型用户需求和系用户需求和系统需求统需求需求规约需求规约需求工程过程需求工程过程需求管理需求管理14l可行性研究是需求工程过程的开始。在较短的时间内作出结可行性研究是需求工程过程的开始。在较短的时间内作出结论。集中答复以下问题：论。集中答复以下问题：l 1系统是否符合组织机构的总体目标。系统不支持系统是否符合组织机构的总

15、体目标。系统不支持这些目标，就没有价值。这些目标，就没有价值。l 2系统是否可能在现有的技术条件、预算和时间系统是否可能在现有的技术条件、预算和时间限制内完成。限制内完成。l 3系统能否与已经存在的系统集成。系统能否与已经存在的系统集成。l该活动要广泛收集信息并评估，答复一些有关的问题，写出该活动要广泛收集信息并评估，答复一些有关的问题，写出研究报告，得出结论：系统是否值得开发？给出具体的意见研究报告，得出结论：系统是否值得开发？给出具体的意见和建议。可能对系统高层需求、功能范围、预算和时间安排和建议。可能对系统高层需求、功能范围、预算和时间安排提出修改意见。提出修改意见。15需求获取与需求分

16、析的区别需求获取与需求分析的区别 需求获取是开发人员与客户或用户一起对应用领域进行调查研究，需求获取是开发人员与客户或用户一起对应用领域进行调查研究，收集系统需求的过程。收集系统需求的过程。 需求分析是将获取到的需求准确的理解、求精，并将其转需求分析是将获取到的需求准确的理解、求精，并将其转化为完整的需求定义包括建模，进而生成需求规约的过程。化为完整的需求定义包括建模，进而生成需求规约的过程。需求获取和分析的难度需求获取和分析的难度 工程相关人员通常并不真正知道希望计算机做什么，让他们清晰工程相关人员通常并不真正知道希望计算机做什么，让他们清晰的表达出需要系统做什么是件困难的事，他们或许提出不

17、切实际的的表达出需要系统做什么是件困难的事，他们或许提出不切实际的要求。要求。 16 工程相关人员用自己的语言表达需求，这些语言包含很多工作工程相关人员用自己的语言表达需求，这些语言包含很多工作中的专业术语和专业知识。系统分析员没有这些知识和经验，而他中的专业术语和专业知识。系统分析员没有这些知识和经验，而他们又必须了解这些需求。们又必须了解这些需求。 不同的工程相关人员有不同的需求，可能以不同的方式表达，分析不同的工程相关人员有不同的需求，可能以不同的方式表达，分析人员必须发现所有潜在的需求资源，而且能发现这些需求的相容或冲突人员必须发现所有潜在的需求资源，而且能发现这些需求的相容或冲突之处

18、。之处。 经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别需求的重要程度会改变，新的需求会从新的工程相关人员那里得到。需求的重要程度会改变，新的需求会从新的工程相关人员那里得到。 17 建立由客户用户、系统分析员、领域专家参加的联建立由客户用户、系统分析员、领域专家参加的联合小组。合小组。 需求获取的方法：个别访谈、召集会议、文档研究、问需求获取的方法：个别访谈、召集会议、文档研究、问卷调查、观察用户工作流程、建立原型。卷调查、观察用户工作流程、建立原型。 获取的需求的表达方式：获取的需求的表达方式： 1需求列

19、表需求列表 需求与系统的特殊视角或环境的关系需求与系统的特殊视角或环境的关系 2业务流程图状态业务流程图状态/活动图活动图 3用例用例Use-Case/场景场景Scenario /用户故事用户故事user story)/ 视点视点(viewpoint)的描述的描述 4数据流图数据流图 5实体关系图实体关系图 6用例图、类图、活动图、时序图、状态图等。用例图、类图、活动图、时序图、状态图等。 18视点视点 可以理解为：可以理解为： 1、数据源或数据池、数据源或数据池SA、SD方法方法 2、一个表示框架系统模型、一个表示框架系统模型 3、效劳的接收者系统的外部成分、效劳的接收者系统的外部成分 特别

20、适用于交互式系统的需求导出。特别适用于交互式系统的需求导出。用例用例 Jacobson说说“用例帮助定义系统之外存在什么参与者以及用例帮助定义系统之外存在什么参与者以及系统应该完成什么。把系统分成一组逻辑的、互相联系较少的系统应该完成什么。把系统分成一组逻辑的、互相联系较少的局部，每一局部都描述了系统与外部角色交互所提供的效劳，即局部，每一局部都描述了系统与外部角色交互所提供的效劳，即用例的集合代表了所有将会在系统需求中出现的交互。因此容易用例的集合代表了所有将会在系统需求中出现的交互。因此容易从使用的角度理解系统应到达的功能。而从使用的角度理解系统应到达的功能。而“用户故事是某种形用户故事是

21、某种形式的简化版用例。式的简化版用例。场景场景 场景是用例的具体描述。一个用例封装了一组场景，每场景是用例的具体描述。一个用例封装了一组场景，每个场景就是一个单个线程。个场景就是一个单个线程。19 例例1：列出图书馆系统与以下参与者角色交互的最小用例：列出图书馆系统与以下参与者角色交互的最小用例集：借阅者、借书员、图书管理员、会计系统。集：借阅者、借书员、图书管理员、会计系统。 借阅者：借阅者： 按题目查询书籍按题目查询书籍 按作者查询书籍按作者查询书籍 按主题查询书籍按主题查询书籍 预定已被其他人借出的书籍预定已被其他人借出的书籍 查询借阅者的个人信息并列出借阅的书籍查询借阅者的个人信息并列

22、出借阅的书籍20 借书员：借书员： 所有借阅者的用例，再加上所有借阅者的用例，再加上 为借阅者查找某一书籍为借阅者查找某一书籍 登记已归还的书籍登记已归还的书籍 续借一本书续借一本书 登记缴纳的罚款登记缴纳的罚款 添加新的借阅者添加新的借阅者 更新借阅者的个人信息地址、更新借阅者的个人信息地址、 号码等号码等 图书管理员：图书管理员： 所有借阅者和借书员的用例，再加上所有借阅者和借书员的用例，再加上 添加藏书添加藏书 删除藏书删除藏书 改变系统中对已有书籍的记录信息改变系统中对已有书籍的记录信息 会计系统独立运行会计系统独立运行 获得借阅者支付的超期罚款获得借阅者支付的超期罚款21l例例2：一

23、个：一个SafeHome系统，系统激活的根本用例用自然系统，系统激活的根本用例用自然语言陈述如下：语言陈述如下：l 参考教材参考教材1)l 房主观察控制面板以确定是否系统已准备好接收输入。房主观察控制面板以确定是否系统已准备好接收输入。如果系统未准备好，房主必须物理地关闭门如果系统未准备好，房主必须物理地关闭门/窗户，以便使窗户，以便使“准备好指示灯亮。准备好指示灯亮。l 房主使用键盘输入房主使用键盘输入4位密码，系统将密码与存储在配置库位密码，系统将密码与存储在配置库中的有效密码比较，如果密码不正确，控制面板鸣叫一次并中的有效密码比较，如果密码不正确，控制面板鸣叫一次并复位等待再次输入。如果

24、密码正确，控制面板等待进一步的复位等待再次输入。如果密码正确，控制面板等待进一步的动作。动作。l 房主选择键入房主选择键入“stay仅激活外部的传感器或仅激活外部的传感器或“away激活所有的传感器以启动系统。激活所有的传感器以启动系统。l 当激活时，房主可观察到一个红色指示灯。当激活时，房主可观察到一个红色指示灯。22 用例：用例： 房主激活监测房主激活监测 场景：场景： 1、房主：观察控制面板。、房主：观察控制面板。 2、房主：输入密码。、房主：输入密码。 3、房主：选择、房主：选择“stay或或“away。 4、房主：观察红色指示灯显示系统已被翻开。、房主：观察红色指示灯显示系统已被翻开

25、。 异常：异常： 1、控制面板未就绪。、控制面板未就绪。 2、密码不正确。、密码不正确。 3、密码不识别。、密码不识别。未解决的问题：未解决的问题： 1、是否有不使用密码激活系统的方式。、是否有不使用密码激活系统的方式。 2、控制面板是否还应显示附加的文字信息。、控制面板是否还应显示附加的文字信息。 3、房主输入密码的时间有无约束。、房主输入密码的时间有无约束。 4、在系统真正激活之前有无方法关闭系统。、在系统真正激活之前有无方法关闭系统。23 需求分析是发现、规约和求精的过程，指开发人需求分析是发现、规约和求精的过程，指开发人员准确的理解用户的需求，通过分析，将不标准的需员准确的理解用户的需

26、求，通过分析，将不标准的需求陈述转化为完整的需求定义，并产生需求规格化说求陈述转化为完整的需求定义，并产生需求规格化说明的过程。明的过程。 获取的需求可能有模糊的、冗余的、有冲突获取的需求可能有模糊的、冗余的、有冲突的或不易理解的地方，需要用文字和图形描述不的或不易理解的地方，需要用文字和图形描述不同视图以揭示更深的、易混淆的问题，确保与所同视图以揭示更深的、易混淆的问题，确保与所有风险承担者达成共识。有风险承担者达成共识。 24 需求分析活动具有以下任务：需求分析活动具有以下任务： 1分析需求的可行性：允许的本钱、性能；分析需求的可行性：允许的本钱、性能；与其他需求的冲突；外界因素的依赖和技

27、术障碍与其他需求的冲突；外界因素的依赖和技术障碍等。等。 2对于渐增式开发要确定需求的优先级别，对于渐增式开发要确定需求的优先级别，以便确立产品版本。以便确立产品版本。 3建模：模型能突出或强调某些关键的系统特建模：模型能突出或强调某些关键的系统特征。使用文本征。使用文本 和图表形式的组合，以相对容易理解和和图表形式的组合，以相对容易理解和能直接评审正确性、完整性和一致性的方式来描述数能直接评审正确性、完整性和一致性的方式来描述数据信息、功能和行为的需求。图形化的表示分析据信息、功能和行为的需求。图形化的表示分析模型可以增强对软件需求的理解，也为软件设计奠定模型可以增强对软件需求的理解，也为软

28、件设计奠定了根底。了根底。 4生成需求规格说明。生成需求规格说明。25 在过去的数年中，人们提出了许多种分析建模的在过去的数年中，人们提出了许多种分析建模的方法，其中两种在分析建模领域占有主导地位：方法，其中两种在分析建模领域占有主导地位： 第一种是结构化分析第一种是结构化分析 (Structured Analysis，SA)，70年代末由年代末由DeMarco等人提出，这是传统的建模方法。等人提出，这是传统的建模方法。该方法不是被所有的使用者一致地使用的单一方法，该方法不是被所有的使用者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是开展了超过众多科学家对其进行了扩充，因此它是开展了

29、超过30年的一个混合物。年的一个混合物。 另一种方法是面向对象的分析，另一种方法是面向对象的分析， 如如Coad-Yourdon方法、方法、Booch方法、方法、Rumbaugh方法、方法、Jacobson 方法等。方法等。 具体的建模方法有具体的建模方法有: 26上下文模型上下文模型 ERD、包图、包图面向流的建模：数据流图面向流的建模：数据流图DFD/CFD数据建模：实体关系图数据建模：实体关系图ERD基于场景的建模：用例图、顺序图、活动图基于场景的建模：用例图、顺序图、活动图基于类的建模：类图、包基于类的建模：类图、包基于行为的建模：基于行为的建模： Petri网、状态图、顺序图、网、状

30、态图、顺序图、 协作图、活动图协作图、活动图 27Sommerville认为模型可以从以下角度去描述：认为模型可以从以下角度去描述： 1、从外部看，它是对系统上下文或系统环境建模。、从外部看，它是对系统上下文或系统环境建模。见下页图见下页图 2、从行为上看，它是对系统运行行为建模。、从行为上看，它是对系统运行行为建模。 3、从结构上看，它是对系统体系结构和系统数据的、从结构上看，它是对系统体系结构和系统数据的结构建模。结构建模。 有如下系统模型的实例有如下系统模型的实例ppt30：28上下文模型定义了系统的边界上下文模型定义了系统的边界29 1、数据处理模型、数据处理模型 如数据流图，说明系统

31、的如数据流图，说明系统的不同阶段数据如何被处理。不同阶段数据如何被处理。 2、组成模型、组成模型 实体关系图，说明一个实体与另实体关系图，说明一个实体与另外实体间的关系或如何由其他实体组成。外实体间的关系或如何由其他实体组成。 3、体系结构模型、体系结构模型 说明构成整个系统的那些主要说明构成整个系统的那些主要的子系统。的子系统。 4、分类模型、分类模型 如对象模型，说明对象间怎样具如对象模型，说明对象间怎样具有共同特性。有共同特性。 5、鼓励、鼓励-响应模型响应模型 说明系统对来自内部和外部的说明系统对来自内部和外部的事件的响应。事件的响应。 具体分析建模的方法请见第具体分析建模的方法请见第

32、3章。章。301、软件需求规约、软件需求规约 Software Requirements Specification，SRS SRS是需求分析阶段的产品，是所有其他开发和是需求分析阶段的产品，是所有其他开发和管理活动的根底。对系统开发过程中其他活动的管理活动的根底。对系统开发过程中其他活动的影响：影响： 工程经理根据它制定或修改开发方案。工程经理根据它制定或修改开发方案。 设计人员根据它进行系统设计。设计人员根据它进行系统设计。 测试人员根据它编写测试方案，设计测试用例。测试人员根据它编写测试方案，设计测试用例。 产品发布人员根据它编写产品介绍和用户文档。产品发布人员根据它编写产品介绍和用户文

33、档。 培训人员根据它编写培训教程。培训人员根据它编写培训教程。31 需求规约的结构：需求规约的结构： 1998 1998年的年的IEEEIEEE标准为需求规约提出了以下结构，组标准为需求规约提出了以下结构，组织机构内部可以基于此标准扩展：织机构内部可以基于此标准扩展： 1 1引言引言 需求文档的目的、产品范围、文档需求文档的目的、产品范围、文档约定缩写词与缩略语、参考文献、文档的其约定缩写词与缩略语、参考文献、文档的其余局部概览余局部概览 2 2综合描述综合描述 产品前景、产品前景、 产品功能与优先级、用产品功能与优先级、用户特征、运行环境、设计与实现上的约束、假设户特征、运行环境、设计与实现

34、上的约束、假设和依赖性和依赖性32 3需求描述需求描述 a. 功能需求功能需求 b. 数据需求：与功能有关的数据定义和数据关数据需求：与功能有关的数据定义和数据关系系 c. 性能需求：响应时间、容量要求、用户数等性能需求：响应时间、容量要求、用户数等 d. 外部接口：用户界面、软硬件接口、通信外部接口：用户界面、软硬件接口、通信接口接口 e. 设计约束：软件支持环境、报表、数据命设计约束：软件支持环境、报表、数据命名等名等 f. 软件质量属性可维护性、可靠性、可移软件质量属性可维护性、可靠性、可移植性、植性、 可用性、平安性等等可用性、平安性等等 g. 其他需求其他需求 这一节是文档中最实质性

35、的局部，由于在机构组这一节是文档中最实质性的局部，由于在机构组织的实践中存在极大的变数，对这一节定义的标准结织的实践中存在极大的变数，对这一节定义的标准结构可以进行增删。构可以进行增删。 4附录词汇表、硬件与数据库的描述、附录词汇表、硬件与数据库的描述、模型、待定问题列表等模型、待定问题列表等 5索引索引331. 范围范围 1.1标识标识 文件状态草稿文件状态草稿/正式发布正式发布/正在修改；文件标识；当前版本；正在修改；文件标识；当前版本； 作者作者 1.2 系统概述名称、功能、性能、上下文关系、用户、开发者系统概述名称、功能、性能、上下文关系、用户、开发者 1.3 文档概述类型、描述方法、

36、预期读者文档概述类型、描述方法、预期读者 1.4 基线基线2. 引用文件引用文件3. 需求概述需求概述 3.1 系统目标系统目标 3.2 运行环境运行环境 3.3 用户特点用户特点4. 功能需求功能需求 5. 外部接口需求外部接口需求6. 数据数据7. 故障处理故障处理34 2、需求验证 需求验证的重要性：如果在后续的开发或当系统投入使用时才发现需求规约中的错误，就会导致更大代价的返工。由需求问题而对系统做变更的本钱比修改设计或代码错误的本钱要大的多。假设需求阶段引入1个错误的需求，设计时对这个需求需要510条设计实现，1条设计需要 510条程序，1条程序需要35种测试组合测试。 原始需求原始

37、需求正确的规格说明正确的规格说明 错误的规格说明错误的规格说明正确的设计正确的设计 错误的设计错误的设计 对错误需求的设计对错误需求的设计正确的编码正确的编码 错误的编码错误的编码 对错误设计的编码对错误设计的编码 对错误需求的编码对错误需求的编码正确功能正确功能 测试到的错误测试到的错误 没有测试到的错误没有测试到的错误 一个错误的需求，纠正本钱一个错误的需求，纠正本钱100元元10 纠正本钱纠正本钱1000元元10535 对需求规约需执行以下类型的检查：对需求规约需执行以下类型的检查： 1有效性检查有效性检查 检查不同用户使用不同功能的有效性。检查不同用户使用不同功能的有效性。 2一致性检

38、查一致性检查 在文档中，需求不应该冲突。在文档中，需求不应该冲突。 3完备性检查完备性检查 需求文档应该包括所有用户想要的功能和约需求文档应该包括所有用户想要的功能和约束。束。 4现实性检查现实性检查 检查保证能利用现有技术实现需求。检查保证能利用现有技术实现需求。36 验证技术：验证技术： 1需求评审：需求评审： 由分析员、设计员、测试员、用户参与的正式或非正式由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。正式会议要有严格的评审程序，要有会议记录，的会议评审。正式会议要有严格的评审程序，要有会议记录，开发组根据缺陷建议修改需求说明并重审。开发组根据缺陷建议修改需求说明并重审。 2利用原型检验系统是否符合用户的真正需要。利用原型检验系统是否符合用户的真正需要。 3对每个需求编写概念性的测试用例。对每个需求编写