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.3.2 Requirements elicitation and analysis

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

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

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

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

• Problems of requirements analysis with stakeholders：

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

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

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

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

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

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

• 例子：stakeholders in MHC-PMS
  

• 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结合。