04-1软件需求分析.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * （2）面向对象需求分析描述工具 用例图 静态模型：类图 动态模型：顺序图、活动图、状态图 组织模型：包图 * 四、需求归档 编写需求规约 需求分析阶段的所有文档 用户需求报告-对应的评审记录表 软件需求规格说明书（SRS -对应的评审记录表 需求变更管理表 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 * 需求规约的原则 1． 从现实中分离功能，即描述要“做什么”而不是“怎样实现”。 2． 要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。 3． 如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。 4． 规约必须包括系统运行环境。 * 5． 规约必须是一个认识模型，而不是设计或实现的模型。 6． 规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。 7． 规约必须允许不完备性并允许扩充。 8． 规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。 * 需求规约 IEEE/ANSI 830-1993标准 Ⅰ. 引言 A.系统参考文献 B.整体描述 C.软件项目约束 Ⅱ. 信息描述 A.信息内容表示 B.信息流表示： ⅰ数据流 ⅱ控制流 Ⅲ. 功能描述 A.功能划分 B.功能描述： ⅰ处理说明 ⅱ限制∕局限 ⅲ 性能需求 ⅳ 设计约束 ⅴ 支撑图 C.控制描述 ⅰ控制规约 ⅱ 设计约束 Ⅳ. 行为描述 A.系统状态 B.事件和响应 Ⅴ. 检验标准 A.性能范围 B.测试种类 C.期望的软件响应 D.特殊的考虑 Ⅵ. 参考书目 Ⅶ. 附录 * 引言：陈述软件目标，在基于计算机的系统语境内进行描述。 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。 功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。 行为描述：描述作为外部事件和内部产生的控制特征的软件操作。 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。 附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。 * 五、需求过程管理 需求管理是一组用于帮助项目组标识、控制和跟踪需求的活动 。包括： 需求确认 需求评审 需求跟踪 需求变更 * 需求确认 ：由明确指定的负责人，与客户协商并确认需求。 非技术需求 技术需求 需求跟踪矩阵 * 需求评审：客户参与，评审需求确认的结果，包括技术需求文档、非技术需求文档和需求跟踪矩阵。评审的主要目的在于： （1）确定分配的软件功能、性能、接口需求，用软件来实现是可行的、适当的。 （2）软件功能、性能、接口需求被清晰、正确地描述。 （3）软件功能、性能、接口需求是一致的、相互不矛盾。 （4）软件功能、性能、接口需求是可测试的。 评审的结束，标志着与客户协商确认需求过程的结束。通过高级管理者批准的需求文档，应置于软件基线库中，进行配置管理和控制，作为软件项目策划的主要输入。 * 需求跟踪的主要内容是跟踪不符合项的改正情况。 可靠的跟踪信息可为需求变更、系统维护、关键成员离开、系统再设计和类似系统设计等很多方面，提供参考和指导，并可以减少风险和提高项目成功。 需求跟踪有两种方式，正向跟踪与逆向跟踪 正向跟踪：以用户需求为切入点，检查《需求规约》中的每个需求是否都能在后继工作产品中找到对应点 逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在《需求规约》中找到出处 一个简单易行的需求跟踪矩阵： * 用户需求点 测试用例 用例执行状态 概要设计 详细设计 程序代码 单元测试 集成测试 用户验收 功能需求1 已产生 已执行 已覆盖 已覆盖 已覆盖 已通过 已通过 功能需求2 已产生 已执行 已覆盖 已覆盖 已覆盖 已通过 未通过 …… …… …… …… …… …… …… …… 性能需求1 已产生 已执行 已覆盖 已覆盖 已覆盖 已通过 未通过 性能需求2 已产生 …… …… …… …… …… …