北京理工大学软件工程实践

《北京理工大学软件工程实践》由会员分享，可在线阅读，更多相关《北京理工大学软件工程实践（62页珍藏版）》请在金锄头文库上搜索。

1、北京理工大学 软件工程实践汤铭端 中国航天科工集团公司204所第四讲需求分析内容n需求分析概念n需求分析过程n需求分析方法n需求分析产品目的n掌握需求分析基本概念n掌握需求分析过程n了解基本需求分析方法（DFD+DD）n了解需求规格说明的内容条目软件需求的定义n客户定义的“需求”对开发者是一个较高层次的产品概念。n开发者所说的“需求”对用户来说像是详细说明。n软件需求包含多个层次，不同层次的需求从不同角度与 不同程度反映着细节问题。nIEEE软件工程术语（1997）的需求定义： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正 式强制性文件所需

2、具有的条件或能力。 （3）反映上面（1）或（2）所描述的条件或能力的文档 说明。n上述定义包括从用户（外部）、从开发者（内部）角度 来阐述需求。需求的层次n业务需求（business requirement）： 反映组织机构或客户对系统、产品高层 次的目标要求。n用户需求（user requirement）：描述 用户使用产品必须要完成的任务。n功能需求（functional requirement）： 定义开发人员必须实现的软件功能。n需求规格说明中还包括非功能需求。软件需求各组成部分之间关系业务需求用户需求功能需求系统需求质量属性其它非功能需求约束条件项目视图与范围文件使用实例文档软件需求

3、规格说明不成熟的需求分析n无足够用户参与n用户需求的不断增加n摸棱两可的需求n不必要的特征（镀金）n过于精简的规格说明n忽略了用户分类n不准确的计划高质量需求过程的获益n开发后期和整个维护阶段的重做的工作大大减少nBoehm发现可以节省成本68倍n有研究认为可以节省成本200倍n强调产品开发中的通力合作，面向市场，让用户积 极参与，可以建立忠实的客户关系，避免在无用功 能上白耗精力，弥补用户期望和开发者实际开发间 的期望鸿沟n采用系统方法将需求分配到各子系统可以简化集成n有效的变更控制和影响分析能降低变更的负面影响n清晰、无二义的需求文档有利于测试需求说明的特征n完整性n正确性n可行性n必要性

4、n划分优先级n无二义性n可验证性需求规格说明的特点n完整性n先用TBD标明缺项n在开发前必须解决所有TBDn一致性n可修改性n每项需求只在SRS中出现一次n可追踪性n结构、粒度方便设计、实现、测试的追踪谁是客户n定制软件：合同甲方（提出方）n通用软件：高层管理者和（或）市场部n嵌入式软件：软件所属计算机系统客户的权利1 要求分析人员使用符合客户语言习惯的表达 2 要求分析人员了解客户的业务及目标 3 要求分析人员编写软件需求规格说明 4 要求得到需求工作结果的解释说明 5 要求开发人员尊重你的意见 6 要求开发人员对需求及产品实施提供建议 7 描述产品易使用的特性 8 调整需求，允许重用已有的

5、软件组件 9 要求对变更的代价提供真实可信的评估 10 获得满足客户功能和质量要求的系统客户的义务1 给分析人员讲解你的业务 2 抽出时间清楚地说明并完善需求 3 准确而详细地说明需求 4 及时地作出决定 5 尊重开发人员的需求可行性及成本评估 6 划分需求优先级别 7 评审需求文档和原型 8 需求出现变更要马上联系 9 应遵守开发机构处理需求变更的过程 10 尊重开发人员采用的需求工程过程对签定需求协议的认识n签约是客户同意需求的标志行为n客户不应当忽略签约的严肃性n开发方不应当因此拒绝变更n签约应当建立在一个需求协议的基线上n应当理解为：“我同意这份文档表达了目前我 们对项目软件需求的了解

6、。进一步的变更可 在此基础上通过项目定义的变更过程来进行 。我知道变更可能会使我们要重新协商成本 、资源和项目时间工期任务等。”需求开发过程n需求获取n需求分析n编写需求规格说明n需求验证n知识培训n需求管理n项目管理需求获取的内容n在同用户的交流过程中收集各种用户的 信息n认真理解用户的各项要求n澄清模糊n排除不合理n明确约束分析人员的两个信条第一：只有在彻底了解和掌握了用户的全 部意图之后，才有可能建立起成功的软 件系统。 第二：一切从用户的角度着想，在条件允 许的情况下，应尽可能地保证用户从所 构造的软件系统中获得最大的利益。容易产生的问题n交流障碍n误解n各方缺乏共同的语言n“完整性”

