THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM- Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm doc

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

h
h
ọ
ọ
c
c
2007
2007
-
-
2008
2008
Giáo viên: TS.Huỳnh QuyếtThắng
BM Công nghệ phầnmềm
Khoa CNTT, ĐHBK HN
2
Chương 1. Tổng hợpvàphântíchcácyêucầuphầnmềm
1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
2. Phát hiệncácyêucầuphầnmềm (Software Elicitation)
3. Xây dựng các đặc tính xác định chấtlượng yêu cầuvàcác
yêu cầu khác
4. Đặctả các yêu cầuphầnmềm
5. Xác định nguồngốcyêucầuvàma trận theo dõi các yêu
cầuphầnmềm
6. Thẩm định xác minh các yêu cầuphầnmềm (verification
requirement)
3
Chương 1. Tổng hợpvàphântíchcácyêucầuphầnmềm
1. 1. Các vấn đề và khái niệm trong yêu cầuphần
mề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

triển đốivớingườisử dụng lại ở mức quá thấp, quá
chi tiếtvàngườisử dụng lại không hiểuhết được.
6
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]
• A study by The Standish Group (1994) reported:
• In the United States, we spend more than $250 billion each
year on IT application development of approximately
175,000 projects. The average cost of a development
project for a large company is $2,322,000; for a medium
company, it is $1,331,000, and for a small company, it is
$434,000….
• The Standish Group research shows a staggering 31% of
projects will be canceled before they ever get completed.
Further results indicate 52.7% of projects will cost 189% of
their original estimates….
z Yêu cầuphầnmềm là gì: [Dean Leffingwell, Fig1-1]
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
7
8
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z IEEE 1997 định nghĩayêucầuphầnmềm:
• (1) Điềukiệnhay khả năng cầnthiết để ngườisử
dụng giảiquyết đượcvấn đề hoặcmụctiêuhay đôí
tượng củahọ
• (2) Điềukiệnhay khả năng đượchiểulàđáp ứng
củahệ thống hay thành phầnhệ thống thoả mãn
hợp đồng, tiêu chuẩn, đặctả hoặccácvănbảnbắt
buộckhác.

• (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ử

dụng là các đặctả mô tả cầnphải làm cái gì. Các đặc
tả này giải thích các thuộc tính các đặctrưng củahệ
thống và các hoạt động chứcnăng củahệ thống.
12
Y/c công
việc
Các yêu cầu khác
Các đặctrưng
Yêu cầu
hệ thống
Y/C
chức
năng
Các ràng buộc
Y/cNSD
Tài liệuvề khả năng, phạmvivàgiớihạncủaphầnmềm
Tài liềuvề cácusecasehoặc
kịch bản miêu tả
Tài liệu đặctả yêu cầuphầnmềm
(Software Requirement Specification)
13
1.1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
z Các mức độ (level) củayêucầu [Wiegers K. E]
• Mức độ 1: Yêu cầu công việc (Business
Requirement): thể hiệncácmụctiêuyêucầu ở mức
cao củatổ chức hay khách hàng về khả năng, phạm
vi ứng dụng và giớihạncủaphầnmềm
• Mức độ 2: Yêu cầungườisử dụng (user requirement):
thể hiện các nhiệmvụ cụ thể mà NSD cầnphải hoàn
thành, làm đượcvớiphầnmềm. Thông thường được

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ẽ

mà các phân tích viên và phát triểnhệ thống cần
phải tuân thủ và giữ vững trong quá trình phá triển
phầnmềm
• Các đặctínhchấtlượng (quality attributes): các đặc
điểmxácđịnh tính chấtvàchấtlượng củaphần
mềm. Lưuý cần nên rõ phương pháp đovàcósự
thông nhấtgiữa NSD và các PTV về các đặc tính
chấtlượng này
17
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 (1) Sự tham gia quá mứccủaNSD:
• Thông thường ngườisử dụng không hiểurõvề
quá trình xây dựng các yêu cầuphầnmềmvà
các đặc điểmcủaphầnmềm.
• Họ sẽđưanhững đòi hỏi quá cao hoặcchẳng
liên quan đến quá trình phát triểnphầnmềm
như viết code,
• Họđưaranhững yêu cầuvàđề nghị rấtkhó
chấpnhận và gây khó khăn cho các PTV
18
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 (2) Có quá nhiềuyêucầutrongyêucầuphầnmềm:
• Thông thường các yêu cầuphầnmềm được phát
hiện trong quá trình khảosátvàrấtcóthể các yêu
cầuvề phầnmềmsẽ lớnhơnkhả năng của đội
ngũ phá triểnphầnmềmvề: nhân lực, thời gian,
tài chính.
• Cầnhạnchế không để các yêu cầuphầnmềm

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

này có thểđòi hỏicáctốnkémvề mặtxâydựng
mà trên thựctế hoàn toàn không cầnthiết.
• Cần đánh giá các đặc tính và tính cầnthiếtcủa
nó đốivới các phầnmềm. Những đặctínhphụ có
thể xem xét kỹ hơnxemkhả năng đáp ứng nó về
mặtkỹ thuậtcóđáng giá hay không
21
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 (5) Đặctả quá ít:
• NSD là chuyên viên trong mộtlĩnh vựcnàođócó
thói quen nghĩ rằng tấtcả các PTV đềulàcác
chuyên viên trong lĩnh vực đó.
• NSD đưaranhững yêu cầu quá ngắngọnmà
không miêu tả kỹ lưỡng hơn chúng là gì
• Cầnhỏi rõ NSD và tranh thủ các kiếnthứccủahọ
z (6) Không lưuý tớinhững ngườisẽ sử dụng phần
mềm:
• Thông thường phầnmềmlàmrachomộttậphợp
các đốitượng nào đósử dụng
• Cần quan tâm tới đặc điểmcủacácđốitượng này
22
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 (7) Kế hoạch sai
• Các PTV đánh giá sai về mức độ phứctạpcủa
vấn đề và dẫntớilậpkế hoạch sai về thờigian
hoàn thành
• Cầnlưuý đánh giá thậtchắcchắncácđặc tính
củaphầnmềmkhilậpkế hoạch xây dựng phần

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

• (3) Defining the System
• (4) Managing Scope
• (5) Refining the System Definition
• (6) Building the Right System