第二章：软件需求工程

使用**💡**标记的是期末考点！

软件需求的基本概念

需求分析的任务

• 确定系统将要实现的各项要求：确定有哪些功能业务
• 数据分析：分析数据存储在哪里，数据如何显示（例如图表显示）
• 定义逻辑模型：也就是把实体的概念转为逻辑概念，比如图书管理系统中抽象出Book类
• 适应需求变更：后期需求可能会更改

  简单概括，分析需求的过程就是：确定需求 -> 分析数据 -> 建立模型 -> 修改变更

💡需求分析的原则

1. (客) 软件人员要从用户角度考虑软件需求
2. (流) 以流程为主线：也就是按照用户对于一个功能描述的流程进行主线开发。
3. (重) 尽量重用软部件：这里的重用是代码和设计模式的重用，主要目的是提升开发效率，节约成本，提高软件质量。
4. (优) 划分需求的优先级
5. (馈) 需求变更要及时反馈

   需求分析的内容

   大致需求如下图所示：
   

可行性分析

可行性分析的内容

• **技术可行性研究**：当前技术是否可行。
• **经济可行性研究**：系统产生的效益是否超过成本。
• **操作可行性研究**：系统在用户中的可操作性（主要是探究系统的操作方式是否符合用户的操作习惯）。

• **法律可行性研究**：技术、经济、操作可行性符合法律规范。

  💡系统流程图

  系统流程图的作用是简单的描绘系统的大致工作原理。

  作用

  系统流程图主要用于表现：

• 从用户角度上看，系统流程图在一个抽象的层面描述用户的操作、应用场景与数据流动。这样，利于和用户交流，准确地获取用户需求。

• 从系统分析员的角度上看，系统流程图使得系统分析员全面了解系统业务流程，便于进行进一步的需求分析。
• 从项目管理者的角度上看，系统流程图有利于系统分析员与用户的交流和沟通。

  符号说明

  

  例题

  某企业需要开发一套人力资源管理系统，实现企业对人事，工资，用户等内容的信息化管理，并且设计良好的帮助系统，提供详细的帮助文档，通过企业局域网，能对相关信息进行增、删、改、查等功能，并能生成相关报告。

根据上面给的例子，剖析整个系统需要的功能，这里就需要自己代入用户使用系统的视角去思考。

1. 首先我需要自己登录这个系统
2. 登录系统之后，我能够看到相应的管理界面
3. 管理界面有四个模块，对应的就是需求里面的四个内容
   1. 人事管理模块
   2. 工资管理模块
   3. 用户管理模块
   4. 帮助模块
4. 以上四个模块共同构成了信息管理模块，这个模块需要数据库来增删改查数据。
5. 做完信息管理操作之后，我可以看到我最终操作的结果

接下来就是按照上面的思路，思考需要哪些符号来表示。最终其流程图如下：

需求工程的过程

需求工程的过程如下：

• 需求获取
• 需求分析和建模

• 需求评审

  💡需求获取技术

  个别会谈和小组会议

  个别会谈需要**分析人员**、**用户**、**系统领域专家**一起参加。

• 用户：提出对系统功能以及性能方面的需求

• 领域专家：提供系统背景和领域需求等方面的知识

这其中，分析人员需要调研需求，学习和掌握系统背景知识，保证需求获取的正确性。
小组会议则是针对系统的不同用户进行的，为了保证各方需求的完整性和一致性。

问卷调查

设计问卷的目的是让用户清晰的明白问题的主旨，方便用户抓住某些功能和系统性能方面问题的实质。
设计问卷的时候需要注意如下事项：

1. 避免使用抽象和含糊不清的词句
2. 避免问题带有导向性
3. 避免全是选择题

   面向用例的场景分析

   就是模拟了实际的用户操作流程进行需求分析。

   快速原型技术

   所谓快速原型技术，指的是让用户尽早的接触到系统，让用户对系统的原型进行不断的评估，指出不足之处并且提出修改意见。分析和开发人员在系统原型基础上针对用户的意见进行修改或者重新开发。
   快速原型法有两种类型：