7、问题n需求永远会变化n用户本身的意见不一致n错误的要求n认识上混淆目标和需求需求获取的过程n确定需求开发过程n编写项目目标和范围文档n将用户群分类并归纳各自特点n选择各类用户的产品代表n建立起典型用户的核心队伍n让用户代表确定使用实例n召开应用程序开发联系会议n分析用户工作流程n确定质量属性和其它非功能属性n通过检查当前系统的问题报告来进一步完善需求n跨项目重用需求建立模型的步骤n分析现有系统和过程，建立物理模型n抽取特征，建立旧系统的逻辑模型n根据新的要求，补充和建立新的逻辑模 型需求分析的内容n提炼、分析和仔细审查已收集到的需求n确保所有利益相关者都明白其含义并找 出其中的错误、遗漏或其它

8、不足的地方n是从用户最初的非形式化需求到满足用 户要求的软件产品的映射过程n是对用户意图不断进行提示和判断的过 程需求分析的过程n绘制系统关联图n创建用户接口（界面）原型n分析需求可行性n确定需求的优先级别n为需求建立模型n创建数据字典n使用质量功能调配（QFD）n明确哪些是客户最关心的特征编制需求规格说明的过程n采用软件需求规格说明（SRS）模版n指明需求的来源n为每项需求注上标号n记录业务规范（操作原则）n创建需求跟踪矩阵需求规格说明的作用n为用户、分析人员和设计人员之间的交 流提供方便n支持目标软件系统的确认n控制软件开发进程软件需求规格说明文档条目1 范围 2 引用文档 3 工程需求

9、3.1 外部接口需求 3.2 功能需求 3.3 内部接口 3.4 数据元素要求 3.5 适应性要求 3.6 容量和时间要求 3.7 安全要求3.8 保密要求 3.9 设计约束 3.10 软件质量因素 3.11 人的工程需求 3.12 需求的可跟踪性 4 合格性需求 4.1 合格性方法 4.2 特殊的合格性需求 5 交付准备软件需求必须包括的属性1）标识：每项软件需求都必须有标识，使以后的各阶段容易跟踪 。 2）需要：基础软件需求必须用上述标识标明。基础软件需求是非 协商性的；其它不那么重要的需求是可协商的。 3）优先级：对于递增式交付，每一项需求必须包括优先级程度， 以便决定研制进度。 4）稳

10、定性：某些需求在软件生存期内是稳定的；另一些可能是更 依赖来自各设计阶段的反馈，或可能在软件生存期内要有所修 改，这种非稳定性需求应当被指出。 5）源：每一项软件需求都必须有一个能回溯到系统需求的索引。 6）清晰性：如果需求有一个并且只有一个解释它就是清晰的。 7）验证性：每一软件需求都必须是能被验证的。这意味着必须能 做到：检查需求已经体现在设计中；证明该软件将实现需求； 测试该软件确实能实现需求。IEEE需求规格说明的编写8原则1 从实际重分离功能，描述“做什么”不描述“怎么做” 2 要求有一个面向处理的软件系统规格说明语言，以描 述软件系统的动态行为 3 必须对以该软件为元素的系统进行说

11、明，以描述清楚 之间的关系 4 必须对软件系统的运行环境进行说明，以保持接口描 述的一致性 5 必须是认识的模型而不是实际的模型 6 必须是可操作的 7 必须容忍不完备性和可修改性 8 必须局部化和松散耦合，使得变化时只修改一个片段SRS编写风格（Kovitz 1999)n保持语句和段落的简短n采取主动语态的表达方式n编写具有正确的语法、拼写和标点的完整句 子n使用的术语和词汇表中所定义的应该一致n需求陈述应该采用一致的样式，如“主体+动 作+可观察的结果”n避免使用模糊的、主观的术语以避免不确定 性n避免使用比较性的词汇需求验证n审查需求文档n以需求为依据编写测试用例n编写用户手册n确定判别

