需求工程

刘启玉PracticingSoftwareEngineering宁波理工学院[e-mail]需求工程浙江大学宁波理工学院2目录●需求工程概述●需求获取●需求分析、协商与建模●需求规约与验证●需求管理浙江大学宁波理工学院3需求工程步骤●需求获取●需求分析与协商●系统建模●需求规约●需求确认●需求管理浙江大学宁波理工学院4需求获取●系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的任意原型。●需求获取的工作产品为进行需求分析提供了基础。浙江大学宁波理工学院5需求分析与协商●需求获取结束后，分析活动对需求进行分类组织，考察需求之间的矛盾和联系，检查需求的一致性、重叠和遗漏的情况，并根据客户选择的优先级别对需求排序。●问题–每个需求是否符合整体的目标–需求是否有不合理的组成成分–需求是否必要、是否无歧义–需求是否定义了来源；需求冲突–是否可行、可测试性●协商–用户提出的要求超出软件系统可以实现的范围或实现能力；–不同的用户提出了相互冲突的需求。浙江大学宁波理工学院6系统建模●通过系统模型，在用户和系统分析人员之间建立统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。●常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。浙江大学宁波理工学院7需求规约●软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。●需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。浙江大学宁波理工学院8需求确认●作为需求开发阶段工作的复查手段，对功能的正确性、完整性和清晰性，以及其它需求给予评价。●为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。●方法–正式的技术评审–建立检查表问题，即问题的CheckList浙江大学宁波理工学院9需求确认●实际开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。浙江大学宁波理工学院10需求管理●需求管理是用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。●方法–建立需求符号表–建立跟踪表»特征跟踪表：需求与系统/产品的特征相关»来源跟踪表»依赖跟踪表：需求之间的相互关联»子系统跟踪表：分类»接口跟踪表浙江大学宁波理工学院11软件需求●软件需求包括–功能需求–性能需求–用户或人的因素–环境需求–界面需求–文档需求–数据需求–资源使用需求–安全保密要求–可靠性需求–软件成本消耗与开发进度需求–其他非功能性要求浙江大学宁波理工学院12需求获取方法与策略●建立顺畅的通信途径●访谈与调查●观察用户操作流程●组成联合小组●获得用例（UseCase）浙江大学宁波理工学院13建立顺畅的通信途径●建立分析所需要的通信途径，以保证能顺利地对问题进行分析。浙江大学宁波理工学院14访谈与调查●在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：–所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；–不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；–提问和回答在汇总后应能够反映用户需求的全貌。浙江大学宁波理工学院15访谈与调查●例子：“赛艇比赛成绩计算系统”的第一次面谈的准备计划浙江大学宁波理工学院16观察用户操作流程●到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。浙江大学宁波理工学院17组成联合小组●便利的应用规约技术(FacilitatedApplicationpecificationTechniques,FAST)：由客户（行业专家）与开发人员共同组成需求获得小组，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调。●方式:联合会议–在中立地点举行会议–建立会议规则，如：发言形式–建立议程计划，涵盖会议所要讨论的要点–协调者：控制会议–定义表达机制，如：采用同一种图形化描述方式–明确目标：标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。浙江大学宁波理工学院18组成联合小组●要点：–不分彼此，即参与人员是一个团队，而不是对立的双方–用规则控制讨论方式，避免跑题与人员不和–集思广益●步骤：–当举行了开发者和用户之间的初步访谈后，确定一个会议的时间地点，并在会议日之前将产品要求发布给所有与会者;–要求每个出席者会前列出一组围绕系统环境的对象，以及对这些对象的操作或对象之间的交互功能，并开发出约束列表(如，成本、规模大小、权重)和性能标准列表(如，速度、精度)。这些列表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉。浙江大学宁波理工学院19组成联合小组–进行会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思想。在建好所有主题的组合列表后，开始讨论活动。缩短、加长或重新组合列表以适当地反映将被开发的产品。–一旦创建了意见一致的列表，应该将团队分为更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中的单词或短语的精细化）。每个小组然后将他们开发的每个小规约提交给所有的FAST出席者讨论，进行添加、删除或进一步的精化等工作。（在所有讨论过程中，团队可能提出某些不能在会议过程中解决的问题，此时要保留问题列表以使这些思想在以后的活动中产生作用。）–在小规约完成后，每个出席者提出一个针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表。这个列表作为需求获取的结果，为需求分析和建模提供基础信息。浙江大学宁波理工学院20需求导出-质量目标识别●质量功能部署(QualityFunctionDeployment,OFD):理解什么是对客户有价值的，并在工程中部署/实现这些价值。–正常的需求（基本需求）–期望的需求（隐含的需求，价值提升，客户满意度上升）–振奋的需求（客户预料之外，但渴望获得的需求）●目的：找出需求的优先级别，在满足正常需求情况下，低优先级需求满足越多，客户的满意程度越高，即这些需求是项目的核心价值.浙江大学宁波理工学院21开发用例●当需求作为非正式会议、Fast的一部分而收集起来后，分析员就可以创建一组标识一串待建造系统的使用场景.●步骤–识别参与者(Actor)：谁会直接使用该系统»人员：使用者»设备或系统：参与运行的数据提供或消费者»即，识别与系统通讯的外部事物–识别与参与者相关的UseCase»该Actor希望系统做什么,Actor希望系统作的每件事将成为一个用例–记录UseCase中所有可能的情景（即Scenario）»对每件事来说，何时Actor会使用系统，通常会发生什么，这就是用例的基本过程。浙江大学宁波理工学院22需求分析原则1.必须能够表示和理解问题的信息域2.必须能够定义软件将完成的功能3.必须能够表示软件的行为(作为外部事件的结果)4.必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节5.分析过程应该从要素信息移向细节信息●要点：在需求分析过程中，重要的是做什么，而不是具体怎么做.浙江大学宁波理工学院23需求协商●协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案，争取“双赢”的结果。●协商不是简单的逻辑或技术上的争论。●协商的艺术：–不是竞争–制定策略–主动的听–关注对方的兴趣–不要进行人身攻击–创新性，打破僵局–随时准备作出承诺浙江大学宁波理工学院24需求建模●在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做●目标软件的模型不应涉及软件实现细节●常用的方法：–面向数据流的结构化分析方法(SA)–面向数据结构的分析方法–面向对象的分析方法(OOA)浙江大学宁波理工学院25需求规约与验证●需求规约的原则–从现实中分离功能，即描述要“做什么”而不是“怎样实现”；–规约必须包括系统运行环境–规约必须是一个认识模型，而不是设计或实现的模型。–规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例–规约必须允许不完备性并允许扩充。–规约必须局部化和松散耦合。浙江大学宁波理工学院26需求规约VI.VII.附