Chương 1:

1. Chương 1: TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM

2. Nội dung • Yêu cầu phần mềm là gì? • Lợi điểm khi thu thập yêu cầu đầy đủ • Các đặc tính của yêu cầu phần mềm • Yêu cầu phần mềm từ quan điểm người dùng • Vai trò và chức năng của người phân tích yêu cầu

3. Tại sao YCPM lại quan trọng • Trước đây, nhiều sản phẩm thành công mà không cần có sự tham gia của các chuyên gia trong việc thu nhận và quản lý yêu cầu. • Nhưng ngày nay thì requirements engineering (RE) lại trở nên vô cùng quan trọng. • Tại sao?

4. Tại sao • Sản phẩm phát triển với tốc độ chóng mặt • Sự thay đổi không ngừng của công nghệ • Gia công phẩn mềm đã làm thay đổi nhanh chóng chu kỳ phát triển phần mềm. • Việc phát triển phần mềm thường liên kết chặt chẽ với nghiệp vụ.

5. 1.1. Yêu cầu phần mềm là gì? Theo IEEE 1990, yêu cầu phần mềm là: • Một điều kiện, năng lực cần thiết cho người dùng để giải quyết một vấn đề hoặc đạt được một mục tiêu. • Một điều kiện hoặc năng lực đó phải được đáp ứng hoặc sở hữu bởi một thành phần hệ thống hoặc hệ thống để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật, hoặc tài liệu chính thức áp đặt khác. • Một tài liệu được đại diện của một điều kiện hoặc năng lực như trong 1 hoặc 2.

6. Yêu cầu phần mềm là gì? • Requirements là đặc tả của cái gì cần được thực thi, mô tả hệ thống sẽ hoạt động như thế nào hay hệ thống có thuộc tính gì. • Yêu cầu cũng có thể là các ràng buộc trong quá trình phát triển hệ thống.

7. 1.2. Lợi điểm khi thu thập yêu cầu đầy đủ • Giảm rework không cần thiết • Sự quan tâm của khách hàng giảm được khoảng cáchgiữa cái người dùng cần và cái developer tạo ra. • Thu thập yêu cầu cho phép đội phát triển hiểu tốt hơn người dùng và thị trường • Lôi cuốn người dùng tham gia sẽ xây dựng được niềm tin và lòng trung thành của khách hàng • Có thể tránh viết những đoạn mã thừa khi nắm vững nhiệm vụ của người dùng

8. Những lợi ích không định lượng • Lỗi về yêu cầu ít hơn • Giảm được việc phải làm lại trong bước phát triển • Ít hơn các tính năng không cần thiết • Hạ thấp chi phí mở rộng • Quá trình phát triển hệ thống sẽ nhanh hơn

9. Những lợi ích không định lượng (tt) • Giảm bớt các giao tiếp sai lầm với khách hàng • Hạn chế phạm vi hệ thống bị phình rộng • Hạn chế được những hỗn độn dự án • Các ước tính về hệ thống chính xác hơn • Mức độ thỏa mãn khách hàng và thành viên của đội sẽ cao hơn

10. 1.3. Đặc trưng của yêu cầu • Feasible (Khả thi) • Valid (Hợp lệ) • Unambiguous (rõ ràng) • Verifiable (kiểm chứng) • Modifiable (sửa đổi) • Consistent (nhất quán) • Complete (hoàn thành) • Traceable (có thể theo dõi)

11. 1.4. Yêu cầu phần mềm từ quan điểm người dùng • Các hoạt động đầu tiên của thu nhận yêu cầu • Phân tích thông tin thị trường, stakeholder, và nhu cầu của người dùng để suy dẫn các yêu cầu chức năng và phi chức năng. • Hiểu được ảnh hưởng của các yêu cầu đến nghiệp vụ • Hợp nhất các yêu cầu này lại để hoàn thành các đặc tả yêu cầu và hệ thống

12. Người dùng (hay khách hàng) là ai? • Khách hàng (customer) là một cá nhân hay 1 tổ chức mong muốn hoặc trực tiếp hoặc gián tiếp có lợi từ sản phẩm. • Hai loại khách hàng phần mềm (Software customer) • Khách hàng ở cấp quản lý • NSD cuối cùng

