Xây dựng tài liệu đặc tả yêu cầu phần mềm

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

ướ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
mềm
3. Ghi lại các nguyên tắc của công việc
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, donhữ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.
Nguyên tắc cô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.
Chúng ta có nghĩ vụ phải xây dựng các yêu cầuhệthống về mặtchứcnăng để
đáp ứng các nguyên tắccông việc này - tuy nhiên không nền đồng
nhấtyêucầuchứcnăng với nguyên tắc công việc.
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.
4. Đặc tả yêu cầu phần mềm theo mẫu
Có thể nó đặctả yêu cầuphầnmềm (SRS) được coi như: đặctả chứcnăng hệ
thống, sự thoả thuậnvề chứcnăng, đặctả hệ thống.
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.
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

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

• 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
hộpthoại, v.v.
5. Các mẫu đặc tả yêu cầu phần mềm
Một số phiên bản của SRS template được khuyến nghị nên sử dụng:
• Robertson and Robertson 1999
• IEEE 830-1998
5.1.Template SRS IEEE 830 -1998
IEEE 830-1998 Adapted and Extended Template:
• Introduction
 Purpose of this document
 Document Convention
 Intended Audience and Reading Suggestion
 Product Scope
 References
• Overall Description
 Product perspective
 Product Functions
 User Characteristics
 Operating Environment
 Design and Implementation Constraints
 Assumptions and Dependencies

[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.

 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
III. 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
[Type the document title]
4
• 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
• Kích nút ok để hoàn thành
• Một vài thuộc tính có thể được Edit
Hình 1 : Create Project
[Type the document title]
5
Hình 2: Chọn Model Requirements
[Type the document title]
6
Hình 3: Requirement Model
Thêm một Function Requirement là Manage Category
Function Requirements and
Non-Function Requirements
[Type the document title]
7
Hình 4: Create Manage Category
[Type the document title]
8

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