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 ppt

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
2008
2008
-
-
2009
2009
Giáo viên: PGS. Huỳnh QuyếtThắng
BM Công nghệ phầnmềm
Khoa CNTT, ĐHBK HN
22
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. Phân tích yêu cầuphầnmềm và xây dựng các đặc tính xác
định chấtlượng yêu cầu và các yêu cầukhá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)
7. Quảnlýthayđổiyêucầuphầnmềm
3
1.4. Đặctả các yêu cầuphầnmềm
z Không phụ thuộccácyêucầuphầnmềm được

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

yêu cầu mang càng nhiều các thông tin về các yêu
cầu đó càng tốt.
(4) Ghi lại các nguyên tắccủa công việc (business rule):
các nguyên lý hoạt động củahệ thống, của các thao
tác, công việccần đượcmiêutả.
6
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):
(5) Nên tạorama trận theo dõi các yêu cầuphầnmềm
(requirements traceability matrix): điều này rấtcóích
trong quá trình phân tích các yêu cầu, quá trình thiết
kế, lập trình và kiểmthử các chứcnăng củahệ
thống. Ma trậnnàycũng rất có ích giúp cho chúng ta
liên kếtcácchứcnăng vớicácyêucầuphầnmềm
liên quan. Nên sử dụng thường xuyên ma trận trong
suốtthời gian phát triểnphầnmềm.
7
1.4.1. Ghi lại các nguyên tắccủa công việc (Record business
rule)
z Khi NSD miêu tả cho chúng ta mộthoạt động nào đó
chỉđượcthựchiện trong những diềukiệnnhất định, do
những tác nhân nhất định, v.v. tức là chúng ta đãcó
một nguyên tắc công việc
z Nguyên tăccôngviệclàtậphợp các các nguyên tăc
hoạt động của quá trình thựchiện công việc
z Chúng ta có nghĩ vụ phảixâydụng các yêu cầuhệ
thống về mặtchứcnăng để đáp ứng các nguyên tắc
công việc này - tuy nhiên không nền đồng nhấtyêucầu
chứcnăng với nguyên tắc công việc
z Trong SRS nên tậphợpvàđặctả tấtcả các nguyên tắ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

texttual tags):Print.Copies.Confirm
10
1.4.2. Đặctả các yêu cầuphầnmềmtheomẫu
2. Đánh dấunhững điểmchưa rõ trong đặctả
Đôi khi chúng ta thiếumộtsố các thông tin về các
yêu cầuphầnmềm, chúng ta cầnthảoluậnvới
NSD để biếtchi tiếthơn, v.v. Tấtcả những chỗ
như vây nên được đánh dấubằng “To be
determined’ - TBD. Như vậy chúng ta đã phân
định rõ những điểmthiếu (gaps) trong đặctảđể
cầnlàsángtỏ.
Tấtcả các TBD này phải đượcgiải quyếttrước
khi bắt đầu quá trình phân tích và xây dựng phần
mềm.
11
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
Sự kếthợpgiữathiếtkế giao diện trong SRS có cả
ưu điểmvànhược điểm:
Nhược điểm:
• Các yêu cầuvề giao diệnthựcchấtchỉ là các giải pháp mà
không phảilàcácyêucầuphầnmềm.
• Quá trình xây dựng các yêu cầusẽ kéo dài
• NSD, khách hàng có thể tốnrất nhiềuthờigianvớigiaodiện
mà quên đi nhiệmvụ chính củahọ là giúp chúng ta xây
dựng các yêu cầuphầnmềm
• Các giao diệnxâydựng ở giai đoạn này chỉ mang tính chất
định hướng
12

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

1.2 Document Convention
1.3 Intended Audience and Reading Suggestion
1.4. Product Scope
1.5. References
2. Overall Description
2.1 Product perspective
2.2 Product Functions
2.3 User Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 Assumptions and Dependencies
15
1.4.3. Các mẫu đặctả yêu cầuphầnmềm (SRS template)
IEEE 830-1998 Adapted and Extended Template
(tiếp):
3. External Interface Requirement
3.1 User Interface
3.2 Hardware Interface
3.3 Software Interface
3.4. Communication Interface
4. System Features
4.x System Feature X
4.x.1 Description and Priority
4.x.2 Stimulus/Response Sequences
4.x.3 Functional Requirement
16
1.4.3. Các mẫu đặctả yêu cầuphầnmềm (SRS template)
IEEE 830-1998 Adapted and Extended Template
(tiếp):
5. Other Non-Functional Requirement

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

machines, decision trees, activity diagrams, entity-
relationship models, object-oriented analysis, and structured
analysis
z We can choose from a variety of technical specification
methods: Pseudo-code, Finite state machines, Decision
trees, Activity diagrams (flowcharts), Entity relationship
models, Object-oriented analysis, Structured analysis
19
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
machines, decision trees, activity diagrams, entity-
relationship models, object-oriented analysis, and structured
analysis
z We can choose from a variety of technical specification
methods: Pseudo-code, Finite state machines, Decision
trees, Activity diagrams (flowcharts), Entity relationship
models, Object-oriented analysis, Structured analysis
z More detail about methods: see chapter 28 of [1]
20
1.5. Xác định nguồngốcyêucầuvàma trận theo dõi các
yêu cầuphầnmềm
Các nguyên tác chỉđạo khi viết đặctả:
(1) Cố gắng viết các câu và đoạnvănngắngọn, không dài dòng
(2) Sử dụng các thuậtngữ dễ hiểu, đã có trong glossary
(3) Viết các câu văn trong sáng, đúng ngữ pháp
(4) Tránh sử dụng những từ mang tính chấtquảng cáo: giao diện

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

Requirement
Forward
to
Requirement
Backward
to
Requirement
Forward
from
Requirement
23
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:
Business
Requirement
System
Requirement
Use cases
Business Rule
External
Interface
Requirement
Software
Functional
Requirement
24
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:

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)