Bài giảng Nhập môn Công nghệ phần mềm - Bài 3: Yêu cầu phần mềm

Nội dung text: Bài giảng Nhập môn Công nghệ phần mềm - Bài 3: Yêu cầu phần mềm

1. Yêu cầu phần mềm Nguyễn Thị Minh Tuyền Nội dung của slide này dựa vào các slides của Ian Sommerville
2. Contents Yêu cầu chức năng và yêu cầu phi chức năng Đặc tả yêu cầu Các quy trình công nghệ yêu cầu Thu thập và phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu www.themegallery.co Tài liệu yêu cầu phầnm mềm Nguyễn Thị Minh Tuyền Nhập môn CNPM
3. Yêu cầu là gì? v Yêu cầu (requirement) có nhiều mức § Mô tả trừu tượng ở mức cao về một dịch vụ hay về một ràng buộc hệ thống. § Đặc tả chi tiết về một chức năng. v Các yêu cầu có thể có hai chức năng § Cơ sở để thương lượng một hợp đồng – vì vậy cần được viết một cách trừu tượng để có thể diễn giải thêm; § Cở sở để viết hợp đồng – vì thế cần phải được định nghĩa chi tiết; § Cả hai trường hợp trên đều được gọi là yêu cầu. Nguyễn Thị Minh Tuyền 3 Nhập môn CNPM
4. Các loại yêu cầu v Yêu cầu người dùng (user requirement) § Những phát biểu bằng ngôn ngữ tự nhiên kết hợp với các biểu đồ về các dịch vụ mà hệ thống cung cấp và những ràng buộc về hoạt động của nó. § Viết cho khách hàng. v Yêu cầu hệ thống (system requirement) § Một tài liệu có cấu trúc mô tả chi tiết chức năng của hệ thống, các dịch vụ và ràng buộc về hoạt động của hệ thống § Định nghĩa chính xác cái gì cần được cài đặt. Có thể là một phần của hợp đồng giữa khách hàng và người nhận thầu. Nguyễn Thị Minh Tuyền 4 Nhập môn CNPM
5. Yêu cầu người dùng và yêu cầu hệ thống v Yêu cầu người dùng 1. Hệ thống MHC-PMS sẽ phát sinh báo cáo tổng kết hàng tháng về giá cả của thuốc được kê đơn bởi mỗi phòng khám trong suốt tháng đó. v Yêu cầu hệ thống 1.1 Vào ngày làm việc cuối cùng của mỗi tháng, xuất ra một bản tóm tắt các loại thuốc được kê đơn, giá cả của mỗi loại thuốc và tên phòng khám kê đơn thuốc. 1.2 Hệ thống sẽ tự động sinh ra báo cáo để in sau 17.30 của ngày làm việc cuối cùng của tháng. 1.3 Một báo cáo sẽ được tạo ra cho mỗi phòng khám và sẽ liệt kê tên thuốc, tổng số đơn thuốc, liều lượng, và tổng chi phí cho thuốc được kê đơn. 1.4 Nếu thuốc sử dụng nhiều loại đơn vị khác nhau (ví dụ 10mg, 20ml) thì phải tách riêng thành các báo cáo khác nhau cho mỗi đơn vị thuốc. 1.5 Việc truy cập vào các báo cáo giá thuốc chỉ dành riêng cho một danh sách hạn chế những người sử dụng. Nguyễn Thị Minh Tuyền 5 Nhập môn CNPM
6. Người đọc đặc tả yêu cầu Client managers System end-users User Client engineers requirements Contractor managers System architects System end-users System Client engineers requirements System architects Software developers Nguyễn Thị Minh Tuyền 6 Nhập môn CNPM
7. Contents Yêu cầu chức năng và yêu cầu phi chức năng Đặc tả yêu cầu Các quy trình công nghệ yêu cầu Thu thập và phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu www.themegallery.co Tài liệu yêu cầu phầnm mềm Nguyễn Thị Minh Tuyền Nhập môn CNPM
8. Yêu cầu chức năng và yêu cầu phi chức năng v Yêu cầu chức năng § Những phát biểu về các dịch vụ mà hệ thống cung cấp, cách mà hệ thống xử lý với các đầu vào cụ thể và cách hệ thống ứng xử trong các tình huống cụ thể § Có thể phát biểu cả những gì mà hệ thống không làm được. v Yêu cầu phi chức năng § Những ràng buộc về dịch vụ hay chức năng cung cấp bởi hệ thống như ràng buộc về thời gian, ràng buộc về quy trình phát triển, các chuẩn, § Thường áp dụng cho toàn hệ thống hơn là một chức năng hay dịch vụ đơn lẻ. Nguyễn Thị Minh Tuyền 8 Nhập môn CNPM
9. Yêu cầu chức năng v Mô tả chức năng và dịch vụ hệ thống. § Yêu cầu chức năng người dùng có thể là những phát biểu ở mức cao về những gì hệ thống sẽ làm. § Yêu cầu chức năng ở mức hệ thống mô tả các dịch vụ hệ thống, các đầu vào và đầu ra của nó, các ngoại lệ ở mức chi tiết. v Phụ thuộc vào loại phần mềm, người sử dụng. Nguyễn Thị Minh Tuyền 9 Nhập môn CNPM
10. Yêu cầu chức năng cho hệ thống MHC-PMS v Một người sử dụng có thể tìm kiếm danh sách các lịch hẹn trong tất cả các phòng khám. v Hàng ngày, đối với mỗi phòng khám, hệ thống sẽ tự động tạo ra một danh sách các bệnh nhân có hẹn ngày hôm đó. v Mỗi nhân viên của phòng khám sử dụng hệ thống sẽ được nhận diện bởi mã nhân viên gồm có 8 chữ số. Nguyễn Thị Minh Tuyền 10 Nhập môn CNPM
11. Sự thiếu chính xác của các yêu cầu v Vấn đề phát sinh khi yêu cầu không được phát biểu một cách chính xác. v Những yêu cầu nhập nhằng không rõ ràng có thể được diễn giải theo nhiều cách khác nhau bởi người phát triển phần mềm và người dùng. v Ví dụ, xem xét từ ‘tìm kiếm’ § Ý định người dùng: tìm kiếm tên một bệnh nhân trong tất cả các lịch hẹn ở tất cả các phòng khám; § Diễn giải của người phát triển: tìm tên một bệnh nhân ở một clinic cụ thể. Người dùng chọn một phòng khám rồi tìm kiếm. Nguyễn Thị Minh Tuyền 11 Nhập môn CNPM
12. Tính hoàn chỉnh và nhất quán của yêu cầu v Về nguyên tắc, các yêu cầu nên hoàn chỉnh và nhất quán. v Hoàn chỉnh (complete) § Tất cả các dịch vụ mà người dùng yêu cầu phải được định nghĩa. v Nhất quán (consistent) § Không có bất cứ mâu thuẫn hay xung đột nào trong các mô tả về các yêu cầu. v Trên thực tế, không thể tạo ra tài liệu các yêu cầu vừa hoàn chỉnh vừa nhất quán được. § Rất dễ mắc lỗi hay bỏ sót yêu cầu khi viết đặc tả cho các hệ thống phức tạp. § Các stakeholder có các nhu cầu khác nhau và thường không nhất quán với nhau. Nguyễn Thị Minh Tuyền 12 Nhập môn CNPM
13. Yêu cầu phi chức năng v Là những yêu cầu không liên quan trực tiếp đến những dịch vụ mà hệ thống cung cấp đến người dùng. v Liên quan đến những thuộc tính hệ thống (độ tin cậy, thời gian trả lời và yêu cầu về mặt lưu trữ) và các ràng buộc (khả năng của thiết bị vào ra, biểu diễn dữ liệu dùng trong các giao diện với các hệ thống khác). v Yêu cầu phi chức năng có thể quan trọng hơn yêu cầu chức năng. § Nếu những yêu cầu này không đạt được, hệ thống sẽ trở nên vô dụng. Nguyễn Thị Minh Tuyền 13 Nhập môn CNPM
14. Cài đặt yêu cầu phi chức năng v Yêu cầu phi chức năng có thể ảnh hưởng đến cấu trúc toàn hệ thống hơn là các component riêng lẻ. § Ví dụ, để đảm các yêu cầu về mặt hiệu suất, bạn phải tổ chức hệ thống để giảm thiểu sự giao tiếp giữa các component. v Một yêu cầu phi chức năng đơn lẻ, chẳng hạn như yêu cầu về bảo mật, có thể phát sinh ra một số yêu cầu chức năng liên quan mà dịch vụ của hệ thống phải có. § Có thể phát sinh các yêu cầu để giới hạn các yêu cầu đang tồn tại. Nguyễn Thị Minh Tuyền 14 Nhập môn CNPM
15. Phân loại yêu cầu phi chức năng v Yêu cầu sản phẩm § Những yêu cầu đặc tả hay ràng buộc hành vi của phần mềm. Ví dụ yêu cầu về hiệu năng của phần mềm liên quan đến tốc độ thực thi, lượng bộ nhớ sử dụng, độ tin cậy, v Yêu cầu tổ chức § Những yêu cầu xuất phát từ các chính sách và thủ tục về mặt tổ chức. Ví dụ như yêu cầu về quy trình hoạt động định nghĩa hệ thống được sử dụng như thế nào, yêu cầu về quy trình phát triển đặc tả ngôn ngữ lập trình, môi trường phát triển và chuẩn về quy trình được sử dụng v Yêu cầu bên ngoài § Những yêu cầu xuất phát từ những nhân tố bên ngoài ảnh hưởng đến hệ thống và quy trình phát triển của nó. Ví dụ yêu cầu về tương tác, yêu cầu về mặt pháp lý, Nguyễn Thị Minh Tuyền 15 Nhập môn CNPM
16. Các loại yêu cầu phi chức năng Non-functional requirements Product Organizational External requirements requirements requirements Efficiency Dependability Security Regulatory Ethical requirements requirements requirements requirements requirements Usability Environmental Operational Development Legislative requirements requirements requirements requirements requirements Performance Space Accounting Safety/security requirements requirements requirements requirements Nguyễn Thị Minh Tuyền 16 Nhập môn CNPM
17. Yêu cầu phi chức năng của hệ thống MHC-PMS v Yêu cầu sản phẩm § Hệ thống MHC-PMS sẽ luôn hoạt động để các phòng khám sử dụng trong suốt giờ làm việc (từ thứ 2 đến thứ 6, 8.30 – 17.30). Thời gian ngừng hoạt động trong suốt giờ làm việc sẽ không vượt quá sẽ không vượt quá 5s trong bất kỳ ngày nào. v Yêu cầu tổ chức § Người sử dụng hệ thống sẽ phải tự đăng nhập bằng thẻ nhân viên của họ. v Yêu cầu bên ngoài § Hệ thống sẽ cài đặt các quy định về tính riêng tư của bệnh nhân. Nguyễn Thị Minh Tuyền 17 Nhập môn CNPM
18. Đánh giá yêu cầu phi chức năng v Yêu cầu phi chức năng khó có thể được phát biểu một cách chính xác § Những yêu cầu không chính xác khó kiểm thử. v Để yêu cầu phi chức năng có thể kiểm định được § Sử dụng một phép đo nào đó để có thể kiểm tra được. § Diễn đạt các yêu cầu ở dạng có thể kiểm tra được. Nguyễn Thị Minh Tuyền 18 Nhập môn CNPM
19. Ví dụ v Mục tiêu: § Đội ngũ bác sĩ sử dụng hệ thống dễ dàng § Hệ thống được tổ chức theo cách nào đó sao cho lỗi người dùng là ít nhất. v Yêu cầu phi chức năng có thể kiểm tra được: § Đội ngũ bác sĩ sẽ có khả năng sử dụng được toàn bộ chức năng của hệ thống sau 4h đào tạo. Sau thời gian đào tạo này, số lỗi trung bình tạo ra bởi người dùng có kinh nghiệm không vượt quá hai lỗi cho mỗi giờ sử dụng hệ thống. Nguyễn Thị Minh Tuyền 19 Nhập môn CNPM
20. Tiêu chí để đo đạc việc đặc tả các yêu cầu phi chức năng Property Measure Speed Processed transactions/second User/event response time Screen refresh time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems Nguyễn Thị Minh Tuyền 20 Nhập môn CNPM
21. Contents Yêu cầu chức năng và yêu cầu phi chức năng Đặc tả yêu cầu Các quy trình công nghệ yêu cầu Thu thập và phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu www.themegallery.co Tài liệu yêu cầu phầnm mềm Nguyễn Thị Minh Tuyền Nhập môn CNPM
22. Đặc tả yêu cầu v Là quy trình viết những yêu cầu người dùng và yêu cầu hệ thống vào tài liệu yêu cầu. v Yêu cầu người dùng phải được mô tả sao cho người sử dụng cuối và khách hàng (những người không có kiến thức về kỹ thuật) có thể hiểu được. v Yêu cầu hệ thống là những yêu cầu chi tiết và có thể bao gồm những thông tin về kỹ thuật. v Yêu cầu có thể là một phần của hợp đồng. § Do đó việc đặc tả yêu cầu hoàn chỉnh đến mức có thể là quan trọng. Nguyễn Thị Minh Tuyền 22 Nhập môn CNPM
23. Các cách viết đặc tả yêu cầu hệ thống Notation Description Natural language The requirements are written using numbered sentences in natural sentences language. Each sentence should express one requirement. Structured natural The requirements are written in natural language on a standard form or language template. Each field provides information about an aspect of the requirement. Design description This approach uses a language like a programming language, but with languages more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical Graphical models, supplemented by text annotations, are used to define notations the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical These notations are based on mathematical concepts such as finite- specifications state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract Nguyễn Thị Minh Tuyền 23 Nhập môn CNPM
24. Yêu cầu và thiết kế v Về nguyên tắc § Yêu cầu nên phát biểu những gì hệ thống cần làm (what). § Thiết kế mô tả cách hệ thống thực hiện việc đó (how). v Thực tế, yêu cầu và thiết kế không tách biệt nhau § Một kiến trúc hệ thống có thể được thiết kế để cấu trúc hóa yêu cầu; § Hệ thống có thể tương tác với các hệ thống khác, từ đó làm nảy sinh các yêu cầu về thiết kế; § Việc sử dụng một kiến trúc cụ thể để thỏa mãn các yêu cầu phi chức năng là cần thiết. Nguyễn Thị Minh Tuyền Nhập môn CNPM
25. Đặc tả bằng ngôn ngữ tự nhiên v Yêu cầu được viết dưới dạng câu dùng ngôn ngữ tự nhiên với sự hỗ trợ của bảng và biểu đồ. v Được dùng để viết yêu cầu vì § Ngôn ngữ tự nhiên biểu cảm, trực quan và phổ biến § Điều này có nghĩa là cả người sử dụng và khách hàng đều có thể hiểu được yêu cầu. Nguyễn Thị Minh Tuyền 25 Nhập môn CNPM
26. Hướng dẫn viết yêu cầu v Tạo ra/chọn một định dạng chuẩn và dùng nó cho tất cả các yêu cầu. v Sử dụng ngôn ngữ một cách nhất quán. § Dùng “phải/sẽ” cho các yêu cầu bắt buộc. § Dùng “nên” cho các yêu cầu mong muốn. v Dùng text highlighting để đánh dấu những phần quan trọng của yêu cầu. v Tránh dùng thuật ngữ chuyên ngành. v Phải giải thích tại sao một yêu cầu đưa ra là cần thiết. Nguyễn Thị Minh Tuyền Nhập môn CNPM
27. Yêu cầu của hệ thống bơm insulin 3.2 Hệ thống sẽ đo lượng đường trong máu và bơm insulin mỗi phút một lần nếu cần thiết. (Nhưng thay đổi về lượng đường trong máu khá chậm vì thế việc đo quá thường xuyên là không cần thiết; nếu số lần đo ít quá có thể dẫn đến lượng đường trong máu cao). 3.6 Hệ thống sẽ chạy một lộ trình tự kiểm tra mỗi phút với các điều kiện để kiểm tra và các hành động liên quan được định nghĩa. (Một lộ trình tự kiểm tra có thể tìm ra các lỗi phần cứng và phần mềm và báo cho người sử dụng biết là hệ thống không thể hoạt động bình thường được. Nguyễn Thị Minh Tuyền 27 Nhập môn CNPM
28. Đặc tả bằng ngôn ngữ có cấu trúc v Một phương pháp viết yêu cầu trong đó § Sự tự do của người viết yêu cầu bị hạn chế § Yêu cầu được viết theo chuẩn. v Cách viết này phù hợp với một số loại yêu cầu, ví dụ như yêu cầu cho hệ thống điều khiển nhúng. v Tuy nhiên nó lại quá cứng nhắc đối với việc viết yêu cầu hệ thống doanh nghiệp. Nguyễn Thị Minh Tuyền 28 Nhập môn CNPM
29. Đặc tả dựa vào form có sẵn v Định nghĩa hàm (function) hay thực thể (entity). v Mô tả đầu vào và nguồn gốc của đầu vào. v Mô tả đầu ra và đích đến của đầu ra. v Thông tin về những thông tin cần thiết được dùng cho việc tính toán hoặc các thực thể khác trong hệ thống được sử dụng. v Mô tả hành động xảy ra. v Các điều kiện: Điều kiện trước và điều kiện sau. v Hiệu ứng phụ (nếu có) của hàm. Nguyễn Thị Minh Tuyền Nhập môn CNPM
30. Đặc tả dựa vào form của một yêu cầu bơm insulin Insulin Pump/Control Software/SRS/3.3.2 Function! Compute insulin dose: Safe sugar level. Description! Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units. Inputs! Current sugar reading (r2), the previous two readings (r0 and r1).! Source! Current sugar reading from sensor. Other readings from memory. Outputs! CompDose—the dose in insulin to be delivered. Destination! Main control loop. Action! CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be delivered. Requirements! Two previous readings so that the rate of change of sugar level can be computed. Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin. Post-condition r0 is replaced by r1 then r1 is replaced by r2. Side effects None. ! Nguyễn Thị Minh Tuyền 30 Nhập môn CNPM
31. Đặc tả dùng bảng v Dùng để hỗ trợ cho ngôn ngữ tự nhiên. v Đặc biệt hữu ích khi cần định nghĩa một số hướng có thể xảy ra. v Ví dụ: hệ thống bơm insulin dựa vào tính toán trên tỉ lệ thay đổi của lượng đường trong máu § Việc dùng bảng để đặc tả sẽ giải thích cách tính toán yêu cầu về lượng insulin trong các trường hợp khác nhau. Nguyễn Thị Minh Tuyền Nhập môn CNPM
32. Tabular specification of computation for an insulin pump Condition Action Sugar level falling (r2 < r1) CompDose = 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of increase CompDose = 0 decreasing ((r2 – r1) < (r1 – r0)) Sugar level increasing and rate of increase CompDose = round ((r2 – r1)/ stable or increasing ((r2 – r1) ≥ (r1 – r0)) 4) If rounded result = 0 then CompDose = MinimumDose Nguyễn Thị Minh Tuyền 32 Nhập môn CNPM
33. Contents Yêu cầu chức năng và yêu cầu phi chức năng Đặc tả yêu cầu Các quy trình công nghệ yêu cầu Thu thập và phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu www.themegallery.co Tài liệu yêu cầu phầnm mềm Nguyễn Thị Minh Tuyền Nhập môn CNPM
34. Nguyễn Thị Minh Tuyền 34 Nhập môn CNPM
35. Công nghệ yêu cầu v Requirements engineering (RE) v Tập hợp các tác vụ và kỹ thuật để dẫn đến việc hiểu rõ các yêu cầu được gọi là công nghệ yêu cầu. v Đứng ở góc độ quy trình phần mềm, công nghệ yêu cầu là hoạt động chính bắt đầu trong suốt hoạt động giao tiếp và tiếp tục trong các hoạt động mô hình hóa. Nguyễn Thị Minh Tuyền 35 Nhập môn CNPM
36. Quy trình công nghệ yêu cầu v Đa dạng, phụ thuộc vào § Miền ứng dụng § Những người liên quan § Tổ chức viết yêu cầu v Tuy nhiên, có một số hoạt động tổng quát cho tất cả các quy trình § Nghiên cứu khả thi (Feasibility study); § Thu thập yêu cầu (Requirements elicitation); § Phân tích yêu cầu (Requirements analysis); § Thẩm định yêu cầu (Requirements validation); § Quản trị yêu cầu (Requirements management). v Thực tế, RE là một hoạt động có tính lặp lại trong đó những quy trình này đan xen nhau. Nguyễn Thị Minh Tuyền 36 Nhập môn CNPM
37. Quy trình công nghệ yêu cầu Requirements specification System requirements specification and modeling User requirements specification Business requirements specification Start Feasibility System study Requirements req. Requirements elicitation elicitation User validation requirements elicitation Prototyping Reviews System requirements document Nguyễn Thị Minh Tuyền 37 Nhập môn CNPM
38. Nghiên cứu khả thi v Một nghiên cứu ngắn, tập trung, nhằm kiểm tra xem § Hệ thống có đóng góp cho các mục tiêu của tổ chức hay không? § Hệ thống có thể được phát triển bằng công nghệ hiện hành và trong phạm vi ngân sách hay không? § Hệ thống có thể được tích hợp với các hệ thống khác đang được sử dụng hay không? Nguyễn Thị Minh Tuyền 38 Nhập môn CNPM
39. Tổng kết v Yêu cầu cho một hệ thống phần mềm thiết lập những gì hệ thống sẽ làm và định nghĩa các ràng buộc về hoạt động và cài đặt. v Yêu cầu chức năng là các phát biểu về các dịch vụ mà hệ thống phải cung cấp hoặc các mô tả về cách tính toán phải tiến hành. v Yêu cầu phi chức năng thường ràng buộc hệ thống phải phát triển và quy trình phát triển được sử dụng. v Quy trình công nghệ yêu cầu là một tiến trình lặp lại gồm nghiên cứu khả thi, thu thập yêu cầu, đặc tả và thẩm định. Nguyễn Thị Minh Tuyền 39 Nhập môn CNPM
40. Contents Yêu cầu chức năng và yêu cầu phi chức năng Đặc tả yêu cầu Các quy trình công nghệ yêu cầu Thu thập và phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu www.themegallery.co Tài liệu yêu cầu phầnm mềm Nguyễn Thị Minh Tuyền Nhập môn CNPM
41. Thu thập và phân tích yêu cầu v Requirements elicitation/requirements discovery. v Kỹ sư phần mềm làm việc với các stakeholder để tìm ra § Miền ứng dụng § Những dịch vụ mà hệ thống cung cấp § Các ràng buộc để vận hành hệ thống (hiệu suất hệ thống, ràng buộc về phần cứng, ) v Stakeholder : người dùng cuối, quản lý, kỹ sư bảo trì hệ thống, Nguyễn Thị Minh Tuyền 41 Nhập môn CNPM
42. Các vấn đề gặp phải v Các stakeholder không biết họ thật sự cần gì. v Các stakeholder diễn đạt các yêu cầu bằng những thuật ngữ riêng của họ. v Các stakeholder khác nhau có các yêu cầu xung đột nhau. v Các nhân tố về mặt tổ chức và chính trị có thể ảnh hưởng đến yêu cầu hệ thống. v Các yêu cầu thay đổi trong suốt quá tình phân tích § Phát sinh các stakeholder mới § Môi trường doanh nghiệp thay đổi. Nguyễn Thị Minh Tuyền Nhập môn CNPM
43. Các hoạt động của quy trình v Nhận diện yêu cầu (Requirements discovery) § Tương tác với các stakeholder để tìm ra các yêu cầu của họ. § Các domain requirements cũng được phát hiện tại bước này. v Tổ chức và phân loại yêu cầu (Requirements classification and organisation) § Nhân nhóm các yêu cầu có liên quan đến nhau và tổ chức chúng thành các nhóm (cluster). v Đặt độ ưu tiên và thương lượng (Prioritisation and negotiation) § Đặt độ ưu tiên cho các yêu cầu và giải quyết xung đột giữa các yêu cầu. v Đặc tả yêu cầu § Yêu cầu được viết thành tài liệu và đặt nó vào vòng xoắn tiếp theo. Nguyễn Thị Minh Tuyền Nhập môn CNPM
44. Quy trình thu thập và phân tích yêu cầu 1. Requirements discovery 4. Requirements 2. Requirements specification classification and organization 3. Requirements prioritization and negotiation Nguyễn Thị Minh Tuyền 44 Nhập môn CNPM
45. Nhận diện yêu cầu v Là quá trình tập hợp các thông tin về các yêu cầu hệ thống đề xuất và các hệ thống đang tồn tại, chọn lọc các yêu cầu người dùng và yêu cầu hệ thống từ những thông tin này. v Nguồn thông tin trong suốt pha này gồm tài liệu, các stakeholder hệ thống và đặc tả của các hệ thống tương tự. Nguyễn Thị Minh Tuyền 45 Nhập môn CNPM
46. Các stakeholder trong hệ thống MHC-PMS v Bệnh nhân: thông tin của họ được lưu trong hệ thống. v Bác sĩ: người chịu trách nhiệm đánh giá tình hình bệnh và chữa trị cho bệnh nhân. v Y tá: người phối hợp khám chữa bệnh với bác sĩ và quản lý một số điều trị. v Lễ tân y tế: người quản lý lịch hẹn của bệnh nhân. v Đội ngũ IT: người chịu trách nhiệm cài đặt và bảo trì hệ thống. v Quản lý về đạo đức y tế: người đảm bảo rằng hệ thống đáp ứng được những hướng dẫn về mặt y đức cho việc chữa trị bệnh nhân. v Đội ngũ lưu trữ y tế: người chịu trách nhiệm việc đảm bảo cho thông tin hệ thống được duy trì và lưu trữ. Nguyễn Thị Minh Tuyền 46 Nhập môn CNPM
47. Stakeholder của hệ thống ATM v Khách hàng (người sử dụng dịch vụ) v Đại diện của các ngân hàng khác (ATM của ngân hàng này có thể dùng để giao dịch với ngân hàng khác) v Quản lý ngân hàng (dùng thông tin quản lý từ hệ thống ATM) v Nhân viên làm việc tại các chi nhánh ngân hàng (vận hành hệ thống) v Quản trị cơ sở dữ liệu (tích hợp hệ thống với CSDL của ngân hàng) v Quản lý an ninh v Phòng marketing (muốn dùng ATM để quảng cáo) v Kĩ sư IT bảo trì phần mềm và phần cứng v Những người điều phối hệ thống ngân hàng quốc gia (đảm bảo hệ thống tuân theo nguyên tắc chung) Nguyễn Thị Minh Tuyền 47 Nhập môn CNPM
48. Phương pháp để nhận diện yêu cầu v Phỏng vấn v Quan sát v Điều tra bằng bảng câu hỏi v Nghiên cứu tài liệu v Joint Application Design – JAD v Làm bản mẫu v Mô hình hóa/Dùng ký pháp đồ hoạ Nguyễn Thị Minh Tuyền 48 Nhập môn CNPM
49. Phỏng vấn v Phỏng vấn mang tính hình thức hay không hình thức đều là một phần của hầu hết các quy trình RE. v Các loại phỏng vấn § Phỏng vấn đóng: dựa vào một danh sách các câu hỏi đã định trước § Phỏng vấn mở: nhiều vấn đề được khám phá ra khi phỏng vấn với các stakeholder. v Phỏng vấn hiệu quả § Cởi mở, tránh hình thành trước ý tưởng về yêu cầu và sẵn sàng lắng nghe các stakeholder. § Gợi ý người phỏng vấn bằng một câu hỏi, một đề xuất, hoặc bằng cách cùng nhau làm việc trên một hệ thống nguyên bản. Nguyễn Thị Minh Tuyền 49 Nhập môn CNPM
50. Phỏng vấn trong thực tế v Thường kết hợp cả phỏng vấn đóng và phỏng vấn mở. v Phỏng vấn có ích cho việc hiểu tổng quan về những gì stakeholder làm và cách họ tương tác với hệ thống. v Phỏng vấn không tốt cho việc tìm hiểu các domain requirement § Các kỹ sư thu thập yêu cầu không thể hiểu được các thuật ngữ chuyên ngành; § Một số kiến thức chuyên ngành quá quen thuộc với các stakeholder đến mức mà họ nghĩ rằng không cần phải giải thích. Nguyễn Thị Minh Tuyền Nhập môn CNPM
51. Kịch bản v Kịch bản (scenario) là những ví dụ thực tế về cách hệ thống được sử dụng. v Có thể gồm § Một mô tả về tình huống ban đầu; § Một mô tả về dòng sự kiện thông thường; § Một mô tả về những trục trặc có thể xảy ra; § Thông tin về các hoạt động xảy ra đồng thời; § Một mô tả về trạng thái khi kịch bản kết thúc. Nguyễn Thị Minh Tuyền Nhập môn CNPM
52. Scenario for collecting medical history in MHC-PMS INITIAL ASSUMPTION: The patient has seen a medical receptionist who has created a record in the system and collected the patient’s personal information (name, address, age, etc.). A nurse is logged on to the system and is collecting medical history. NORMAL: The nurse searches for the patient by family name. If there is more than one patient with the same surname, the given name (first name in English) and date of birth are used to identify the patient. The nurse chooses the menu option to add medical history. The nurse then follows a series of prompts from the system to enter information about consultations elsewhere on mental health problems (free text input), existing medical conditions (nurse selects conditions from menu), medication currently taken (selected from menu), allergies (free text), and home life (form). WHAT CAN GO WRONG: The patient’s record does not exist or cannot be found. The nurse should create a new record and record personal information. Patient conditions or medication are not entered in the menu. The nurse should choose the ‘other’ option and enter free text describing the condition/medication. Patient cannot/will not provide information on medical history. The nurse should enter free text recording the patient’s inability/unwillingness to provide information. The system should print the standard exclusion form stating that the lack of information may mean that treatment will be limited or delayed. This should be signed and handed to the patient. OTHER ACTIVITIES: Record may be consulted but not edited by other staff while information is being entered. SYSTEM STATE ON COMPLETION: User is logged on. The patient record including medical history is entered in the database, a record is added to the system log showing the start and end time of the session and the nurse involved. Nguyễn Thị Minh Tuyền 52 Nhập môn CNPM
53. Use case v Use-case là kỹ thuật dựa vào scenario bằng ngôn ngữ UML § Chỉ ra các actor trong một tương tác § Mô tả chính tương tác đó. v Một tập các use case mô tả tất cả các tương tác có thể với hệ thống. v Sơ đồ tuần tự có thể được dùng để bổ sung chi tiết cho các use case bằng cách chỉ ra chuỗi tuần tự các sự kiện trong hệ thống. Nguyễn Thị Minh Tuyền 53 Nhập môn CNPM
54. Use cases for the MHC-PMS Register Export patient statistics View Manager Generate Medical receptionist personal info. report View record Nurse Doctor Edit record Setup consultation Nguyễn Thị Minh Tuyền 54 Nhập môn CNPM
55. Contents Yêu cầu chức năng và yêu cầu phi chức năng Đặc tả yêu cầu Các quy trình công nghệ yêu cầu Thu thập và phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu www.themegallery.co Tài liệu yêu cầu phầnm mềm Nguyễn Thị Minh Tuyền Nhập môn CNPM
56. Thẩm định yêu cầu v Chứng tỏ rằng yêu cầu định nghĩa được hệ thống mà khách hàng cần. v Chi phí để sửa lỗi yêu cầu cao, do đó việc thẩm định rất quan trọng § Sửa một lỗi yêu cầu sau khi bàn giao phần mềm có thể tốn kém gấp 100 là chi phí sửa lỗi cài đặt. Nguyễn Thị Minh Tuyền 56 Nhập môn CNPM
57. Kiểm tra yêu cầu v Tính hiệu lực (Validity) § Hệ thống có cung cấp những chứ năng đáp ứng tốt nhu cầu của người dùng ko? v Tính nhất quán (Consistency) § Có các yêu cầu nào xung đột nhau hay không? v Tính đầy đủ (Completeness) § Có đủ các chức năng mà khách hàng yêu cầu không? v Tính thực tế (Realism) § Có thể cài đặt các yêu cầu với ngân sách và công nghệ cho trước không? v Tính kiểm định được (Verifiability) § Có cách nào kiểm tra được các yêu cầu không? Nguyễn Thị Minh Tuyền 57 Nhập môn CNPM
58. Kỹ thuật thẩm định yêu cầu v Duyệt yêu cầu (Requirements reviews) § Phân tích một cách có hệ thống các yêu cầu (không dùng công cụ tự động). v Phiên bản thử nghiệm (Prototyping) § Sử dụng một mô hình chạy được của hệ thống để kiểm tra các yêu cầu. v Sinh test-case (test-case generation) § Phát triển các test cho các yêu cầu để kiểm tra khả năng test được hay không. Nguyễn Thị Minh Tuyền 58 Nhập môn CNPM
59. Duyệt yêu cầu v Nên duyệt yêu cầu thường xuyên trong quá trình định nghĩa yêu cầu đang được hình thành. v Cả hai bên ký hợp đồng nên tham gia duyệt yêu cầu. v Việc duyệt yêu cầu có thể mang tính hình thức (với tài liệu hoàn chỉnh) hoặc không mang tính hình thức. Giao tiếp tốt giữa người phát triển, khách hàng và người dùng có thể giải quyết được các vấn đề ngay từ đầu. Nguyễn Thị Minh Tuyền 59 Nhập môn CNPM
60. Kiểm tra gì khi duyệt yêu cầu v Tính có thể kiểm định được (Verifiability) § Về thực tiễn, có test được yêu cầu này không? v Tính dễ hiểu (Comprehensibility) § Yêu cầu này có dễ hiểu không? v Tính có thể lần vết được (Traceability) § Nguồn gốc của yêu cầu này có được chỉ rõ không? v Tính thích nghi được (Adaptability) § Có thể thay đổi yêu cầu này mà không làm ảnh hưởng đến các yêu cầu khác không? Nguyễn Thị Minh Tuyền 60 Nhập môn CNPM
61. Contents Yêu cầu chức năng và yêu cầu phi chức năng Đặc tả yêu cầu Các quy trình công nghệ yêu cầu Thu thập và phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu www.themegallery.co Tài liệu yêu cầu phầnm mềm Nguyễn Thị Minh Tuyền Nhập môn CNPM
62. Quản trị yêu cầu v Quản trị yêu cầu (requirements management) là quy trình quản trị sự thay đổi yêu cầu trong suốt quá trình công nghệ yêu cầu và phát triển hệ thống. v Các yêu cầu mới phát sinh khi hệ thống đang được phát triển và cả khi nó được đưa vào sử dụng. v Cần theo dõi những yêu cầu đơn lẻ và duy trì mối liên hệ giữa các yêu cầu phụ thuộc nhau § Để có thể đánh giá được ảnh hưởng khi thay đổi yêu cầu. v Cần thiết lập một quy trình hình thức cho những đề nghị thay đổi và tạo mối liên hệ giữa yêu cầu này với các yêu cầu hệ thống. Nguyễn Thị Minh Tuyền 62 Nhập môn CNPM
63. Thay đổi yêu cầu v Môi trường doanh nghiệp và kỹ thuật của hệ thống luôn luôn thay đổi trong quá trình phát triển hệ thống và cả sau khi đưa hệ thống vào sử dụng. v Người chi trả cho hệ thống và người dùng hệ thống đó hiếm khi là một. § Khách hàng hệ thống áp đặt yêu cầu vì những ràng buộc về mặt tổ chức và tài chính. Các yêu cầu này có thể xung đột với yêu cầu của người dùng cuối. Do đó, sau khi hệ thống được đưa vào sử dụng, những chức năng mới có thể phải được thêm vào để đáp ứng yêu cầu của người dùng. Nguyễn Thị Minh Tuyền 63 Nhập môn CNPM
64. Thay đổi yêu cầu v Những hệ thống lớn thường có một cộng đồng người dùng đa dạng. Những người dùng khác nhau có những yêu cầu khác nhau và độ ưu tiên cũng khác nhau, do đó có thể dẫn đến xung đột giữa các yêu cầu. Nguyễn Thị Minh Tuyền 64 Nhập môn CNPM
65. Cải tiến yêu cầu Initial Changed understanding understanding of problem of problem Initial Changed requirements requirements Time Nguyễn Thị Minh Tuyền 65 Nhập môn CNPM
66. Kế hoạch quản lý yêu cầu v Thiết lập mức độ chi tiết về quản lý yêu cầu. v Trong quá trình quản lý yêu cầu, cần lập kế hoạch cho: § Định danh yêu cầu Mỗi yêu cầu phải được đánh số duy nhất để có thể được tham chiếu từ các yêu cầu khác. § Một quy trình quản lý sự thay đổi Đây là một tập các hoạt động để đánh giá mức độ ảnh hưởng và chi phí của các thay đổi. § Các chính sách lần vết Những chính sách này định nghĩa mối quan hệ giữa các yêu cầu và giữa yêu cầu với thiết kế hệ thống. § Công cụ hỗ trợ Sử dụng các công cụ hỗ trợ cho công việc quản lý các thay đổi về yêu cầu. Nguyễn Thị Minh Tuyền 66 Nhập môn CNPM
67. Quy trình quản lý thay đổi yêu cầu Identified Revised problem Problem analysis and Change analysis Change requirements change specification and costing implementation Nguyễn Thị Minh Tuyền 67 Nhập môn CNPM
68. Quy trình quản lý thay đổi yêu cầu v Có 3 giai đoạn chính § Phân tích vấn đề và đặc tả thay đổi • Trong giai đoạn này, việc thay đổi và các vấn đề được phân tích để kiểm tra tính hợp lệ của nó. Việc phân tích này là để trả lời người đưa ra yêu cầu cho việc thay đổi để quyết định xem nên chấp nhận thay đổi hay nên quyết định hủy bỏ yêu cầu thay đổi. § Phân tích và ước lượng chi phí cho sự thay đổi • Dùng thông tin lần vết và những kiến thức tổng quát về yêu cầu hệ thống để đánh giá hiệu ứng của sự thay đổi. Một khi hoàn thành phân tích này, một quyết định sẽ được đưa ra để xem liệu có nên tiến hành thay đổi yêu cầu hay không. § Cài đặt thay đổi • Sửa tài liệu yêu cầu và tài liệu cài đặt và thiết kế hệ thống nếu cần. Trong trường hợp lý tưởng, tài liệu nên được tổ chức sao cho việc thay đổi được cài đặt dễ dàng. Nguyễn Thị Minh Tuyền 68 Nhập môn CNPM
69. Contents Yêu cầu chức năng và yêu cầu phi chức năng Đặc tả yêu cầu Các quy trình công nghệ yêu cầu Thu thập và phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu www.themegallery.co Tài liệu yêu cầu phầnm mềm Nguyễn Thị Minh Tuyền Nhập môn CNPM
70. Tài liệu yêu cầu phần mềm v Tài liệu yêu cầu phần mềm là phát biểu chính thức về những gì mà người phát triển hệ thống phải cài đặt. v Nên bao gồm cả định nghĩa yêu cầu người dùng và đặc tả yêu cầu hệ thống. v Đây không phải là tài liệu thiết kế, chỉ nên định nghĩa về cái gì hệ thống sẽ hỗ trợ hơn là đi vào chi tiết việc phải cài đặt như thế nào. Nguyễn Thị Minh Tuyền 70 Nhập môn CNPM
71. Ai sử dụng tài liệu yêu cầu? Specify the requirements and System read them to check that they customers meet their needs. Customers specify changes to the requirements. Use the requirements Managers document to plan a bid for the system and to plan the system development process. System Use the requirements to engineers understand what system is to be developed. System test Use the requirements to engineers develop validation tests for the system. System Use the requirements to maintenance understand the system and engineers the relationships between its parts. Nguyễn Thị Minh Tuyền 71 Nhập môn CNPM
72. Tài liệu yêu cầu v Thông tin trong tài liệu yêu cầu phụ thuộc vào loại hệ thống và phương pháp phát triển được sử dụng. v Hệ thống được phát triển dần dần thường sẽ chứa ít chi tiết trong tài liệu yêu cầu. v Các chuẩn về tài liệu yêu cầu được thiết kế sẵn, ví dụ như chuẩn IEEE. Các chuẩn này có thể áp dụng được cho các dự án công nghệ hệ thống lớn. Nguyễn Thị Minh Tuyền 72 Nhập môn CNPM
73. Cấu trúc của một tài liệu yêu cầu Chapter Description Preface This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. Introduction This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. Glossary This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader. User requirements Here, you describe the services provided for the user. The definition nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. System architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted. Nguyễn Thị Minh Tuyền 73 Nhập môn CNPM
74. Cấu trúc của một tài liệu yêu cầu Chapter Description System This should describe the functional and nonfunctional requirements in requirements more detail. If necessary, further detail may also be added to the specification nonfunctional requirements. Interfaces to other systems may be defined. System models This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. Appendices These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Index Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on. Nguyễn Thị Minh Tuyền 74 Nhập môn CNPM
75. Tổng kết v Có thể sử dụng một tập các kỹ thuật để thu thập yêu cầu bao gồm việc phỏng vấn, xây dựng kịch bản, vẽ use case. v Thẩm định yêu cầu là quy trình kiểm tra yêu cầu về tính hợp lệ, tính nhất quán, tính hoàn chỉnh, tính thực tế và tính có thể kiểm định được. v Sự thay đổi về công việc, tổ chức và kỹ thuật dẫn đến sự thay đổi về yêu cầu của một hệ thống phần mềm. Quản trị yêu cầu là quy trình quản lý và điều khiển các thay đổi này. v Tài liệu yêu cầu phần mềm là phát biểu được chấp nhận của yêu cầu hệ thống. Tài liệu này được tổ chức sao cho cả khách hàng và người phát triển có thể sử dụng được. Nguyễn Thị Minh Tuyền 75 Nhập môn CNPM
76. Câu hỏi? Nguyễn Thị Minh Tuyền Nhập môn CNPM