《软件需求工程》PPT课件.ppt

软件需求工程,周立新 博士 北京大学软件与微电子学院,课程提纲,软件需求基本理论和概念 软件需求工程过程 软件需求获取 软件需求分析 软件需求规格说明 软件需求验证 软件需求管理 软件需求实现 软件需求工程新进展 软件需求开发与需求管理工具,课程参考书,Karl E. Wiegers著, 陆丽娜，王忠民，王志敏等译，软件需求，机械工业出版社，2000 Ian K. Bray著，需求工程导引，人民邮电出版社，2003 Geri Schneider and Jason P. Winters著, 姚淑珍，李巍等译，用例分析技术，机械工业出版社，2002 Dean Leffingwell and Don Widrig著, 蒋慧，林东译，软件需求管理：统一方法，机械工业出版社，2002 Ralph R. Young著, 韩柯，耿民等译，有效需求实践，机械工业出版社，2002 以上参考书相对应的英文版本 RUP,第一章 软件需求基本理论和概念,软件需求定义 需求工程的本质 问题域与解系统 软件需求分类 功能需求 性能需求 (非功能需求) 设计约束 商业约束 客户/用户/开发者的需求观 不合格的需求派生的问题 高质量的需求带来的好处 优秀需求所具有的特征,项目失败的原因分析,Source: Carnegie-Mellon University, Software Engineering Institute,错误认识,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 软件调节和改变是很灵活的，任何需求的变更都可容易地在软件中反映出来,这些认识多来自极小项目的开发经验，当你面对一个中大型项目时必须彻底改变这些错误观念！,1. 软件需求的定义,IEEE软件工程中需求的定义(1977) 用户解决问题或达到目标所需的条件和能力 系统或系统部件为满足合同、标准、规范或其它正式规定文档所需具有的条件和能力 以上条件和能力的文档说明 客户希望在问题域内产生的效果 需求与问题域的差别 Sommerville & Sawyer 1997 需求是指系统必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束,2. 需求工程的本质,需求工程简单化描述为她关注系统将要做什么；而设计关注系统将怎样做 需求工程可以看作把一个定义不足的问题转换为一个定义充分的问题以便找出解决方案。这是因为客户需求信息经常是粗糙的和不完整的 需求工程的通用性、理论性和实践性，怎样理解其学科性质，如何学习才能掌握它的本质？有一劳永逸的方法和工具吗？能否将另一个成功项目的需求工程方法照搬到现在的项目 答案是不能！,3. 问题域(Problem Domain)与 解系统(Solution System),问题域：被开发系统的应用领域，即在现实世界中由这个系统进行处理的业务范围 解系统：指可以在问题域内产生某种效果的系统，而构成软件需求的正是这些想要获得的效果，它也正是为何做软件需求的原因和目的,问题域 Problem Domain,问题域 接口,解系统,分析,规格说明,设计,问题域的类型,分类I 系统软件 应用软件，进一步划分为商业软件和工程软件 分类II 批处理系统/系统脱机 交互系统 实时系统 分类III 数据为主的系统 交互为主的系统 算法为主的系统,问题域的类型,数据为主,交互为主,算法为主,气象预报系统 收银机系统 电梯控制系统 工资系统 文字处理系统 文件转换系统 手机定位系统,A,B,C,D,E,F,G,需求的层次,业务需求,项目视图与 范围文档,用户需求,质量属性,使用实例文档,系统需求,功能需求,其它非功 能需求,约束条件,软件需求规格说明 SRS,4. 软件需求的分类,业务需求 业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图和范围文档中予以说明 例如某运营商对定位系统的业务需求,4. 软件需求的分类,用户需求 用户需求(user requirement)描述了用户使用产品必须要完成的任务，它们在使用实例(use case)和情景描述(scenario)文档中予以说明,4. 软件需求的分类,功能需求 “一般”意义的需求指的是功能或行为需求，这样的需求通常是和解系统的适当行为(用户需求)相关联，是开发人员必须实现的软件功能。功能需求可以在多种不同的抽象层次上来表达，这使得导出需求过程比较复杂和困难： a) Physical behavior b) Input-output relationship c) Observable states d) User interface,4. 软件需求的分类,非功能需求 非功能需求是功能需求的补充，它描述了系统完成功能实现的补充和约束条件。如产品必须遵从的标准、国际规范和合约；外部界面的规范；性能需求如：系统运行速度(Speed)，可靠性(Reliability)，容量(Capacity)，可用性(Availability),可使用性(Usability)；其它质量属性如：快捷性、简易性、直觉性、健壮性等。在具体操作时，关于可靠性和可用性的规范最为困难，但又是客户最为关心的,4. 软件需求的分类,非功能需求 a) Response b) Accuracy c) Frequency d) Capacity e) Throughput f) Defect rates g) Modifiability h) Supportability,4. 软件需求的分类,设计约束 设计约束是真正意义上的非功能约束，它们约束系统怎样被构建而不是系统做什么。设计约束的一般内容为 解系统将在其上运行的目标机器 底层的体系结构 - 分布式的或本地的 系统运行的内存大小 应当采用的任何前端图形用户界面(GUI)程序包 系统运行的操作系统 应当使用的编程语言 其它应集成的软件包如数据库管理系统(DBMS) 必须应用的开发标准 应采用的设计方法等等,4. 软件需求的分类,设计约束 a) Language b) OS c) SW to HW interface d) Algorithm e) Power f) Timing g) Memory h) Processor utilization I) Weight etc,4. 软件需求的分类,商业约束 商业约束通常关注的是软件产品完成的时间以及开发费用问题，是客户最为关心的问题。 解系统的开发时间和费用与系统功能性、可靠性、可用性等关键需求性能有着必然与复杂的关系。是项目需求与项目管理的结合点。 商业约束通常是和需求工程过程同步的，即商业约束是在调查其它需求的同时获得，而且易于识别，不存在技术上的困惑，但却是管理上的难点。 商业约束如果不存在一个独立文档，则会出现在业务需求描述中。,4. 软件需求的分类,系统需求 对于一个复杂的系统或产品，软件功能需求只是系统需求的一个子集，需要从系统需求中剥离出来。系统需求描述了系统中各个方面的需求，可能包含硬件、软件、其它关联系统，而且系统的功能及非功能描述并不依赖于物理层次，如软件和硬件的划分。系统和软件需求分析人员需要将软件需求部分独立出来。在CMM中这部分工作称为需求分配(requirement allocation),4. 软件需求的分类,开发过程需求(Process Requirements) A requirements that specifies a need or constraint about how a product well be designed, produced, delivered, or maintained; e.g., the specification of a methodology, manufacturing process, or delivery constraint. Process requirements are distinguished 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 Assurance h) Review processes I) Verification Standards,5.客户/用户/开发者的需求观,客户的需求观在一个比较高的层次上，为产品提供宏观的描述和指导性的框架，是项目的基础； 用户的需求观往往代表了产品应该完成的任务及其具有的特性，细节，真实性； 开发者的需求观则应是使产品最大限度的满足需求，并最大程度的理解用户的需求。,6. 不合格的需求派生的问题,如果项目初始的需求分析不合理，会导致客户和开发人员之间的目标不一致，这意味着客户对产品的期望和目标得不到准确的理解，很可能在开发过程中或移交产品后发现产品不能符合客户实际的需求，从而导致项目的失败。,不适当的需求引起的一些风险,无足够用户参与 用户参与不多会导致产品无法被接受 用户需求的不断增加 用户需求的增加带来过度的耗费和产品质量的降低 模棱两可的需求说明 将导致时间的浪费和返工 不必要的特性 用户增加一些不必要的特性和开发人员画蛇添足 过分精简的规格说明 过分简略的需求说明以致遗漏某些关键需求 忽略用户分类 忽略某类用户的需求将导致众多客户的不满 不准确的计划 不完善的需求说明使得项目计划和跟踪无法准确进行,不适当的需求引起的一些风险,无足够用户参与 客户经常不明白为什么收集需求和确保需求质量需花费那么多工夫，开发人员可能也不重视用户的参与。很多情况下，开发人员觉得已经完全明白了用户的需求，甚至想当然地设计了一些用户并不认可的使用实例。尽管原因是多方面的，尽早让具有代表性的用户参与是可以避免一定的风险的,不适当的需求引起的一些风险,用户需求的不断增加 在开发过程中，若不断地补充需求，项目就会越来越大直到超出计划和预算范围。这是软件开发中极其普遍的问题，也是软件需求管理中重点涉及的问题。 如果变更发生在设计编码以后，这样的变更会使软件结构日渐紊乱，补丁代码使模块违背强内聚、低耦合的设计原则，使程序越来越难以理解和维护。 要想把变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束和成功标准给予明确说明，并作为今后需求变更处理时的参考框架。,不适当的需求引起的一些风险,模棱两可的需求说明 模棱两可，也就是需求的“二义性”，是需求说明中最可怕的问题。 模棱两可的需求风险承担者产生不同的期望，使开发人员产生错误的设计，使测试人员编写不匹配的测试用例。 模棱两可的需求直接的后果就是返工。根据统计，返工会耗费总开发费用的40%，其中70%80%是由需求方面的错误造成的。 认真、高质量的需求评审可以消除大部分的模棱两可型的错误。,不适当的需求引起的一些风险,不必要的特性 “画蛇添足”是指开发人员力图增加一些“用户可能欣赏”，但需求规格中并未涉及的新功能；这类新功能可能很花哨但用户并不认为很有用，但实现却耗费可观。相反的情况也存在，即客户会提出这些花哨的但缺乏实用价值的需求，需求分析人员应做的是去说服客户避免将资源浪费在这些无关紧要的功能上。 与此相关的做法是，在可能的情况下，为客户提供新的解决方案，在允许的资源和技术可行性之间求得平衡。,不适当的需求引起的一些风险,过分精简的规格说明 有时客户并不明白需求分析如此重要，于是只作一份简略之至的规格说明。仅涉及产品的某些概念，其它让开发人员在项目进展中去完善，结果是为了管理上的某种要求，开发人员先建立产品结构、甚至是完成编码，然后再补充需求说明。大多数情况下，这会增加开发过程的迂回、返工。,不适当的需求引起的一些风险,忽略用户分类 多数产品是由不同的人使用不同的特性，使用频繁程度、受教育程度、经验水平也不相同。如果产品功能设计不能满足某些关键用户需求，会大大影响产品的用户接受度。,不适当的需求引起的一些风险,不准确的计划 需求分析不充分和缺乏理解会导致计划的乐观估计；导致需求过程中软件成本估计极不准确的主要原因为： 频繁的需求变更； 遗漏的需求； 与用户交流不够； 质量低下的需求规格说明； 不完善的需求分析。,7. 高质量的需求带来的好处,实行有效的需求工程管理的组织能获得多方面的好处。最大的好处是在开发后期和整个维护阶段重做的工作大大减少了。这使得整个开发过程少走了许多弯路，并在开始阶段就为整个产品开发过程指明了方向。,8. 优秀需求所具有的特征,完整性(Complete) 正确性(Correct) 可行性(Feasible) 必要性(Necessary) 与实现无关性(Implementation Independent) 划分优先级 (Prioritized, Future and trade-offs) 无二义性(Unique) 可验证性(Verifiable) 正确的详细层次(Right level of details),8. 优秀需求所具有的特征,完整性(Complete) 每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。 正确性(Correctness) 每一项需求都必须准确地陈述所要开发的功能。其判别标准是是否符合需求的来源，如用户需求和系统需求。其检验标准就是通过用例和场景分析验证是否满足用户或客户的真实需要。,8. 优秀需求所具有的特征,可行性(Feasible) 每一项需求都必须在已知系统和环境的技术、资源等限制范围内是可以实施的。做到这一点，需要多方人员参与检查其可行性，这些人员包括：开发软件工程师，系统工程师，市场人员等。 必要性(Necessary) 每一项需求都必须和某项真正用户需求，如使用实例或某项高层系统需求，相关联。 It specifies what must be done and only what must be done,8. 优秀需求所具有的特征,与实现无关性 需求关注的是系统将要做些什么，其后的阶段如设计，关注该系统将怎样来实现。如果一项需求与实现密切相关，这会限制设计人员优化、合理设计系统的自由度。 划分优先级 给每项需求分配一个可实施的优先级以指明其在产品中的重要程度。如果所有的需求都同等重要，项目管理者在节省预算或调度中就会无从选择。,8. 优秀需求所具有的特征,无二义性(Unique，Unambiguous) 每项需求对所有相关的读者只能有一个明确统一的解释。由于自然语言极易导致二义性，应尽量把每项需求用简明的用户语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型等。 可验证性(Verifiable) 每项需求都应能够被人或机器加以验证，否则将无法确定该项需求是否实现正确。验证方法主要为测试用例，场景符合性分析，正规审查，原型演示。,8. 优秀需求所具有的特征,正确的详细层次(Right level of detail) 每项需求或者一组需求都应包含相应的层面信息，以便据此足以导出下一层产品需求或设计，但不应提供对下一层活动如设计不必要的限制,优秀需求具有的特性,需求规格说明的特征 完整性(Complete) 一致性(Consistent) 简洁明了(Concise) 可修改性(Modifiable) 可跟踪性(Traceable),优秀需求规格说明的特性,完整性(Complete) 需求规格说明完整性是指不能遗漏任何必要的信息，这里不仅仅指需求本身，还包括相关的参考信息，如基于的国际标准，高层需求信息等。,优秀需求规格说明的特性,一致性(Consistent) 需求规格说明一致性是指软件需求不能与其它需求如系统需求、业务需求相矛盾。正规的文档审查和基于实例和场景分析的验证是保证一致性的通用做法。 Intern