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 [...]... title] • Thuộc tính của yêu cầu ngoài 14 [Type the document title] Hình 7: Một số thuộc tích của Yêu cầu 15 [Type the document title] thiết lập trang thái của yêu cầu 2 Tạo các yêu cầu bên trong từ một thành phần khác (Internal Requirement) Ta có thể tạo ra các yêu cầu phần mềm bên trong 1 Element khác như Usecase, Class,… để chỉ ra rằng Element đó có nhiệm vụ cài đặt các yêu cầu đã nêu Để thực hiện... chọn package để lưu External Requirement 17 [Type the document title] 4 Quản lý các thuộc tính cơ bản của yêu cầu Các thuộc tính cơ bản của yêu cầu được quản lý trong EA: • Tên • Trạng thái thực hiện (đề xuất, đã phê chuẩn, đang cài đặt, bắt buộc, đã kiểm tra) • Độ khó • Độ ưu tiên • Loại yêu cầu ( Chức năng, hiển thị, báo cáo, kiểm thử , …) • Ghi chú • Các thông tin khác 18 [Type the document title]... Key – Value lưu trữ các thông tin bổ sung cho yêu cầu ) 19 [Type the document title] Hình 8: thêm các thuộc tính ngoài Hình 9: Thêm Tagged Value 20 [Type the document title] 21 [Type the document title] 6 Xóa , Sắp xếp các yêu cầu Thực hiện trong cửa sổ Project Browser, thông qua các button trên toolbox hoặc menu ngữ cảnh 7 Tạo cấu trúc phân cấp cho yêu cầu Khi muốn chuyển 1 Requirement thành con của... trúc phân cấp cho yêu cầu Khi muốn chuyển 1 Requirement thành con của 1 Requirement khác, trong cửa sổ Project Browser, ta rê rồi thả Requirement-con vào Requirement-cha.Với chức năng này, ta có thể xây dựng được cấu trúc phân cấp cho Requirement: 1 requirement lớn có thể bao gồm nhiều Reqiurement nhỏ hơn 22 [Type the document title] 8 Đánh số cho các Requirement Nháy phải vào package, chọn Show Level... Documentation • Lựa chọn loại báo cáo phù hợp ( Rich Text Format, HTML,…) • Trong hộp thoại mở ra, nhập các thông số cần thiết Chú ý chọn Use template là requirement template 26 [Type the document title] Phần 4: Các thuật ngữ và các chữ viết tắt 27 [Type the document title] STT 1 2 3 4 5 6 Tên Viết Tắt SRS NSD IEEE HTML EA GUI Ý Nghĩa Software Requirement Specification Người Sử Dụng Institute of Electrical . 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. 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ả