17/03/23

Chapters Kỹ thuật yêu cầu RE

1. Yêu cầu
1. Yêu cầu là gì?
Chapter III 2. Phân loại yêu cầu
3. Thế nào là một yêu cầu tốt?
Requirements Engineering 2. Quy trình RE
1. Rút ra yêu cầu từ thực tế
2. Phân tích yêu cầu và thương lượng
3. Đặc tả yêu cầu
4. Xác thực yêu cầu
5. Quản lý yêu cầu

1 2

1 2

Mục tiêu Yêu cầu là gì (Requirement - IEEE)?

 Kỹ thuật yêu cầu là một quá trình lặp bao gồm
nhiều loại hoạt động mang tính cộng tác
 Kết quả của quá trình là những đặc tả về hệ
thống phần mềm
 Ta dùng Requirements Engineering thay
cho Requirement Analysis vì nó có nghĩa
rộng hơn
a) A condition or capability needed by a user to solve
a problem or achieve an objective
b) A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification or other
formally imposed document
c) A documented representation of a condition or
capability as in definition (a) or (b)

3 4

3 4
 17/03/23

Yêu cầu phần mềm Needs of Different Audiences

 Đặc tả yêu cầu phản ánh việc hiểu biết lẫn

nhau về vấn đề được giải quyết giữa người
phân tích và khách hàng
 Nó là nền tảng cho hợp đồng giữa khách
hàng và tổ chức phát triển
 Hệ thống được phát hành phải được kiểm tra
về việc thỏa mãn các đặc tả yêu cầu
 Nó chuẩn bị cho giai đoạn tiếp theo là giai
đoạn phân tích

5 6

Mức độ mô tả yêu cầu Ví dụ: Xác định và đặc tả

 Yêu cầu người dùng:

 Viết chủ yếu cho người dùng
 Thường bằng ngôn ngữ tự nhiên cộng với các biểu đồ
 Mô tả các dịch vụ và những ràng buộc hoạt động
 Yêu cầu hệ thống
 Tài liệu có cấu trúc mô tả chi tiết chức năng, dịch vụ và
ràng buộc
 Có thể là một phần của hợp đồng, xác định những gì
cần phải thực hiện

7 8

7 8
 17/03/23

Người đọc Kỹ thuật yêu cầu (Requirements Engineering)?

 RE là bước chính yếu đầu tiên nhằm giải quyết vấn đề xử lý

dữ liệu. Trong giai đoạn này:
 Những yêu cầu của người dùng đối với hệ thống tương lai
được xác định và được tài liệu hóa cẩn thận
 Không cần xác định cách nào để giải quyết vấn đề

9 10

9 10

The hardest part What makes requirements difficult?

“The hardest single part of building a software system is deciding Comprehension (understanding)
precisely what to build. No other part of the conceptual work is as
difficult as establishing the detailed technical requirements...No
• People don’t (really) know what they want (…
other part of the work so cripples the resulting system if done wrong. until they see it)
No other part is as difficult to rectify later.” • Superficial grasp is insufficient to build correct
F.P. Brooks, “No Silver Bullet: Essence and Accidents of
software
Software Engineering” Communication
• People
work best with regular structures, conceptual
coherence, and visualization
• Software’s conceptual structures are complex,
arbitrary, and difficult to visualize

11 12
 17/03/23

What makes requirements difficult? Requirements engineering

Control (predictability, manageability)
• Difficult to predict which requirements will
be hard to meet
• Requirements change all the time
• Together can make planning unreliable, cost and schedu
le unpredictable
Inseparable Concerns
• Many requirements issues
cannot be cleanly separated (i.e., decisions about onen
ecessarily impact another)
• Difficult to apply “divide and conquer”
• Must make tradeoffs where requirements conflict
vs Requirement Analysis
We use the term requirement engineering rather
than the narrower notion of requirements analysis
to emphasize that it is an iterative and co-operative
process of analyzing a problem
 Documenting the resulting observations and
 Checking the accuracy of the understanding
gained
Requirements Engineering not only involves
technical concerns of how to prepare the
requirements but also play a dominant role in social
and cognitive aspects

14

13 14

3.1.2 Phân loại yêu cầu Yêu cầu chức năng

 Có 3 loại yêu cầu:  Một số yêu cầu chức năng

 Yêu cầu chức năng: chức năng dịch vụ hệ thống cung cấp  Chức năng tính toán
 Yêu cầu phi chức năng: những ràng buộc về tiêu chuẩn,  Chức năng lưu trữ
