CHAPTER 6 REQUIREMENTS ENGINEERING (RE) 1
CHAPTER 6: REQUIREMENTS ENGINEERING (RE) ⇒ Chủ động nắm bắt nhu cầu khách hàng hỏi họ có u cầu cho phần mềm RE process CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Phương pháp Phương pháp lặp lại tăng dần thường áp dụng cho dự án Agile Feasibility studies (Case khả thi) Chúng ta nghiên cứu định có nên đầu tư vào dự án hay không CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Một số cách nghiên cứu ngắn: Hệ thống có đóng góp cho mục tiêu ban đầu tổ chức hay khơng Hệ thống có nên phát triển dựa cơng nghệ có hay khơng Hệ thống tích hợp với hệ thống khác hay khơng Hệ thống phát triển phạm vi ngân sách tiến độ Hệ thống có cạnh tranh với hệ thống tương tự thị trường hay không Interviews in practice Phỏng vấn người dùng tiềm Uses-case Diagrams Chức năng: mơ hình hóa Uses-case Uses case miêu tả loạt hành động thực actor để tạo kết trực quan cho actor khác Types of Use Case Relationships CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Sự khác biệt include extend: Include Extend Khi làm case phải làm thêm case Khi làm case khơng phải khác, kết hợp vào case làm thêm case khác kết hợp vào mainflow case include phải chung case main flow case extend main flow case alternative flow case Thu 23/06/2022 Requirements validation Validation make sure the requirements reflect what the customer wants Những dự án cần đưa yêu cầu phần mềm phải khảo sát, mị mẫm cầu khách hàng thể phải ánh yêu cầu người dùng Người ta làm chức đơn giản, nội dung nhỏ để thăm dò thị trường Đối với dự án tin học lớn dành cho quan, trường học,… yêu cầu phần mềm gần rõ ràng CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Requirements checking Validity: Tính đắn phần mềm Verifiability: Khả kiểm thử phần mềm Consistency: Phần mềm phải đồng nhất, hệ thống phải tương thích với tảng có Completeness: Phần mềm có đáp ứng đủ yêu cầu hay chưa Realism: Phần mềm phải thực tế đơi khách hàng yêu cầu chức cao siêu, cơng nghệ chưa có đủ khả đáp ứng Requirements reviews Regular reviews cần tổ chức xác định u cầu Hình thức review formal informal Các hình thức liên lạc hiệu giúp cho việc giải vấn đề hồn thành từ giai đoạn đầu Formal review process Step: Plan: What, Who, When, How, Why Hold an overview meeting Each member reads and finds errors in requirements Hold a review meeting/record errors Authors fix errors found Follow-up until all errors are fixed Informal review process Gửi tài liệu cho thành viên, phát lỗi sửa Review Record No Title Description CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Severity (Độ nghiêm trọng) Requirements Management Một trình quản lý thay đổi suốt trình làm đồ án Requirements change Thay đổi thay xu hướng Thay đổi theo độ đáp ứng công nghệ Thay đổi theo độ ưu tiên Dựa môi trường kỹ thuật doanh nghiệp Requirements engineering processes Common activies: Requirements elicitation (rút trích, thu thập) Requirements analysis (phân tích từ liệu khác nhau) Requirements validation CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Requirements managements Feasibility studies (Case khả thi) Đầu tư Dựa vào yêu cầu gì, thu thập thơng tin viết báo cáo Ai sử dụng ứng dụng ? Thị trường ? Công nghệ ? Kĩ cần thiết ? Thời gian, kế hoạch Ngân sách Requirements elicitation and analysis Tìm hiểu ứng dụng lĩnh vực Các dịch vụ mà hệ thống cung cấp Những ràng buộc vận hành Tham gia nhiều bên khác Problems of requirements analysis Các stakeholders thứ họ cần Stakeholders đưa yêu cầu riêng họ Những xung đột yêu cầu stakeholders Các tổ chức yếu tố trị ảnh hưởng Thay đổi yêu cầu phần mềm (thay đổi luật, sách,…) Process activities Tìm yêu cầu Phân loại yêu cầu tổ chức Sắp xếp thứ tự ưu tiên thương lượng CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Ghi lại yêu cầu Requirements discovery Thu thập liệu Các nguồn thông tin khác Types of viewpoint Interator viewpoints: Góc nhìn người dùng tương tác trực tiếp với hệ thống Indirect viewpoints: Góc nhìn tương tác gián tiếp Domain viewpoints: góc nhìn người liên quan đến nghiệp vụ Viewpoint identification Dịch vụ hệ thống Tiêu chuẩn quy định Interviewing Phỏng vấn người dùng tiềm Khám phá yêu cầu khách hàng cách vấn, xác nhận với người dùng Lắng nghe khách hàng Không áp u cầu muốn Use Case Diagrams Mơ hình hố yêu cầu phần mềm Đặc tả yêu cầu phần mềm Use Cases Viết hành động Actors cho kết quan sát CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Description of Use Cases Một chuỗi dịng chảy kiện Một dịng chảy (Main flow/Basic flow) nhiều dòng chảy phụ (Alternative flows) Scenarios Một dòng chảy khả thi, xảy thực tế User story = Scenario Types of Use Case Relationship Association Generalization Include: Khi làm case phải làm thêm case khác, kết hợp vào case main flow case include phải chung main flow case Extend: Khi làm case làm thêm case khác, kết hợp vào case main flow case extend alternative flow case Example: Khi login làm relationship với use case riêng để tránh login dependency vào use case khác, gây nên khó hiểu, nên có pre-condition Requirements validation Reflect what the customer wants Error in requirements result problems in design, code and test Requirements error costs are high Fixing errors caused by incorrect requirements after delivery is much higher than in early stages Requirements checking Validity (Kiểm chứng, độ xác) CHAPTER 6: REQUIREMENTS ENGINEERING (RE) Mò mẫm requirements ban đầu → Làm features → Dị thị trường Khơng phản ánh thị trường, fail Verifiability (Khả kiểm thử phần mềm) Yêu cầu phải cụ thể Consistency (Đồng nhất) Các yêu cầu có conflict Conpleteness (Độ hồn thiện) Tất u cầu có hoàn thiện Realism (Thực tế) Cài đặt được, chạy thực tế Rất khó nhiều u tố ảnh hưởng Requirement validation techniques Requirements reviews Most common approach Manual analysis of the requirements Prototyping Using an executable model Test-case generation Check testability Requirements reviews Requirements are defined Requirements analysts, designers, developers, testers May be formal (Strict reviews) or informal (Many ways to reviews: send documents, share docs to fix immediately, walkthrough the docs and feedback) Resolve problems at an early stage CHAPTER 6: REQUIREMENTS ENGINEERING (RE) 10 Formal review process Được xác định công ty Plan: what, who (Moderator, Authors, Reviewers), when, how, why Hold an overview meeting Each member reads and finds errors in requirements Hold a review meeting/record errors Authors fix errors found Follow-up until all errors are fixed Review Record Requirements management Process of managing changing requirements during the project Requirements change New and changed business needs Better understanding Priority from different viewpoints changes Business and technical environments change Requirements change management CHAPTER 6: REQUIREMENTS ENGINEERING (RE) 11 Change request Change analysis and costing Change implementation Key points Feasibility study, requirements elicitation and analysis, requirements specification and requirements management CHAPTER 6: REQUIREMENTS ENGINEERING (RE) 12