13. Khách hàng ở cấp quản lý • Là loại khách hàng trả tiền hay tài trợ dự án phần mềm. • Có nhiệm vụ xác định yêu cầu nghiệp vụ (business requirement)

14. Người sử dụng cuối cùng • Bao gồm tất cả những ai sẽ thực sự sử dụng sản phẩm dù trực tiếp hay gián tiếp. • Users có thể mô tả nhiệm vụ mà họ cần thực thi với sản phẩm và chất lượng mà họ mong đợi từ sản phẩm

15. Một số những lưu ý • Thường xung đột (conflict) có thể xuất hiện giữa yêu cầu nghiệp vụ và yêu cầu người dùng. • Yêu cầu nghiệp vụ phản ánh chiến lược của tổ chức và các hạn chế về tài chính mà người dùng có thể không nhìn thấy được  người dùng thất vọng về hệ thống mới. • Việc giao tiếp rõ ràng về mục tiêu và các ràng buộc của dự án có thể làm dịu đi các bức xúc của người dùng. • Nhà phân tích nên làm việc với các đại diện chính của người dùng và các nhà tài trợ để hòa giải các xung đột.

16. Stakeholder • Customers • Users • Requirements analysts • Developers • Testers • Documentation writers • Project managers • Legal staff – nhân viên pháp lý • Manufacturing people – nhà sản xuất • Sales, marketing, field support, help desk, …

17. 1.5. Vai trò và chức năng của người phân tích yêu cầu • Các từ đồng nghĩa với Requirements analyst : • Systems analyst • Requirements engineer • Requirements manager • Analyst.

18. Người phân tích yêu cầu • Là người có nhiệm vụ cơ bản là thu thập, phân tích, ghi chép và kiểm tra nhu cầu của stakeholders. • Analyst như 1 cầu nối giữa cộng đồng khách hàng và đội phát triển phần mềm. • Analyst đóng vai trò trung tâm trong việc thu thập và phổ biến thông tin, còn project manager giữ vai trò lãnh đạo trong việc truyên đạt thông tin dự án.

19. Người phân tích yêu cầu

20. Vai trò của người phân tích yêu cầu • Analyst là người chuyển (translator) các suy nghĩ của người nào đó thành đặc tả yêu cầu. • Analyst là người phản ánh (reflector) thông tin đến các stakeholder, giúp các stakeholder tìm thấy sự khác nhau giữa cái họ muốn và cái họ thực sự cần.

21. Nhiệm vụ của người phân tích yêu cầu • Analyst trước tiên phải • Hiểu mục tiêu của người dùng • Sau đó xác định các yêu cầu chức năng, cho phép người quản lý dự án làm các ước tính, các developers thiết kế, xây dựng và kiểm định sản phẩm. • Xác định các yêu cầu kinh doanh • Xác định các bên liên quan đến dự án ( stakeholders) và người sử dụng

22. Nhiệm vụ của người phân tích yêu cầu (tt) • Gợi ý các yêu cầu • Viết các đặc tả yêu cầu • Mẫu yêu cầu • Hướng dẫn các yêu cầu xác nhận • Tạo điều kiện cho các yêu cầu ưu tiên • Quản lý yêu cầu

23. Kỹ năng của nhà phân tích • Kỹ năng nghe • Kỹ năng phỏng vấn và đặt câu hỏi • Kỹ năng phân tích • Tạo thuận lợi cho các kỹ năng • Kỹ năng quan sát • Kỹ năng viết • Kỹ năng tổ chức. • Mô hình hóa các kỹ năng • Kỹ năng giao tiếp • Sáng tạo

24. Bài tập • Bạn là một người quản lý sản phẩm cho một công ty máy công cụ. Giám đốc đã yêu cầu bạn để phát triển một máy cắt mới để cắt vải cho trang phục thời trang của tất cả các kích cỡ và các mẫu. Máy sẽ được bán cho các nhà sản xuất quần áo trên thế giới: a.Các bên liên quan của bạn là ai? b. Làm thế nào bạn sẽ phân tích và xác nhận danh sách các bên liên quan của bạn?