CPT203 W4

The objectives of this week:

• understand the concepts of user and system requirements and why these requirements should be written in different ways;
• understand the differences between functional and nonfunctional software requirements;
• understand how requirements may be organized in a software requirements document;
• understand the principal requirements engineering activities of elicitation, analysis and validation, and the relationships between these activities;

---

Lecture

SOFTWARE PROCESS

1. Software Specification (This is what we mainly discussed about.)
2. Software Design and Implementation
3. Software Validation
4. Software Evolution

BACKGROUND

• The requirements for a system are the descriptions of what the system should do
  • reflect the needs of customers for a system 系统的需求是对系统应该做什么的描述，反映了客户对系统的需求
• The process of finding out, analyzing, documenting and checking these needs and constraints is called requirements engineering (RE) 发现、分析、记录和检查这些需求和约束的过程称为需求工程
• The requirements can be described in a high-level, abstract statement of a service that a system should provide or a constraint on a system. At the other extreme, it is a detailed, formal definition of a system function. 需求可以在系统应该提供的服务或系统约束的高级抽象声明中描述。在另一个极端，它是详细的、正式的系统功能定义。

---

USER REQUIREMENTS AND SYSTEM REQUIREMENTS

• High-level description or detail description? 高级描述还是详细描述?
  • As part of a contract for a large software development project, it must define its needs in a sufficiently abstract way 作为大型软件开发项目合同的一部分，它必须以一种足够抽象的方式定义其需求
  • Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do 一旦合同被授予，承包商必须为客户编写更详细的系统定义，以便客户理解并能够验证软件将做什么
• Different level of details serve different purpose. User requirements and system requirements 不同层次的细节服务于不同的目的。用户需求和系统需求
  • User requirements - Statements in a natural language plus diagrams to describe the services and constraint of a system 用户需求:用自然语言加上图表来描述系统的服务和约束
  • System requirements - more detailed descriptions of the software system’s functions, services, and operational constraint 系统需求:对软件系统功能、服务和操作约束的更详细的描述

---

Requirements should state what the system should do and the design should describe how it does this. 需求应该说明系统应该做什么，设计应该描述它是如何做的。

User Requirements:

• Client Managers
• System End-Users
• Client Engineers
• Contractor Managers
• System Architects

System Requirements:

• System End-Users
• Client Engineers
• System Architects
• Software Developers

---

FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS

• Software system requirements are often classified as functional requirements or nonfunctional requirements: 功能性需求和非功能性需求都是Software system requirements，功能性需求都是程序运行的最基本需求，非功能性是锦上添花的，例如搜索，软件运行速度之类的需求。
  • Functional requirements: These are statements of services the system should provide. How the services should react and behave in certain condition. In some cases, the functional requirements may also explicitly state what the system should not do. 功能需求这些是系统应该提供的服务声明。服务在特定条件下应该如何反应和行为。在某些情况下，功能需求还可能明确说明系统不应该做什么。
  • Non-functional requirements: These are constraints on the services or functions offered by the system. Non-functional requirements often apply to the system as a whole, rather than individual system features or services. 非功能需求这些是对系统提供的服务或功能的约束。非功能性需求通常作为一个整体应用于系统，而不是单独的系统特性或服务。但假如non functional requirement假如没有实现也可能会带来多个functional requirement的没有实现，最后导致系统无法正常使用。

The distinction between different types of requirement is not as clear-cut as these simple definitions suggest. 不同类型的需求之间的区别并不像这些简单定义所暗示的那样明确。

---

我觉得这样翻译ppt没有什么作用，主要的还是自己去看和理解吧。。。要是有空我再把这部分补上。

---

说一说use case diagram的事。
在use case图中，中间的矩形代表的是app部分。左右两边的小人代表的是这个程序的使用者，而中间的圆形则代表的了程序中发生的事件。箭头的指向则代表了人物参加app中的此项活动进行。
然而由于一个app中会有不同的事件发生。事件的关系一般有四种：

1. association
2. include
3. extend
4. generalization

假如A事件发生之后B事件一定会发生(属于A事件的子事件)，这种情况我们用虚线箭头从父事件连接子事件，并加上include，假如B事件发生之后A事件可能会发生，也可能不发生，我们用箭头从extend use case连接到base use case上，虚线上写上extend。
Extend points是主要事件的细节解释。
教你怎么画用例图（use case diagram）

找Actors：
who use the system
who maintain system
who start & stop system
谁提供信息给sys
什么外部系统和本系统相关联
在用例图中，每个小圈圈就是一个事件。我们需要让use case diagram中的事件越简单越好，细节都是写在use case scenario description里面。

---

References

1. XJTLU CPT203 slides (Week4)
2. 教你怎么画用例图（use case diagram）