thời gian, quy trình phát triển…, chủ yếu là những yêu  Chức năng tìm kiếm
cầu về chất lượng.
 Chức năng kết xuất
 Yêu cầu miền ứng dụng: phản ánh những đặc trưng của
 Chức năng backup, restore
miền ứng dụng
 Chức năng đa người dùng
 Có những yêu cầu ngầm định (implicit)
 Chức năng đa phương tiện…
 A requirement may be conscious (nhận biết) (known,
 Yêu cầu chức năng chỉ ra những gì hệ thống làm, chúng
spoken) / unconscious (forgotten, unspoken…)
thường quan hệ với những nguồn đặc trưng, thường là
các use-case hay những quy tắc nghiệp vụ (business
rule)

15 16

15 16
 17/03/23

Ví dụ Yêu cầu phi chức năng

 Trong hệ thống quản lý thư viện
 Người dùng có thể tìm kiếm, download, in những bài báo
 Người dùng được cấp một vùng lưu trữ riêng để có thể
copy để lưu trữ tài liệu lâu dài
 Một số yêu cầu phi chức năng
 Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ…
 Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ
lập trình…
 Yêu cầu của người sử dụng: dễ sử dụng, thân thiện
 Ràng buộc về ngân sách
 Phù hợp với các chính sách của tổ chức sử dụng hệ
thống
 Yêu cầu tương thích giữa phần cứng và phần mềm
 Các yêu cầu từ các tác nhân ngoài khác…

17 18

17 18

Các loại yêu cầu phi chức năng Các loại yêu cầu phi chức năng

19 20
 17/03/23

Ví dụ Mục tiêu (Goal) và đo lường (measure)

 Trong hệ thống quản lý thư viện
 Yêu cầu sản phẩm: giao diện người dùng không chứa
frame và applet java
 Yêu cầu tổ chức: qui trình phát triển hệ thống và tài liệu
phân phối phải phù hợp theo tiêu chuẩn “STAN-07”
 Yêu cầu ngoài: hệ thống không được lộ thông tin của
khách hàng
 Những yêu cầu phi chức năng khó phát biểu chính xác,
mơ hồ nên cần bổ sung bằng mục tiêu và một số đo
lường
 Ví dụ
 Một mục tiêu của hệ thống
 Hệ thống dễ sử dụng cho những người đã có kinh nghiệm và
người dùng có thể tùy biến được giao diện làm việc
 Một yêu cầu phi chức năng có thể kiểm tra
 Người dùng có kinh nghiệm có thể sử dụng tất cả các chức
năng sau 2 giờ huấn luyện. Sau khi huấn luyện người dùng có
kinh nghiệm sẽ không có lỗi trung bình quá 2 lỗi /ngày

21 22

21 22

Đo lường Yêu cầu miền ứng dụng

 Yêu cầu miền ứng dụng được xác định từ lĩnh vực
Property Measure
ứng dụng của hệ thống, nó phản ánh các thuộc tính
Speed Processed transactions/second
User/Event response time và ràng buộc của lĩnh vực ứng dụng.
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames

Reliability Mean time to failure

Probability of unavailability
Rate of failure occu rrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems

23 24

23 24
 17/03/23

Các vấn đề về yêu cầu miền ứng dụng
 Tính hiểu được
 Yêu cầu cần diễn đạt theo ngôn ngữ miền ứng dụng,
khó hiểu cho người phát triển
 Ẩn ý
 Những chuyên gia miền thường quá thông thuộc trong
lãnh vực của mình nên họ thường làm những yêu cầu
miền không tường minh
3.1.3 Thế nào là một yêu cầu tốt?
 Correct - a quality that can only be ensured by the
customer or user representative
 Possible (feasible khả thi) - a quality that requires
knowledge of the environment on the part of the developer;
available tools, techniques, people and budgets must be
able to satisfy the final requirements;
 Necessary
 Prioritized
 Very important – absolutely necessary (to be implemented in the
next release)
 Important - but not necessary for the next release
 Purely optional - nice to have but implementation will depend
on resources and schedule

25 26

25 26

3.1.3 Thế nào là một yêu cầu tốt? 3.2 Requirements Engineering

 Unambiguous (rõ ràng) ●The requirements engineering process can

 Concise (ngắn gọn) - with only the information necessary to be described in five distinct steps:
proceed too the next development step; ● requirements elicitation
 Verifiable (có thể thẩm tra) (testable, measurable) ● requirements analysis and negotiation
