软件工程第3章

1、第3章 需求工程l需求工程概述l需求获取l需求分析、协商与建模l需求规约与验证l需求管理l需求工程概述l需求获取l需求分析、协商与建模l需求规约与验证l需求管理lAlan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动” lHerb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理 lMatthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证 理解客户需要，即理解客户需要，即背后的问题背后的问题使用用户语言、简使用用户语言、简单描述问题解决方单描述问题解决方案

2、，目的是同用户案，目的是同用户沟通做确认沟通做确认分解细化需求规格，分解细化需求规格，明确地描述产品的明确地描述产品的外在行为和特征外在行为和特征需求层级产生方式例子（ATM提款机）业务需求客户提出/市场识别出不在银行柜台客户也可以提款，方便客户、减少缓解银行业务工作量用户需求需求挖掘1、要有可靠的安全措施确保客户的账户不会被盗取；2、提取的金额有一定限度，以确保ATM存储的款项不被一次性提空，别人无法提取；3、产品需求需求分析1、用户验证功能：1.1 用户插入银行卡，系统进入密码输入界面，密码为6为数字；1.2 如果密码正确，系统进入操作界面；1.3 如果密码错误，系统提示“密码错误，请重新

3、输入”，最多允许输入3次错误密码，如果第4次输入密码依然错误，则系统提示“因多次密码输入错误，您的银行卡已被ATM机保护，请到银行办理取手续”，且银行卡无法取出2、l项目开始的时候：l需求还没有，开发就开始了l想当然的以为问题已经得到了充分的理解l项目进展当中：l设计/解决方案与需求混杂在一起l在编码过程构思需求和设计方案l需求不断变化，缺乏有效控制机制，相关人员得不到变更通知l项目交付时：l并不与当初的期望相匹配l需求仍有不断地变更l本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。l系统分析人员通过与用户的交流、对现有系统的观察及对任务进行

4、分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的任意原型。 l需求获取的工作产品为进行需求分析提供了基础 l项目层面的需求获取l关注特定产品的需求l关注短期需求，为项目开发提供输入l一次性的，参与人员有限l组织层面的需求获取l关注客户的需求，没有产品的限定l不仅关注短期需求，更关注中长期需求，为产品规划提供输入l持续不断的，全员参与l需求获取结束后，分析活动对需求进行分类组织，分析每个需求其它需求的关系来，检查需求的一致性、重叠和

5、遗漏的情况，并根据用户的需要对需求进行排序。l在需求获取阶段，经常出现以下问题： l用户提出的要求超出软件系统可以实现的用户提出的要求超出软件系统可以实现的范围或实现能力；范围或实现能力； l不同的用户提出了相互冲突的需求不同的用户提出了相互冲突的需求 l建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。l常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。 l软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求

6、和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。l需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。 l作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。 l在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。l需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。l换句话说，需求管理就是：一种获取、组织并记录系

7、统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。 l需求工程概述l需求分析、协商与建模l需求规约与验证l需求管理l功能需求 l性能需求 l用户或人的因素 l环境需求 l界面需求 l文档需求 数据需求数据需求 资源使用需求资源使用需求 安全保密要求安全保密要求 可靠性需求可靠性需求 软件成本消耗与开软件成本消耗与开发进度需求发进度需求 其他非功能性要求其他非功能性要求 l建立顺畅的通信途径 l访谈与调查 l观察用户操作流程 l组成联合小组 l用况（Use Case） l建立分析所需要的通信途径，以保证能顺利地对问题进行分析。l在具体的实践中，通常采用折衷的方

8、法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：l所提问的问题应该循序渐进，从整体的方面开始提问，所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细接下来的问题应有助于对前面的问题更好的理解和细化；化；l不要限制用户对问题的回答，这有可能会引出原先没不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；有注意的问题；l提问和回答在汇总后应能够反映用户需求的全貌。提问和回答在汇总后应能够反映用户需求的全貌。 l执行访谈时l首先采用无场景问题（Context-free question），避免个人偏见影响访谈效

