软件工程系统定义——需求开发与需求管理

• • • • 【更新日志】
• 系统定义阶段
• 需求分析概述
• 软件需求分析层次
• • 业务需求
  • 用户需求
  • 系统需求
  • 其它详细需求及约束
• 需求分析的过程（需求开发）
• • 需求获取
  • 需求分析（分析与建模）
  • 需求定义
  • 需求阶段性验证评审
• 需求管理（待更新……）
• • 需求跟踪（待更新……）
  • 需求变更（待更新……）

【更新日志】

最近更新：

系统定义阶段

系统定义是软件生命周期的第一阶段，有着根据用户的具体要求解决系统做什么的重要任务。系统定义阶段主要完成三部分，即问题提出、可行性研究、需求分析

• 问题提出：针对生活中、 会中某一具体领域某一具体方面某一具体现象提出有建设性、创造性或改良性意义的问题
• 可行性分析：针对问题的提出，思考分析运用软件工程解决该问题的可行性，如在技术实现、开发维护成本、法律规定、具体实施的可操作性等多方面的分析

• 需求分析：是软件定义时期的最后一部分，也是软件生存期中重要的决定性的一步，深入描述软件的功能和性能需求，确定软件设计的约束、软件同其它系统元素的接口细节、相关模型，定义软件的业务需求、用户需求等有效性需求

【需求分析部分主要工作产品有《软件需求规格说明书》和《初步用户手册》】

业务需求

• 业务需求反映企业/组织对软件系统的高层次目标需求，即软件的建设目标，描述为什么要开发系统，是系统建立的战略出发点
• 为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性，特性说明了系统为用户提供的各项功能，限定了系统的范围
• 参与系统的各方需要对高层次的解决方案达成一致，建立一个共同的前景

用户需求

• 用户需求反映执行实际工作的用户对系统所能完成的具体任务的期望，描述系统能够帮助用户做些什么
• 用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及内部特性
• 用户需求通常是在业务需求定义的基础上通过用户访谈、调查，对用户使用的场景进行整理，从而进行用户角度的需求建立
• 对所有的用户需求都应有充分的问题域知识作为背景支持

系统需求

• 系统需求可直接映射为系统行为，即定义系统中需要实现的功能，描述开发人员需要实现什么
• 将用户需求转化为系统需求的过程较为复杂
  首先需要分析问题域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型
  然后将用户需求部署到系统模型中，即定义一系列系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求
  该过程即为需求过程中的需求分析活动，即建模与分析
• 一系列的行为联系在一起帮助用户完成任务，从而也满足了业务需求

其它详细需求及约束

功能需求

• 功能需求描述系统应提供的功能或服务，通常涉及用户或外部系统与该系统间的交互，一般不考虑系统的实现细节
• 传统的需求开发方法中，通常会以软件系统——子系统——模块——子模块的层次结构来组织
• 现代需求理论更强调需求分析人员从用户的角度将系统理解为一个黑盒子，从使用角度来整理需求

非功能需求（性能需求）

• 非功能需求从各个角度描述对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，如响应时间、数据精度、可靠性、开发过程的标准等
• 一般在软件开发过程中可以将非功能需求划分为性能需求、质量属性、对外接口等
  性能需求：主要有速度、容量、吞吐量、负载等
  质量属性：系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量，质量属性是为了度量质量要素而选用的特性
  对外接口：系统和其它系统之间的软硬件接口以及用户界面
• 软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等

设计约束

一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明，一般包括非技术因素决定的技术选型问题以及预期的软硬件环境、预期的使用环境等

PS：非技术因素决定的技术选型：对于软件开发而言，有些技术不是由技术团队决定的，而是会受到企业/组织实际情况的影响。如必须采用具有自主 知识产权的数据库系统，系统开发必须使用J2EE技术等

需求分析的过程（需求开发）

需求分析阶段的工作可分为4个步骤，即需求获取、需求分析、需求定义、需求验证。每个步骤完成后都得到相应的结果：N、R1、R2、R3，从而使得软件需求的状态不断变化

