Tổng Hợp Và Phân Tích Các Yêu Cầu Phần Mềm - TaiLieu.VN

Trang chủ » Thiết Kế Và Xây Dựng Phần Mềm Là Gì » Tổng Hợp Và Phân Tích Các Yêu Cầu Phần Mềm - TaiLieu.VN

Có thể bạn quan tâm

OPTADS360 intTypePromotion=1 zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn tailieu.vn NÂNG CẤP Đăng Nhập | Đăng Ký Chủ đề »
  • Ngôn ngữ lập trình
  • Lập trình hướng đối tượng
  • Lập trình Android
  • Lập trình Java
  • Lập trình IOS
  • HOT
    • FORM.08: Bộ 130+ Biểu Mẫu Thống Kê...
    • FORM.04: Bộ 240+ Biểu Mẫu Chứng Từ Kế...
    • CEO.24: Bộ 240+ Tài Liệu Quản Trị Rủi...
    • TL.01: Bộ Tiểu Luận Triết Học
    • LV.26: Bộ 320 Luận Văn Thạc Sĩ Y...
    • CMO.03: Bộ Tài Liệu Hệ Thống Quản Trị...
    • CEO.27: Bộ Tài Liệu Dành Cho StartUp...
    • FORM.07: Bộ 125+ Biểu Mẫu Báo Cáo...
    • LV.11: Bộ Luận Văn Tốt Nghiệp Chuyên...
    CEO.29: Bộ Tài Liệu Hệ Thống Quản Trị Doanh...
TUYỂN SINH YOMEDIA ADSENSE Trang Chủ » Công Nghệ Thông Tin » Kỹ thuật lập trình 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...

AMBIENT/ Chủ đề:
  • phân tích phần mềm
  • thiết kế phần mềm
  • xây dựng phần mềm
  • phương pháp đánh giá
  • dự án phần mềm
  • phần mềm máy tính

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

Đă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

  • Hướng Dẫn Thực Hành Winform - phần 7 Thiết kế và xây dựng phần mềm theo mô hình 3 tầng xử lý

    pdf 8 p | 327 | 151

  • Hướng Dẫn Thực Hành Winform - phần 6 Thiết kế và xây dựng phần mềm theo mô hình 2 tầng xử lý

    pdf 8 p | 389 | 140

  • THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM - Chương 2 Thiết kế phần mềm

    pdf 57 p | 425 | 80

  • Web development Izwebz - Thiết kế web theo chuẩn: Phần 1 - Võ Minh Mẫn

    pdf 125 p | 253 | 63

  • THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM- Chương 3: Xây dựng phần mềm

    pdf 71 p | 151 | 27

  • THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM-Chương 0: Cơ sở của thiết kế và xây dựng phần mềm

    pdf 37 p | 115 | 23

  • Bài giảng Thiết kế và xây dựng mạng Lan và Wan: Chương 2 - ThS. Trần Bá Nhiệm

    pdf 99 p | 121 | 17

  • Vai trò của phân tích, thiết kế hệ thống thông tin trong quy trình xây dựng phần mềm

    pdf 7 p | 1153 | 15

  • Web development (Phát triển web): Phần 1

    pdf 126 p | 79 | 14

  • CÁCH 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

    pdf 38 p | 162 | 14

  • Giáo trình Thiết kế hình ảnh bằng phần mềm CorelDraw (Ngành: Thiết kế đồ họa - Cao đẳng) - Trường Cao đẳng Xây dựng số 1

    pdf 100 p | 18 | 9

  • Giáo trình Thiết kế và xây dựng mạng Lan và Wan: Phần 2

    pdf 74 p | 68 | 8

  • Giáo trình Thiết kế đồ họa bằng phần mềm Adobe Illustrator (Ngành: Thiết kế đồ họa - Cao đẳng) - Trường Cao đẳng Xây dựng số 1

    pdf 89 p | 14 | 7

  • Giáo trình Thiết kế và xây dựng mạng Lan (Nghề: Tin học văn phòng - Trình độ: Trung cấp) - Trường Cao đẳng nghề Cần Thơ

    pdf 100 p | 11 | 6

  • Giáo trình Thiết kế và xây dựng mạng LAN (Nghề: Quản trị mạng máy tính - Trung cấp) - Trường Trung cấp nghề Quang Trung

    pdf 90 p | 11 | 6

  • Giáo trình Thiết kế và xây dựng mạng Lan và Wan: Phần 1

    pdf 90 p | 55 | 6

  • Bài giảng Thiết kế, xây dựng mạng (Nghề: Công nghệ thông tin): Phần 1 - CĐ Công nghệ và Nông lâm Nam Bộ

    pdf 147 p | 35 | 6

Thêm tài liệu vào bộ sưu tập có sẵn: Đồng ý Thêm vào bộ sưu tập mới: *Tên bộ sưu tập Mô Tả: *Từ Khóa: Tạo mới Báo xấu
  • Hãy cho chúng tôi biết lý do bạn muốn thông báo. Chúng tôi sẽ khắc phục vấn đề này trong thời gian ngắn nhất.
  • Không hoạt động
  • Có nội dung khiêu dâm
  • Có nội dung chính trị, phản động.
  • Spam
  • Vi phạm bản quyền.
  • Nội dung không đúng tiêu đề.
Hoặc bạn có thể nhập những lý do khác vào ô bên dưới (100 ký tự): Vui lòng nhập mã xác nhận vào ô bên dưới. Nếu bạn không đọc được, hãy Chọn mã xác nhận khác.. Đồng ý LAVA AANETWORK THÔNG TIN
  • Về chúng tôi
  • Quy định bảo mật
  • Thỏa thuận sử dụng
  • Quy chế hoạt động
TRỢ GIÚP
  • Hướng dẫn sử dụng
  • Upload tài liệu
  • Hỏi và đáp
HỖ TRỢ KHÁCH HÀNG
  • Liên hệ
  • Hỗ trợ trực tuyến
  • Liên hệ quảng cáo
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.

Đang xử lý... Đồng bộ tài khoản Login thành công! AMBIENT

Từ khóa » Thiết Kế Và Xây Dựng Phần Mềm Là Gì