9、果l然后采用方案场景的问题，挖掘未被表达出的需求l访谈期间及时确认你的理解l做记录l结束时，要简要总结，确保无遗漏、理解正确l致谢l访谈之后l文档化访谈报告l同被访谈者确认访谈结果l访谈报告作为需求分析的输入l例：“赛艇比赛成绩计算系统”的第一次面谈的准备计划 初次与初次与Dartchurch航行俱乐部的航行秘书（航行俱乐部的航行秘书（DR）接触，面谈有关）接触，面谈有关事宜。事宜。(在电话交谈时，了解到他们希望得到的是一个在电话交谈时，了解到他们希望得到的是一个“价廉价廉”的，的，基于基于PC的系统，以用于计算赛艇比赛成绩的系统，以用于计算赛艇比赛成绩)时间：时间：2005-6-5地点：对方

10、场地地点：对方场地主要问题主要问题确定基本问题。确定基本问题。确定确定DR的角色的角色还涉及其它人员吗？还涉及其它人员吗？调查财物方面事宜。调查财物方面事宜。系统（大致上）是如何运作的？系统（大致上）是如何运作的？当前存在的问题是什么？当前存在的问题是什么？他们都希望做些什么？他们都希望做些什么？l到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。 l便利的应用规约技术(Facilitated Application Specification Techniques , FAST) ：打破用

11、户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调 在中立的地点举行由开发者和用户出席的会议；建立准备和参与会议的规则；建议一个足够正式的议程以便可以进行自由的交流；一个“协调者”(他可以是用户、开发者或其他外人)来控制会议；使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)；目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。1)当举行了开发者和用户之间的初步访谈后，确定一个FAST会议的时间地点，并在会议日之前将产品请求发布给所有的与会者。2)要求每个FA

12、ST 出席者会前列出一组围绕系统环境的对象，以及对这些对象的操作或对象之间的交互功能，并开发出约束列表(如，成本、规模大小、权重)和性能标准列表(如，速度、精度)。这些列表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉。3)进行FAST 会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思想。在建好所有主题的组合列表后，开始讨论活动。缩短、加长或重新组合列表以适当地反映将被开发的产品。l4)一旦创建了意见一致的列表，应该将团队分为更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中

13、的单词或短语的精细化）。每个小组然后将他们开发的每个小规约提交给所有的FAST 出席者讨论，进行添加、删除或进一步的精化等工作。（在所有讨论过程中，团队可能提出某些不能在会议过程中解决的问题，此时要保留问题列表以使这些思想在以后的活动中产生作用。）l5)在小规约完成后，每个FAST 的出席者提出一个针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表。这个列表作为需求获取的结果，为需求分析和建模提供基础信息。l当需求作为非正式会议、Fast的一部分而收集起来之后，分析员就可以创建一组标识一串待建造系统的使用场景。 l创建用况模型的主要步骤如下：1)1)确定谁会直接

14、使用该系统，即参与者（确定谁会直接使用该系统，即参与者（ActorActor） 2)2)选取其中一个参与者选取其中一个参与者 3)3)定义该参与者希望系统做什么，参与者希望系统作的每件定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况事将成为一个用况 4)4)对每件事来说，何时参与者会使用系统，通常会发生什么，对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程这就是用况的基本过程 5)5)描述该用况的基本过程描述该用况的基本过程l需求工程概述l需求获取l需求规约与验证l需求管理1必须能够表示和理解问题的信息域2必须能够定义软件将完成的功能3必须能够表示软件

15、的行为(作为外部事件的结果)4必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节5分析过程应该从要素信息移向细节信息l干系人的需要（needs）、期望和优先级通常不会描述足够细化或使用定量的术语l设计、开发和测试等活动都需要详细的、可测量的需求描述l定义需求意味着把需要（needs）转化为需求（requirement）描述 注意：需求定义可能会经历多轮迭代。l完整的理解用户/客户的需求l消除需求中的不一致性、不规则的地方l识别隐含的需求，特别是非功能性需求l需求文档化l在创建需求分析之前先理解问题、挖掘用户需求l所有的需求要有来源l为不清楚的需求开发原型l平衡和消除需求间的冲突l使用

