需分

软件需求分析

1.软件需求前言

1.1.1.项目失败的原因

(1)需求不完整

(2)缺少客户的参与

(3)缺少资源

(4)期望值过高

(5)缺少高层的支持

1.1.2.需求—导致项目失败的罪魁祸首

• 2014年,根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。

• 而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。

• 也就是说,有近45%的项目最终因为需求的问题最终导致失败。

• 在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：

  不完整的需求; 没有用户的介入; 不实际的客户期望; 需求和规范的变更; 提供了不再需要的

  

1.1.3.软件需求的重要性

• 软件需求是决定软件开发是否成功的一个关键因素.
  • 需求分析可以帮助开发人员真正理解业务问题.
  • 需求分析是估算成本和进度的基础.
  • 需求分析可以避免建造错误的系统从而减少不必要的浪费.
  • 软件规格说明有助于开发人员与客户在"系统应该做什么"问题上达成正式契约.
  • 需求分析形成了软件开发的基线,有助于管理软件的演化和变更.
  • 软件需求是软件质量的基础,为系统验收测试提供了标准.

2.可行性研究

2.1.1.可行性研究的概念

​ --可行性研究是一个综合的概念，它综合运用多学科的知识，寻找一种方案，该方案可使得拟建系统达到最佳收益。

​ --可行性研究的任务，是在做出决策之前，全面论证管理信息系统开发项目的必要性、可能性、有效性和合理性。通过调查研究，全面分析与管理信息系统项目有关的因素，组合设计出多个可能的方案，并对各个方案的经济效果进行分析，最后评选最优方案，为决策者提供决策依据。

​ --可行性研究的作用，在于保证决策者为了达到所追求的目标，能够有效地利用现有的人力、物力和财力等资源，达到预期的效果。

​ --可行性研究的核心是经济问题。从字面上来说，“可行”很容易被理解为可以做到，然而可以做到的事情在经济上不一定是合理的。因此，可行性研究应该回答的问题不仅是某一事情能否做到，而且应该回答该事情是否应该做？什么时间做？如何去做？所以，可行性研究必须对各种影响因素，尽可能地以货币为尺度，进行全面的、定量的分析，并计算出投资项目在整个使用期间的经济效益，这是可行性研究的特点之一。

2.1.2.可行性研究的流程

​ 按照系统分析的原理,要做好可行性研究,必须按照一定工作程序进行.

1. 确定项目规模和目标
2. 系统调查研究正在运行的系统
3. 列出可能的技术方案
4. 技术先进性分析
5. 经济效益分析
6. 综合评价
7. 优选可取方案并写出可行性研究报告

2.1.3.可行性研究的内容

​ 可行性研究的内容可概括为环境、技术和经济三个方面。环境的研究是可行性研究的前提；技术上的可行是可行性研究的基础；经济上的可行则是可行性研究评价和决策的主要依据。因此，凡是影响到费用和收益的因素，都是可行性研究的内容。
​ 例如，对一个信息系统开发项目来说，可行性研究要回答：为什么要开发该项目？资源情况如何？市场条件如何？开发项目规模有多大？技术条件怎样？需要哪些基础条件？何时实施最佳？投资效果和成功的可能性怎样？此外还要考虑国家的有关政策及该项目对社会的影响等。
​ 由此可见，可行性研究的内容十分广泛，涉及到社会、政治、经济、法律和多方面的专业技术知识，其综合性很强，需要各方面的专家分工合作。因此，较复杂系统的可行性研究一般都由专门咨询机构承担。

• 环境可行性

  • 要对系统进行全面整体的调查分析，大体可以从两个方面着手进行，一是对系统的外界环境进行调查分析，即系统的目的调查分析；二是对系统的内部进行调查分析，即系统的方案调查分析。
    系统的目的调查分析中，又有两个内容，一是对系统的输出调查分析，就是外界环境对系统的需求调查分析；二是对系统的输入调查分析，就是外界环境对系统的限制性的调查分析。在系统的方案调查分析中，也有两个内容，首先是系统实施方案的可行性分析，然后是各实施方案的经济效益分析。

