Chapter4：Requirements Engineering：SE_Notes《软件工程》笔记

Chapter4：Requirements Engineering

4.1 User / System Requirements

• Topic covered：
  

• Requirements engineering

  需求工程：是建立服务Service和限制Constraints的一个过程。

  Service：客户需要系统提供什么样的功能？

  Constraints：系统在开发和运行过程中受到的限制。

  Requirements：是在需求过程活动中产生的功能和限制的描述。

• What is a requirement?

  这种需求描述。涵盖了从高层次抽闲的语句上的描述，到非常详细的数学上的功能定义。也就是说，需求的描述可以是自然语言的描述也可以是数学上的精确的定义。

  之所以需要比较高层的抽象，采用自然语言、一般的图表来陈述。这需要客户和开发团队的对高层概念的理解，同时可能是

  也有可能是合同投标的基础，因为大家都可以理解。

  详细的数学定义：包括了数学模型，专业的建模语言，主要是为了开发者详细描述功能和约束条件，设计和开发才能够满足准确的功能和性能上的要求。这也是客户和开发团队签合同的基础。

• 一个领域的专家对软件需求描述到什么样的程度？

  抽象到什么样的程度？抽象是有不同的粒度的。粗细。红色字体部分：

  需求应该对还没有开发的软件，有足够的抽象来定义。

  一方面是，需求的描述要让投标方（开发团队）和客户都能理解。

  另一方面，详细和准确的合同定义，是合同条约的基础。并且也为软件做完后，交付后如何验证提供依据。

• 两方面的需求

  用户需求和系统需求。

  用户需求：自然语言 + 图表 来描述系统提供的功能和限制。是为客户需要产生的。

  系统需求：更详细的描述。定义的是实现什么？可能是合同的一部分。

  不同：

  系统能生成月报表，能展示处方药的价格。

  哪些人需要的？读者是谁？

• 用户需求和系统需求是哪些人需要的，读者是谁？

Client managers不会关注系统细节，developers会关注。

后面讲到a b 测试， 用于最终用户检验：软件是否满足了他们的需求

4.2 Functional and non-functional requirements

4.2.1 What is NR&NFR ?

前面提到的Service和Constrains。Service就是Function requirements；Constrains就是Non-functional requirements

域需求，应用域的概念，某个领域对系统的约束。

4.2.2 Functional Requirements

• 介绍：
  

• 例子：对MHC-PMS的功能性需求的描述：
  
  ​ 这些描述是不准确的，自然语言表达的，模糊的，只适合用户需求的描述。

• 需求如果不能带来准确的描述的话，就会有歧义imprecision

  比如ppt12里对“search”的理解不同。

• 需求的完整性complete和一致性consistency

  • 所有需要的功能都被列出了。
  • 所有的需求描述不相互冲突。
  • 实际上，完全满足完整性和一致性的文档是不可能的，往往需要寻找平衡点。

4.2.3 Non-functional Requirements

• 介绍

  定义了系统的属性properties和限制constrains【比如可靠性、响应时间等】

  开发过程中的限制【比如你要用特定的IDE】

  非功能需求可能比功能性需求更重要。

• Types of non-functional requirements

  Product R：产品本身的限制。

  Organizational R：开发机构的策略上、过程上的需求限制。环境上、运行操作中、开发过程中的。行业标准等。

  External R：来自外部的对系统本身和开发过程中的限制。行业监管的、道德文化的、法律层面的。
  

• 可能影响到系统的整体结构。
  

• 例子：
  

• 用一些度量指标来测试目标的非功能性需求满足度

  • 涉及到verify这个过程：非功能性需求比较难被verify，所以我们需要有一些指标的描述来特使目标产品的费功能性需求。变成一个：Testable non-functional requirements

  ​ ppt20例子

  • 非功能性度量指标
    
    这些只是一些举例，运用时要根据实际情况进行合适的修改和选择。

4.3 Requirements Engineering

4.3.1 RE processes

• RE processes 需求工程过程

  需求工程过程，会因为应用域、人员、开发机构等的不同，有很大的区别。

  但是，所有的过程都有一些通用的活动

  需求过程是迭代的过程的集合，上述活动是交替进行的。
  

• A spiral view of the RE process
  

4.4 Requirements elicitation and analysis

4.4.1 brief

• 需求的导出和分析【也称需求发现】

  工作人员和用户一起工作，发现应用域需求【service and constrains】

  设计的人员：最终用于、管理人员、维护人员、行业专家、贸易伙伴等，都称之为：stakeholders：系统的相关人员、拥有者、参与者。

  从不同的stakeholders角度看，每种角色需要哪些功能和性能上的要求。
  

4.4.2 Problems of requirements analysis with stakeholders：

stakeholders可能不知道他们真正想要的是什么【比如学历比较低】

也会经常使用他们自己的术语来描述需求。

不同的stakeholders会有相冲突的需求。【比如管理者和最终用户】

