软件需求工程ppt课件

1、软件需求工程,周立新 博士 北京大学软件与微电子学院,课程提纲,软件需求基本理论和概念 软件需求工程过程 软件需求获取 软件需求分析 软件需求规格说明 软件需求验证 软件需求管理 软件需求实现 软件需求工程新进展 软件需求开发与需求管理工具,课程参考书,Karl E. Wiegers著, 陆丽娜，王忠民，王志敏等译，软件需求，机械工业出版社，2000 Ian K. Bray著，需求工程导引，人民邮电出版社，2003 Geri Schneider and Jason P. Winters著, 姚淑珍，李巍等译，用例分析技术，机械工业出版社，2002 Dean Leffingwell and Do

2、n Widrig著, 蒋慧，林东译，软件需求管理：统一方法，机械工业出版社，2002 Ralph R. Young著, 韩柯，耿民等译，有效需求实践，机械工业出版社，2002 以上参考书相对应的英文版本 RUP,第一章 软件需求基本理论和概念,软件需求定义 需求工程的本质 问题域与解系统 软件需求分类 功能需求 性能需求 (非功能需求) 设计约束 商业约束 客户/用户/开发者的需求观 不合格的需求派生的问题 高质量的需求带来的好处 优秀需求所具有的特征,项目失败的原因分析,Source: Carnegie-Mellon University, Software Engineering Inst

3、itute,错误认识,A general statement of objectives is sufficient to begin writing programs we can fill in the details later 需求不清楚就进入编程阶段，期望以后修改。更多的情况下是边写边修改 Project requirements continually change, but change can be easily accommodated because software is flexible 软件调节和改变是很灵活的，任何需求的变更都可容易地在软件中反映出来,这些认识多来自

4、极小项目的开发经验，当你面对一个中大型项目时必须彻底改变这些错误观念,1. 软件需求的定义,IEEE软件工程中需求的定义(1977) 用户解决问题或达到目标所需的条件和能力 系统或系统部件为满足合同、标准、规范或其它正式规定文档所需具有的条件和能力 以上条件和能力的文档说明 客户希望在问题域内产生的效果 需求与问题域的差别 Sommerville e.g., the specification of a methodology, manufacturing process, or delivery constraint. Process requirements are distinguish

5、ed from product requirements. Process requirements often appear in a Statement of Work rather than in a requirements document,4. 软件需求的分类,开发过程需求(Process Requirements) a) Configuuration Management b) Deployment c) Development Methods d) Docummentation e) Manufacturing Methods f) Metrics g) Quality Ass

6、urance h) Review processes I) Verification Standards,5.客户/用户/开发者的需求观,客户的需求观在一个比较高的层次上，为产品提供宏观的描述和指导性的框架，是项目的基础； 用户的需求观往往代表了产品应该完成的任务及其具有的特性，细节，真实性； 开发者的需求观则应是使产品最大限度的满足需求，并最大程度的理解用户的需求,6. 不合格的需求派生的问题,如果项目初始的需求分析不合理，会导致客户和开发人员之间的目标不一致，这意味着客户对产品的期望和目标得不到准确的理解，很可能在开发过程中或移交产品后发现产品不能符合客户实际的需求，从而导致项目的失败,不

7、适当的需求引起的一些风险,无足够用户参与 用户参与不多会导致产品无法被接受 用户需求的不断增加 用户需求的增加带来过度的耗费和产品质量的降低 模棱两可的需求说明 将导致时间的浪费和返工 不必要的特性 用户增加一些不必要的特性和开发人员画蛇添足 过分精简的规格说明 过分简略的需求说明以致遗漏某些关键需求 忽略用户分类 忽略某类用户的需求将导致众多客户的不满 不准确的计划 不完善的需求说明使得项目计划和跟踪无法准确进行,不适当的需求引起的一些风险,无足够用户参与 客户经常不明白为什么收集需求和确保需求质量需花费那么多工夫，开发人员可能也不重视用户的参与。很多情况下，开发人员觉得已经完全明白了用户的

8、需求，甚至想当然地设计了一些用户并不认可的使用实例。尽管原因是多方面的，尽早让具有代表性的用户参与是可以避免一定的风险的,不适当的需求引起的一些风险,用户需求的不断增加 在开发过程中，若不断地补充需求，项目就会越来越大直到超出计划和预算范围。这是软件开发中极其普遍的问题，也是软件需求管理中重点涉及的问题。 如果变更发生在设计编码以后，这样的变更会使软件结构日渐紊乱，补丁代码使模块违背强内聚、低耦合的设计原则，使程序越来越难以理解和维护。 要想把变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束和成功标准给予明确说明，并作为今后需求变更处理时的参考框架,不适当的需求引起的一些风险,模棱

9、两可的需求说明 模棱两可，也就是需求的“二义性”，是需求说明中最可怕的问题。 模棱两可的需求风险承担者产生不同的期望，使开发人员产生错误的设计，使测试人员编写不匹配的测试用例。 模棱两可的需求直接的后果就是返工。根据统计，返工会耗费总开发费用的40%，其中70%80%是由需求方面的错误造成的。 认真、高质量的需求评审可以消除大部分的模棱两可型的错误,不适当的需求引起的一些风险,不必要的特性 “画蛇添足”是指开发人员力图增加一些“用户可能欣赏”，但需求规格中并未涉及的新功能；这类新功能可能很花哨但用户并不认为很有用，但实现却耗费可观。相反的情况也存在，即客户会提出这些花哨的但缺乏实用价值的需求，