• 技术可行性

  • 根据现有技术条件分析能够达到系统所提出的要求
    • 硬件：存储量、速度、质量、可靠性等方面
    • 开发的风险:在给出的限制范围内,能否设计出系统并实现必须的功能和性能
    • 软件：各种系统软件的能力、是否已有专用软件
    • 技术人员：水平、数量、流动性
  • 是否具备所需的物理资源

• 经济可行性

  对于大多数系统,一般衡量经济上是否合算,应考虑一个"底线".

  • 资金可得性
    • 初始成本
    • 日常维护费用:维护、易耗品、其他各种开销
  • 经济合理性
    • 直接效益:节省人员、减少库存、增加产量
    • 间接效益:准确的信息、决策支持、竞争力
    • 投资回收期:T=V0*(1+t)T/B

• 社会可行性

  • 可行组织内部的改革是否能够推行（体制变化、人员 精简）
  • 领导和员工的素质、支持度或受阻程度
  • 上级单位的认同
  • 政策、法规等环境影响

• 可行性研究的评价原则

  （1） 效益性原则
  （2） 经济性原则
  （3） 可靠性原则
  （4） 可比性原则
  a 满足需要可比
  b 消耗费用可比
  c 价格可比
  d 时间可比

• 可行性报告的内容:

  1. 引言
  2. 系统建设的背景、必要性和意义
  3. 拟建系统的候选方案
  4. 可行性论证
  5. 几个方案的比较
  6. 结论(立即开发/改进原系统/不可行)

3.需求获取与需求分析阶段的任务

3.1.1. 需求获取的任务和原则

• 需求获取的主要任务是与客户或用户沟通，了解系统或产品的目标是什么？客户或用户想要实现什么？系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作？

• 获取并理解用户的需求是软件工程师所面对的最困难的任务之一。

• 导出需求变得如此困难的原因归为以下几个方面的问题：

  • 系统的目标或范围问题（系统边界不清楚）；
  • 需求不准确性问题 ；
  • 需求的易变问题 ；
    • 需求获取除了需要有专业的系统分析师，还需要通过有效的客户／开发者的合作才能成功。

• 1)需求获取的任务

  ​ (1)发现和分析问题，并分析问题的原因/结果关系。

  ​ (2)与用户进行各种方式的交流，并使用调查研究方法收集信息。

  ​ (3)按照三个成分观察问题的不同侧面：即数据、过程和接口。

  ​ (4)将获取的需求文档化，形式有用例、决策表、决策树等。

• 2)需求获取应遵循的原则

  ​ (1)深入浅出的原则。就是说，需求获取要尽可能全面、细致。获取的需求是个全集，目标系统真正实现的是个子集。

  ​ (2)以流程为主线的原则。在与用户交流的过程中，应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。流程的描述既有宏观描述，也有微观描述。

3.1.2.需求获取的过程

1>开发高层的业务模型

2>定义项目范围和高层需求

3>识别用户类和用户代表

​ 系统的不同用户之间在很多方面存在差异，例如：

​ (1)使用产品的频率；

​ (2)用户在应用领域的经验和使用计算机系统的技能；

​ (3)所用到的产品功能；

​ (4)为支持业务过程所进行的工作；

​ (5)访问权限和安全级别

4>获取具体的需求

​ 确定了项目范围和高层需求，并确定了用户类及用户代表后，就需要获取更具体、完整和详细的需求。具体需求的来源可以来自以下几种典型的途径。

​ (1) 与用户进行交流。
(2) 现有产品或竞争产品的描述文档。
(3) 系统需求规格说明。
​ (4) 当前系统的问题报告和改进要求。
(5) 市场调查和用户问卷调查。
(6) 观察用户如何工作。

