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

tìm ra, đượcxâydựng như thế nào, cuối cùng
bao giờ chúng ta cũng phải đặctả các yêu cầu
này.
z Các tiêu thức để đánh giá một đặctả: tính nhất
quán, tính thân thiện, dễ sử dụng
z Trong đặctả phải nêu đượccả business
requirement, phạmvi ứng dụng, giớihạncủa
ứng dụng
z Trong đặctả phải nêu được đầy đủ các user
requirement, sử dụng các mẫu (template) của
các trường hợpsử dụng củatừng yêu cầu.
4
1.4. Đặctả các yêu cầuphầnmềm
Các điểmlưuý khiđặctả yêu cầuphầnmềm (SRS):
(1) Làm theo và sử dụng các mẫu đặctả: nên quy định
mộtmẫu đặctả chung trong tổ chứccủa chúng ta,
sử dụng mộtsố mẫu (template) nào đó: IEEE 830 -
1998. Lưuý rằng hoàn toàn có quyềnsửđổi, quy
định lạicácbiểumẫunếunhưđiều đólàcầnthiết.
(2) Xác đinh rõ nguồngốccủayêucầuphầnmềm trong
đặctả: để có thể tấtcả biết đượctạisaolại phát sinh
các yêu cầuphầnmềm này, chúng ta nên chỉ rõ tại
saonólạicó-từ NSD, yêu cầuchứcnăng hệ thống,
do quy chế, hay do các nguồn khác.
5
1.4. Đặctả các yêu cầuphầnmềm
Các điểmlưuý khiđặctả yêu cầuphầnmềm (SRS):
(3) Đặt nhãn (label) cho từng yêu cầuphầnmềm: chúng
ta nên thống nhất quy ướccáchđặt nhãn (tên) cho
các yêu cầu - nên đặt nhãn làm sao nhãn củacác

của công việcvàomộtmục riêng.
8
1.4.2. Đặctả các yêu cầuphầnmềmtheomẫu
z Có thể nó đặctả yêu cầuphầnmềm (SRS) được
coi như: đặctả chứcnăng hệ thống, sự thoả thuận
về chứcnăng, đặctả hệ thống.
z SRS là cơ sở cho mọihoạt động củadự án: phân
tích, thiếtkế, lậpkế hoạch, viếtmã, kiểmthử, v.v.
z Khi đặctả yêu cầuphầnmềmcóthể sử dụng các
công cụ:
• Vănbản (textual document)
• Mô hình đồ hoạ (graphical models)
• Các ngôn ngữđặctả hình thức
z Các điểmlưuý:
• Tấtcả các yêu cầuphầnmềmphải được đua vào đặctả.
• SRS đượcxâydựng trước khi phân tích và xây dựng
phầnmềm
9
1.4.2. Đặctả các yêu cầuphầnmềmtheomẫu
1. Gán nhãn các yêu cầuphầnmềm (labeling)
Để có đượcmột đặctả tốt, có thể theo dõi mối liên
quan giữacácyêucầu, quá trình phát sinh ra
chúng, v.v. chúng ta cầncómột quy định gán
nhãn các yêu cầumột cách khoa học. Có mộtsố
phương pháp thông dụng:
• Gánnhãnliêntiếp (sequence number): UR - xxxx
• Gán nhãn theo thứ bậc (Hierarchical numbering):
UR 3.2.1 (phương pháp này đượcsủdụng rộng
rãi nhất)
• Gán nhãn theo tên thẻ thứ bậc (Hierarchical

1.4.2. Đặctả các yêu cầuphầnmềmtheomẫu
3. Mối liên quan giữa đặctả và giao diệnngười
sử dụng (tiếp)
Uu điểm:
• Có khả năng trau chuốtcácyêucầuphầnmềm, xây dựng
các tương tác trở nên hữuhìhvàdễ hiểuhơnchocả
khách hàng và cả các PTV
• Trợ giúp tốthơnchoviệclậpkế hoạch và đánh giá khối
lượng công việc.
Kếtluận ởđay là nên sử dụng mộtsố giao diện
chuẩnhoặc các mô hình giao diệnở mức độ vừa
phải để đưavàođặctả: mô hình chung củacác
giao diệnnhậpliệu, các giao diện-mànhìnhsử
lý, giao diện-mànhinhhiểnthị, các hộpthoại, v.v.
13
1.4.3. Các mẫu đặctả yêu cầuphầnmềm (SRS template)
z Mỗitổ chức, công ty phầnmềm đềucầnxâydựng
các SRS template củamình
z Mộtsố phiên bảncủa SRS template được khuyến
nghị nên sử dụng:
• Robertson and Robertson 1999
• IEEE 830-1998
z Các SRS template là các tài liệucócấutrúctốt,
mềmdẻo, có khả năng tuỳ biến được theo yêu
cầucủamỗi công ty phầnmềm
14
1.4.3. Các mẫu đặctả yêu cầuphầnmềm (SRS template)
IEEE 830-1998 Adapted and Extended Template:
1. Introduction
1.1 Purpose of this document

5.1. Performance Requirement
5.2. Safety Requirement
5.3. Security Requirement
5.4. Software Quality Attributes
5.5. Business Rules
5.6. User Documentation
6. Other Requirement
Appendix A: Glossary
Appendix B: Analysis Model
Appendix C: To - Be - Determined List
17
1.4.4. Quality Measures of the Modern SRS Package )
z A Good Table of Contents
z A Good Index
z A Revision History:
• The revision number or code for each change to the
published information
• The date of each revision to the published information
• A short summary of the revisions made to the published
information
• The name of the person responsible for the changes to
the published information
z A Glossary
18
1.4.5. Technical Methods for Specifying Requirements
z Technical methods for specifying requirements are
appropriate when the requirement description is too
complex for natural language or if you cannot afford to
have the specification misunderstood.
z Technical methods include pseudo-code, finite state

