软件需求详解

软件需求

软件需求其实就像是一个目标一样，朝着这个“目标”所开发出的软件才算得上是合格的软件。不难想象，如果最开始的这个“目标”就是错的，那么无论你费多大劲，你做出来的软件都是不符合用户要求的软件。
为了明确这个“目标”，软件工程大致是这么做的：对软件需求进行定义 ——> 获取需求 ——> 把需求整理成（软件）需求规约。

1-软件需求的重要性

在软件开发的过程中，获取正确的需求可以算是软件开发中最难的事了。因为：

• 大部分用户并不知道自己想要什么。

• 就算用户并知道自己想要什么，用户如何把它准确地表达出来是个问题。

• 而且，就算用户表达清楚了自己的需求，开发人员是否能够正确理解用户表达的需求也是个大问题（了解用户所处的行业的专业术语等）。举个例子，用户想要个苹果，但是用户把它描述成了一个梨，然后需求分析员把这个“梨”描述给开发人员，开发人员听过需求分析员的描述后，又误以为用户要做一个橘子，于是就把做好的橘子给了用户，这要是不打起来才怪呢。

• 很多时候软件项目的需求是在不断变化的。只是有的时候我们为了做软件项目而人为的把它在某个时刻的需求冻结了，但这并不意味着软件项目的需求就不会变化了。

我们如何应对这种不断变化的需求；如何控制需求变化的规模；在项目的执行中，什么样的需求允许发生变化，什么样的需求不允许变化；通过什么样的方式去控制需求的变更等，都是重要的问题。

那么解决这些问题的第一步就是正确地定义需。因为只有当我们准确地，统一地定义了需求，我们才能在获取软件需求的过程中挖掘出那些满足条件的“真正的需求”，并且使相关人员对需求有一个统一的认识（有了这个前提，我们才能去解决哪些由“需求”所引起的问题）。为了正确地定义需求，我们首先需要解决两个问题：

1. 定义需求的基本要素是什么——需求包括哪些基本要素。“软件需求的定义”解决的就是这个问题。
2. 定义需求的基本格式是什么——如何采用规范的方式去描述需。此问题由“需求规约”解决。
   
   
   

2-软件需求的定义

作用：描述了待开发 产品/系统 功能上的能力、性能参数或其它性质。

需求的要素，即具有了以下5个标准 的描述才能算得上是一个需求：

1. 必要的——此描述中指明了某项要求，如“系统必须支持100个以上的用户并发”。

2. 无歧义的——此描述只能用一种方式解释吗？如果一个描述，用户、需求分析员和软件开发人员所理解的意思互不相同，那么最终开发出的软件就很难满足用户的实际要求。

3. 可测的——对于给定的一个或一组输入，我们一定会得到一个或一组确定的输出。

4. 可跟踪的——可以从一个开发阶段的另一个开发阶段对它进行跟踪吗？

5. 可测量的。比如说对于“此系统需要良好的安全性”这个描述，“良好的安全性”只是一个定性的描述，我们无法对其进行量化（即，有一个漏洞就叫做“不安全” 还是说 有十个漏洞才叫做“不安全” 或者是 能运行就叫做“安全”？）。
   
   
   

3-软件需求的分类

1. 功能需求：功能需求是系统同最核心的需求，是整个需求的主题，其它的非功能需求是附加在功能需求之上的，即没有功能需求就没有非功能需求——性能需求、外部接口需求、设计约束和质量属性。

2. 性能需求：性能需求规定了一个系统或系统构件必须具有的性能。如，对于“系统因该在5分钟内计算出给定季度的销售税”这个描述来说，功能需求是“计算出给定季度的销售税”，性能需求是“在5分钟内计算出结果”。性能需求隐含了一些满足功能需求的设计方案，经常对涉及产生一些关键性的影响。例如排序，花费时间的限制将确定那种算法是可行的。

3. 外部接口需求：外部接口需求规定了 系统或系统构件必须与之交互的硬件、软件或数据库元素。外部接口可分为：

   • 系统接口：描述一个应用如何与系统的其他应用进行交互。
   • 用户接口：规约了软件产品和用户之间接口的逻辑特性。即规约 给用户所显示的数据，对用户所要求的数据以及用户如何控制该用户接口。
   • 硬件接口：如果软件系统必须与硬件设备进行交互，那么就应说明所要求的支持和协议类型。
   • 软件接口：允许与其它软件产品进行交互，如，数据管理系统、操作系统或数学软件包。
   • 通讯接口：规约待开发系统与通讯设施(如，局域网)之间的交互。如果通讯需求包含了系统必须使用的网络类型（TCP/IP，WindowsNT,Novell），那么有关类型的信息就应包含在SRS中。
   • 其它：内存约束、操作和地点需求。
     
     

