《需求工程——软件建模与分析》阅读笔记1

一、满足需求就是解决问题

问题解决的 两个方面——问题域与解系统

     首先，我们需要简要了解这两点的概念。第一，问题域是需求的背景，要理解需求就必须先理解问题域。问题域的背景信息又被称为问题域特性（problem domain feature），与需求相区别的是，问题域是自治的，它有自己的运行规律，而且这些规律不会因为解系统的引入而发生改变。第二，解系统是指软件系统通过影响问题域帮助人们解决问题，软件解决方案在通用计算机上的实现。需要注意的是，需求工程师要注意区分用户与软件开发人员在关注点上的不同：用户关注于问题域，软件开发人员更关注解系统。

　　其次，解系统的核心是软件解决方案和解决方案在通用计算机上的实现。实现部分主要是软件内部的组成元素、结构关系、物理实现等软件系统的构成要素。需求工程所关注的仅仅是解决方案，不涉及软件的实现环节。在需求开发过程中，问题域中的用户提出问题与需求，在整个衔接过程中，需求是用户与需求工程师的协作基础，解决方案是需求工程师与软件开发者的协作基础。因为解决方案以对外交互的方式定义了软件系统的功能，所以解决方案被称为软件系统的需求规格说明（specification）。

• 规格说明定义为：以一种完全的、精确的、可验证的方法规定系统或部件的需求、设计、行为或者其他特性的文件，并经常指明判定这个规定是否满足的过程。
• 需求规格说明定义为：规定系统或部件的需求的文档，典型地包括功能需求、性能需求、接口需求、设计需求和开发标准。

问题解决的基础——模拟与共享现象

      问题与解系统能够形成互动的基础是解系统的部分模拟了问题域，将这种模拟现象称为共享现象。

问题解决的方法——直接与间接

　　模拟并操纵共享现象是软件系统满足需求的最直接方法。考虑问题和需求满足的方法时，成本是重要的因素。在设计解决方案时要防止解系统的引入在问题域中引发未预见的连锁反应。

　　间接特性不会与解系统直接交互，不会受到解系统的直接影响，但是却可能因为连锁反应而受到影响。

问题解决方案——需求规格说明

 　　数据和功能为软件系统的最核心部分。

问题解决的困难性

　　例如，（1）不存在描述明确的问题域特性；（2）不存在确定的针对系统行为的评估标准需求；（3）根据问题域特性和系统行为推测系统应用效果是简单的推理过程，但根据问题域特性和期望的系统应用效果构建系统行为是困难的。因为，这其中需要考虑到技术的可行性，还要尽可能满足客户需求，准确挖掘出客户需求。

二、需求和问题都是有层次的

　　问题和期望粒度不同的现象被称为需求的不同抽象层次。系统最为常见的系统层次有如下三种：

1. 业务需求，针对整个业务的期望。
2. 用户需求，针对具体任务的期望。
3. 系统级需求，针对用户与系统一次交互的期望。

　　严格意义上的需求分类：

1. 功能需求，和系统主要工作相关的要求，即在不考虑物理约束的情况下，用户希望系统能够执行的活动。
2. 性能需求，系统整体或其组成部分应该拥有的性能特征。
3. 质量属性。
4. 对外接口，包括硬件接口、软件接口和数据库接口。
5. 约束（constraint），如编程语言、硬件设施等。

　　系统特性说明了系统为用户提供的各项功能，它限定了系统的范围，定义良好的系统特性可以帮助用户和开发者确定系统的边界。用户经过明确和细化的处理，可以转化为系统级需求。 

　　人们将软件、硬件和人力资源联合起来，这种联合的形势被称为系统工程。

转载于:https://www.cnblogs.com/liusx/p/9255547.html