搜索
制作者程丽软件工程第二章需求工程本章介绍以下内容可行性分析需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理课程的任务、目的和基本要求掌握可行性分析的方法掌握需求工程的定义及六个阶段掌握软件需求内容掌握需求获取的方法与策略掌握需求分析原则掌握需求规约的原则掌握需求规约的内容了解需求验证过程了解需求管理相关概念接下来介绍可行性分析需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理可行性研究的任务可行性研究的具体步骤系统流程图成本－效益分析方案的选择和折衷可行性分析的结论可行性研究的文档可行性分析提出问题→有无解决的办法→是否值得去做可行性研究的目的可行性研究的任务技术可行性确定技术风险，项目实现的可能性经济可行性考虑投入—产出，市场前景，经营策略社会可行性考虑合同、责任、侵权、用户组织的管理模式及规范问题可行性研究的步骤确定项目规模和目标研究正在运行的系统－系统流程图建立新系统的高层逻辑模型－简单数据流图导出和评价各种方案推荐可行的方案编写可行性研究报告，交使用部门审查用图形符号描述项目处理流程、范围和功能处理输入/输出连接换页连接数据流文档联机存储磁盘显示人工输入人工操作辅助操作通信链路系统流程图工资处理过程：每月末教师把他们当月实际授课时数登记在课时表上，由各系汇总后交给财务科。职工把他们当月完成承包任务的情况登记在任务表上，汇总后交给财务科。会计根据这些原始数据计算每名教职工的工资，编制工资表、工资明细表。然后，把记有每名教职工工资总额的工资表报送银行，由银行把钱打到每名教职工的工资存折上，同时把工资明细表发给每名教职工。例子：人工系统计算工资和编制报表教师课时表任务表职工工资支付系统工资表工资明细表银行教师职工成本效益分析效益表现有形效益：无形效益：货币的时间价值、投资回收期、纯收入从性质上、心理上进行衡量货币的时间价值F=P*(1+n*i)(不计复利)P=F/(1+n*i)i----利率P---现在值（元）n----年数F---将来值（元）成本效益分析成本效益分析投资回收期使累计的经济效益等于最初投资费用所需的时间投资回收期越短，就越快获得利润纯收入整个生存周期之内的累计经济效益（折合成现在值）与投资之差一个系统可以有多个可行的实现方案，每个方案对成本、时间、人员、技术、设备都有不同的要求，不同方案开发出来的系统在功能、性能方面也会有所不同。因此要在多个可行的实现方案中作出选择。由于系统的功能和性能受到多种因素的影响，某些因素之间相互关联和制约。如，为达到高的精度就可能导致长的执行时间，为达到高可靠性就会导致高的成本等等。因此，在必要时应进行折衷。方案的选择和折衷可行性分析的结论可以立即开始进行需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行需要对开发目标进行某些修改之后才能开始进行因为某种原因（如，技术不成熟、经济上不合算等）不能进行可行性研究的文档在可行性研究后提交的文档，包括引言可行性研究前提对现有系统的分析所建议的系统可选择的其它系统方案投资及效益分析社会因素方面的可行性分析结论接下来介绍可行性分析需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理软件需求工程细分为需求获取需求分析与协商系统建模需求规约需求验证需求管理需求工程需求获取系统分析人员与用户交流，对现有系统观察，对任务进行分析，确定系统或产品的范围，与系统或产品有关的人员及特征，系统的技术环境，系统功能，应用于每个需求的领域限制，一组描述不同运行条件下系统或产品使用状况的应用场景。需求分析与协商需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其它需求的关系，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。在需求获取阶段，经常出现以下问题：用户提出的要求超出软件系统可以实现的范围或实现能力；不同的用户提出了相互冲突的需求系统建模建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。需求规约软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。需求验证作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。获取分析与建模编写规约验证重新评估更正并减小误差证实重写需求管理需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。接下来介绍可行性分析需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理软件需求包括功能需求性能需求用户或人的因素环境需求界面需求文档需求数据需求资源使用需求安全保密要求可靠性需求软件成本消耗与开发进度需求其他非功能性要求需求获取方法与策略建立顺畅的通信途径访谈与调查观察用户操作流程组成联合小组用况（UseCase）建立顺畅的通信途径建立分析所需要的通信途径，以保证能顺利地对问题进行分析。访谈与调查在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；提问和回答在汇总后应能够反映用户需求的全貌。例：“赛艇比赛成绩计算系统”的第一次面谈的准备计划初次与Dartchurch航行俱乐部的航行秘书（DR）接触，面谈有关事宜。(在电话交谈时，了解到他们希望得到的是一个“价廉”的，基于PC的系统，以用于计算赛艇比赛成绩)时间：2005-6-5地点：对方场地主要问题确定基本问题。确定DR的角色――还涉及其它人员吗？调查财物方面事宜。系统（大致上）是如何运作的？当前存在的问题是什么？他们都希望做些什么？观察用户操作流程到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。组成联合小组便利的应用规约技术(FacilitatedApplicationSpecificationTechniques,FAST)：打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调FAST基本原则①在中立的地点举行由开发者和用户出席的会议；②建立准备和参与会议的规则；③建议一个足够正式的议程以便可以进行自由的交流；④一个“协调者”(他可以是用户、开发者或其他外人)来控制会议；⑤使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)；⑥目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。FAST会议步骤1)当举行了开发者和用户之间的初步访谈后，确定一个FAST会议的时间地点，并在会议日之前将产品请求发布给所有的与会者。2)要求每个FAST出席者会前列出一组围绕系统环境的对象，以及对这些对象的操作或对象之间的交互功能，并开发出约束列表(如，成本、规模大小、权重)和性能标准列表(如，速度、精度)。这些列表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉。3)进行FAST会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思想。在建好所有主题的组合列表后，开始讨论活动。缩短、加长或重新组合列表以适当地反映将被开发的产品。FAST会议步骤(续)4)一旦创建了意见一致的列表，应该将团队分为更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中的单词或短语的精细化）。每个小组然后将他们开发的每个小规约提交给所有的FAST出席者讨论，进行添加、删除或进一步的精化等工作。（在所有讨论过程中，团队可能提出某些不能在会议过程中解决的问题，此时要保留问题列表以使这些思想在以后的活动中产生作用。）5)在小规约完成后，每个FAST的出席者提出一个针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表。这个列表作为需求获取的结果，为需求分析和建模提供基础信息。用况（UseCase）当需求作为非正式会议、Fast的一部分而收集起来之后，分析员就可以创建一组标识一串待建造系统的使用场景。创建用况模型的主要步骤如下：1)确定谁会直接使用该系统，即参与者（Actor）2)选取其中一个参与者3)定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况4)对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程5)描述该用况的基本过程接下来介绍可行性分析需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理需求分析原则1．必须能够表示和理解问题的信息域2．必须能够定义软件将完成的功能3．必须能够表示软件的行为(作为外部事件的结果)4．必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节5．分析过程应该从要素信息移向细节信息为什么要引入信息域？所有的软件应用程序均可被称为数据处理。如：工资系统的批处理软件，开发控制汽车发动机油流的实时嵌入式软件。将数据从一种形式变换为另一种形式对事件的处理也不例外。例如，压力传感器检测压力是否超过安全值，并发送警报到监控软件，警报信号是一个事件，该事件控制系统的行为。因此，数据(数值、字符、图象、声音等)和控制(事件)二者均驻留于问题的信息域内。信息域信息域：包括信息内容、信息流、以及信息结构。信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出信息结构表示了各种数据和控制项的内部组织•数据或控制项将被组织为n维表还是树形结构？•在结构的语境内，什么信息是和其他信息相关的？•信息包含在单个结构中，还是使用不同的结构？•在某信息结构中的信息如何和在另一个结构中的信息相关？信息域抽象、分解与多视点分析问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系首先关注一般问题的解决途径，进而指导特殊问题的解决方法。问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分例如横向分解纵向分解需求协商协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案协商不是简单的逻辑或技术上的争论要注意组织和行政方面的因素①不一致的目标②责任的丧失或转移③组织文化④组织管理态度和士气⑤部门差异通常会议是解决冲突最快的方式参加者