intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE
 » 
 » 

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

Chia sẻ: Cao Tuấn | Ngày: | Loại File: PDF | Số trang:46

Thêm vào BST
Báo xấu
627
lượt xem 53
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

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

Chủ đề:

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

Lưu

Nội dung Text: 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

  1. 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
  2. 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
  3. 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
  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): (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
  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): (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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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 đ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 11
  12. 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 (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 ở đay 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. 12
  13. 1.4.3. 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 13
  14. 1.4.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 14
  15. 1.4.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 15
  16. 1.4.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 16
  17. 1.4.4. Quality Measures of the Modern SRS Package ) A Good Table of Contents A Good Index A Revision History: • The revision number or code for each change to the published information • The date of each revision to the published information • A short summary of the revisions made to the published information • The name of the person responsible for the changes to the published information A Glossary 17
  18. 1.4.5. Technical Methods for Specifying Requirements Technical methods for specifying requirements are appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood. Technical methods include pseudo-code, finite state machines, decision trees, activity diagrams, entity- relationship models, object-oriented analysis, and structured analysis We can choose from a variety of technical specification methods: Pseudo-code, Finite state machines, Decision trees, Activity diagrams (flowcharts), Entity relationship models, Object-oriented analysis, Structured analysis 18
  19. 1.4.5. Technical Methods for Specifying Requirements Technical methods for specifying requirements are appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood. Technical methods include pseudo-code, finite state machines, decision trees, activity diagrams, entity- relationship models, object-oriented analysis, and structured analysis We can choose from a variety of technical specification methods: Pseudo-code, Finite state machines, Decision trees, Activity diagrams (flowcharts), Entity relationship models, Object-oriented analysis, Structured analysis More detail about methods: see chapter 28 of [1] 19
  20. 1.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 Các nguyên tác chỉ đạo khi viết đặc tả: (1) Cố gắng viết các câu và đoạn văn ngắn gọn, không dài dòng (2) Sử dụng các thuật ngữ dễ hiểu, đã có trong glossary (3) Viết các câu văn trong sáng, đúng ngữ pháp (4) Tránh sử dụng những từ mang tính chất quảng cáo: giao diện thân thiện, hệ thống hoạt động hiệu quả, v.v một cách chung chung mà cần chỉ rõ như thế nào là thân thiện, như thế nào là hiệu quả (5) Tránh sử dụng những tính từ so sánh: tốt hơn tốt nhất mà nên chỉ ra rõ ràng các tiêu thức đánh giá trong đặc tả. 20
ADSENSE

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 © 2022-2032 TaiLieu.VN. All rights reserved.

 

Đồng bộ tài khoản
17=>2