MÔ ĐUN 03

ĐẶC TẢ YÊU CẦU PHẦN MỀM

Bộ môn Khoa học máy tính – Khoa Công nghệ thông tin
 MỤC TIÊU

- Yêu cầu là gì?

- Kỹ nghệ yêu cầu là gì? Mô tả quy trình Kỹ nghệ yêu cầu?
- Có những loại yêu cầu nào? Sự khác nhau giữa chúng?

- Có những phương pháp đặc tả yêu cầu nào? Sự khác nhau giữa
chúng?
- Có những công cụ đặc tả yêu cầu phần mềm nào? Mô tả một số
công cụ tiêu biểu?
- Giới thiệu chuẩn IEEE 830-1984.

2
 NỘI DUNG

 Kỹ nghệ yêu cầu

 Các loại yêu cầu
 Yêu cầu người dùng và Yêu cầu hệ thống
 Yêu cầu chức năng
 Yêu cầu phi chức năng
 Các phương pháp đặc tả yêu cầu
 Chuẩn tài liệu đặc tả yêu cầu IEEE 830-1984

3
 Yêu cầu là gì?

 Yêu cầu (requirement):

• là một tuyên bố (statement) trừu tượng ở mức cao về một
dịch vụ mà hệ thống phải cung cấp hoặc một ràng buộc lên
hệ thống. (Sommerville, 2011) (có thể dưới dạng biểu thức
toán học)
• là một tuyên bố về thứ hệ thống phải làm hoặc đặc tính mà
hệ thống cần phải có. (Dennis et al., Systems Analysis &
Design, (2012), trang 104)
 Các yêu cầu phản ánh nhu cầu của khách hàng đối với
hệ thống.
4
 Kỹ nghệ yêu cầu

 Kỹ nghệ yêu cầu (requirements engineering) là quá

trình tìm hiểu, phân tích, lập tài liệu và kiểm tra các dịch
vụ và các ràng buộc của hệ thống. (Ian Sommerville,
SOFTWARE ENGINEERING, (2011), trang 83)

5
 Quy trình Kỹ nghệ yêu cầu

Nguồn: Ian Sommerville, SOFTWARE ENGINEERING, (2011), trang 38.

6
 Quy trình Kỹ nghệ yêu cầu (tt.)

 Quá trình thiết lập những dịch vụ được yêu cầu và các
ràng buộc lên việc vận hành và phát triển của hệ thống.
• Nghiên cứu tính khả thi (Feasibility Study): Việc xây
dựng hệ thống có khả thi về mặt kỹ thuật và chi phí?
• Khám phá và Phân tích yêu cầu (Requirements
Elicitation and Analysis): Các bên liên quan yêu cầu hoặc
mong đợi gì từ hệ thống?
• Đặc tả yêu cầu (Requirements Specification): Định nghĩa
các yêu cầu một cách chi tiết.
• Thẩm định yêu cầu (Requirements Validation): Kiểm tra
tính hợp lệ của các yêu cầu.
7
 NỘI DUNG

 Kỹ nghệ yêu cầu

 Các loại yêu cầu
 Yêu cầu người dùng và Yêu cầu hệ thống
 Yêu cầu chức năng
 Yêu cầu phi chức năng
 Các phương pháp đặc tả yêu cầu
 Chuẩn tài liệu đặc tả yêu cầu IEEE 830-1984

8
 Yêu cầu người dùng và Yêu cầu hệ thống

 NÊN có sự phân biệt rõ ràng giữa các mức mô tả yêu

cầu.
 Theo Sommerville (2011):
• Yêu cầu người dùng (User Requirements -> UR) là yêu cầu
có mức trừu tượng cao.
• Yêu cầu hệ thống (System Requirements -> SR) là mô tả
chi tiết về thứ hệ thống phải làm.
• Một UR có thể được mở rộng thành một số SR chi tiết hơn.

9
 Định nghĩa UR và SR
 Yêu cầu người dùng là các tuyên bố bằng ngôn ngữ tự
nhiên hoặc các biểu đồ, mô tả những dịch vụ mà hệ thống
được mong đợi ​sẽ cung cấp cho người dùng và các ràng
buộc mà hệ thống phải tuân theo. (Ian Sommerville,
SOFTWARE ENGINEERING, (2011), trang 83)
 Yêu cầu hệ thống là những mô tả chi tiết về các chức
năng, các dịch vụ và các ràng buộc vận hành của hệ
thống phần mềm. (Ian Sommerville, SOFTWARE
ENGINEERING, (2011), trang 83)
• Tài liệu yêu cầu hệ thống (tài liệu đặc tả chức năng) cần phải
mô tả chính xác những gì sẽ được thực hiện. 10
 Ví dụ về UR và SR trong