● requirements specification
Cần chú ý tới những nhu cầu trong tương lai (future needs)
● requirements validation
● requirements management

27 28

27 28

Requirements Elicitation
● In requirements engineering, requirements elicitation is
the practice of researching and discovering the
requirements of a system from users, customers, and
other stakeholders. The practice is also sometimes
referred to as "requirement gathering".
29
29
Requirements Elicitation
31
17/03/23
Requirements Elicitation
● Requirements elicitation is difficult
● Problems of scope. The boundary of the system is ill-
defined or the customers specify unnecessary technical
detail that may confuse,
● Problems of understanding. The customers are not
completely sure of what is needed, have a poor
understanding of the capabilities and limitations of their
computing environment, don’t have a full understanding of
the problem domain, have trouble communicating needs to
the system engineer, omit information that is believed to be
“obvious,” specify requirements that conflict with the needs
of other customers/users, or specify requirements that are
ambiguous or untestable.
● Problems of volatility. The requirements change over time.
30
30
Requirements Elicitation
32

Requirements Elicitation
● Detailed guidelines for requirements elicitation:
● Assess the business and technical feasibility for the
proposed system.
● Identify the people who will help specify requirements
and understand their organizational bias.
● Define the technical environment (e.g., computing
architecture, operating system, telecommunications
needs) into which the system or product will be placed.
● Identify “domain constraints” (i.e., characteristics of the
business environment specific to the application
domain) that limit the functionality or performance of
the system or product to be built.
33
33 34
Requirements Elicitation
● The work products include:
● A statement of need and feasibility.
● A bounded statement of scope for the system.
● A list of customers, users, and other stakeholders who
participated in the requirements elicitation activity.
● A description of the system’s technical environment.
● A list of requirements (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.
35
35 36
17/03/23
Requirements Elicitation
● Detailed guidelines for requirements elicitation (cont.):
● Define one or more requirements elicitation methods
(e.g., interviews, focus groups, team meetings).
● Solicit participation from many people so that
requirements are defined from different points of view;
be sure to identify the rationale for each requirement
that is recorded.
● Identify ambiguous requirements as candidates for
prototyping.
● Create usage scenarios to help customers/users better
identify key requirements.
34
Requirements Analysis & Negotiation
● Analysis
● categorizes requirements and organizes them into
related subsets;
● explores each requirement in relationship to others;
● examines requirements for consistency, omissions,
and ambiguity;
● and ranks requirements based on the needs of
customers/users.
36
 17/03/23

Requirements Analysis & Negotiation Requirements Analysis & Negotiation

● The following questions are asked and answered:
● Is each requirement consistent with the overall
objective for the system/product?
● Have all requirements been specified at the proper
level of abstraction? That is, do some requirements
provide a level of technical detail that is inappropriate
at this stage?
● Is the requirement really necessary or does it
represent an add-on feature that may not be essential
to the objective of the system?
● The following questions are asked and answered (cont.):
● Is each requirement bounded and unambiguous?
● Does each requirement have attribution? That is, is a
source (generally, a specific individual) noted for each
requirement?
● Do any requirements conflict with other requirements?
● Is each requirement achievable in the technical
environment that will house the system or product?
● Is each requirement testable, once implemented?

37 38

37 38

Requirements Specification Requirements Specification

● A specification can be:
● a written document, Everyone knew exactly
● a graphical model, what had to be done
● a formal mathematical model, until someone wrote it
down!
● a collection of usage scenarios,
● a prototype,
● or any combination of these.
● For large systems, a written document, combining natural
language descriptions and graphical models may be the
best approach.
● For smaller systems, usage scenarios may be all that are
required for smaller products or systems that reside within
well-understood technical environments.
39 40

39 40

Requirements Specification
● The Software Requirement Specification (SRS) is the final
work product produced by the system and requirements
engineer.
● It describes the function and performance of a computer-
based system and the constraints that will govern its
development. The specification bounds each allocated
system element.
● The System Specification also describes the information
(data and control) that is input to and output from the
system.
41
41
Đặc tả bằng ngôn ngữ có cấu trúc
 Giới hạn sự tự do của người viết bằng những mẫu
 Tất cả yêu cầu được viết theo một cách chuẩn
 Giới hạn thuật ngữ sử dụng
 Duy trì sự thuận lợi của diễn đạt của ngôn ngữ tự
nhiên nhưng có sự đồng nhất
43
43
17/03/23
Đặc tả yêu cầu
 Đặc tả bằng ngôn ngữ tự nhiên
 Đặc tả yêu cầu của hệ thống bằng ngôn ngữ tự
nhiên thường gặp một số vấn đề sau:
 Không rõ ràng: Ngôn ngữ tự nhiên có thể diễn đạt
phong phú nhưng thiếu chính xác
 Quá mềm dẻo: với cùng một vấn đề nhưng có
nhiều cách khác nhau để đặc tả
 Thiếu tính cấu trúc
42
42
Đặc tả dựa vào biểu mẫu
Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: Safe sugar level
Description Computes the dose of insulin to be delivered when the current measured sugar level is in
the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1)
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose Š the dose in insulin to be delivered
Destination Main control loop
Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of
increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is
computed by dividing the difference between the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be
delivered.
Requires Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects None
44
44
 17/03/23

