Chương 2

1. Chương 2 PHÁT TRIỂN YÊU CẦU PHẦN MỀM Xây dựng tầm nhìn và phạm vi dự án Establishing the Product Vision and Project Scope BM HTTT - Khoa CNTT - HUI

2. Nội dung • Xác định những người liên quan (stakeholder) • Hiểu nhu cầu khách hàng • Thu nhận yêu cầu từ khách hàng • Phân biệt goal và requirement • Khái niệm Product Vision và Project Scope • Xác định boundary bằng phương pháp soft system • Xác định yêu cầu chức năng bằng phương pháp hard system • Lược đồ ngữ cảnh BM HTTT - Khoa CNTT - HUI

3. Qui Trình BM HTTT - Khoa CNTT - HUI

4. Stakeholder là gì • Stakeholder: An individual, group of people, organisation or other entity that has a direct or indirect interest (or stake) in a system. • A stakeholder’s interest in a system may arise from using the system, benefiting from the system (in terms of revenue or other advantage), being disadvantaged by the system (in terms, for instance, of cost or potential harm), being responsible for the system, or otherwise being affected by it. • Stakeholders are legitimate sources of requirements.

5. Stakeholder • Customers • Users • Requirements analysts • Developers • Testers • Documentation writers • Project managers • Legal staff – nhóm người làm việc hợp pháp • Manufacturing people – người sản xuất • Sales, marketing, field support, help desk, …

6. Xác định những người liên quan • Stakeholder: • Bao gồm những người, tổ chức mà là một phần của môitrường hệ thống. Hệ thống cung cấp cho họ những lợi ích và họ có tầm quan trọng trong hệ thống • Stakeholder: • Users, operators, bill payers, owners, regulatory agencies, victims, sponsors, maintainers, architects, managers, customers, surrogate customers … BM HTTT - Khoa CNTT - HUI

7. Các stakeholder của Boeing 787 • Users: passengers that fly on the airplane • Operators: fight crews and mechanics • Bill payers: airline companies • Owners: stockholders of these companies • Regulators: FAA • Sponsor: corporate headquarters • Maintenance: ground crew • Victims: people living near the airports… BM HTTT - Khoa CNTT - HUI

8. Cần quan tâm tới qui trình BM HTTT - Khoa CNTT - HUI

9. Các stakeholder khác • Users and operators: employees in the manufacturing plant • Bill payer: Boeing • Owner: stockholders of Boeing • Regulators: OSHA • Victims: physically and emotionally injured workers • Air traffic control tower BM HTTT - Khoa CNTT - HUI

10. Stakeholder của hệ thống ATM • Khách hàng của ngân hàng • Đại diện của các ngân hàng khác • Người quản lý ngân hàng • Nhân viên thu tiền • Người quản trị CSDL • Người quản lý bảo mật • Kỹ sư bảo trì phần cứng và phần mềm • Những người điều phối ngân hàng… BM HTTT - Khoa CNTT - HUI

11. Stakeholder • Stakeholder không rõ những gì họ thật sự muốn • Stakeholder diễn đạt yêu cầu theo những thuật ngữ riêng của họ • Những stakeholder có thể có những yêu cầu tranh chấp • Nhân tố quyền lực và tổ chức ảnh hưởng tới yêu cầu hệ thống • Những yêu cầu có thể thay đổi trong quá trình phân tích, có thể xuất hiện những nhân tố mới, những thay đổi về môi trường nghiệp vụ BM HTTT - Khoa CNTT - HUI

12. Các hoạt động đầu tiên của requirements engineering • 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

13. Hiểu nhu cầu của khách hàng • Nhà phân tích phải ở trong môi trường của kháchhàng để khám phá các chi tiết và giải thích cho họ • Thiết kế mềm dẻo và tạo mẫu nhanh là những phương tiện xác định yêu cầu của khách hàng BM HTTT - Khoa CNTT - HUI

14. Phát biểu của khách hàng BM HTTT - Khoa CNTT - HUI

15. Khách hàng là ai? • Khách hàng là một cá nhân hay 1 tổ chức mong muốn 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: • Khách hàng cấp quản lý (management level) • Người dùng cuối (end user) BM HTTT - Khoa CNTT - HUI

