I. Đặ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
ướccách đặt nhãn (tên) chocác yêu cầu - nên đặt nhãn làm sao nhãn
củacácyêu cầu mang càng nhiều các thông tin về các yêucầu đó càng tốt.
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 thaotác, công việccần đượcmiêutả.
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óíchtrong quá trình phân tích các yêu cầu, quá trình
thiếtkế, 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 taliên kếtcácchứcnăng vớicácyêucầuphầnmềmliên
quan. Nên sử dụng thường xuyên ma trận trongsuốt thời gian phát triển phần

(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ỏ.
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
[Type the document title]2
• 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
• Các giao diệnxâydựng ở giai đoạn này chỉ mang tính chấtđịnh
hướng
Ưu điểm:
• Có khả năng trau chuốtcácyêucầuphầnmềm, xây dựngcác tương
tác trở nên hữuhìnhvà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ốilượng công
việc.
Kếtluận ở đây là nên sử dụng mộtsố giao diệnchuẩnhoặc các mô hình giao
diệnở mức độ vừaphải để đưavào đặctả: mô hình chung của các giao
diệnnhậpliệu, các giao diện-mànhình xửlý, giao diện-mànhinhhiểnthị, các

• 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.
 Chúng ta lựa chọn từ một vài phương thức đặc tả kỹ thuật: mã giả, máy
trạng thái hữu hạn, cây quyế đị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
II. Chức năng EA hỗ trợ đặc tả yêu cầu phần mềm
1. Tạo các yêu cầu ngoài (External Requirements)
• Kích chuột trái Custom Button trong UML Toolbox để mở một bảng tùy chọn
• Kích và chọn thành phần Requirement từ tùy chọn trên biểu đồ
• EA cho phép bạn đặc tả một vài thuộc tính của yêu cầu
 Trường Short Description sẽ được hiện thị trên biểu đò
 Nhìn thấy các thuộc tính External Requirement ở dưới cho nhiều thông
tin hơn