12、产品合格的准则需求验证的内容n一致性：任何需求不与其它需求矛盾n可行性：现有技术条件下可以实现n完整性：包括用户需要的每一个功能和 性能n有效性：正确有效，确实能够解决用户 面对的问题知识培训n培训需求分析人员n培训软件需求的用户代表和管理人员n让开发人员了解应用领域的基本概念n编写项目术语汇编分析员的职责）作为管理员、用户和顾客的顾问； ）从各种来源收集数据，并综合问题的解答 ； ）分析新的系统，并评价现有的系统； ）准备文档和管理报告； ）理解硬件和软件的界面； ）为了产生软件需求规格说明，必要时要进 行一些研究工作； ）为编写软件需求规格说明主持座谈会； ）不断吸收先进技术。分析员的素质

13、）能够合乎逻辑地、象征性地、抽象地、创造性地思 考问题； ）能作为小组中的一个成员很好地开展工作； ）熟悉计算机硬件和软件的能力； ）自觉遵守时间，能按规定的进度完成任务； ）在系统的分析和设计中能发挥其他人的作用； ）能保持教师和学生的双重身份，愿意培养其他人， 而他本人亦能通过夜校、自学、培训班等不断提高 ； ）能够倾听别人的意见，但又能根据客观事实来作决 策，而不是依赖别人的意见； ）熟悉商业和政策管理部门的组织、原则。分析员应该显示的性格特征1）善于领会一些抽象的概念，重新整理使之成为 各种逻辑成分，并根据各种逻辑成分综合出问题 的解决办法。 2）善于从各种相应冲突或混淆的原始资料中汲

14、取 恰当的依据。 3）能够理解用户需求者的环境。 4）具备把系统的硬件部分和（或）软件部分应用 于用户需求者环境的能力。 5）具备良好的用书面或口头形式进行讨论及交换 意见的能力。 6）具有“既能看到树木，又能看到森林”的能力。需求管理n确定需求变更控制过程n建立变更控制委员会（CCB）n进行需求变更影响分析n跟踪所有受需求变更影响的工作产品n建立需求基准版本和需求控制版本文档n维护需求变更历史记录n跟踪每项需求的状态n衡量需求稳定性n使用需求管理工具与需求分析相关的项目管理n选择一种合适的软件开发模型n基于需求的项目计划n发生需求变更时协商项目约定n文档化和管理与需求相关的风险n跟踪需求工程

15、耗费的工作量描述工具n数据流图(Data Flow Diagram，简称 DFD)n控制流图(Control Flow Diagram，简称 CFD)n状态转换图（State Transition diagram ，简称STD）n数据字典(Data Dictionary，简称DD)n处理说明模型结构过程模型PSPECDFD控制模型CSPECCFD控制输入数据输出控制输出数据输入数据条件过程启动数据流图图符2.1 打印数据流Data Flow 加工处理Process外部实体External Entity数据存储Data Store数据流图图符说明n数据流：箭头表示数据流方向。一般在旁边 标注数据

16、流名。n加工处理：对数据进行加工、处理和变换， 从而实现某个功能或操作n外部实体：表示要加工处理的数据是从外部 得到或从外部提供，同时也是数据结果的接 收者，可以是人、组织、其它系统n数据存储：表示处理过程中存放各种数据的 文件建立DFD的步骤n由外向里：先画系统的输入输出，然后 画系统的内部，再画处理的内部。n由顶向下： 顶层、中间层、底层数据 流图n逐层分解：从外向里顶层DFDn用一个加工处理表示软 件n含所有相关外部实体n含外部实体与软件中间 的数据流n不含数据存储n唯一n描述软件的作用范围， 对总体功能、输入、输 出进行抽象描述，反映 软件和系统、环境的关 系ABC软件ab cd中间和底层DFD2.1 aaa2.2 bbb2.3 cccddd数据DFD规则和注意事项n数据存储不出现在顶层图中，外部实体通常 不出现在顶层图外n数据存储之间不应该有数据流n仔细、恰当地为处理命名：处理+对象n仔细、恰当地为数据流命名：反映整体含义n对处理建立唯一、层次性编号n每个处理通常要求既有输入又有输出n一个DFD的处理个数为72（魔数7 2）n不要试