16、不同视图/模型表达需求l定义所有的功能l定义所有的信息域l表达外部事件的因果关系与行为l描述信息、功能和行为的模型必须以分层的形式描述l分析的过程是从基本信息向实现的细节迁移的过程l信息域：包括信息内容、信息流、以及信息结构。l信息内容表示了单个数据和控制对象，目标软信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。件所有处理的信息集合由它们构成。 l例如，数据对象例如，数据对象“工资工资”是一组重要数据体的是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、组合：领款人的姓名、净付款数、付款总额、扣除额等等扣除额等等 l信息流表示了数据和控制在系统中流动时的变化信

17、息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息方式，输入对象被变换为中间信息( (数据和数据和/ /或控或控制制) )，然后进一步被变换为输出，然后进一步被变换为输出l信息结构表示了各种数据和控制项的内部组织信息结构表示了各种数据和控制项的内部组织 l数据或控制项将被组织为n维表还是树形结构？l在结构的语境内，什么信息是和其他信息相关的？l信息包含在单个结构中，还是使用不同的结构？l在某信息结构中的信息如何和在另一个结构中的信息相关？ l协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案 l协商不是简单的逻辑或技术上的争论 l要注意组织和行政方面的因素 不一致的目标

18、不一致的目标 责任的丧失或转移责任的丧失或转移 组织文化组织文化 组织管理态度和士气组织管理态度和士气 部门差异部门差异 l通常会议是解决冲突最快的方式 l参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 l会议应该讨论那些非正式讨论不能解决的问题 l通常会议分为三个阶段：l叙述阶段叙述阶段l讨论阶段讨论阶段l决策阶段决策阶段 l在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做l目标软件的模型不应涉及软件实现细节 An ActorA Use CaseAn ActorA Use Case箭头表明谁发起交换箭头表明谁发起交换有时用有时用us

19、e case会发起一个交互会发起一个交互l常用的分析方法：l面向数据流的结构化分析方法面向数据流的结构化分析方法 (SA)(SA)l面向数据结构的分析方法面向数据结构的分析方法 l面向对象的分析方法面向对象的分析方法 (OOA)(OOA)l需求工程概述l需求获取l需求分析、协商与建模l需求管理1从现实中分离功能，即描述要“做什么”而不是“怎样实现”。2要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。3如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中

20、。4规约必须包括系统运行环境。5规约必须是一个认识模型，而不是设计或实现的模型。6规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。7规约必须允许不完备性并允许扩充。8规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。l具有良好的可读性，站在读者的角度上写l句子和段落要短，采用主动语气l使用正确的语法，拼写，标点l有图形和表格等配合描述l使用术语，要保持一致性，并在术语表或数据字典中定义它们l一个需求中的有连接词“和”

21、、“或”，可能是多个需求合成了单个需求，应该分解为多个需求l避免在需求文档中过多的冗余描述l需求要被有效的定义，如需额外的解释则有效性还不够l至少包括：l功能性需求l非功能性需求l设计与实现的约束条件l不应包含在需求规格说明中的：l 项目的需求（人力资源要求、里程碑与时间点要求等）l设计l产品质量保证计划等l快速l足够l易于l通常l有时l显然l等等l先进的l标准的l用户友好的l有效的l精确的l灵活的l不限于l每条需求要独立描述，不要有需求组合描述的情况，避免“需求1和需求2”这样的情况l文档组织清晰，按需求类别进行组织内容l内容没有冗余，采用引用的方式避免重复书写l便于增加需求l便于删除需求l