hệ thống MHC-PMS
 Định nghĩa một UR: “Hệ thống sẽ tạo các báo cáo
quản lý hàng tháng để nắm được chi phí kê đơn thuốc
cho bệnh nhân của mỗi phòng khám hàng tháng”.
 Đặc tả các SR tương ứng:
• “Hệ thống sẽ tự động tạo các báo cáo sau 17:30 ngày làm
việc cuối cùng của tháng”.
• “Một báo cáo sẽ được tạo tự động cho mỗi phòng khám.
Nó sẽ thống kê thông tin chi tiết về từng loại thuốc được
kê đơn, tổng số đơn thuốc được kê, tổng chi phí của các
đơn thuốc được kê đơn”.
• “Quyền truy cập vào các báo cáo này sẽ bị hạn chế, chỉ
một số người dùng cụ thể được ủy quyền truy cập”.
Nguồn: Ian Sommerville, SOFTWARE ENGINEERING, (2011), trang 84. 11
 Ai đọc URs và SRs?

Nguồn: Ian Sommerville, SOFTWARE ENGINEERING, (2011), trang 85.

12
 NỘI DUNG

 Kỹ nghệ yêu cầu

 Các loại yêu cầu
 Yêu cầu người dùng và Yêu cầu hệ thống
 Yêu cầu chức năng
 Yêu cầu phi chức năng
 Các phương pháp đặc tả yêu cầu
 Chuẩn tài liệu đặc tả yêu cầu IEEE 830-1984

13
 Yêu cầu chức năng
 Các yêu cầu của một hệ thống phần mềm thường được
phân loại thành các yêu cầu chức năng và các yêu cầu
phi chức năng.
 Yêu cầu chức năng (functional requirements) là
những tuyên bố về các dịch vụ mà hệ thống phải cung
cấp, cách thức hệ thống phản ứng với các đầu vào cụ
thể và cách hệ thống hoạt động trong các tình huống cụ
thể. (Ian Sommerville, SOFTWARE ENGINEERING,
(2011), trang 84-85)
• Trong một số trường hợp, các yêu cầu chức năng cũng có
thể tuyên bố về những gì hệ thống KHÔNG cần phải làm.
14
 Mô tả các yêu cầu chức năng

 Phụ thuộc vào loại phần mềm đang được phát triển,
mong đợi của người dùng và loại hệ thống trong đó phần
mềm được sử dụng.
• Khi được thể hiện dưới dạng URs, các yêu cầu chức năng
thường được mô tả một cách trừu tượng (người dùng hệ
thống có thể hiểu được).
• Khi được thể hiện dưới dạng SRs, các yêu cầu chức năng
thường được mô tả một cách chi tiết.

15
 Ví dụ về các yêu cầu chức năng
trong hệ thống MHC-PMS

1. “Người dùng có thể tìm kiếm thông tin các cuộc hẹn
khám của bệnh nhân trong tất cả các phòng khám”.
2. “Hằng ngày, hệ thống sẽ tạo ra một danh sách các
bệnh nhân dự kiến đến khám cho từng phòng khám”.
3. “Mỗi nhân viên phòng khám sẽ được định danh duy
nhất bằng ID của nhân viên đó (gồm tám chữ số) khi
đăng nhập hệ thống”.
Nguồn: Ian Sommerville, SOFTWARE ENGINEERING, (2011), trang 86.

16
 Một số lưu ý

 Theo Sommerville (2011):

• Các vấn đề sẽ xuất hiện nếu các yêu cầu chức năng được
mô tả không chính xác.
• Các yêu cầu chức năng được mô tả không rõ ràng có thể
khiến nhà phát triển và khách hàng/người dùng hệ thống
hiểu theo những cách khác nhau.
• Về nguyên tắc, mô tả các yêu cầu chức năng phải đầy đủ
và có tính nhất quán.
 Trong thực tế, việc tạo ra một tài liệu yêu cầu chức năng
vừa đầy đủ vừa nhất quán là KHÔNG khả thi (rất khó).
17
 NỘI DUNG

 Kỹ nghệ yêu cầu

 Các loại yêu cầu
 Yêu cầu người dùng và Yêu cầu hệ thống
 Yêu cầu chức năng
 Yêu cầu phi chức năng
 Các phương pháp đặc tả yêu cầu
 Chuẩn tài liệu đặc tả yêu cầu IEEE 830-1984

18
 Yêu cầu phi chức năng

 Yêu cầu phi chức năng (non-functional requirements)