• 抛弃原型法：设计完初代原型之后，把原有的模型抛弃重新迭代设计一个更加符合用户需求的系统。
• 演化原型法：不断在初代原型的基础上增加功能，修改原型的不足，知道制作出符合用户需求的软件。

  💡结构化需求分析与建模

  面向数据的数据建模

  所谓数据建模设计系统各部分的数据对象，数据对象就是实体，实体属性以及实体间的关系。一般我们会使用E-R图来表示这种数据对象。
  E-R图的符号说明如下：
  

  详细的绘制在后面的案例当中讲解。

面向数据流的功能建模

计算机系统其实本质是可以看做一个转换函数，用户输入x，系统输出y。功能模型就是在抽象层次上，用户输入x在系统中变化成为y的转换函数。

数据流图（Data Flowing Diagram，DFD）是结构化建模中最流行的功能建模工具。DFD描述从数据输入、数据转换、数据存储到数据输出的全过程。能对DFD图分层，分层的DFD更进一步刻画了系统的功能分解。
符号说明如下：

DFD的分层思想是：自内向外，自顶向下，逐层细化，逐步精细。DFD的顶层（第0层）就是一个 x -> 某一系统 -> y的绘制。 下面分层的DFD就是对于这个系统细化的绘制。

这里只需要掌握DFD的顶层图的绘制即可。具体再后续的例子当中展现。

面向状态转化的行为建模

状态转换图（Status Transition Diagram，STD）通过描述系统状态及引起状态转换的事件来表示系统行为。STD图同时也反映了事件执行的行为。STD图主要由状态、转换和事件（什么样的情况下进行状态转化）的图形符号构成。

• 状态：大致分为初态，中间状态，终态，复合状态
• 状态转换：从一个状态转变为另一个状态
• 事件：触发状态转换的条件或者一系列动作
  • enetry事件：用于说明转换到该状态的特定动作
  • exit事件：用于说明触发该状态的特定动作
  • do事件：用于说明处于当前状态的时候执行的动作

符号说明如下：

过程描述语言（PDL）也叫作伪代码语言，通过伪代码简略描述DFD中的过程，其关键词语义通常和程序设计语言的保留字一致。他主要包括以下内容：
（1）顺序结构
（2）选择结构
选择结构的PDL的关键词定义如下：

if A then B

上面的意思是，如果满足表达式A，则执行相关B代码块。

if A then B else C

上面的意思是，如果满足表达式A，则执行相关B代码块，否则执行代码块C。

select A
    case value1:BLOCK1;
    case value2:BLOCK2;
    ...
    case valueN:BLOCKN;
end select

上面的意思是，如果A = value1，则执行相关BLOCK1代码块，后面也是以此类推。
（3）循环结构

while (条件表达式1) {BLOCK1;} // 满足表达式1的时候，循环执行BLOCK1
do{BLOCK2;} while(条件表达式2) // 先执行BLOCK2，满足表达式2的时候继续，否则停止
repeat{BLOCK3;} until(条件表达式3) // 循环执行BLOCK3，直到满足表达式3

注意**;**。

（4）整体框架

procedure 程序名称()
{
    程序内容;
}

同样注意这里每一句结束都要加上分号;

举个例子：

procedure ATM自动取款()
{
    插入银行卡，输入密码次数初始化：InputTimes = 0;
    while(InputTimes <= 3){
        输入密码KEY;
        if (KEY == 预留密码) then 退出循环;
        InputTimes++;
    }
    if(InputTimes > 3){ 提示：输入密码错误;}
    else{取款;}
    退出银行卡;
}

数据字典

数据字典一般用于描述整个系统中的所有的数据信息，需要包含数据的名称，含义，类型，范围，一般以数据库对象为单位进行描述。

数据字典的设计原则

1. 按照统一的数据字典定义形式来编写
2. 实用为基础
3. 保证数据字典定义的完整性
4. 确保数据字典定义的一致性

   数据字典的词条描述

   例如：

   数据元素名：词
   类型：文字（char* 类型）
   长度：任意长度
   取值范围：1{名次|代词|动词|副词|形容词|数量词|介词|连词|助词}n
   相关的数据元素：小词性
   相关数据元素的数据结构：字符型（不能为空）

   也就是说明数据的名字，类型，长度，范围等因素，具体根据题目来。

   一般不考。

