第3章需求工程概论

第3章需求工程概论3.1软件需求的概念3.2需求工程的预备知识3.3需求工程的过程模型22017/6/14需求的任务：•回答“系统必须做什么？”的问题•What?32017/6/143.1软件需求的概念软件需求的定义：•是利益相关方（stakeholder，也称“筹码持有者”）对目标软件系统在功能、质量等方面的期望，以及对目标软件系统在运行环境、资源消耗等方面的要求或约束。42017/6/143.1软件需求的概念3.1.1软件需求的分类•软件需求:①功能需求②质量需求③约束性需求质量需求和约束性需求可统称为非功能需求。•功能需求：指利益相关方要求目标软件系统应该具有的功能。（主体）如“制订选课计划”、“接收并处理传感器数据”等。•功能需求还包括软件系统在业务处理过程中完成这些功能时必须遵守的约定或限制。•质量需求:利益相关方对目标软件系统的质量要求。性能：所有界面操作的响应时间小于1.5秒”、可靠性：任何故障不可导致用户已提交的数据丢失”。52017/6/143.1.1软件需求的分类3.1软件需求的概念•约束性需求:利益相关方对目标软件系统在项目预算、完成时间、技术选型、遵循的标准与规范等方面提出的要求，以及由预期的开发、运行环境的特征而导致的针对目标软件系统的约束。如家庭保安系统中可供软件使用的内存为1M、必须采用特定的操作系统62017/6/143.1.1软件需求的分类3.1软件需求的概念3.1.2软件需求的质量要素•正确性包含真实性、一致性、精确性、无冗余四个质量指标。•完全性指，所有需求项构成的全集完整地覆盖所有必须在目标软件产品中实现的利益相关方需求，不能遗漏重要或者紧迫的需求。•可行性是指，在实际资源约束条件下，软件需求能够被完整实现的可能性。72017/6/143.1软件需求的概念3.2需求工程的预备知识3.2.1与用户交流的技巧•利益相关方代表和需求工程师组成联合工作组•克服沟通障碍•消弥利益冲突82017/6/143.2.2需求调查的基本方法•访谈和会议系统分析员将提出一些事先准备好的具体问题。•调查问卷经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。•业务文档分析•现场观摩92017/6/143.2需求工程的预备知识3.2.3需求建模的基本方法•抽象•分解•多视点分析102017/6/143.2需求工程的预备知识3.3需求工程的过程模型一个完整的需求工程过程一般包含以下活动:•需求工程策划•需求获取需求获取的结果是软件需求的最初模型。•需求分析•需求规范化•需求验证•总结112017/6/143.3.1需求工程中的活动3.3需求工程的过程模型122017/6/143.3.1需求工程中的活动图3.1用UML活动图表示的需求工程过程的工作流图3.2单次子过程中的缺陷追踪及返工3.3.2迭代式的过程模型•对于大中型软件项目，前述的单次需求工程过程几乎不可能获得完整的、高质量的软件需求。132017/6/14图3.3迭代式的需求工程过程模型3.3需求工程的过程模型•进入每次迭代前，应检查入口条件是否满足、输入文档是否齐备。•在完成每次迭代前，应检查出口条件是否达到、输出文档是否齐备并符合预定的质量标准。•首次迭代的输入为有关项目目标、范围的陈述性文档；后续迭代时，输入文档还可以包括缺陷描述、待新增的需求项的概略性描述文档，或者需求变更申请书。•需求获取活动必须针对前次迭代的工作成果、需求变更或缺陷报告进行理解和分析，由此导出新的需求获取动作。•在一次迭代完成后进入后续迭代的条件是，所有参与者对新需求的获取或针对已有需求的变更之必要性达成共识。142017/6/143.3.2迭代式的过程模型3.3需求工程的过程模型3.3.3过程模型的裁剪•在实际的软件项目中，针对前述的迭代式过程模型可以进行因地制宜的裁剪或具体化。（1）应用场景1•对于小型软件项目或软件需求容易确立的项目，迭代仅需进行一次。152017/6/143.3需求工程的过程模型3.3.3过程模型的裁剪（2）应用场景2•如果一个软件能够分解成多个子系统，那么，针对各子系统的需求工程活动可以并行地在各自的迭代子过程中进行。•此前必须通过至少一个迭代子过程给出整个软件的概略性需求并确定分解结构；•最后必须通过至少一个迭代子过程对各部分的需求进行整合并给出完整的软件需求规约。162017/6/143.3需求工程的过程模型172017/6/14图3.4系统分解后针对子系统并行迭代的需求工程过程模型示意图需求工程各阶段中的某些子活动可以并行开展•如，可以将课程注册管理系统划分为面向学生、面向教师和面向教务管理员的三个子系统，安排三轮迭代分别针对它们进行需求获取和分析，最终整合为完整的需求规约。182017/6/143.3.3过程模型的裁剪3.3需求工程的过程模型（3）应用场景3•在本次迭代的需求验证阶段，如果发现了缺陷，或认为某些需求项需要新增或变更，可以形成缺陷分析报告或需求变更申请报告，以此为输入启动下次迭代。•在迭代式过程模型中，缺陷更正和需求变更可以很自然地在后续迭代过程中实现。192017/6/143.3.3过程模型的裁剪3.3需求工程的过程模型202017/6/14图3.5通过迭代支持缺陷更正和需求变更的需求工程过程模型例3.1家庭保安系统需求工程过程•成立由需求工程师和利益相关方代表组成的联合工作组•制定工作制度，如，每次会议开始前必须有确定的议程，参加者必须针对各项议程进行充分的准备，这种准备不仅是思想上的，还应形诸文字。•经过数次会议讨论，明确待解软件问题的范围、业务背景，并就开发软件产品的必要性达成共识后，工作组负责人要求每位参加者列出应用问题及环境中有关的对象，这些对象所施行的操作以及对象间的相互作用。这种列举不一定完全，但应尽可能全面地反映用户熟悉的某个问题侧面。212017/6/143.3需求工程的过程模型•市场营销人员可能列出控制面板、电话机、警报器等对象，以及用户配置、电话拔号、报警等操作；•负责策划该系统的客户可能列举门窗监视器、烟雾传感器、警报器等对象。•会议上，负责人要求他们对传感器事件接收、异常情形判别、电话报警、用户配置等操作进行更详细的描述，必要时示以业务处理流程图。•客户可能还会提出一些约束条件，如造价不应超过1,000元，对异常事件必须在1秒内作出响应，事件必须按优先级顺序进行处理，等。•会后，需求工程师对这些信息加以综合、整理，形成文档•该文档应能反映家庭保安系统中的软件产品的全貌。222017/6/14例3.1家庭保安系统需求工程过程3.3需求工程的过程模型•该文档的某个局部可能形如：　232017/6/14家庭保安系统的软件允许用户在安装时进行系统配置，实施对传感器上报数据的监控并通过控制面板与用户进行信息交互。用户配置操作包括：(1)指定每一传感器的种类、编号和安装位置；(2)设置开、关机密码；(3)设定报警电话号码；(4)指定报警延迟和电话重拔延迟时间。当软件系统接收到传感器发出的数据后判别是否出现异常事件。如果是，则在指定的延迟时间内拔报警电话号码，拔号操作将按照重拔延迟反复进行，直至电话接通。然后软件系统负责报告时间、位置和异常事件的性质。开机后软件系统负责显示当前工作状态，接收并处理用户指令。例3.1家庭保安系统需求工程过程3.3需求工程的过程模型•联合工作组被分成两个小组，分别处理用户配置和传感器监测子系统。•分组的目的是对子问题的需求进行获取、分析、规范化等项工作。•在各子系统的需求已基本明确并形成需求模型后，联合工作组还应就子系统的整合及需求验证标准展开讨论。•子系统整合包括：子系统接口之间的一致性检查、子系统合成后系统功能和行为的完整性检查。•需求验证标准应该是可测试的，以便开发人员在代码生成后能够通过测试结果向客户表明软件系统已完整地实现了所有需求。242017/6/14例3.1家庭保安系统需求工程过程3.3需求工程的过程模型小结•软件需求指，利益相关方对目标软件系统在功能、性能、质量等方面的期望，以及对目标软件系统在运行环境、资源消耗等方面的约束。•软件需求可划分为功能需求、质量需求和约束性需求三种类型。•质量需求和约束性需求统称为非功能需求。•软件需求的质量要素包括正确性、完全性和可行性。•为了获得高质量的需求模型，需求工程师必须掌握与用户/客户交流的技巧。252017/6/14•与利益相关方代表组成目标一致、荣辱与共的联合工作组，克服开发方与利益相关方之间的沟通障碍、消弥他们之间的利益冲突。•需求工程师必须熟练运用需求调查和需求建模的基本方法，前者包括访谈和会议、调查问卷、业务文档分析、现场观摩，后者包括抽象、分解和多视点分析。•为了获得高质量的需求模型，需求工程师还必须遵循系统化的需求工程过程模型，它通常包括策划、需求获取、需求分析、需求规范化、需求验证、总结等活动。262017/6/14小结小结•对大中型软件项目以及初期需求不明朗的软件项目，需求工程过程往往采用迭代方式，经过反复发掘、分析、评审后才能日臻完善。•除以上基本技能和方法外，需求工程师有必要进一步掌握分别针对需求工程各阶段的行之有效的具体技术和方法。•第4至5章将依次介绍需求获取、需求分析及需求验证的过程和技术。272017/6/14课程实践•题目（可以参考并自选题目）1、网上购物系统①用户注册、登录、退出；②用户通过浏览器访问网上购物系统，系统以分类的形式显示所有商品；③系统提供关键词检索功能，帮助用户逐步找到所要的商品；④用户在浏览商品目录时可以点击查看商品的具体信息和价格。如果满意，用户可以将商品暂时放入“购物车”，也可以随时从“购物车”中取出商品。当用户选定后进行付款处理，用户输入信用卡号，系统连接到对应的银行卡支付系统，开始支付；⑤系统向管理员提供查询界面和各类报表，统计商品的销售情况。282017/6/14课程实践•题目（可以参考并自选题目）2、图书管理系统①管理读者的基本信息：读者姓名、姓别、学号等；②管理书籍的基本信息：图书名称、图书编号、作者、出版社、单价、存在状态（已借出或是库存）、存放地点，若已借出，则归还时间等；③对新进图书进行录入，包括图书的基本信息；④支持读者查询图书的基本信息；⑤对撤销的图书信息进行删除；⑥为读者办理注册，包括读者的基本信息；⑦为读者办理借书手续（非注册者不能借书）；⑧若读者借书到期末还，要对读者进行罚款，并记录读者的不良记录。292017/6/14课程实践•题目（可以参考并自选题目）3、在线购/订票（汽车票）系统①用户注册、登录、退出；②在线售票：用户选中要买的车票，输入银行卡号，系统链接到相应的银行支付系统，支付车票费（支付前需登录）；③在线订票：用户选中要订的车票，输入银行卡号，系统链接到相应的银行支付系统，支付车票费（支付前需登录）；④购票跟踪：跟踪用户的交易过程，记录用户的交易历史，方便用户查询；⑤出行信息：系统向用户展示当前的票务信息，包括去向、票价、车型、发车时间、到达时间、延误的概率等信息。302017/6/14课程实践•题目（可以参考并自选题目）4、教室管理系统①管理本学期要开的课程信息，包括课程的任课老师、上课时间和选课人数，以及是否要求多媒体教学等；全校的教室资源信息，包括教室的编号，最大容量，是否支持多媒体教学等；②根据课程信息和教室资源信息，给每门课安排一个最佳的上课时间和地点，保证同一个老师不在同一个时间段授两门或两门以上的课程（即授课的时间不交叉），同一个教室不在同一个时间段安排两门或两门以上的课程（即授课地点不冲突），安排的教室能够满足选课人数和多媒体的要求（假设学校的教学资源能够满足这些要求）；③如果有临时讲座，能够尽量安排一个满足讲座要求的教室，如时间、容纳人数、多媒体等；④如遇意外情况，如老师临时停课，则要实时更新教室的使用情况信息；老师有临时变更上课时间的要求，则能够查询教室的使用情况信息，并尽力为其变更时间并重新安排教室。312017/6/14