Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm

1THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM (SOFTWARE DESIGN AND CONSTRUCTION) Năm học 2007-2008 Giáo viên: TS.Huỳnh Quyết Thắng BM Công nghệ phần mềm Khoa CNTT, ĐHBK HN 2Chươ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. 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) 31.2. Phát hiện các yêu cầu phần mềm (Software Elicitation) 1. Phân tích bài toán 2. Xác định quá trình phát triển các yêu cầu phần mềm 3. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm 4. Xác định các nhóm người sử dụng và đặc tính của họ và đại diện tiêu biểu cho mỗi nhóm 5. Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm NSD 6. 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 (non-functional requirement) 41.2.1. Phân tích bài toán (vấn đề) z [Dean Leffingwell] • Problem analysis is the process of understanding real-world problems and user's needs and proposing solutions to meet those needs. • The goal of problem analysis is to gain a better understanding, before development begins, of the problem being solved. • To identify the root cause, or the problem behind the problem, ask the people directly involved. • Identifying the actors on the system is a key step in problem analysis 51.2.1. Phân tích bài toán (vấn đề) z [Dean Leffingwell] - The 5 specific steps that must be taken in order to achieve the goal: • Gain agreement on the problem definition. • Understand the root causes—the problem behind the problem. • Identify the stakeholders and the users. • Define the solution system boundary. • Identify the constraints to be imposed on the solution. 61.2.1. Phân tích bài toán (vấn đề) z Step 1: Gain Agreement on the Problem Definition • Simply write the problem down and see whether everyone agrees. • The Problem Statement: Table 4-1. Problem statement format Element Description The problem of Describe the problem. affects Identify stakeholders affected by the problem. the result of which Describe the impact of this problem on stakeholders and business activity. Benefits of Indicate the proposed solution and list a few key benefits. 71.2.1. Phân tích bài toán (vấn đề) z Step 2: Understand the Root Causes—The Problem Behind the Problem • Your team can use a variety of techniques to gain an understanding of the real problem and its real causes. One such technique is "root cause" analysis, which is a systematic way of uncovering the root, or underlying, cause of an identified problem or a symptom of a problem 81.2.1. Phân tích bài toán (vấn đề) z Step 3: Identify the Stakeholders and the Users • Who are the users of the system? • Who is the customer (economic buyer) for the system? • Who else will be affected by the outputs that the system produces? • Who will evaluate and bless the system when it is delivered and deployed? • Are there any other internal or external users of the system whose needs must be addressed? • Who will maintain the new system? • Is there anyone else? 91.2.1. Phân tích bài toán (vấn đề) z Step 4: Define the Solution System Boundary • Who will supply, use, or remove information from the system? • Who will operate the system? • Who will perform any system maintenance? • Where will the system be used? • Where does the system get its information? • What other external systems will interact with the system? 10 1.2.1. Phân tích bài toán (vấn đề) z Step 5: Identify the Constraints to Be Imposed on the Solution • Potential system constraints: Economic, Political, Technical, System, Environmental, Schedule and resources 11 1.2.1. Xác định quá trình phát triển các yêu cầu phần mềm z Xác định các bước và tài liệu mô tả quy trình chúng ta sẽ thực hiện quá trình phát triển các yêu cầu phần mềm z Mô tả phương pháp xác định các NSD trong phạm vi bài toán của phần mềm và các kỹ thuật sẽ sử dụng để phát hiện các yêu cầu phần mềm z Mô tả các đặc tả hoặc các mô hình phân tích của phần mềm z Các thông tin cho mỗi yêu cầu, trọng số của yêu cầu z Các bước tiến hành phá hiện các yêu cầu, phân tích yêu cầu 12 1.2.2. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm z Khả năng và phạm vi của phần mềm tập hợp các yêu cầu phần mềm ở mức độ cao (business requirement) z Mô tả khả năng, mục tiêu của phần mềm, các phạm vi ứng dụng của phần mềm, các hạn chế của phần mềm, một số đặc điểm của ứng dụng: ai sử dụng, trong mô trường nào z Thông thường tất cả các thôg tin này được mô tả ngắn gon trong 3-8 trang theo cấu trúc như sau: 13 1.2.2. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm z Cấu trúc của tài liệu: 1. Yêu cầu phần mềm (mức cao business) 1.1. Cơ sở (background) 1.2. Cơ hội 1.3. Đối tượng 1.4. Yêu cầu khách hàng hay yêu cầu thị trường 1.5. Các giá trị cung cấp cho khách hàng 1.6. Các rủi ro 2. Khả năng của phần mềm (vision of solution) 2.1. Các khả năng 2.2. Các đặc điểm 2.3. Các phụ thuộc và chấp nhận 14 1.2.2. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm z Cấu trúc của tài liệu: 3. Phạm vi và giới hạn (scope and limitation) 3.1. Phạm vi của phiên bản đầu 3.2. Phạm vi của các phiên bản tiếp theo 3.3. Hạn chế và ngoại lệ 4. Ngữ cảnh công việc (business context) 4.1. Tiểu sử khách hàng 4.2. Các trong số dự án 5. Các yếu tố thành công của dự án 15 1.2.2. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm 1. Yêu cầu phần mềm (mức cao business requirement) Mô tả các đặc điểm chính mà phần mềm mới sẽ cung cấp cho khách hàng. Thông thường phần này rất khác nhau cho những phần mềm khác nhau 1.1 Cơ sở (background) Mô tả lý do hợp lý cần phát triển phần mềm mới: tai sao, cơ sở nào. Có thể giải thích tổng thể lịch sử hoặc tình huống quyết định cần phải xây dựng phần mềm 1.2. Cơ hội (business opportunity) Mô tả cơ hội trên thị trường đang tồn tại vấn đề mà phần mềm sẽ giải quyết. Có thể mô tả ngắn gọn một số phần mềm tương tự và các đặc tính của chúng và giải thích tại sao càan làm phần mềm này 16 1.2.2. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm 1.3. Đối tượng/mục tiêu Mô tả mục tiêu mà phần mềm giải quyết 1.4. Yêu cầu khách hàng hay yêu cầu thị trường Mô tả các đối tượng khách hàng mà phần mềm sẽ phục vụ. 1.5. Các giá trị cung cấp cho khách hàng Mô tả chi tiết các khả năng của phần mềm sẽ cung cấp cho khách hàng: - Khả năng giải quyết công việc - Khả năng tiết kiệm - Khả năng tự độnghóa các công việc trước đây .... 1.6. Các rủi ro Mô tả các rủi ro của công việc khi phát triển phần mềm. Đánh giá các rủi ro và các phương pháp tránh 17 1.2.2. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm 2. Khả năng của phần mềm (vision of solution) Mô tả cáckhả năng của phần mềm. ở đay sẽ không mô tả các chức năng phần mềm 2.1. Các khả năng Mô tả chính xác ngắn gọn các mục đích dài hạn của phần mềm 2.2. Các đặc điểm Danh sách các đặc điểm chính của phần mềm. Các đặc điểm này sẽ khách những phần mềm tương tự như thế nào 2.3. Các phụ thuộc và chấp nhận Ghi nhận lại các phụ thuộc và các chấp nhận đã thực hiên trong phần mềm 18 1.2.2. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm 3. Phạm vi và giới hạn (scope and limitation) Mô tả các giới hạn về khả năng của phần mềm. Phần mềm chỉ giải quyết bài toán ở mức độ như vậy 3.1. Phạm vi của phiên bản đầu Các phạm vi của phiên bản đầu (1.0) 3.2. Phạm vi của các phiên bản tiếp theo Các phạm vi của các phiên bản tiếp theo 3.3. Hạn chế và ngoại lệ Mô tả các hạn chế và ngoại lệ của phần mềm 4. Ngữ cảnh công việc (business context) 4.1. Tiểu sử khách hàng 4.2. Các trong số dự án 5. Các yếu tố thành công của dự án 19 1.2.2. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm 4. Ngữ cảnh công việc (business context) 4.1. Tiểu sử khách hàng Các đặc điểm của khách hàng: Phân loại khách hàng 4.2. Các trong số dự án Chia làm 03 loại: Các mục tiêu chính của phần mềm (objectives) Các ràng buộc và hạn chế (constraint) Mức độ tự do của phần mềm (khả năng cân đối giữa mục tiêu và các ràng buộc) 5. Các yếu tố thành công của dự án Các yếu tố làm dự án khả thi Các yếu tố chứng tỏ khả ăng cạnh tranh của phần mềm 20 (1) Phân lớp người sử dụng phần mềm (user classes) Phân loại theo đặc điểm Phân loại theo vị trí địa lý Phân loại theo vai trò công việc Phân loại theo chức năng Liệt kê các phân loại (các lớp) và mô tả chi tiết các đặc điểm của NSD ở từng lớp (2) Tìm các NSD tiêu biểu (presentative user) (3) Khái niệm Product Champion: Những đại diện tiêu biểu của từng nhóm người sử dụng. Trên thực tế các yêu cầu phần mềm sẽ được phát hiện từ những khách hàng này 1.2.3. Xác định các nhóm người sử dụng và đặc tính của họ và đại diện tiêu biểu cho mỗi nhóm 21 1.2.3. Xác định các nhóm người sử dụng và đặc tính của họ và đại diện tiêu biểu cho mỗi nhóm Manager Analyst 1 Analyst 2 Analyst n Product Champion 1 Product Champion 2 Requirement Product Champion n Requirement Requirement 22 1.2.4 Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm NSD Nguyên tắc của phát hiện yêu cầu phần mềm: (1) định nghĩa phạm vi và giới hạn phần mềm (2) Xác định các phân nhóm người sử dụng (3) Xác định các đại diện của từng nhóm (4) Xác định Product Champion của từng nhóm (5) Lựa chọn kỹ thuật phát hiện yêu cầu phần mềm (6) áp dụng kỹ thuật cho từng đại diện - Product Champion (7) Xây dựng các tiêu thức chất lượng (8) Chi tiết hóa (chuyển hóa) các trường hợp sử dụng thành chức năng phần mềm (9) Xem xét các trường hợp sử dụng và chức năng (10) Phất triển mô hình phân tích, gải thích và làm rõ với các khách hàng 23 1.2.4 Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm NSD Nguyên tắc của phát hiện yêu cầu phần mềm: (11) Phá ttriển và đánh giá giao diện cho từng yêu cầu (12) Phát triển các trường hợp kiểm thử cho các yêu cầu (13) Sử dụng các trường hợp kiểm thử để kiểm tra (14) Lặp lại các bước 6-13 trước khi thiết kế 1 2 3 4 65 7 8 9 10 11 1312 24 1.2.4 Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm NSD z Phát hiện các yêu cầu phần mềm là một công việc phức tạp z Đây chính là cầu nối để giải quyết bài toán z Đây chính là cầu nối giữa PTV và NSD z Đòi hỏi rất nhiều nỗ lực và các phẩm chất của PTV z Một trong những kỹ thuật tiêu biểu để xác định và phát hiện các yêu cầu sử dụng là “Trường hợp sử dụng”- use-case 25 1.2.4 Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm NSD z Use-case: Thể hiện tập hợp các tương tác giữa các tác nhân (actor) và hệ thống z Actor (tác nhân): z Trường hợp sử dụng: 26 1.2.4 Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm NSD use-case workshops Use-Case Description Draft Functional Requirement Draft Test Case Draft Analysis Models Verified Functional Requirement Veryfied Analysis Model Common Understanding 27 1.2.4 Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của các nhóm NSD Các lỗi thường hoặc là những điểm nên tránh trong phát hiện yêu cầu: (1) Có quá nhiêu use-case (2) Có các use-case trùng lặp (3) Trong mô hinh use-case xay dựng không được phép dưa vào giao diện với NSD (4) Định nghĩa dữ liệu trong các use-case (5) Cố gắng gắn mỗi yêu cầu với một use-case 28 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 1. Interview 2. Requirements Workshops 3. Brainstorming and Idea Reduction 4. Storyboarding 5. Applying Use Cases 6. Prototyping 29 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 1. Interview z Interviewing is a simple and direct technique. z Context-free questions can help achieve bias-free interviews. z Then, it may be appropriate to search for undiscovered requirements by exploring solutions. z Convergence on some common needs will initiate a "requirements repository" for use during the project. z A questionnaire is no substitute for an interview 30 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 1. Interview z The Context-Free Question z Who is the user? z Who is the customer? z Are their needs different? z Where else can a solution to this problem be found? 31 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 1. Interview z Prepare an appropriate context-free interview, and jot it down in a notebook for reference during the interview. Review the questions just prior to the interview. z Before the interview, research the background of the stakeholder and the company to be interviewed. Don't bore the person being interviewed with questions you could have answered in advance. On the other hand, it wouldn't hurt to briefly verify the answers with the interviewee. z Jot down answers in your notebook during the interview. (Don't attempt to capture the data electronically at this time!) z Refer to the template during the interview to make certain that the right questions are being asked. 32 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 2. Requirement Workshop z The requirements workshop is perhaps the most powerful technique for eliciting requirements. z It gathers all key stakeholders together for a short but intensely focused period. z The use of an outside facilitator experienced in requirements management can help ensure the success of the workshop. z Brainstorming is the most important part of the workshop. 33 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 2. Requirement Workshop z Preparing for the Workshop: • Selling the Concept • Ensuring the Participation of the Right Stakeholders • Logistics • "Warm-Up Materials" z Role of the Facilitator z Setting the Agenda z Running the Workshop 34 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 3. Brainstorming and Idea Reduction z Brainstorming involves both idea generation and idea reduction. z The most creative, innovative ideas often result from combining multiple, seemingly unrelated ideas. z Various voting techniques may be used to prioritize the idea created. z Although live brainstorming is preferred, Web-based brainstorming may be a viable alternative in some situations. 35 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 4. Storyboarding z The purpose of storyboarding is to elicit early "Yes, But" reactions. z Storyboards can be passive, active, or interactive. z Storyboards identify the players, explain what happens to them, and describe how it happens. z Make the storyboard sketchy, easy to modify, and unshippable. z Storyboard early and often on every project with new or innovative content 36 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 4. Storyboarding z Types of Storyboards z Passive storyboards tell a story to the user. They can consist of sketches, pictures, screen shots, PowerPoint presentations, or sample outputs. z Active storyboards try to make the user see "a movie that hasn't been produced yet." Active storyboards are animated or automated, perhaps by an automatically sequencing slide presentation or an animation tool or even a movie. z Interactive storyboards let the user experience the system in as realistic a manner as practical. They require participation by the user in order to execute. Interactive storyboards can be simulations or mock-ups or can be advanced to the point of throwaway code. 37 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 5. Applying Use Cases z Use cases, like storyboards, identify the who, what, and how of system behavior. z Use cases describe the interactions between a user and a system, focusing on what the system "does" for the user. z The use-case model describes the totality of the system's functional behavior 38 1.2.5 Các kỹ thuật phát hiện yêu cầu phần mềm từ phía khách hàng 6. Prototyping z Prototyping is especially effective in addressing the "Yes, But" and "Undiscovered Ruins" syndromes. z A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements. z Prototype the "fuzzy" requirements: those that, although known or implied, are poorly defined and poorly understood.