là những ràng buộc đối với các dịch vụ hoặc các chức
năng của hệ thống. (Ian Sommerville, SOFTWARE
ENGINEERING, (2011), trang 85)
• Các ràng buộc về thời gian, các ràng buộc về tiến trình phát
triển, các chuẩn, …
 Các yêu cầu phi chức năng thường áp dụng cho toàn bộ
hệ thống hơn là áp dụng cho các dịch vụ hoặc các đặc
tính hệ thống riêng lẻ.

19
 Yêu cầu phi chức năng (tt.)

 Các yêu cầu phi chức năng xác định các đặc tính và các
ràng buộc của hệ thống.
• Độ tin cậy, thời gian phản hồi, các yêu cầu về lưu trữ, giao
diện, phương pháp thiết kế, ngôn ngữ lập trình, …
 Yêu cầu ngoại lai: yêu cầu về chi phí, yêu cầu về thời
gian, yêu cầu về bản quyền, …
 Các yêu cầu phi chức năng có thể QUAN TRỌNG HƠN
các yêu cầu chức năng.
• Nếu các yêu cầu phi chức năng không được đáp ứng, hệ
thống được tạo ra có thể vô ích.
20
 Phân loại yêu cầu phi chức năng

Nguồn: Ian Sommerville, SOFTWARE ENGINEERING, (2011), trang 88. 21

 Ba phân loại chính

 Theo Sommerville (2011):

• Product Requirements là các yêu cầu xác định sản phẩm cần
bàn giao phải hoạt động theo một cách cụ thể (tốc độ thực thi, độ
tin cậy, ...).
• Organisational Requirements là các yêu cầu bắt nguồn từ các
chính sách và các thủ tục trong tổ chức của khách hàng và bên
phát triển hệ thống (yêu cầu về ngôn ngữ lập trình, yêu cầu về
môi trường phát triển, yêu cầu về các chuẩn được sử dụng, …).
• External Requirements là các yêu cầu phát sinh từ các yếu tố
bên ngoài hệ thống và quá trình phát triển hệ thống (các yêu cầu
về đạo đức, …).

22
 Ví dụ về các yêu cầu phi chức năng
trong hệ thống MHC-PMS

 Product Requirement: “Hệ thống khả dụng cho tất cả các

phòng khám trong khung giờ làm việc (8:30-17:30, T2->T6).
Trong đó, thời gian ngừng hoạt động không được vượt quá 5s”.
 Organisational Requirement: “Người dùng hệ thống (các nhân
viên phòng khám) sẽ xác thực bằng IC được cấp bởi phòng
khám của họ”.
 External Requirement: “Hệ thống MHC-PMS sẽ thực hiện các
điều khoản về quyền riêng tư của bệnh nhân theo quy định”.
Nguồn: Ian Sommerville, SOFTWARE ENGINEERING, (2011), trang 89.

23
 Phân biệt: Mục đích (Goals) và yêu cầu phi
chức năng

 Non-functional requirements may be very difficult to

state precisely and imprecise requirements may be
difficult to verify.
 Goal
• A general intention of the user such as ease of use.
 Verifiable non-functional requirement
• A statement using some measure that can be objectively
tested.
 Goals are helpful to developers as they convey the
intentions of the system users.
 Ví dụ: chuyển đổi Goals -> Usability
requirements:

 The system should be easy to use by medical

staff and should be organized in such a way
that user errors are minimized. (Goal)
 Medical staff shall be able to use all the system
functions after four hours of training. After this
training, the average number of errors made by
experienced users shall not exceed two per
hour of system use. (Testable non-functional
requirement)
 Các đo lường để xác định
các yêu cầu phi chức năng
Property Measure
Processed transactions/second
Speed User/event response time
Screen refresh time
Mbytes
Size Number of ROM chips
Training time
Ease of use Number of help frames
Mean time to failure
Probability of unavailability
Reliability Rate of failure occurrence
Availability
Time to restart after failure
Robustness Percentage of events causing failure
Probability of data corruption on failure
Percentage of target dependent statements
Portability Number of target systems

Nguồn: Ian Sommerville, SOFTWARE ENGINEERING, (2011), trang 90. 24

 Một số lưu ý

 Theo Sommerville (2011):

• Các yêu cầu phi chức năng có thể ảnh hưởng đến kiến trúc
tổng thể của hệ thống hơn là các thành phần riêng lẻ.
• Một yêu cầu phi chức năng có thể sinh ra một số yêu cầu
chức năng liên quan hạn chế các yêu cầu hiện có.
• Một số yêu cầu phi chức năng rất khó để mô tả một cách
chính xác.

25