机构的策略政策可能会影响到系统需求

新的stakeholders出现或者环境改变，使得需求变化。

• 所以，Requirements elicitation and analysis 就必须要包含一些stages来尽量解决上述的问题，这是一个循环迭代的过程
  

4.4.3 确定stakeholders

• 例子：stakeholders in MHC-PMS
  

4.4.4 Interviewing & Ethnography

• Interviewing

  确立了stakeholders，下面就要进行一系列的活动和stakeholders交流。
  
  承上启下：

  interview常用于挖掘需求，但是interview对于理解行业领域需求【必须要有特定的知识背景才能理解需求】并不是一个好的方式，这就需要用另一种方法：ethnography【花时间观察实际工作从而理解特定行业知识理解需求】

• Ethnography

  • A social scientist spends a considerable time observing and analyzing how people actually work.

  • 观察实际工作模式能帮助理解已经存在的工作过程，但是不太容易识别出：要加入系统中的，系统的新的特性。

  • 那么如何来挖掘出系统里要加入的新的特性呢？可以结合Ethnography 和 prototype。

    原型可以帮助导出需求。原型建立了用户可以看得到的系统的初步轮廓，会启发用户的思维，提出更加精确的需求。
    

• 总结：
  先确立stakeholders，然后用interviewing或者ethnography的方法来获取需求。

  Interviewing用于一般的系统开发

  ethnography用于专业领域性较强的系统开发，且常和prototype结合。

  4.4.5 Stories and Scenarios

• 和stakeholders进行交流的时候，可以用stories和scenarios来描述实际的工作场景，有利于挖出工作流事件流。
  

• 例子：Scenario for collecting medical history in MHC-PMS

  在MHC-PMS系统中，现在要收集病史。我们现在用scenarios来描述这样的场景。

  具体见ppt2/3

4.5 Requirements specification

4.5.1 brief

• 到这一步开始写文档了。
  

• Ways of writing a system requirements specification

  有哪些表达方式呢？每种描述方式有哪些特性呢？
  

• Requirements and design

  原则上，需求Requirements应该说明系统应该做什么，而设计design应该描述它是如何做到这一点的。
  在实践中，需求和设计是分不开的。
  可以设计一个系统架构来构造需求;
  该系统可与产生设计要求的其他系统互操作;
  使用特定的体系结构来满足非功能性需求可能是领域需求。
  这可能是监管要求的结果。

4.5.2 Natural language specification

• 自然语言来描述需求、常与图表一起、这是所有人都能理解的【intuitive and universal 直观、通用】

• guidelines 建议
  

• 用自然语言描述需求的例子

  Example requirements for the insulin pump software system
  

4.5.3 Structed specifications

• 采用模板和表格的形式来进行需求的描述。
  

• Form-based specifications
  

• 例子：A structured specification of a requirement for an insulin pump .
  

• 表格Tabular specification

  表格用于对自然语言描述的东西做一些补充。
  
  例如：
  

4.5.4 Use cases

• Use cases 是一种 图形化的描述方法、图形化的模型。
  

• 例子：Use cases for the MHC-PMS

  小人：actor ；

  反应了系统的参与者，系统要提供的服务之间的交互。这是一种比较高层次的抽象，信息量少。

  后面还需要：用例描述、时序图，来描述细节。
  

4.5.5 requirements document

• brief
  

• 对于敏捷开发的需求文档

  敏捷开发、极限编程一般用 “user stories” 就好了，写太多需求文档没必要，因为需求变化很快，写的文档容易 out of date 。

  另一种系统叫做 Critical system ，比较严格，需要多个团队来开发，这就需要文档。
  

• stakeholders都用document来干啥？
  

• 需求文档的形式

  每个公司可能都有不同的标准，这里给出的是IEEE推荐的格式。

  具体见ppt22/23

  Preface、Introduction、Glossary、User Requirements Definition、System Architecture、System Requirements Specification、System Models、System evolution

  Chapter	Description
  前言	文档建立的背景、历史、原因。
  引言	描述系统功能、与其他系统的合作、系统如何适应运行软件的结构的整体业务和战略目标。
  词汇表	列出所有的技术词汇。
  用户需求	用户需求
  系统架构	描述高层的、总体的系统结构概况。
  系统需求	功能性、非功能性需求、与外部系统的接口。
  系统模型	采用图形建模方式来反应系统各组件之间、与外部环境之间的关系。从不同的角度来反应系统的行为特征。
  系统演化	基于基础的假设，应该能应对哪些可能产生的硬件软件变化。对设计决策重要。

4.6 Requirements validation

• 完成需求定义以后，需要对需求进行验证，用来证明写下的需求就是客户真正想要的。
  
• 主要检验这几个部分：
  
• 主要的需求验证技术：
  

4.7 Requirements Managements

• 管理变化的需求、还涉及到跟踪需求、维护需求之间的依赖关系。