22、便于更改需求l写好需求文档的前提是做好需求挖掘和需求分析l全面识别需求干系人并把使之参与需求挖掘和分析活动中l项目的需求阶段主要活动不是写文档，而是调研、讨论和确认l好需求文档图文并茂，并满足需求文档特点要求l写需求文档前使用需求文档检查表以确保一次把文档写好l通过有效评审过程进一步提高需求文档的质量l业务领域知识l有效沟通能力l软件需求建模能力l需求文档化能力. 引言引言 A.系统参考文献系统参考文献B.整体描述整体描述C.软件项目约束软件项目约束. 信息描述信息描述 A.信息内容表示信息内容表示B.信息流表示：信息流表示： 数据流数据流 控制流控制流. 功能描述功能描述 A.功能划分功能划

23、分 B.功能描述：功能描述： 处理说明处理说明 限制限制局限局限 性能需求性能需求 设计设计约束约束 支撑图支撑图 C.控制描述控制描述 控制规约控制规约 设计约束设计约束. 行为描述行为描述 A.系统状态系统状态 B.事件和响应事件和响应. 检验标准检验标准 A.性能范围性能范围B.测试种类测试种类C.期望的软件响应期望的软件响应D.特殊的考虑特殊的考虑. 参考书目参考书目. 附录附录l引言：陈述软件目标，在基于计算机的系统语境内进行描述。l信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。l功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙

24、述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。l行为描述：描述作为外部事件和内部产生的控制特征的软件操作。l检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。l参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。l附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。l需求验证目的是要检验需求是否能够反映用户的意愿 l评审人员评审时往往需要检查以下内容：1.1.系统定义的目标是否与用户

25、的要求一致；系统定义的目标是否与用户的要求一致；2.2.系统需求分析阶段提供的文档资料是否齐全；文档中系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求；的描述是否完整、清晰、准确地反映了用户要求；3.3.被开发项目的数据流与数据结构是否确定且充足；被开发项目的数据流与数据结构是否确定且充足；4.4.主要功能是否已包括在规定的软件范围之内，是否都主要功能是否已包括在规定的软件范围之内，是否都已充分说明；已充分说明；5.5.设计的约束条件或限制条件是否符合实际；设计的约束条件或限制条件是否符合实际；6.6.开发的技术风险是什么；开发的技术风险是什么；7.7.

26、是否详细制定了检验标准，它们能否对系统定义是否是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。成功进行确认。 尽早发现需求文档中的缺陷通过评审熟悉整个系统促进参与人员之间的技术交流和相互学习 增进团队交流，增加团队凝聚力使作者能高质量地完成工作产品计划计划介绍会议介绍会议预评审预评审会议会议缺陷跟踪缺陷跟踪分析分析上游工作产品的作者 如客户代表、市场人员、系统工程师依据该工作产品开展下游工作的人员 设计人员、测试人员、用户资料写作人员、维护人员与该工作产品存在接口关系的人员 硬件人员、相关系统的工程师作者的同行、专家 领域专家下游下游上游上游相关组相关组l需求工程概述l需求获取l需

27、求分析、协商与建模l需求规约与验证l需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动 l需求跟踪有两种方式，正向跟踪与逆向跟踪 l正向跟踪：以用户需求为切入点，检查正向跟踪：以用户需求为切入点，检查需求规约需求规约中的每个中的每个需求是否都能在后继工作产品中找到对应点需求是否都能在后继工作产品中找到对应点l逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在能在需求规约需求规约中找到出处中找到出处l变更控制l对需求的变更进行管理l需求跟踪l和其它需求之间的关系l和其它项目交付件之间的关系l版本控制l标识需求文档的版本l标识每条需求的修订l需求状态跟踪l定义需求状态l跟踪每条需求的状态l需求变更是不可避免的，甚至是必要的l需求基线是需求变更的前提l需求变更过程是一个受控的有序的过程l过于频繁的需求变更，其根源是需求开发能力弱l变更可能外部触发或内部触发，都要填写变更申请l外部触发（如客户提出变更）的需求变更，一般由项目内部人员填写变更申请l变更申请内容包括：l变更内容l变更类型l变更原因l外部原因l客