16. Khách hàng ở cấp quản lý • Thường là những khách hàng trả tiền hay tài trợ dự án phần mềm. • Khách hàng ở cấp quản lý có nhiệm vụ xác định yêu cầu nghiệp vụ • Mô tả mục tiêu nghiệp vụ mà khách hàng, công ty hay các stakeholder muốn hoàn thành. • Xác lập các thành phần chính cho phần còn lại của dự án • Các yêu cầu nghiệp vụ không đủ chi tiết để giúp các nhà phát triển biết phải xây dựng cụ thể cái gì BM HTTT - Khoa CNTT - HUI

17. Khách hàng là người dùng cuối • Bao gồm tất cả những ai sẽ thực sự sử dụng sản phẩm • Người dùng có thể mô tả việc dùng sản phẩm chocông việc của họ và những mong đợi về chấtlượng từ sản phẩm BM HTTT - Khoa CNTT - HUI

18. Đặc tính của khách hàng • Thường cả hai loại khách hàng này đều cho rằnghọ không có nhiều thời gian để làm việc với các nhà phân tích yêu cầu. • Đôi lúc họ nghĩ là nhà phân tích sẽ hình dung ra được cái người dùng cần mà không cần phải thảo luận với nhau. BM HTTT - Khoa CNTT - HUI

19. Đặc tính của khách hàng • Thường xuất hiện những xung đột giữa yêu cầunghiệ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 ràng buộc về tài chính mà người dùngcó thể không nhìn thấy được người dùngthường thất vọng về hệ thống mới, họnghĩ mình như “con tốt” của 1 tương lai khôngnhư ý… • Nhà phân tích nên làm việc với các đại diện chínhcủa người dùng và các nhà tài trợ để hòa giải cácxung đột. BM HTTT - Khoa CNTT - HUI

20. Quanhệkháchhàngvànhàpháttriển • Thường có sự mâu thuẫn giữa người phát triển và khách hàng • Người quản lý thường ưu tiên cho việc phù hợp với lịch làm việc của chính họ BM HTTT - Khoa CNTT - HUI

21. Chất lượng dưới nhiều góc độ BM HTTT - Khoa CNTT - HUI

22. Bill of Rights for Software Customers • Expect analysts to speak your language. • Expect analysts to learn about your business and your objectives for the system. • Have analysts explain all work products created from the requirements process. • Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product. • Describe characteristics of the product that will make it easy and enjoyable to use... BM HTTT - Khoa CNTT - HUI

23. Khách hàng với Thu nhận yêu cầu • Xác định tầm quan trọng của quan điểm khách hàng • Là một kỹ thuật đòi hỏi nhiều kiến thức BM HTTT - Khoa CNTT - HUI

24. Các bước tìm hiểu khách hàng • Nhận biết các lớp người dùng khác nhau • Xác định các nguồn của yêu cầu người dùng. • Chọn và làm việc với cá nhân tiêu biểu cho mỗi lớp người dùng hay nhóm stakeholder khác nhau. • Thỏa thuận các yêu cầu với người ra quyết định của dự án. BM HTTT - Khoa CNTT - HUI

25. Các khó khăn khi thu thập • Việc không phù hợp giữa sản phẩm mà khách hàng mong đợi và sản phẩm mà nhà phát triểnxây dựng thường do: • Thiếu sự quan tâm của khách hàng. • Khách hàng thường không biết chính xác cái họ thực sự cần • Nhà phân tích yêu cầu cần thu thập user input, phân tích và xác định rõ cần xây dựng cái gì để giúp người dùng hoàn thành công viêc̣ của họ. BM HTTT - Khoa CNTT - HUI

26. Managing the Customer Relationship • Cầnphảibảođảmđượcsựhợptáccủakháchhàngđểcóthểthunhậnđượcchuyênmônnghiệpvụ (domain expertise) • Vídụ: nếu 1 dựáncólịchbiểucốđịnhvàmốiquanhệvớikháchhàngkhôngđượctốt việctiếpnhậnvềchuyênmônbịhạnchế, dẫnđếnkếtthúcdựánbịquáhạn It is out experience that constant communication with the customer BM HTTT - Khoa CNTT - HUI

27. Phânloạiyêucầucủakháchhàng • Không nên mong đợi khách hàng sẽ cung cấp 1 danh mục có thứ tự, hoàn chỉnh và đầy đủ mọi nhu cầu của họ. • Analysts cần phải phân loại vo số thông tin lộn xộn mà họ thu thập được thành các loại khác nhau sao cho có thể ghi nhận và sử dụng được một cách hiệu quả. BM HTTT - Khoa CNTT - HUI

28. Chínloạiyêucầucủakháchhàng BM HTTT - Khoa CNTT - HUI

