SRE04-需求描述.pptVIP

SRE05 需求描述 软件需求的表现形式 功能需求 性能需求 易用性、质量、性能、安全性，移植性、可重用性等 设计约束 运行环境 开发环境 其它要求：如开发周期 2 软件需求说明书的作用 减少开发后期和整个维护阶段的重做的工作 B o e h m（1 9 8 1）发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误要多付出6 8倍的成本。近来很多研究表明这种错误导致成本放大因子可以高达2 0 0倍 强调需求质量并不能引起某些人的重视，他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间。传统的质量成本角度分析揭示了需求及其它早期质量工作的重要性( Wiegers 1996a) 3 需求规格特性 完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。 正确性 每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明 若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，一定要有用户的积极参与 需求规格特性 可行性 每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。 必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。 需求规格特性 划分优先级 给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。 无二义性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。 需求规格特性 可验证性 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的 需求规格特性 4 需求规格说明文档的编写要求 5 需求规格说明的结构和内容(1) 需求规格说明的结构和内容 信息系统的本质：数据信息化 信息系统的核心作用是：根据应用对数据进行有效处理，从而得出对人们更有价值的信息。 信息系统的类别 在信息工程的理论框架中，将信息系统分为了联机事务处理系统(OLTP)、管理信息系统(MIS)、主管信息系统(EIS)、决策支持系统(DSS)、专家系统、办公自动化系统(OA)等几种主要的类型 需求规格说明的结构和内容 不同信息系统的功能 联机事务处理系统是数据的生产者：联机事务处理系统负责对流程进行电子化，在这个过程中，将通过用户输入、系统采集等方式积累出大量的数据。 管理信息系统是数据的消费者：管理信息系统是为中层管理人员(事务型管理人员)提供服务的，主要是通过查询、分析、统计的手段来完成监督、控制等活动，其核心的载体就是报表。 主管信息系统、决策支持信息是数据的高级消费者：这两类系统是为高层管理人员(决策型管理人员)提供服务的，其形式与管理信息系统类似，但将会对数据做更深层次的挖掘 5 需求规格说明的结构和内容(2) 嵌入式系统的需求视图 面向直接用户的嵌入式系统 针对此类系统的特点，在梳理需求时要重视可用性设计，这可以针对每 个使用场景进行行为分析，以便设计出更合理的用户界面，这样做通常能够让各个功能域中的功能点有机地融合在一起 面向特定设备的嵌入式系统 这类嵌入式系统不会与用户发生直接的关系，例如设备监测器、GPS模块等都是这种系统的实例。对于此类系统，需求主要包括对外接口和内部功能两部分 需求规格说明文档的编写要求 需求规格说明文档的编写要求 需求规格说明文档的编写要求 需求规格说明文档的编写要求 需求规格说明文档的编写要求 需求规格说明的描述语言 不存在一个包罗万象的图，把所有的内容都包容进一个完整的需求描述中，分析模型应该增强自然语言的需求规格说明，而不是替换之 需求的图形化表示的模型包括数据流图（ D F ）、实体关系图（ E R D）、状态转化图（S T D）、对话图和类图。项目规划工具 需求规格说明的描述语言 E-R图（实体关系