系统架构14 - 软件工程（2）-Toy模板网

这篇具有很好参考价值的文章主要介绍了系统架构14 - 软件工程（2）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

软件需求

是指用户对系统在功能、行为、性能、设计约束等方面的期望。
是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

两大过程

需求开发->需求获取、需求分析、需求定义（需求规划说明书SRS）、需求验证。
需求管理->变更控制、版本控制、需求跟踪、需求状态跟踪。

三个层次

业务需求(business requirement)

反映了组织机构或客户对系统、产品高层次的目标要求。

用户需求(user requirement)

描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望。这两种构成了用户原始需求文档的内容。

功能需求 (functional requirement)

定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。

非功能需求

作为补充，软件需求规格说明还应包括非功能需求。
它描述了系统展现给用户的行为和执行的操作等。
它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
所谓约束是指对开发人员在软件产品设计和构造上的限制，常见的有设计约束和过程约束。
质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。

概述

需求工程是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。
需求工程覆盖了体系结构设计之前的各项开发活动，主要包括分析客户要求、对未来系统的各项功能性及非功能性需求进行规格说明。
需求工程的目标简单明了：确定客户需求，定义设想中系统的所有外部特征。

活动阶段

需求获取
形成需求规格(或称之为需求文档化)
按照相关标准，生成需求模型的文档描述，用户原始需求书作为用户和开发者之间的一个协约，往往被作为合同的附件；软件需求描述规约作为后续软件系统开发的指南。
需求确认与验证
以需求规格说明为输入，通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。
需求管理
包括需求文档的追踪管理、变更控制、版本控制等管理性活动。
软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线 (Baseline)。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定 (Agreement)。需求约定是需求开发和需求管理之间的桥梁。
需求管理是一个对系统需求变更、了解和控制的过程。
需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的初稿，需求管理活动就开始了。需求管理的主要活动如图：

强调：
（1）控制对需求基线的变动。
（2）保持项目计划与需求一致。
（3）控制单个需求和需求文档的版本情况。
（4）管理需求和联系链，或管理单个需求和其他项目可交付产品之间的依赖关系。
（5）跟踪基线中的需求状态。

需求获取

通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。

基本步骤

（1）开发高层的业务模型。
建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过迭代，更深入地了解应用领域，之后再对业模型进行改进。
（2）定义项目范围和高层需求。
项目范围描述系统的边界以及系统与系统交互的参与者之间(包括组织、人、硬件设备、其他软件等)的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。常见的建模手段包括系统上下文图和系统顶层用例图等。
（3）识别用户角色和用户代表。
涉众不仅包括传统的用户、客户，还包括测试人员、维护人员、市场人员等。
首先确定所有涉众，然后挑选出每一类涉众并与他们一起工作。
用户角色可以是人，也可以是与系统打交道的其他应用程序或硬件部件。如果是其他应用程序或硬件部件，则需要以熟悉这些系统或硬件的人员作为用户代表。
（4）获取具体的需求。
确定了项目范围和高层需求，并确定了所有涉众后，就需要获取每个涉众的具体、完整和详细的需求。
（5）确定目标系统的业务工作流。
具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则。
（6）需求整理与总结。
最后对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，即软件的需求。并提出这些需求的实现条件，以及需求应达到的标准。

获取方法

（1）用户访谈
1对1-3，找有代表性的用户进行访谈，对提问者的水平是有要求的。其形式包括结构化(有剧本)和非结构化(随意发挥)两种。
（2）问卷调查
用户多，无法一一访谈，收集到的需求不够精准，比较杂乱，比较考验问卷编写者的水平。
（3）采样
从种群中系统地选出有代表性的样本集的过程，类似于数学中的数理统计。样本数量=0.25*可信度因子错误率)2
（4）情节串联板
一系列图片，通过这些图片来把需求给进行叙述出来，这样虽然生动，但是耗时
（5）联合需求计划（JRP）
通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。
（6）需求记录技术
任务卡片、场景说明、用户故事、Volere白卡。

需求分析

为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求,这就是需求分析的工作。

常见的需求分析任务：

绘制系统上下文范围关系图 (数据流图)
创建用户界面原型
分析需求的可行性
确定需求的优先级
为需求建立模型
创建数据字典
使用QFD（QFD:质量功能部署，把需求和QFD进行关联）

结构化特点：
自顶向下，逐步分解，面向数据。

三大模型

功能模型(数据流图DFD)、行为模型(状态转换图STD)、数据模型(E-R图)以及数据字典。

数据流图

数据流图DFD基本圆形元素：外部实体、假功、数据存储、数据源。

数据流: 由一组固定成分的数据组成，表示数据的流向在DFD中，数据流的流向必须经过加工

加工:描述了输入数据流到输出数据流之间的变换，数据流图中常见的三种错误:

有输入但是没有输出，称之为“黑洞。
有输出但没有输入，称之为“奇迹”。
中输入不足以产生输出，称之为“灰洞”。

数据存储：用来存储数据。
外部实体(外部主体)：是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)。

数据字典DD

数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流
文件、加工，以及组成数据流或文件的数据项做出说明，即为了描述数据流图的。
数据字典有以下4类条目: 数据流、数据项、数据存储和基本加工。(外部实体不是系统内部的内容)

需求定义

需求定义（软件需求规格说明书，SRS）：是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对任何规模和性质的软件项目都不应该缺少。

严格定义也称为预先定义(结构化定义) ，需求的严格定义建立在以下的基本假设之上: 所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形(或文字)可以充分体现最终系统，适合需求明确的情况。
原型方法，迭代的循环型开发方式，需要注意的问题：并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。特点:需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求验证

也称为需求确认，目的是与用户一起确认需求无误,，对需求规格说明书SAS进行评审和测试，包括两个步骤

需求评审：正式评审和非正式评审
需求测试：设计概念测试用例，设计场景来测试需求，没有代码.

需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

需求管理

需求基线

定义需求基线：通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行。

变更控制过程

变更控制过程用来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。一旦确定了需求基线，应该使所有已建议的变更都遵循变更控制过程。
系统架构14 - 软件工程（2）,软考系统架构,系统架构,软件工程,需求分析
(1) 问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
(2) 变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
(3) 变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤；在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略：
(1) 所有需求变更必须遵循变更控制过程。
(2) 对于未获得批准的变更，不应该做设计和实现工作。
(3) 变更应该由项目变更控制委员会决定实现哪些变更。
(4) 项目风险承担者应该能够了解变更的内容。
(5) 绝不能从项目配置库中删除或者修改变更请求的原始文档。
(6) 每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。
目前存在很多需求变更跟踪工具，这些工具用来收集、存储和管理需求变更。问题跟踪工具也可以随时按变更状态分类报告变更请求的数目

变更控制委员会CCB

也称为配置控制委员会，其任务是对建议的配置项变更做出评价、审批，以及监督已经批准变更的实施。
变更控制委员会 (Change Control Board，CCB) 是项目所有者权益代表，负责裁定接受哪些变更。 CCB 由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。 CCB 是决策机构，不是作业机构，通常CCB 的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。