数据字典的定义式描述

这个方法是借助BNF来描述数据的。

💡需求评审

软件需求规格说明

这里一般包括两样东西：

• 软件需求规格说明（SRS）：这是经过分析员分析之后形成的软件文档

• 数据需求说明（DRD）：描述在生命周期内所处理的数据

  需求评审标准和需求验证

  需求评审就是验证SRS/DRD是否满足以下八个性质：

• 正确性

• 完整性
• 一致性
• 可行性
• 可理解性
• 可验证性
• 可修改性

• 可追踪性

  需求变更管理

  有四个阶段：

• 确定需求基线

• 需求变更影响分析
• 需求变更维护记录
• 需求变更的稳定性、可控性和延续性

💡案例——简历自动获取和查询系统的需求建模

具体问题的描述，参见书上P28-29页。大致的功能就是用户可以向该系统提供各种简历，系统会自动识别每一份简历，提取出关键信息，形成一份简化的简历，HR就可以通过查看这简化的简历节省时间精力。

数据建模——E-R图绘制

首先需要从问题的描述出，归纳总结出这个系统所需要的：

• 实体
• 实体和实体之间的关系
• 实体拥有的相应属性

那么这里可以归纳出如下实体：

• 简历：编号，姓名，性别，年龄，专业*，手机号码，特长
• 用户：工号，姓名，所属部门编号，权限，参加工作时间，专业，特长，简历
• 部门：编号，名称，职责，隶属，管理

  其中*表示属性不能为空

根据上述归纳可以画出ER图为：

功能建模——数据流图绘制

这里只需要学会绘制顶层数据流图，这里需要确定三个元素：

• 输入：用户需要输入登录信息和查询的简历信息
• 函数：也就是所使用的的系统
• 输出：经过系统查询到的简历信息

再考虑数据的流向：

• 数据发出的发起者：部门的用户
• 数据发出的源头：原始简历数据库、简历数据库
• 数据发出的尽头：部门的用户

行为建模——状态转换图绘制

绘制之前，首先剖析一下部门用户在这个系统中的状态：

• 未登录状态（初态）
• 主页面要求用户登录的状态
• 用户登录的时候系统等待用户的状态
• 系统验证用户信息的状态
• 主页面显示查询业务的状态
• 数据库检索所需要查询简历的装填
• 查询简历成功的状态
• 查询简历失败状态
• 退出登录状态（终态）

大概率会考原题，所以如果不会分析过程的话，就把这张图背下来。

加工逻辑——PDL语言描述

这里我们需要使用PDL语言来描述简历自动获取的过程。首先我们需要知道简历自动获取的过程如下：

1. 系统依次获取简历数据库当中的所有简历
2. 系统扫描当前的简历，提取出关键词和关键信息相关的语句的集合
3. 依次读取关键信息相关的语句的集合，获取其关键信息Info
4. 如果这个Info符号系统给的数据要求，那么把这个Info存入数据文件当中

   procedure 简历自动获取()
   {
    打开“原始简历数据库”;
    while(原始简历数据库不为空)
    {
        读取下一个电子简历文件Fi;
        用类自然语言文法分析Fi中的关键词;
        获取候选简历信息语句集;
        while(候选简历信息语句集不为空)
        {
            读取下一条简历信息语句Sj;
            根据文法描述获取语句Sj中的简历信息Info;
            if(Info符合数据要求)
            {
                将Info存入数据文件;
            }
        }
    }
   }

   数据字典

   我看了书上好几遍，就是没翻到有关这个系统的详细数据描述，所以大家直接背背吧。

   卡片形式定义

   

   定义式定义

   
   这里解析一下手机号：1[3|5|8]9{数字}9
   这里分为三个部分

• 1：表示开头为1
• [3|5|8]：表示第二位是3或者5或者8
• 9{数字}9：表示至少有9位数字，至多也是9位数字

这里的9{数字}9也可以写作