29. Nguyên tắc khi thu thập thông tin khách hàng • Tránh làm phiền đến đời sống và công việc thường ngày của khách hàng • Chuẩn xác tối đa, phân biệt rõ thông tin thật giả • Nắm bắt điểm máu chốt, loại bỏ thông tin không cần thiết • Không được tùy tiện để lộ thông tin của khách hàng ra ngoài.

30. Nhà phân tích yêu cầu - Requirements analyst • Các từ đồng nghĩa: • Nhà phân tích yêu cầu (Requirements analyst) • Nhà phân tích hệ thống (Systems analyst) • Kỹ sư yêu cầu (Requirements engineer) • Nhà quản lý yêu cầu (Requirements manager) • Nhà phân tích (Analyst)Systems analyst

31. Vai trò của analyst • Nhà phân tích là người chuyển các ý tưởng thànhnhững đặc tả yêu cầu. • Nhà phân tích là người có quan hệ truyền thông với 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 • 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 các stakeholder • Họ như là một cầu nối giữa cộng đồng kháchhàng và đội phát triển phần mềm. • Nhà phân tích đóng vai trò trung tâm trong việcthu thập và phổ biến thông tin, còn người quản lýdự án (project manager) giữ vai trò lãnh đạotrong việc truyền đạt thông tin dự án

32. Requirements analyst

33. Nhiệm vụ của nhà phân tích • 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. • Thực hiện nhiệm vụ với thời gian tiêu tốn cao (lặp) nhưng nếu không đầu tư thời gian thì có thểdẫn đến hậu quả: phải thực hiện lại, trễ hạn, khách hàng không thỏa mãn BM HTTT - Khoa CNTT - HUI

34. Nhiệm vụ của Requirements analyst • Xác định yêu cầu nghiệp vụ - Define business requirements.   • Xác định các stakeholder và các lớp người dùng-dentify project stakeholders and user classes.   • Rút ra những yêu cầu - Elicit requirements • Viết đặc tả yêu cầu-Write requirements specifications • Mô hình hóa yêu cầu-Model the requirements • Điều hành việc đánh giá yêu cầu-Lead requirements validation • Phân loại ưu tiên các yêu cầu- Facilitate requirements prioritization • Quản lý yêu cầu - Manage requirements Assignment ??

35. Kỹ năng của nhà phân tích • Kỹ năng lắng nghe - Listening skill • Kỹ năng phỏng vấn - Interviewing and questioning skill • Kỹ năng phân tích - Analytical skill, • Kỹ năng điều khiển - Facilitation skills.   • Kỹ năng quan sát - Observational skills. • Kỹ năng viết - Writing skills • Kỹ năng tổ chức - Organizational skills • Kỹ năng mô hình hóa - Modeling skills • Kỹ năng giao tiếp - Interpersonal skills • Tính sáng tạo - Creativity • Assignment ??

36. Phân loại người dùng • Dựa vào các yếu tố sau: • Mức độ thường xuyên người dùng sử dụng sản phẩm • Kinh nghiệm về miền ứng dụng của họ, sự thành thạo về hệ thống máy tính • Các tính năng mà người dùng sử dụng • Các tác vụ để hỗ trợ xử lý nghiệp vụ • Quyền truy xuất và cấp độ bảo mật BM HTTT - Khoa CNTT - HUI

37. Phân cấp người dùng BM HTTT - Khoa CNTT - HUI

38. Kinhnghiệmphânloạingườidùng • Nên phân loại người dùng sớm để có thể thu thập yêu cầu từ đại diện của mỗi lớp người dùng. • Không nên e ngại nếu lúc đầu có quá nhiều lớp người dùng • Không nên bỏ qua bất kỳ lớp người dùng nào vì sau này có thể sẽ phải rework • Ghép chung các lớp người dùng nào có yêu cầu tương tự nhau. Nên giảm xuống sao cho không quá 15 lớp người dùng khác nhau. BM HTTT Khoa CNTT - HUI

39. Tàiliệungườidùng • Ghi chép các lớp người dùng, tính cách, trách nhiệm, và địa điểm làm việc vào tài liệu SRS • Giúp đội phát triển xếp loại độ ưu tiên các yêu cầu • Giúp các tester xây dựng cách sử dụng hệ thống (usage profile for the system) và có thể lập kế hoạch cho việc kiểm thử BM HTTT Khoa CNTT - HUI

40. Cáclớpngườidùngtronghệthống Chemical tracking BM HTTT Khoa CNTT - HUI

