Phần 3 Xây dựng tài liệu đặc tả yêu cầu phần mềm
I. Giới thiệu chung
1. Mục đích
Mục đích của phần báo cáo này nói rõ cách đặc tả yêu cầu phần mềm
2. Tài liệu tham khảo
• Requirements Management in Enterprise Architect
• Slide môn Xây Dựng và Thiết Kế Phần Mềm Của thầy Huỳnh
Quyết Thắng
• Managing Software Requirement
II. Đặc tả các yêu cầu phần mềm
1. Giới thiệu
Không phụ thuộc các yêu cầu phần mềm được tìm ra , được xây dựng như thế
nào, cuối cùng bao giờ chúng ta cũng phải đặc tả các yêu cầu này.
Các tiêu thức để đánh giá một đặc tả:
• Tính nhất quán
• Tính thân thiện
• Dễ sử dụng
Trong đặc tả phải nêu được cả Business Requirement, phạm vi ứng dụng, giới
hạn của ứng dụng.
Trong đặc tả 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ợp sử dụng của từng yêu cầu.
2. Các điểm lưu ý khi đặc tả yêu cầu phần mềm
Làm theo và sử dụng các mẫu đặc tả : nên quy định một mẫu đặc tả chung
trong tổ chức của chúng ta, sử dụng một số mẫu (template) nào đó: IEEE 830
– 1998. Lưu ý rằng hoàn toàn có quyền sửa đổi , quy định lại các biểu mẫu
nếu như điều đó là cần thiết.
Xác đinh rõ nguồngốccủayêucầuphầnmềm trongđặc tả: để có thể tấtcả biết
đượctạisaolại phát sinhcác yêu cầuphầnmềm này, chúng ta nên chỉ rõ
tạisaonólạicó-từ NSD, yêu cầuchứcnăng hệ thống, do quy chế, hay do các
nguồn khác.
Đặt nhãn (label) cho từng yêu cầuphầnmềm: chúng ta nên thống nhất quy

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
4.1.Gán nhãn các yêu cầu phần mềm
Để 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 rachúng, v.v. chúng ta cầncómột quy định gánnhãn các yêu
cầu một cách khoa học. Có một số 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ộngrãi nhất)
• Gán nhãn theo tên thẻ thứ bậc (Hierarchical texttual
tags):Print.Copies.Confirm
4.2.Đánh dấu những điểm chưa rõ ràng trong đặc tả
Đô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ớiNSD để 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ỏ.
[Type the document title]
2
Tấtcả các TBD này phải được giải quyếttrướckhi bắt đầu quá trình phân tích
và xây dựng phầnmềm.
4.3.Mỗi liên quan giữa đặc tả và giao diện ngườ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ệnmà quên
đi nhiệmvụ chính củahọ là giúp chúng ta xâydựng các yêu
cầuphầnmềm

[Type the document title]
3
• External Interface Requirement
 User Interface
 Hardware Interface
 Software Interface
 Communication Interface
• System Features
 System Feature X
• Description and Priority
• Stimulus/Response Sequences
• Functional Requirement
• Other Non-Functional Requirement
 Performance Requirement
 Safety Requirement
 Security Requirement
 Software Quality Attributes
 Business Rules
 User Documentation
• Other Requirement
Appendix A: Glossary
Appendix B: Analysis Model
Appendix C: To - Be - Determined List
6. Phương thức kỹ thuật cho đặc tả yêu cầu
 Phương thức kỹ thuật cho đặc tả các yêu cầu là thích hợp khi mô tả các
yêu cầu là không quá phức tạp với ngôn ngữ tự nhiên hoặc nếu bạn
không có đủ khả năng có đặc tả dễ hiểu.
 Phương thức kỹ thuật bao gồm mã giả, máy trạng thái hữu hạn, cây quyết
định, biểu đồ hoạt động, mô hình thực thể liên kết, phân tích hướng đối
tượng và phân tích cấu trúc.

Hình 5: Thêm yêu cầu “Thêm Thể Loại”
Hoặc có thể tạo trong Package
 Tạo Package
[Type the document title]
9
 Chọn Add -> New Requirement
[Type the document title]
10