Computing and SE II Chapter 4: Requirements Engineering

Presentation on theme: "Computing and SE II Chapter 4: Requirements Engineering"— Presentation transcript:

1 Computing and SE II Chapter 4: Requirements Engineering
Er-Yu Ding Software Institute, NJU

2 Main Contents What is requirement? Why RE (requirements engineering)?
Activities of RE

3 1. What is requirement? 需求定义[IEEE] （1）用户为了解决问题或达到某些目标所需要的条件或能力；
（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力； （3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。

4 What is requirement? －－问题域与解系统（1）
软件系统与外部环境

5 1. What is requirement? －－问题域与解系统 (2)
当现实的状况与人们期望的状况产生差距时，就产生了问题。 要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。 这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（Problem Domain） 软件系统通过影响问题域，能够帮助人们解决问题，称为解系统

6 1. What is requirement? －－共享现象
软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分的具有模拟特性。 换句话说，软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。 问题域中的某些信息能够和模型中的信息建立映射关系 这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象

7 1. What is requirement? －－需求
需求是用户对问题域当中的实体状态或事件的期望描述 R1：一旦书籍被借出，则在归还之前，它不能被再次借阅。 R2：在归还的书超过30天的归还期限时，归还后应该进行超期处罚。 直接需求 可以通过更改共享现象被满足的需求 间接需求 需要修改共享现象，同时连锁影响问题域才能满足的需求

8 1. What is requirement? －－规格说明
规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征 主要包括两个部分： （1）对共享现象（模型）的描述； （2）系统对共享现象所施加的操作的描述。

9 1. What is requirement? －－问题域特性
问题域自治的规律性称为问题域特性 包括结构特性和行为特性等 问题域特性的重要性 要想解决问题，它就需要了解问题域特性，将解决方案和问题域特性结合起来 要防止解系统的引入在问题域当中引发未预见的连锁反应

10 1. What is requirement? －－从问题域、需求和规格说明的关系看需求工程
描述明确的问题域特性E; 定义良好的系统行为S ; 预期的需求R 需求工程的目的就是根据E，构建S，使得 需求工程的困难之处： （1）不存在描述明确的E； （2）不存在确定的针对S的评估标准R； （3） 是一个创造性的过程。 需求工程的主要工作 需求开发,确定 R 研究问题背景，描述问题域特性E 构建解系统，描述解系统行为S，使得

11 1. What is requirement? －－需求的分类IEEE
功能需求（Functional Requirement）： 和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。 性能需求（Performance Requirement）： 系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。 质量属性（Quality Attribute）： 系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。 对外接口（External Interface）： 系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。 约束 进行系统构造时需要遵守的约束，例如编程语言、硬件设施等

12 1. What is requirement? －－功能需求的层次性

13 1. What is requirement? －－功能需求的层次性
业务需求 系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统 参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision） 用户需求 执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么 特性 模糊、不清晰 多特性混杂 多逻辑混杂 系统级需求 用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求 系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么

14 1. What is requirement? －－功能需求的层次性
将用户需求转化为系统需求的过程是一个复杂的过程 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型； 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。

15 2. Why RE ？ －－From theory （1） 模拟性
应该如何在计算世界中模拟现实世界？ 怎样建立共享知识？ 计算世界 现实世界

16 2. Why RE ？ －－From theory （2）现实世界
复杂 复杂性1：包含大量关联事物，具有巨量的分解和组合 复杂性2：对任一事物都不能完全描述，因为从不同的角度出发有不同的观察结论 非形式化的事物描述 实体 概念 …

17 2. Why RE ？ －－From theory （3）计算世界
形式化描述 有限的实体单位 合作 依赖 包含、继承 调用、使用 控制逻辑 序列 软件构建单位 单位组织方法

18 2. Why RE ？ －－From theory （4）需求分析
建立分析模型 以中立的（接近用户语言）语言、半形式化的方式定义“软件应该做什么” 限定了模拟的范围，软件设计按照定义来安排计算实体及其组合方式 缓和了用户和软件设计者之间（形式化 VS 非形式化）的交流差距

19 2. Why RE ？ --From Practices (1)

20 2. Why RE ？ --From Practices (2) ,Standish Group 1995
成功项目的影响要素 影响指数 用户参与 15.9％ 高层管理支持 13.9％ 清晰的需求说明 13.0％ 正确的项目计划 9.6％ 切合实际的期望 8.2％ 细化的项目里程碑 7.7％ 员工能力 7.2％ 主人翁精神 5.3％ 清晰的目标和前景 2.9％ 努力工作 2.4％ 其他