5>确定目标系统的业务工作流

		  具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则，采取需求调研的方法获取所需的信息。例如，针对信息系统的需求调研方法如下：
					     (1) 调研**用户的组织结构、岗位设置、职责定义，从功能上区分有多少个子系统，划分系统的大致范围**，明确系统的目标。
						 (2) 调研**每个子系统的工作流程、功能与处理规则，收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系**。
						 (3) 对调研内容事先准备，针对不**同管理层次的用户询问不同的问题**，列出问题清单。将**操作层、管理层、决策层**的需求既联系又**区分开**来，形成一个层次的需求。 

6>需求整理与总结

​ 必须对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，即软件的需求。
​ 并提出这些需求实现条件，以及需求应达到的标准。
​ 这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求等。

3.1.3.软件需求分析阶段的任务

​ 可以把软件需求分析阶段的工作分为4个步骤即获取需求、分析需求、定义需求和验证需求,如图所示

软件需求分析阶段的工作步骤

​ 1).需求获取

​ 通过启发、引导从客户（或用户）那里得到的原始需求是他们的业务要求（needs），简称为N。
这是分析之前获取的需求，其中可能存在一些实际问题，这些问题只有通过分析才能得到解决，直接把获取的需求作为软件 设计阶段的依据将会导致严重的后果。

​ 2).需求分析

​ 认真研究获取的需求，必须考虑以下几方面：

​ (1) 完整性：每项获取的需求都应给出清楚的描述，使得软件开发工作能够取得设计和实现该功能所需要的全部必要信息。
(2) 正确性：获取的每项需求必须是准确无误的，并且需求描述无歧义性。
(3) 合理性：各项需求之间、软件需求与系统需求之间应是协调一致的，不应存在矛盾和冲突。 (4) 可行性：包括技术可行性 、经济可行性 、社会可行性
​ (5) 充分性：获取的需求是否全面、周到。

​ 由于分析的过程会对获取的需求做部分调整，也即从获取的需求N中去掉了一些a，又补充了一些c，从而得到的是分析的需求R1（b+c）。

​ 3).需求定义

​ 将已经过分析的需求清晰、全面、系统、准确地描述成为正式的文档，这一步定义需求的工作就是编写需求规格说明。

​ 4).需求验证

​ 为了确保已定义的需求（需求规格说明）准确无误，并能为客户（或用户）理解和接受，需要对其进行严格的评审。

• 软件需求
  • ①用户解决问题或达到目标所需的条件或能力。
  • ②系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
  • ③一种反映上面①或②所描述的条件或能力的文档说明。
• 对定义的理解
  • 软件需求的概念涵盖了用户角度（系统的外部行为）和开发人员角度（系统的内部特性）两个方面，其中的关键在于需求一定要文档化。

3.1.4.不同层次的软件需求

1.业务需求

• 业务需求是组织或客户对于系统的高层次目标要求，定义了项目的远景和范围，即确定软件产品的发展方向、功能范围、目标客户和价值来源。
• 业务需求的内容
  业务：产品属于哪类业务范畴？应该完成什么功能？需要为什么服务？
  客户：产品为谁服务？目标客户是谁？
  特性：产品区别于其他竞争产品的特性是什么？
  价值：产品的价值体现在什么方面？
  优先级：产品功能特性的优先级次序是什么？

2.用户需求

• 用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。
• 用户需求的描述
  原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。
  问题：自然语言表达容易含糊和不准确。

3.系统需求

• 系统需求是更加详细地描述系统应该做什么，通常包括许多不同的分析模型，诸如对象模型、数据模型、状态模型等。
• 系统需求模型的描述
  • 结构化英语（PDL ）
  • 可视化模型
  • 形式化方法
• 系统需求主要是面向开发人员进行描述，是开发人员进行软件设计的基础。

4.功能需求

​ 描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。

5.非功能需求

​ 从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。

6.需求的来源

• 客户或用户
  • 学院的高层管理者、项目投资人
  • 系统管理员
  • 教师、学生、图书管理员
• 标准
  • 图书资料的标准
• 政策或法律
  • 图书资料管理规程、知识产权和版权保护等
• 系统或过程文档
  • 当前手工管理的文件、表格、记录等
• 相关领域的专家