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

Các vấn đề và khái niệm trong yêu cầu phần mềm Phát hiện các yêu cầu phần mềm (Software Elicitation) Phân tích yêu cầu phần mềm và xây dựng các đặc tính xác định chất lượng yêu cầu và các yêu cầu khác Đặc tả các yêu cầu phần mềm Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm Thẩm định xác minh các yêu cầu phần mềm (verification requirement) Quản lý thay đổi yêu cầu phần mềm .1.4. Đặc tả các yêu cầu phần mềm Không phụ thuộc các yêu cầu phần mềm được...
Nội dung trích xuất từ tài liệu:
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 THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM (SOFTWARE DESIGN AND CONSTRUCTION) Năm học 2008-2009 Giáo viên: PGS. Huỳnh Quyết Thắng BM Công nghệ phần mềm Khoa CNTT, ĐHBK HN 1 Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm 1. Các vấn đề và khái niệm trong yêu cầu phần mềm 2. Phát hiện các yêu cầu phần mềm (Software Elicitation) 3. Phân tích yêu cầu phần mềm và xây dựng các đặc tính xác định chất lượng yêu cầu và các yêu cầu khác 4. Đặc tả các yêu cầu phần mềm 5. Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm 6. Thẩm định xác minh các yêu cầu phần mềm (verification requirement) 7. Quản lý thay đổi yêu cầu phần mềm 2 1.4. Đặc tả các yêu cầu phần mềm 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. 3 1.4. Đặc tả các yêu cầu phần mềm Các điểm lưu ý khi đặc tả yêu cầu phần mềm (SRS): (1) 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ử đổi, quy định lại các biểu mẫu nếu như điều đó là cần thiết. (2) Xác đinh rõ nguồn gốc của yêu cầu phần mềm trong đặc tả: để có thể tất cả biết được tại sao lại phát sinh các yêu cầu phần mềm này, chúng ta nên chỉ rõ tại sao nó lại có- từ NSD, yêu cầu chức năng hệ thống, do quy chế, hay do các nguồn khác. 4 1.4. Đặc tả các yêu cầu phần mềm Các điểm lưu ý khi đặc tả yêu cầu phần mềm (SRS): (3) Đặt nhãn (label) cho từng yêu cầu phần mềm: chúng ta nên thống nhất quy ước cách đặt nhãn (tên) cho các yêu cầu - nên đặt nhãn làm sao nhãn của cá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ắc của công việc (business rule): các nguyên lý hoạt động của hệ thống, của các thao tác, công việc cần được miêu tả. 5 1.4. Đặc tả các yêu cầu phần mềm Các điểm lưu ý khi đặc tả yêu cầu phần mềm (SRS): (5) Nên tạo ra ma trận theo dõi các yêu cầu phần mềm (requirements traceability matrix): điều này rất có í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ểm thử các chức năng của hệ thống. Ma trận này cũng rất có ích giúp cho chúng ta liên kết các chức năng với các yêu cầu phần mềm liên quan. Nên sử dụng thường xuyên ma trận trong suốt thời gian phát triển phần mềm. 6 1.4.1. Ghi lại các nguyên tắc của công việc (Record business rule) Khi NSD miêu tả cho chúng ta một hoạt động nào đó chỉ được thực hiện trong những diều kiện nhấ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 Nguyên tăc công việc là tập hợp các các nguyên tăc hoạt động của quá trình thực hiện công việc Chúng ta có nghĩ vụ phải xây dụng các yêu cầu hệ thống về mặt chức năng để đáp ứng các nguyên tắc công việc này - tuy nhiên không nền đồng nhất yêu cầu chức năng với nguyên tắc công việc Trong SRS nên tập hợp và đặc tả tất cả các nguyên tắc của công việc vào một mục riêng. 7 1.4.2. Đặc tả các yêu cầu phần mềm theo mẫu Có thể nó đặc tả yêu cầu phần mềm (SRS) được coi như: đặc tả chức năng hệ thống, sự thoả thuận về chức năng, đặc tả hệ thống. SRS là cơ sở cho mọi hoạt động của dự án: phân tích, thiết kế, lập kế hoạch, viết mã, kiểm thử, v.v. Khi đặc tả yêu cầu phần mềm có thể sử dụng các công cụ: • Văn bản (textual document) • Mô hình đồ hoạ (graphical models) • Các ngôn ngữ đặc tả hình thức Các điểm lưu ý: • Tất cả các yêu cầu phần mềm phải được đua vào đặc tả. • SRS được xây dựng trước khi phân tích và xây dựng phần mềm 8 1.4.2. Đặc tả các yêu cầu phần mềm theo mẫu 1. Gán nhãn các yêu cầu phần mềm (labeling) Để có được một đặc tả tốt, có thể theo dõi mối liên quan giữa các yêu cầu, quá trình phát sinh ra chúng, v.v. chúng ta cần có một quy định gán nhã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án nhãn liên tiế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 được sủ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 9 1.4.2. Đặc tả các yêu cầu phần mềm theo mẫu 2. Đánh dấu những điểm chưa rõ trong đặc tả Đôi khi chúng ta thiếu một số các thông tin về các yêu cầu phần mềm, chúng ta cần thảo luận với NSD để biết chi tiết hơn, v.v. Tất cả những chỗ như vây nên được đánh dấu bằng “To be determined’ - TBD. Như vậy chúng ta đã phân định rõ những điểm thiếu (gaps) trong đặc tả để cần là sáng tỏ. Tất cả các TBD này phải được giải quyết trước khi bắt đầu quá trình phân tích và xây dựng phần mềm. 10 1.4.2. Đặc tả các yêu cầu phần mềm theo mẫu 3. Mối liên quan giữa đặc tả và giao diện người sử dụng Sự kết hợp giữa thiết kế giao diện trong SRS có cả ưu điểm và nhược điểm: Nhược đ ...