4. 设计约束：设计约束限制了系统或系统构件的设计方案。为了满足功能、性能和其它需求，许多设计约束将对软件项目规划、所需要的附加成本和工作产生直接影响。比如“系统必须使用C++或其它面向对象语言编写”。

5. 质量属性：质量属性规定了一个软件产品必须具有的一个性质 是否达到质量方面一个所期望的水平。例如（属性只表达了性质，而描述是对属性的一种量化）:

4-获取软件需求的方法

(1)自悟

描述：需求人员把自己作为系统的最终用户，审视该系统并提出问题。

适用条件：需求工程师不能直接与用户进行交流。

(2)交谈

描述：需求人员通过提出问题/用户回答这一方式，直接询问用户需要的是一个什么样的系统。

适用条件：需求人员具有“正确提出问题”的能力；回答人员具有“揭示需求本意”的能力。

风险：在交谈期间需求可能不断增长。因为很多时候用户在提出需求的时候并不会考虑成本、进度和开发特点等因素，如果在这种情况下需求人员不清楚用户想要的需求是否是合理的，那么就会导致最终获得的需求“过于完美”但无法实现。

应对措施：项目管理人员和客户管理人员应该定期地对交谈的结果进行复审。其主要解决的问题是，“需求增长的界限在哪里”和“什么时候将需求的增长告诉用户”。

(3)观察

描述：通过观察用户执行其现行的任务和过程，或观察他们如何操作与所期望的新系统有关的现有系统，了解系统运行的环境。

风险：一、客户可能会抵触这一观察，因为它们可能会认为开发者打扰了它们的正常业务（想想，如果你在工作的时候总有一个人在旁边看着）；二、客户还可能认为开发者在签约之前 就已经熟悉了它们的业务（由于观察时客户与开发者不会有太多的交流，所以客户可能不会对一些业务进行详细的解释）。

(4)小组会

描述：举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求。
，并提取相关的信息。

优点：一、如果会议组织得当，可很快地标识出一些需求；二、可使需求开发人员在一次会议中能够对一个给定的需求得到多种观点，从而不但可节省与个人交谈的时间，还可节省联系他们的时间；三、有关需求不同观点之间的冲突，可以揭示需求中存
7在的问题，也有助于客户在其内部达成一致。

(5)提炼

复审技术文档：复审技术文档，并提取相关的信息。

适用条件：已经有了部分需求文档。

5-需求规约（也称需求规格说明书）

此阶段解决的问题是：如何规范化地去描述软件需求。
软件需求被规范化地描述之后就形成了软件需求规约。

5.1-定义

需求规约是一个软件 产品/系统 所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型。

5.2-需求规约必备的基本性质

• 重要性和稳定性程度：对获取到的需求进行分类，一共分为三类——基本需求（必须要实现的需求）、可选需求和期望需求（未来考虑的需求）。

• 可修改的：在不过多影响其他需求的前提下，可以容易地修改一个单一需求。

• 完整的：把获取到的需求描述为需求规约后，需求规约中没有漏掉其中的需求。

• 一致的：需求规约中的需求不存在互斥。
  
  

5.3-需求规约的格式

5.4-需求规约的三种表达方式

1. 非形式化的需求规约（一般使用在起草需求规约的时候）：以一种自然语言来表达需求规约，如同使用自然语言写了一篇文章。易理解但容易产生歧义。比如，“你不要乱来”可以理解为“你不要乱来”或“你不要乱，来！”。所以我们需要 为那些在一个特定语境中所使用的术语提供语义定义，一般情况下，该语境与通常使用该术语的语境是由区别的。

2. 半形式化的需求规约（一般在对需求进行技术分析期间使用）：以半形式化符号体系来表达需求规约。因此，半形式化规约的编制应遵循一个标准的表示模板或约定。

3. 形式化的需求规约（对于质量，特别是安全性要求比较高的软件产品/系统，一般使用此规约）：以一种基于良好数学概念的符号体系来编制需求规约，一般往往伴有解释性注释的支持。容易进行形式化的验证但是提高了阅读人群的门槛。
   
   

5.5-需求规约的作用

1. （软件开发角度）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。事实上，软件需求规约是开发组织与用户之间的第一次“亲密握手”。有了软件需求规约后，开发组织与用户就能在“做什么”的事情上达成共识，进而才能有序地进行软件设计，软件实现等工作。

2. （软件管理角度）对于项目的其余大多数工作，需求规约是一个管理控制点。对于项目经理来说，软件需求规约是实施管理的重要文档，因为成本估算，进度控制等都需要以软件需求规约为依据。

3. 对于产品/系统的设计，需求规约是一个正式的、受控的起始点。软件设计人员只有在拿到需求规约时，才能对软件进行设计。

4. 需求规约是创建产品验收测试计划和用户指南的基础，即基于需求需求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。

转载：https://blog.csdn.net/hufuzhi1146231094/article/details/105394968