zunia.vn

Tuyển sinh 2024 dành cho Gen-Z

zunia.vn

» Công Nghệ Thông Tin

» Tin học văn phòng

Bài giảng Phân tích yêu cầu phần mềm: Chương 3 - PGS. TS.Huỳnh Quyết Thắng

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:16

Báo xấu

1
lượt xem 0
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng "Phân tích yêu cầu phần mềm" Chương 3 - Đặc tả các yêu cầu phần mềm, được biên soạn gồm các nội dung chính sau: Cấu trúc tài liệu đặc tả các yêu cầu phần mềm; Đặc tả hệ thống; Đặc tả các yêu cầu hệ thống; Đặc tả các yêu cầu phần mềm;...Mời các bạn cùng tham khảo!

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Phân tích yêu cầu phần mềm: Chương 3 - PGS. TS.Huỳnh Quyết Thắng

PHÂN TÍCH YÊU CẦU PHẦN MỀM Năm học 2013-2014 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 3. Đặc tả các yêu cầu phần mềm 1.Cấu trúc tài liệu đặc tả các yêu cầu phần mềm 2. Đặc tả hệ thống 3. Đặc tả các yêu cầu hệ thống 4. Đặc tả các yêu cầu phần mềm 2
Các mẫu đặc tả yêu cầu phần mềm (SRS template)  Mỗi tổ chức, công ty phần mềm đều cần xây dựng các SRS template của mình  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  Các SRS template là các tài liệu có cấu trúc tốt, mềm dẻo, có khả năng tuỳ biến được theo yêu cầu của mỗi công ty phần mềm 3
1.3.3. Các mẫu đặc tả yêu cầu phần mềm (SRS template) IEEE 830-1998 Adapted and Extended Template: 1. Introduction 1.1 Purpose of this document 1.2 Document Convention 1.3 Intended Audience and Reading Suggestion 1.4. Product Scope 1.5. References 2. Overall Description 2.1 Product perspective 2.2 Product Functions 2.3 User Characteristics 2.4 Operating Environment 2.5 Design and Implementation Constraints 2.6 Assumptions and Dependencies 4
1.3.3. Các mẫu đặc tả yêu cầu phần mềm (SRS template) IEEE 830-1998 Adapted and Extended Template (tiếp): 3. External Interface Requirement 3.1 User Interface 3.2 Hardware Interface 3.3 Software Interface 3.4. Communication Interface 4. System Features 4.x System Feature X 4.x.1 Description and Priority 4.x.2 Stimulus/Response Sequences 4.x.3 Functional Requirement 5
1.3.3. Các mẫu đặc tả yêu cầu phần mềm (SRS template) IEEE 830-1998 Adapted and Extended Template (tiếp): 5. Other Non-Functional Requirement 5.1. Performance Requirement 5.2. Safety Requirement 5.3. Security Requirement 5.4. Software Quality Attributes 5.5. Business Rules 5.6. User Documentation 6. Other Requirement Appendix A: Glossary Appendix B: Analysis Model Appendix C: To - Be - Determined List 6
Đặ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. 7
Đặ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. 8
Đặ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ả. 9
Đặ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. 10
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. 11
Đặ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 12
Đặ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 13
Đặ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. 14
Đặ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 điểm: • Các yêu cầu về giao diện thực chất chỉ là các giải pháp mà không phải là các yêu cầu phần mềm. • Quá trình xây dựng các yêu cầu sẽ kéo dài • NSD, khách hàng có thể tốn rất nhiều thời gian với giao diện mà quên đi nhiệm vụ chính của họ là giúp chúng ta xây dựng các yêu cầu phần mềm • Các giao diện xây dựng ở giai đoạn này chỉ mang tính chất định hướng 15
Đặ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 (tiếp) Uu điểm: • Có khả năng trau chuốt các yêu cầu phần mềm, xây dựng các tương tác trở nên hữu hìh và dễ hiểu hơn cho cả khách hàng và cả các PTV • Trợ giúp tốt hơn cho việc lập kế hoạch và đánh giá khối lượng công việc. Kết luận ở đây là nên sử dụng một số giao diện chuẩn hoặc các mô hình giao diệnở mức độ vừa phải để đưa vào đặc tả: mô hình chung của các giao diện nhập liệu, các giao diện - màn hình sử lý, giao diện - màn hinh hiển thị, các hộp thoại, v.v. 16

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN

TRỢ GIÚP

HỖ TRỢ KHÁCH HÀNG

Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright ©2025 TaiLieu.VN. All rights reserved.