1
THI
THI
Ế
Ế
T K
T K
Ế
Ế
V
V
À
À
XÂY D
XÂY D
Ự
Ự
NG PH
NG PH
Ầ
Ầ
N M
N M
Ề
Ề
M
M
(SOFTWARE DESIGN AND CONSTRUCTION)
(SOFTWARE DESIGN AND CONSTRUCTION)
Năm
Năm

(1) Các định nghĩa, khái niệmvấn đề
(2) Các khó khăn trong xác định yêu cầuphần
mềm
(3) Các đặc tính củayêucầuphầnmềm
(4) Quá trình phát triểnvàquảnlýyêucầuphần
mềm
4
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z Yêu cầuphầnmềm là gì: [Dean Leffingwell, Don
Widrig
]
• The goal of software development is to develop quality
software—on time and on budget—that meets
customers real needs.
• Project success depends on good requirements
management.
• Requirements errors are the most common type of
systems development error and the most costly to fix.
• A few key skills can significantly reduce requirements
errors and thus improve software quality.
5
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z Yêu cầuphầnmềmlàgì:
• Trên thựctếđây một trong những vấn đề của công
nghiệpphầnmềm: thiếusựđịnh nghĩachínhxácvề
yêu cầuphầnmềm.
• Các yêu cầuxuất phát từ ngườisử dụng chương trình
đốivớingười phát triểnphầnmềm thông thường quá
là trừutượng, ở mứccao.
• Ngượclạinhững mô tả từ phía những người phát

• (3) Vănbảnthể hiệncácđiềukiệnhoặckhả năng
đãthể hiện ở (1) và (2).
9
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z Tính chấthaimặtcủayêucầuphầnmềm: cách nhìn
và suy nghĩ về phầnmềmtừ phía ngườisử dụng và
cách nhìn và suy nghĩ về phầnmềmtừ phía người
phát triển.
z Một trong những điềukiện quan trong nhất đãchỉ ra
trong định nghĩa này là tính đặctả của nó: phải được
đúc kếtlạibằng vănbản.
z Có sự tham gia và xác nhậncủacả hai phía: ngườisử
dụng và người phát triển
z Quá trình phát triểnvề cách hiểucủayêucầuphần
mềmsẽ cho thấy tính đầy đủ của định nghĩa thêo
IEEE.
z Tính chất hai mặtcủayêucầuphầnmềm: [Dean
Leffingwell, Fig2-1]
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
10
11
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z Các định nghĩakhácvề yêu cầuphầnmềm:
• Alan Davis (1993): các nhu cầucủangườisử dụng
(các đặctính, chứcnăng và đặc điểm) củahệ thống
cầnphảithể hiệntừ các quan sát bên ngoài vào hê
thống.
• Jones (1994): Các yêu cầu và phát biểucủangườisử
dụng khởisự quá trình phát triểnphầnmềm.
• Sommervile và Sawyer (1997): Yêu cầucủangườisử

miêu tả bằng các trường hợpsử dụng (user case)
hoặccáckịch bảnmiêutả (scenario description).
14
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z Các mức độ (level) của yêu cầu
• Mức độ 3: Yêu cầuchứcnăng (Functional
Requirement): định nghĩacácchứcnăng phầnmềm
mà người phát triểncầnphảixâydựng để có thểđáp
ứng đượctấtcả các nhiệmvụđãmiêutả trong yêu
cầungườisử dụng ở mứctrên.
• Các yêu cầuchứcnăng đượcvănbản hóa bằng một
tài liệu: Tài liệu đặctả yêu cầuphầnmềm (Software
Requirement Specification)
15
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z Các khái niệm khác trong yêu cầuphầnmềm
• Tài liệu đặctả yêu cầuphầnmềm (Software
Requirement Specification): tài liệu đặctả mô tảđầy
đủ các hoạt động, chứcnăng cầnphảicócủaphần
mềm. Đốivớicáchệ thống phầnmềmlơn đây được
coi là một thành phầncủahệ thống sẽ chuyểngiao
cho khách hàng
• Các yêu cầu khác: (nonfunctional requirement): thông
thường chứacácchuẩn, các điềuchỉnh, các điềukiện
mà phầnmềmcầnphảicó
16
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z Các khái niệm khác trong yêu cầuphần
mềm
• Các ràng buộc: (constraint): các quy định chặtchẽ

phá sinh điquáphạmvi vàgiớihạncủaphần
mềm.
• Cầnquản lý các thay đổivề yêu cầuphầnmềm
mộtcáchhợplývàxemxétảnh hương củanóitới
kiếntrúchệ thống, trong quá trình phát triển
19
1.1.1. Các khó khăncóthể xảy ra trong xây dựng yêu cầu
phầnmềm
z (3) Các yêu cầuphầnmềmmơ hồ nhậpnhằng:
• Đây là mộtvấn đề rất hay xảyratrogquátrìnhpháttriển
các yêu cầuphầnmềm
• Các yêu cầuphầnmềmcầnphải rõ ràng, không được
phép hiểu theo nhiềucách
• Phương pháp sửacácyêucầumơ hồ nhậpnhằng là
làm lại, đặctả lạicácyêucầu này.
• Theo đánh giá của các nhà phân tích: làm lạiyêucầu
phầnmềmthường chiếmkhaỏng 40% quá trình xây
dựng nó và 70, 80% các đặc tính xây dựng lạicóthể
dẫn đếncáclỗi
• Lưuý tớitừng yêu cầuphầnmềm và không để sót
những yêu cầumơ hồ, không rõ ràng
20
1.1.1. Các khó khăncóthể xảy ra trong xây dựng yêu cầu
phầnmềm
z (4) Các đặc tính thừa:
• Thông thường người phá triển theo các thói quen
nghề nghiệp thêm vào các yêu cầuphầnmềm
các chứcnăng không cầnthiếtchophầnmềm
• Tương tự như thế ngườisử dụng có thểđưara
mộtsố yêu cầuphụ cho phầnmềm. Các yêu cầu

mềm
• Nên trả lời cho khách hàng các câu trả lờidạng
“gần chính xác”: trong trường hợpxấunhất ,
nếu thì.
23
1.1. 2. Các đặc điểmcủamộtyêucầuphầnmềmtốt
z Các đặc điểmcủatừng yêu cầuphầnmềm:
• (1) Hoàn thiện(complete)
• (2) Chính xác (correct)
• (3) Khả thi (feasible)
• (4) Cầnthiết (necessary)
• (5) Đượcsắpxếptheothứ tựưutiêncácyêu
cầu.
• (6) Rõ ràng
• (7) Kiểmtrađược, xác minh được
24
1.1. 2. Các đặc điểmcủamộtyêucầuphầnmềmtốt
z Các đặc điểmcủatàiliệu đặctả yêu cầu
phầnmềm:
• (1) Hoàn thiện(complete)
• (2) Phù hợp (consistent)
• (3) Sửa đổi được (modifiable)
• (4) Theo dõi được (traceable)
25
1.1. 2. Các đặc điểmcủamộtyêucầuphầnmềmtốt
z Các kỹ năng cầnthiết để thựchiệnxâydựng các
yêu cầuphầnmềm
[Dean Leffingwell]
• (1) Analyzing the Problem
• (2) Understanding User Needs