41. Tìmđạidiệnngườidùng • Mỗi loại dự án đều cần có đại diện người dùng thích hợp để cung cấp tiếng nói chung cho nhóm người dùng đó. • Người đại diện không chỉ tham gia trong giai đoạn thu thập yêu cầu mà trong suốt chu kỳ phát triển dự án BM HTTT Khoa CNTT - HUI

42. Đạidiệnlớpngườidùng(user representatives) • Each user class needs to be represented • Đối với ứng dụng của công ty: dễ dàng xác định người dùng thực sự cho mỗi lớp người dùng. • Ví dụ: chọn Fred là kỹ sư hóa cho lớp chelmistt • Đối với phần mềm thương mại (commericial software): chỉ có thể có được người dùng thực sự sau khi phát hành phiên bản chạy thử (beta-testing) hay đầu tiên • Nên thiết lập nhóm người tình nguyện (focus group) từ những người dùng phần mềm của mình hay phần mềm của đối thủ BM HTTT Khoa CNTT - HUI

43. Focus Group • Phải đảm bảo nhóm tình nguyện đại diện cho loại người dùng mà nhu cầu của họ giúp ta phát triển hệ thống. • Nên bao gồm cả người dùng thành thạo và người dùng ít kinh nghiệm • Nếu nhóm tình nguyện chỉ toàn những người mơ mộng (blue –sky thinkers) không thực tế thì có thể sẽ thu được những yêu cầu phức tạp mà người dùng bình thường không hề nghĩ đến BM HTTT Khoa CNTT - HUI

44. Người dùng tiêu biểu PC • PC (Product champion) dùng để chỉ những thànhviên chính trong cộng đồng người dùng cung cấp cho dự án các yêu cầu. • Cs (Champions) là các người dùng thực sự, khôngphải là người đại diện như nhà tài trợ, nhân viêntiếp thị, người quản lý … BM HTTT - Khoa CNTT - HUI

45. VaitròcủaProductChampiom(PC) • PC (Product champion) thu thập yêu cầu từ các thành viên khác thuộc lớp người dùng mà họ đại diện và hợp nhất lại yêu cầu không giống nhau. • Phát triển yêu cầu là trách nhiệm chung của nhà phân tích và khách hàng đã được chọn, mặc dù nhà phân tích sẽ là người viết yêu cầu. BM HTTT - Khoa CNTT - HUI

46. Một PC tốt • Có cái nhìn rõ ràng về hệ thống mới và ủng hộ hệ thống vì họ thấy được lợi ích dành cho họ từ hệ thống mới này. • Là người cởi mở và được đồng nghiệp tín nhiệm. • Là người hiểu biết thấu đáo về nghiệp vụ và môitrường hoạt động của hệ thống. • Nhận thức được tầm quan trọng của họ đối với sự thành công của dự án. BM HTTT - Khoa CNTT - HUI

47. PC bên ngoài • Khi phát triển phần mềm thương mại, rất khó tìm PC từ bên ngoài. • Nếu có quan hệ công việc gần gũi với 1 số công ty, một số người thể sẵn lòng tham gia vào quá trình thu thập yêu cầu. • Nên khích lệ bằng kinh tế cho các PC bên ngoài như giảm giá sản phẩm hay trả tiền theo giờ khi họ tham gia công việc BM HTTT - Khoa CNTT - HUI

48. Quyền hạn của product champion • Phương pháp dùng PC chỉ tốt khi mỗi champion có quyền đưa ra các quyết định đại diện cho lớp của minh • Nếu quyết định của champion luôn bị gạt bỏ bởi managers hay SW group thì thời gian và thiện chí của họ sẽ bị lãng phí. • Nhưng champion cũng nên nhớ rằng họ không phải là khách hàng duy nhất BM HTTT - Khoa CNTT - HUI

49. Hạn chế tử PC • Làm thế nào để tránh chỉ nghe yêu cầu từ CP mà bỏ qua các nhu cầu từ các khách hàng khác. • Nếu khách hàng đa dạng thì nên trước tiên cầnnhận biết yêu cầu cơ bản chung cho mọi kháchhàng, sau đó xác định các yêu cầu khác từ cácloại người dùng khác, từ bộ phận tiếp thị, từ khách hàng riêng lẻ,… BM HTTT - Khoa CNTT - HUI

50. Hệ thống theo dõi hóa chất(Chemical Tracking) BM HTTT - Khoa CNTT - HUI