thân thiện, hệ thống hoạt động hiệuquả, v.v một cách chung
chung mà cầnchỉ rõ như thế nàolàthânthiện, như thế nào
là hiệuquả
(5) Tránh sử dụng những tính từ so sánh: tốthơntốtnhấtmànên
chỉ ra rõ ràng các tiêu thức đánh giá trong đặctả.
21
1.5. Xác định nguồngốcyêucầuvàma trận theo dõi các
yêu cầuphầnmềm
Tracing Requirement:
z Theo dõi dấuvếtcủamộtyêucầuphầnmềmcho
phép chúng ta quảnlýđược các yêu cầuphầnmềm
này, nguồngốccủa nó, các mối liên quan củanóvà
cách thựchiện, kiểmthử, bảodưỡng và phát triển nó.
z Tồntại 04 thao tác với quá trình theo dõi dấuvếtcủa
mộtyêucầuphầnmềm
• Forward to Requirement
• Backward from Requirement
• Forward from Requirement
• Backward to Requirement
22
1.5. Xác định nguồngốcyêucầuvàma trận theo dõi các
yêu cầuphầnmềm
Tracing Requirement:
Customer
Needs
Requirement
Downstream
work
Backward
from

z Tính chứng nhận (certification): xác thựctấtcả cácchức
năng đã đượcthựchiện
z Khả năng phân tích phầnmềmtốthơn (change impact
analyis)
z Khả năng bảodưỡng phầnmềmtốthơn (maintenance)
z Khả năng theo dõi quản lý, hiệuchỉnh dự án tốthơn
(project tracking)
z Khả năng phát triểnhệ thống: Reengineering
25
1.5. Xác định nguồngốcyêucầuvàma trận theo dõi các
yêu cầuphầnmềm
Tại sao cần Tracing Requirement (tiếp):
z Khả năng tái sử dụng (reuse)
z Khả năng giảmrủi ro (Risk Reduce)
z Khả năng kiểmthử (testing)