Đặc tả dạng bảng NGÔN NGỮ PDL

 Ngôn ngữ PDL (program design language) vay mượn từ

Condition
Sugar level falling (r2 < r1)
Sugar level stable (r2 =r1)
Sugar level increasing and rate of
increase decreasing ((r2-r1)<(r1-r0))
Sugar level increasing and rate of
increase stable orincreasing. ((r2-r1) <
(r1-r0))
vựng của ngôn ngữ tự nhiên và cú pháp của ngôn ngữ
Action lập trình có cấu trúc. Nó có các tính chất sau
CompDose = 0
 Cú pháp chặt chẽ của các từ khoá hỗ trợ đặc tả cấu trúc,
khai báo dữ liệu, phân chia module
CompDose =0
 Cú pháp tự do của ngôn ngữ tự nhiên giúp miêu tả xử lý
CompDose = 0
 Phương tiện mô tả dữ liệu đơn cũng như dữ liệu tổ hợp
 Cơ chế định nghĩa chương trình con và cách gọi
CompDose = round ((r2-r1)/4)
If rounded result = 0 then
CompDose = MinimumDose

45 46

45 46

NGÔN NGỮ PDL Đặc tả theo mô hình

procedure AnalyzeTriangle( a, b, c: in real;
type: out string)
begin
sort a, b, c so that a >= b >= c;
if ( c > 0 and a < b + c )
if ( a = c )
type := “Equilateral”
else
if ( a = b or b = c )
type := “Isosceles”
else
if ( a*a = b*b + c*c )
type := “Right”
else
type := “Scalene”
else
type := “Error”
end
47

47 48
 17/03/23

Đặc tả theo mô hình Đặc tả theo mô hình

49 50

Đặc tả theo mô hình Đặc tả theo mô hình

52

51 52
 17/03/23

Tài liệu đặc tả theo IEEE System Modelling

 1. Giới thiệu
 1.1. Mục đích của tài liệu yêu cầu ● In order to fully specify what is to be built, you would need
 1.2. Phạm vi của sản phẩm a meaningful model.


1.3. Các định nghĩa, từ viết tắt
1.4. Các tham chiếu
● It is important to evaluate the system’s components in
 1.5. Tổng quan về tài liệu yêu cầu
relationship to one another, to determine how
 2. Mô tả chung requirements fit into this picture, and to assess the
 2.1. Giới thiệu chung về sản phẩm “aesthetics” of the system as it has been conceived.
 2.2. Các chức năng của sản phẩm
 2.3. Đặc điểm của người sử dụng
 2.4. Các ràng buộc
 2.5. Giả thiết và các phụ thuộc
 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức
năng, miền ứng dụng và giao diện.
 4. Phụ lục
 5. Chỉ mục

53 54

53 54

Requirements Validation Requirements Validation

● Requirements validation examines the specification to ● The primary requirements validation mechanism is the
ensure that formal technical review.
● all system requirements have been stated ● The review team includes system engineers, customers,
unambiguously; users, and other stakeholders.
● that inconsistencies, omissions, and errors have been ● The review team examine the system specification, look
detected and corrected; for:
● and that the work products conform to the standards ● errors in content or interpretation,
established for the process, the project, and the ● areas where clarification may be required,
product.
● missing information,
● inconsistencies,
● conflicting requirements,
● or unrealistic (unachievable) requirements.
55 56

55 56
 17/03/23

Requirements Management Requirements Management

● Requirements management is a set of activities that help ● Once requirements have been identified, traceability
the project team to identify, control, and track tables are developed.
requirements and changes to requirements at any time as
the project proceeds.
● Each requirement is assigned a unique identifier that
might take the form:
<requirement type><requirement #>
where requirement type takes on values such as F = functional
requirement, D = data requirement, B = behavioral requirement, I =
interface requirement, and P = output requirement.