需求获取的过程

不同规模不同类型的项目，需求获取过程均有差别，大致步骤如下

• 开发高层的业务模型（业务需求）
  即对目标系统的应用环境与应用领域有了充分的了解后，建立一个业务模型，描述用户的业务过程，确定用户的初始需求，然后通过迭代，更深入地了解应用领域，再对业务模型不断进行改进
• 定义项目范围和高层需求
  在所有利益相关方中建立一个共同愿景。项目范围描述系统的边界以及与外部事物（包括组织、人、硬件设备、其他软件等）的关系；高层需求主要表示系统需求的概貌，不涉及过多的细节
• 识别用户类和用户代表（用户需求）
  1、用户类：系统的不同用户之间在很多方面存在差异，例如
  （1）使用产品的频率
  （2）用户在应用领域的经验和使用计算机系统的即能
  （3）所用到的产品功能
  （4）为支持业务过程所进行的工作
  （5）访问权限和安全级别（如普通用户、来宾用户或系统管理员）
  根据这些差异可将用户分为若干不同的用户类，每类用户都会根据其成员要执行的工作提出一组自己的需求，不同用户类可能还有不同的非功能性需求，不同用户类的需求可能还会发生冲突，对于发生冲突的需求必须做出权衡与折中
  【PS：用户类可以是人，也可以是与系统打交道的其它应用程序或硬件部件】
  2、用户代表：为准确地了解用户需求，需要首先确定目标系统的不同用户类型，挑选出每一类用户和其他利益相关方的代表参与项目的整个开发过程
• 确定目标系统的业务工作流（系统需求）
  针对当前待开发的应用系统，确定系统的业务工作流和主要的业务规则，采取需求调研的方法获取所需的信息。如
  1、调研用户的组织结构、岗位设置、职责定义等，从功能上区分子系统数量，划分系统的大致范围，明确系统的目标
  2、调研每个子系统的工作流程、功能与处理规则，收集信息资料，用数据流图表示各流程关系
  3、对调研内容事先准备，针对不同管理层次的用户询问不同的问题，将不同层次不同类别的用户需求既联系又区分开来，形成一个具有层次的需求
• 需求整理与总结
  对上述所有步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，并提出这些需求的实现条件以及需求应达到的标准

需求分析（分析与建模）

针对获取的需求进行详细分析，从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素间的联系、接口特性、设计上的限制，判断是否存在因片面性或短期行为而导致的不合理的用户要求，最终综合成系统的解决方案，给出目标系统的详细逻辑模型

需求分析过程中必须考虑以下几个方面：

• 完整性：没想获取的需求都应给出清楚的描述，使得软件开发工作能够取得设计和实现该功能所需要的全部必要信息
• 正确性：获取的每项需求必须准确无误且需求描述无歧义性
• 合理性：各项需求之间应协调一致，不应存在矛盾与冲突
• 可行性：获取的每项需求必须具有
  技术可行性：在现有条件和环境下技术可进行实现
  经济可行性：设计和实现不会超出预算范围
  会可行性：不会涉及知识产权侵权问题、不触犯法律规定等
• 充分性：需求的获取是否全面、周到

分析的过程会对获取的需求做部分调整（即获取的需求与分析的需求有所差异），并进一步做详细展开，进行模型的建立

需求定义

作为软件开发的依据，将已经分析的需求清晰、全面、系统、准确地描述成正式的文档，编写软件需求规格说明书

需求阶段性验证评审

需求分析阶段工作的复查，对功能的正确性、文档的一致性、完备性、准确性和清晰性，以及其它需求给予评价 。评审人员除分析员之外，用户/需求者、开发的管理者、软件设计、实现、测试等人员均应当参加评审工作

需求管理（待更新……）

需求跟踪（待更新……）

需求变更（待更新……）

持续更新中……
我是桐小白，一个摸爬滚打的计算机小白