10、需求分析人员应做的是去说服客户避免将资源浪费在这些无关紧要的功能上。 与此相关的做法是，在可能的情况下，为客户提供新的解决方案，在允许的资源和技术可行性之间求得平衡,不适当的需求引起的一些风险,过分精简的规格说明 有时客户并不明白需求分析如此重要，于是只作一份简略之至的规格说明。仅涉及产品的某些概念，其它让开发人员在项目进展中去完善，结果是为了管理上的某种要求，开发人员先建立产品结构、甚至是完成编码，然后再补充需求说明。大多数情况下，这会增加开发过程的迂回、返工,不适当的需求引起的一些风险,忽略用户分类 多数产品是由不同的人使用不同的特性，使用频繁程度、受教育程度、经验水平也不相同。如果产品功

11、能设计不能满足某些关键用户需求，会大大影响产品的用户接受度,不适当的需求引起的一些风险,不准确的计划 需求分析不充分和缺乏理解会导致计划的乐观估计；导致需求过程中软件成本估计极不准确的主要原因为： 频繁的需求变更； 遗漏的需求； 与用户交流不够； 质量低下的需求规格说明； 不完善的需求分析,7. 高质量的需求带来的好处,实行有效的需求工程管理的组织能获得多方面的好处。最大的好处是在开发后期和整个维护阶段重做的工作大大减少了。这使得整个开发过程少走了许多弯路，并在开始阶段就为整个产品开发过程指明了方向,8. 优秀需求所具有的特征,完整性(Complete) 正确性(Correct) 可行性(Fe

12、asible) 必要性(Necessary) 与实现无关性(Implementation Independent) 划分优先级 (Prioritized, Future and trade-offs) 无二义性(Unique) 可验证性(Verifiable) 正确的详细层次(Right level of details,8. 优秀需求所具有的特征,完整性(Complete) 每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。 正确性(Correctness) 每一项需求都必须准确地陈述所要开发的功能。其判别标准是是否符合需求的来源，如用户需求和系

13、统需求。其检验标准就是通过用例和场景分析验证是否满足用户或客户的真实需要,8. 优秀需求所具有的特征,可行性(Feasible) 每一项需求都必须在已知系统和环境的技术、资源等限制范围内是可以实施的。做到这一点，需要多方人员参与检查其可行性，这些人员包括：开发软件工程师，系统工程师，市场人员等。 必要性(Necessary) 每一项需求都必须和某项真正用户需求，如使用实例或某项高层系统需求，相关联。 It specifies what must be done and only what must be done,8. 优秀需求所具有的特征,与实现无关性 需求关注的是系统将要做些什么，其后的阶

14、段如设计，关注该系统将怎样来实现。如果一项需求与实现密切相关，这会限制设计人员优化、合理设计系统的自由度。 划分优先级 给每项需求分配一个可实施的优先级以指明其在产品中的重要程度。如果所有的需求都同等重要，项目管理者在节省预算或调度中就会无从选择,8. 优秀需求所具有的特征,无二义性(Unique，Unambiguous) 每项需求对所有相关的读者只能有一个明确统一的解释。由于自然语言极易导致二义性，应尽量把每项需求用简明的用户语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型等。 可验证性(Verifiable) 每项需求都应能够被人或机器加以验证，否则将无法

15、确定该项需求是否实现正确。验证方法主要为测试用例，场景符合性分析，正规审查，原型演示,8. 优秀需求所具有的特征,正确的详细层次(Right level of detail) 每项需求或者一组需求都应包含相应的层面信息，以便据此足以导出下一层产品需求或设计，但不应提供对下一层活动如设计不必要的限制,优秀需求具有的特性,需求规格说明的特征 完整性(Complete) 一致性(Consistent) 简洁明了(Concise) 可修改性(Modifiable) 可跟踪性(Traceable,优秀需求规格说明的特性,完整性(Complete) 需求规格说明完整性是指不能遗漏任何必要的信息，这里不仅仅

16、指需求本身，还包括相关的参考信息，如基于的国际标准，高层需求信息等,优秀需求规格说明的特性,一致性(Consistent) 需求规格说明一致性是指软件需求不能与其它需求如系统需求、业务需求相矛盾。正规的文档审查和基于实例和场景分析的验证是保证一致性的通用做法。 Internally consistent Externally consistent,优秀需求规格说明的特性,简洁明了(Concise) 每一需求都应清晰地对应某一系统功能或用户需要，它能够容易地被所有风险承担者阅读和理解并能够容易地映射到某一使用实例或场景,优秀需求具有的特性,Original: All satelite image

17、s in the database shall be made available at the workstation upon request in those presentations defined in 8.8 (15 pages long,Improved: All satelite images in the database shall be made available at the workstation upon request in those presentations defined in 8.8.6 (contain 2 pages instruction,优秀需求规格说明的特性,可修改性(Modifiable) 涉及同类主题的需求应该