E.g., a requirement identified as F09 indicates a functional requirement

assigned requirement number 9.

57 58

57 58

Requirements Management Software Requirements Analysis

● Among many possible traceability tables are the following: ● Requirements analysis allows the software engineer to
● Features traceability table. Shows how requirements refine the software allocation and build models of the
relate to important customer observable data, functional, and behavioral domains that will be
system/product features. treated by software.
● Source traceability table. Identifies the source of each ● Requirements analysis provides the software designer
requirement. with a representation of information, function, and
behavior that can be translated to data, architectural,
● Dependency traceability table. Indicates how
requirements are related to one another. interface, and component-level designs.
● Subsystem traceability table. Categorizes ● Finally, the requirements specification provides the
requirements by the subsystem(s) that they govern. developer and the customer with the means to assess
quality once software is built.
● Interface traceability table. Shows how requirements
relate to both internal and external system interfaces.

59 60

59 60
 17/03/23

Software Requirements Analysis Software Requirements Analysis

● Software requirements analysis may be divided into five ● The analyst must
areas of effort: ● define all externally observable data objects,
● (1) problem recognition, ● evaluate the flow and content of information,
● (2) evaluation and synthesis, ● define and elaborate all software functions,
● (3) modeling, ● understand software behavior in the context of events
● (4) specification, that affect the system, establish system interface
● and (5) review characteristics,
● and uncover additional design constraints.

61 62

61 62

Software Req. Analysis Principles Software Req. Analysis Guidelines

1. The information domain of a problem must be ● Understand the problem before you begin to create the
represented and understood.
analysis model
2. The functions that the software is to perform must be
defined. ● Develop prototypes that enable a user to understand how
3. The behavior of the software (as a consequence of
external events) must be represented. human/machine interaction will occur.
4. The models that depict information, function, and
behavior must be partitioned in a manner that uncovers
● Record the origin of and the reason for every requirement.
detail in a layered (or hierarchical) fashion. ● Use multiple views of requirements.
5. The analysis process should move from essential
information toward implementation detail. ● Rank requirements.
● Work to eliminate ambiguity.

63 64

63 64
 17/03/23

Software Models Prototyping Approach

● Functional models. Software transforms information, and ● The prototyping paradigm can be either close-ended or
in order to accomplish this, it must perform at least three open-ended.
generic functions: input, processing, and output. When ● The close-ended approach is often called throwaway
functional models of an application are created, the prototyping;
software engineer focuses on problem specific functions.
● An open-ended approach, called evolutionary
prototyping, uses the prototype as the first part of an
● Behavioral models. Most software responds to events analysis activity that will be continued into design and
from the outside world. This stimulus/response construction.
characteristic forms the basis of the behavioral model. A
computer program always exists in some state—an
externally observable mode of behavior (e.g., waiting,
computing, printing, polling) that is changed only when
some event occurs.

65 66

65 66

Prototyping Approach Prototyping Approach

● It is necessary to determine whether the system to be built
● It is necessary to determine whether the system to be built is amenable to prototyping.
is amenable to prototyping.
● application area,
● application area,
● application complexity,
● application complexity,
● customer characteristics,
● customer characteristics,
● and project characteristics.
● and project characteristics.

67 68

67 68

Prototyping Approach
● Prototyping Methods and Tools
● Fourth generation techniques
● Reusable software components
● Formal specification and prototyping
environments
69
69
Software Specification Principles
● Specification principles:
● Separate functionality from implementation.
● Develop a model of the desired behavior of a system
that encompasses data & the functional responses of a
system to various stimuli from the environment.
● Establish the context in which software operates by
specifying the manner in which other system
components interact with software.
● Define the environment in which the system operates
71
71
17/03/23
Software Specification
● Specification may be viewed as a representation process.
Requirements are represented in a manner that ultimately
leads to successful software implementation.
70
70
Software Specification Principles
● Specification principles (cont.):
● Create a cognitive model rather than a design or
implementation model. The cognitive model describes
a system as perceived by its user community.
● Recognize that “the specifications must be tolerant of
incompleteness and augmentable.” A specification is
always a model of some real situation that is normally
quite complex. Hence, it will be incomplete and will
exist at many levels of detail.
● Establish the content and structure of a specification in
a way that will enable it to be amenable to change.
72
72