需求工程第一章导论以及第二章需求基础

需求工程

第一章导论

当前软件发展趋势：

​ 开发流程迭代加速，开发方法面向维护与演化，系统复杂性增高

软件分析获得活动：

面向专业用户的工具型软件：

创新：观念，技术创新—》功能分析—》设计、实现与集成—》发布

评判标准：功能的复杂性，使用的高效性，技术的先进性

关注点：创新性

面向普通用户的工具型软件：

功能分析：有用性—》设计、实现与集成—》发布

评判标准：功能的有用性，使用的方便性，技术的可行性

关注性：有效性

应用型软件：

现实分析：目的、问题领域知识—》功能分析：“模拟”性—》设计、实现与集成—》移交

评判标准：功能的模拟性，使用的方便性，技术的可行性

关注点：模拟性

有了好的idea除了差程序员之外还差什么？

软件系统涉众所带来的非技术性和社会性因素。领域知识和业务逻辑如何向软件系统转化？如何用程序模拟领域内业务逻辑的运转？

需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实。

开发软件最难的部分就是说明开发什么，最为困难的概念性工作就是编写出详细的技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。

---

第二章需求基础

需求的定义：

1、用户为了解决问题或者达到某些目标所需要的条件或能力；

2、系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；

3、对1或2中的一个条件或一种能力的一种文档化表述

问题域：

为了解决问题所需要改变的实体或实体的状态就称为问题解决的基本范围。

解系统：

软件系统通过影响问题域，能够帮助人们解决问题称为解系统。是手段而不是目的

问题解决的基础：模拟与共享

模拟：软件系统当中含有问题域某些部分的模型（模拟），常见的模型包括数据模型、对象模型、处理模型等

共享：问题域的某些信息能够和模型中的信息建立映射关系，这些通过映射建立的共同知识，就是共享现象。

需求规格说明：

解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。

主要包括：1、对共享现象（模型）的描述；2、系统对共享现象所施加的操作的描述

需求工程的主要工作：

1、需求开发，确定预期的需求

2、研究问题背景，描述问题域特性

3、构建解系统，描述解系统行为

需求的层次性：

问题-》目标-》用户需求-》系统级需求

背景-》系统特性-》问题域知识-》分析模型

业务需求：

系统建立的战略出发点，表现为高层次的目标，描述组织为什么要开发系统。

# 业务需求级别的抽象用例：

用例x:商品管理

级别：概要（抽象）

目标：减少商品挤压、缺货和报废的现象

场景： 1、分析店铺商品库存，发现可能的商品积压，缺货和报废现象；

      2、制定。。。。。。处理积压商品

用户需求：

执行实际工作的用户对系统所能完成具体任务的期望，描述了系统能够帮助用户做些什么。直接用户，间接用户（通用，公共服务软件等用户无法确定的系统）。

基本表述方式：“用户可以使用系统完成。。。任务”

# 用户需求实例：连锁商店销售系统
用例1.1：销售处理
级别：用户需求
目标：快速、正确地完成商品销售
场景：收银员逐一输入。。。（UR1）
扩展场景：系统记录用户积分

系统级需求：

用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求。

用户需求和系统级需求，用户习惯用户需求，开发者希望得到系统级需求

需求的常见类型：

需求:
    项目需求
    过程需求
    系统需求:
        软件需求:
            功能需求:
                定义：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。    
            性能需求:
                定义：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
                包括：速度，容量，吞吐量，负载，实时性
            质量属性:
                定义：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。
                包括：可移植性，可维护性，可用性，效率，可靠性，功能性，安全性，易用性
                形容词和副词通常意味着质量属性的存在
            对外接口:
                定义：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
                包括：解系统和其他系统之间的软硬件接口，用户界面，通信接口
            约束:
                定义：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等
            数据需求
            安装需求
            培训需求
        硬件需求
        其他需求
不切实际的期望

优秀需求的特性

完备性

不需要做更多的扩展就可以充分说明用户所需要的系统功能

每一个需求的描述都应该包含开发人员设计和实现这项功能所需要的所有信息

功能需求完备性：行为触发者，行为的前置条件，行为，后置条件，不满足前置条件的情况以及相应情况下的结果。

数据需求完备性：类型，语义，组成成分，初始值或缺省值，可能的取值范围，度量单位，数据量，更新频率，可以对其施加的合理操作，对外关系。

对外接口的完备性：接口的名字，接口的定义，接口的方向声明，服务请求（语法，语义，异常，接口定义的特殊数据类型，质量属性要求）

质量属性的完备性：针对系统或其部件的质量标准，明确了需要满足质量标准的情况与条件，衡量质量标准所使用的单位，质量度量的阈值

R2.5-1：系统应该允许被扩展

R2.5-2：系统的调度算法应允许被扩展

正确性

真实的反应用户的意图，必须请需求的提出者予以确认。

①多问用户“为什么”，将需求描述从具体情景、技术环境等约束中抽离出来

②从业务方面描述需求，而不是从技术方面描述需求。

③关注涉众的想法。包括关注涉众对需求的效益评价，关注涉众对需求的优先级划分，真正理解需求对于涉众的意义。

④在演化中理解需求。将最初始的需求展示给涉众，并利用涉众的反馈发现真正的需求。

⑤通过量化手段准确理解需求。对验证标准的反复推敲可以更准确地理解涉众的需求含义。

可行性

由开发人员进行检查，需要进行一定的分析和研究，而不是单纯的凭借经验和直觉，必要时要通过开发原型加以验证

必要性

满足用户的业务需求所必需的

无歧义

每一项需求都应该有且只有一种解释。

可验证性

通过分析、检查等方法判断需求是否被满足