21 2. Why RE ？ --From Practices (3) , Standish Group1995
失败项目的影响要素 影响指数 不完整的需求说明 13.1％ 缺少用户输入 12.4％ 缺乏资源 10.6％ 不切实际的期望 9.9％ 缺乏高层管理支持 9.3％ 需求变化 8.7％ 缺乏计划 8.1％ 额外的无用功能 7.5％ 缺乏IT管理 6.2％ 技术能力不足 4.3％ 其他

22 2. Why RE ？ --From Practices (4) , Standish Group1995
需求因素 用户参与（用户输入） 高层管理支持 清晰的需求说明 切合实际的期望 清晰的目标和前景 需求变化 额外的无用功能 综合来看，需求因素 对成功项目的影响指数为53.9％ 对失败项目的影响指数为60.9％

23 2. Why RE ？ --From Practices (5) , ESPITI，1996
欧洲软件协会ESI 欧洲软件过程改进培训计划项目ESPITI 17个国家的超过3800个组织

24 2. Why RE ？ --People think requirements is main troubles
“There is little doubt that project requirements are the single biggest cause of trouble on the software project front. Study after study has found that, where there is a failure, requirements problems are usually at the heart of the matter.” [GLAS98] 'as much as 90% of subsequent troubles can be traced back to erroneous original specifications.’ [BRUC89]

25 2. Why RE ？ －－需求工程 是软件工程的一个分支 它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束
同时它也关注以上因素和准确的软件行为规格说明之间的联系 关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系

26 3. Activities of RE 最常见的基本活动分类

27 3. Activities of RE－－教材的活动分类
Inception Elicitation Elaboration Negotiation Specification Validation Requirements management Elicitation Analysis

28 3. Tasks of RE---Inception
Establishing project vision and scope basic understanding of the problem (Objectives) the nature of the solution that is desired (Vision) How many things needed to developing the solution (Scope) Stakeholders Analysis the people who want a solution Characteristics of Stakeholders the effectiveness of preliminary communication and collaboration between the customer and the developer Make usage of characteristics of Stakeholders

29 3. Activities of RE---Inception
Identify stakeholders “who else do you think I should talk to?” Recognize multiple points of view Understand stakeholders Work toward collaboration Establish common objectives, vision and scope The first questions Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution Is there another source for the solution that you need?

30 3. Tasks of RE---Elicitation
From where? (Source) Stakeholders, hard data, environments Elicit what? (Content) How many requirements How many elicit activities Which requirements in each elicit activities How to elicit (technique) Interview, prototype, observe, scenario (use case)… Up to source and content

31 3. Activities of RE--- Eliciting Requirements
the goal is to identify the problem propose elements of the solution negotiate different approaches, and specify a preliminary set of solution requirements

32 3. Activities of RE--- Elicitation Work Products
a statement of need and feasibility. a bounded statement of scope for the system or product. a list of customers, users, and other stakeholders who participated in requirements elicitation a description of the system’s technical environment. a list of requirements (preferably organized by function) and the domain constraints that apply to each. a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. any prototypes developed to better define requirements. …

33 3. Activities of RE---Elaboration
Create an analysis model that identifies data, function and behavioral requirements 一图胜千言 Analysis models can describe requirements more precise In analysis, solution requirements can be deduced Elaboration and elicitation are interweaved activities Get something, understand them, and need more…

34 3. Activities of RE--- Negotiating Requirements
Agree on a deliverable system that is realistic for developers and customers Identify the key stakeholders for conflicts These are the people who will be involved in the negotiation Determine each of the stakeholders “win conditions” Win conditions are not always obvious Negotiate Work toward a set of requirements that lead to “win-win”

35 3. Activities of RE---Specification
Writing what you know For communication to Developers Projects managers Users Testers User manual writers … With documents Using template Using writing techniques

36 3. Activities of RE--- Validating Requirements
Assure the specifications are according to users requirements Misunderstanding Writing error missing Validating focus See textbook Validating with some standards Good enough, but not perfect

37 3. Activities of RE--- Requirements management
Establishing baseline after requirements development Putting RE products into Software Configuration Management Maintaining track matrix Knowing the impacts of each requirements Change control Not every change is forbidden Not every change is permitted

38 The End Recommend Paper Next Lecture
《Software Requirements: A Tutorial》 《The World and The Machine》 Next Lecture Requirement Analysis