Chapter 3: Thu thập yêu cầu

1. Chapter 3: Thu thậpyêucầu Requirements Elicitation Or Requirement gathering BM HTTT Khoa CNTT - HUI

2. Nội dung • Thu thập yêu cầu (Requirement elicitation) là gì? • Các kỹ thuật thu thập yêu cầu • Chọn lựa kỹ thuật thu thập yêu cầu • Quy tắc nghiệp vụ và chính sách • Quản lý mối quan hệ khách hàng BM HTTT Khoa CNTT - HUI

3. A major aspect of requirements engineering is the elicitation of requirements from the customer. It’s not just a simple matter of writing down what the customer says he wants !!! BM HTTT Khoa CNTT - HUI

4. Requirement elicitation • Elicitation là quá trình xác định yêu cầu và làm giảm sự khác biệt giữa các nhóm có liên quan để rút ra các yêu cầu đáp ứng được nhu cầu của tổ chức hay dự án trong khi vẫn giữ được các ràng buộc. • Có rất nhiều kỹ thuâṭ elicitation khác nhau BM HTTT Khoa CNTT - HUI

5. Phân biệt giữa elicitation và analysis • Elicitation là sự tương tác với stakeholders để nắm bắt được nhu cầu của họ. • Analysis là tinh chỉnh (refinement) nhu cầu của stakeholder thành các đặc tả sản phẩm chính thức. BM HTTT Khoa CNTT - HUI

6. Tầm quan trọng • Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication-intensive aspect of software development. • Elicitation chỉ có thể thành công thông qua mối quan hệ hợp tác giữa customer và đội development . BM HTTT Khoa CNTT - HUI

7. Mô hình song song của quy trình yêu cầu BM HTTT Khoa CNTT - HUI

8. Why is it difficult to elicit requirements? • Customers and users often do not understand how software design and development works, and cannot specify their own software requirements in a way that works for developers. • Software developers often do not understand the problems and needs of customers and users well enough to specify the requirements on their behalf. BM HTTT Khoa CNTT - HUI

9. Vấn đề về người dùng và khách hàng • Người dùng không hiểu họ muốn gì • Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa • Người dùng nhất định đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển đã được hoạch định xong. • Mức độ giao tiếp với người dùng là thấp • Người dùng thường không tham gia các đợt thẩm định hoặc không thể tham gia. • Người dùng không hiểu kỹ thuật • Người dùng không hiểu quy trình phát triển. BM HTTT Khoa CNTT - HUI

10. Các hoạt động của yêu cầu BM HTTT Khoa CNTT - HUI

11. Trướckhithuthậpyêucầu • Đã viết “vision and scope” • Vẽ lược đồ ngữ cảnh (context diagram) • Xác định stakeholder • Xác định người dùng và đại diện người dùng BM HTTT Khoa CNTT - HUI

12. Lượcđồngữcảnh • Phạm vi (scope) dùng để xác định đường biên (boundary) và các mối nối kết giữa hệ thống đang phát triển và mọi thứ khác bên ngoài. • Lược đồ ngữ cảnh được dùng để minh họa đường biên này. BM HTTT Khoa CNTT - HUI

13. Lượcđồngữcảnh • Là mức 0 (top level) của lược đồ dòng dữ liệu (data flow diagram) theo cách phân tích hướng cấu trúc • Được dùng rộng rãi cho bất kỳ phương pháp phát triển nào • Có thể nằm trong tài liệu vision, trong phục vụ đặc tả yêu cầu (SRS) BM HTTT Khoa CNTT - HUI

14. Lượcđồngữcảnh BM HTTT Khoa CNTT - HUI

15. Keeping Scope in Focus • Scope change isn’t a bad thing if it helps you steer the project toward satisfying evolving customer needs • Khi có ai đó kiến nghị 1 yêu cầu mới thì RA phải làm gì?? • Cần xem xét yêu cầu mới có nằm trong scope hay không?? • Nếu yêu cầu kiến nghị nằm trong scope thì có thể hợp nhất yêu cầu mới vào dự án nếu có độ ưu tiên cao so với yêu cầu hiện cócó thể phải trì hoãn hay hủy bỏ các yêu cầu hiện tại BM HTTT Khoa CNTT - HUI

16. Keeping Scope in Focus • Nếu yêu cầu kiến nghị nằm ngoài scope thì có thể có 1 trong các phương án sau: • Nên đưa vào phiên bản sau hay trong dự án khác. • Scope của dự án có thể thay đổi để đáp ứng yêu cầu mới  cần có phản hồi từ phía người dùng và cần cập nhật lại tài liệu vision and scope (nếu đã phê duyệt thì cần giám sát mọi thay đổi) • Khi phạm vi dự án tăng, thường phải thỏa thuận lại ngân sách(budget), tài nguyên (resource), thời gian (schedule) BM HTTT Khoa CNTT - HUI

17. XácđịnhStakeHolder • Identify the different classes of users for your product • Identify source of user requeriments • Select and work with individual who represent each user class and other stakeholder groups • Agree on who the requirements decision makers are for you project • It’s not enough simply to ask a few customers what they want and then start coding. If the developers build exactly what customers initially request, they’ll probably have to build it again because customers often don’t know what they really need. BM HTTT Khoa CNTT - HUI

18. XácđịnhStakeHolder • Những tính chất mà người dùng đưa ra lúc đầu thường không đủ để trở thành chức năng của hệ thống. • Để có cái nhìn chính xác hơn nhu cầu người dùng, RA phải tập hợp các yêu cầu người dùng, phân tích và xác định chỉ nên xây dựng cái gì để người dùng làm tốt được công việc của họ. BM HTTT Khoa CNTT - HUI

19. Phân loại StakeHolder • Customers (người tài trợ dự án hay mua sản phẩm) • Users (người tương tác trực tiếp hay gián tiếp sản phẩm) • Requiremements analysts (người viết yêu cầu và làm việc với đội phát triển phần mềm) • Developers (người thiết kế, thực thi và bảo trì sản phẩm) • Testers (người kiểm tra xem sản phẩm có thực thi như mong muốn) BM HTTT Khoa CNTT - HUI

20. Phân loại StakeHolder • Documentation writers (người tạo ra sổ tay người dùng, hệ thống trợ giúp) • Project managers (người lập kế hoạch cho dự án, quản lý đội phát triển phần mềm) • Legal staff (người bảo đảm sản phẩm phù hợp với luật và quy chế) • Manaufacturing people (người phải xây dựng sản phẩm có chứa phần mềm) • Sales, marketing, field support, help desk, và những người khác sẽ làm việc với sản phẩm và khách hàng. BM HTTT Khoa CNTT - HUI

21. Các kỹ thuật thu thập yêu cầu • Document Sampling • Interviewing • Survey and observation • Questionaires • Workshop and Brainstorming • JAD (Joint Application Development) sessions Ba kỹ thuậtphổ biếnnhất là Document sampling, interviewing và questionaires BM HTTT Khoa CNTT - HUI

22. Các kỹ thuật thu thập yêu cầu BM HTTT Khoa CNTT - HUI

23. Các kỹ thuật thu thập yêu cầu • Assignment 12: Document Sampling • Nhóm??? • Assignment 13: Questionaires BM HTTT Khoa CNTT - HUI

24. Interviewing • Là kỹ thuật trực tiếp và đơn giản • Phỏng vấn để thu nhận từ các cá thể thao tác và các vấn đề trong hệ thống hiện hành, chính sách, nhu cầu mong muốn trong hệ thống mới. • Câu hỏi context-free có thể giúp hoàn thành các phỏng vấn bias-free interviews • Tập hợp lại 1 số nhu cầu chung sẽ tạo “requirements repository”để dùng trong suốt dự án • Questionnaire không thể thay thế cho interview. BM HTTT Khoa CNTT - HUI

25. Interviews • Interview cá nhân hay nhómcácngườidùng là nguồnthuthậpyêucầukiềutruyếnthốngchocả sảnphẩmthươngmạicũngnhưcáchệ thốngthông tin. • Tìmhiểucáchnghĩ củangườidùngkhi họ trìnhbàycácyêucầu, rútracácquyếtđịnh có tính logic củangườidùng. Để mô tả quá trìnhđưaracácquyếtđịnh logic có thể dùng flowchart và câyquyếtđịnh (decision tree) bảođảmmọingườihiểuđượctạisaohệ thốngphảithựchiệncácchứcnăngnày. • Đôikhicácyêucầucủangườidùngphảnánhcácquytrìnhnghiệp vụ đã lỗithời hay khônghiệu quả nữavà khôngnênđưavàohệ thốngmới. BM HTTT Khoa CNTT - HUI

26. Một số hướng dẫn để phỏng vấn thành công BM HTTT Khoa CNTT - HUI

27. Interview: Context free question • Là câu hỏi có thể dùng cho bất kỳ dự án nào đang khảo sát. • Là các câu hỏi chung về bản chất của dự án và môi trường mà sản phẩm sẽ được dùng. • Được dùng trong mỗi giai đoạn khác nhau của cuộc phỏng vấn. BM HTTT Khoa CNTT - HUI

28. Các dạng câu hỏi context free • Opening Questions: khibắtđầuphỏngvấn, câuhỏi context free sẽ giúpkhởiđầucuộcphỏngvấnvà vượt qua đượccáclúngtúng ban đầu. • Redirection: có thể đượcdùngđể chuyểnhướngphỏngvấnkhinội dung cuộcđốithoạirangoàichủ đề hay quá sâukhôngcầnthiết, đưacuộcđốithoạivề lại vị trí trunglậpđể hướngđếnchủ đề mongmuốn. • Closing: dùngđể kếtthúccuộcphỏngvấn “Is there anything else you would like to tell me?”  chongườiđượcphỏngvấn (interviewee) cơhộiđượcchủ độngvà chia xẻ̃ các thông tin khác. BM HTTT Khoa CNTT - HUI

29. Các dạng câu hỏi BM HTTT Khoa CNTT - HUI

30. Làmthế nàođề thựchiện interview • Phải chuẩn bị một danh sách các câu hỏi context free trước khi phỏng vấn. Có thể đặt cùng 1 hay 2 câu hỏi cho người được phỏng vấn (interviewee) để tìm ra điểm khác biệt. • Thông qua câu hỏi context free để giúp người tham gia phỏng vấn có hiểu biết chung • Không bận tâm vào câu trả lời “right/wrong”. Nhiều câu hỏi dùng gây ấn tượng hơn là để thu nhận dữ liệu, dùng để thu thập chi tiết hơn yêu cầu đang khảo sát. BM HTTT Khoa CNTT - HUI

31. Các chiến lược phỏng vấn • Top-down: bắt đầu bằng các câu hỏi tổng quát, tiếp đến là các câu hỏi cụ thể • Bottom-up: ngược lại BM HTTT Khoa CNTT - HUI

32. Interview: Show time Nên dành thời gian để: • Establish Customer or User Profile • Assessing the Problem • Understanding the User Environment • Recap the Understanding • Analyst’s Inputs on Customer’s Problems • Assessing Your Solution (if applicable) BM HTTT Khoa CNTT - HUI

33. Questionaries Thường dùng khi cần thu thập thông tin và ý kiến từ số đông. BM HTTT Khoa CNTT - HUI

34. So sánh giữa Questionaries và Interview BM HTTT Khoa CNTT - HUI

35. Chọn người tham gia phiếu điều tra • Chọn người đại diện cho mỗi nhóm • Không phải ai nhận phiếu điều tra cũng đều hoàn tất nó, trung bình chỉ thu lại được 30-50% phiếu điều tra bằng giấy hay email, chỉ 5 – 30% phiếu điều tra qua Web BM HTTT Khoa CNTT - HUI

36. Thiết kế phiếu điều tra • Thường dùng câu hỏi dạng closed-ended • Câu hỏi phải được viết rõ ràng và không nên chừa quá nhiều khoảng trống dễ gây hiểu nhầm BM HTTT Khoa CNTT - HUI

37. Thiết kế phiếu điều tra • Hai dạng câu hỏi: • Hướng ý kiến (opinion): thường yêu cầu người trả lời phải cho biết mức độ mà họ đồng tình hay phản đối. • Hướng số liệu (fact – oriented): câu trả lời là một giá trị cụ thể BM HTTT Khoa CNTT - HUI

38. Thiết kế phiếu điều tra • Phải hiểu rõ thông tin thu thập được từ nhiều điều tra sẽ được phân tích và dùng như thế nào, tránh tình trạng phân phối điều tra xong rồi mới phát hiện điều tra có vấn đề. • Các câu hỏi phải tương đối đồng nhất về định dạng, người trả lời không cần đọc hướng dẫn mỗi câu hỏi trước khi trả lời • Nên để các đồng nghiệp xem lại phiếu điều tra và test lại trước khi phân phối BM HTTT Khoa CNTT - HUI

39. Giám sát phiếu điều tra • Kỹ thuật chung để cải thiện tỷ lệ tham gia của người trả lời: • Giải thích rõ ràng tại sao cần thực hiện phiếu điều tra và tại sao người trả lời được chọn. • Xác định ngày phiếu điều tra cần được thu hồi • Cho 1 khích lệ để người trả lời hoàn tất phiếu điều tra. • Một số kỹ thuật khác: • Giao tận tay phiếu điều tra • Gặp riêng những ai không trả lại phiếu điều tra sau 1 hay 2 tuần • Cử giám sát viên cho từng nhóm người trả lời BM HTTT Khoa CNTT - HUI

40. Technique: Requirements Workshop • Có thể là kỹ thuậtnăngđộngnhấtđể thuthậpyêucầu. • Tậphợptấtcả các stakeholder chínhcùngvớinhautrong 1 giai đoạn, tuyngắnnhưngrấttậptrung. • Sử dụng người trợ giúp (facilitator) có kinhnghiệmtừ bênngoàitrongquảnlý yêucầu có thể bảođảmchosự thànhcôngcủa workshop. • Brainstorming là phầnquan trọngnhấtcủa workshop. BM HTTT Khoa CNTT - HUI

41. Preparing for the workshop • Bảođảm có sự thamgiacủacác stakeholder phù hợp • Côngtáchậucần (Logistics) • Cố và tránhluật Murphy’s law • Baogồmcả du lịch, giải trí và ănnhẹ buổichiều (“afternoon sugar filled snacks.”) • Tàiliệuđầubuổihộithảo (Warm-up materials) • Thông tin củabuổihộithảo • Out-of-box thinking preparation BM HTTT Khoa CNTT - HUI

42. Trong lúc Workshop • Để dễ dànggiaotiếp, nênsử dụngtừ ngữ củamiềnứngdụngthay vì bắtkháchhànghiểucácthuậtngữ máytính. • Nênđưacácthuậtngữ nghiệp vụ vào danh sách các từ khó (glossary) để cácthànhviêncùngdùngchungcácđịnhnghĩa • Customer nênhiểu là việcthảoluậnvề chứcnăngkhônghẳn là 1 nhiệm vụ phải có trongsảnphẩm. BM HTTT Khoa CNTT - HUI

43. Trong lúc workshop • Kỹ năngđể dẫndắtcáccuộcthảoluậnphântíchyêucầuphải có đượctừ kinhnghiệm, tậphuấnphỏngvấn, hỗ trợ nhóm, giảiquyếtxungđột, .. • Ngườiphântíchphảikhảosátcẩnthận (probe) nhucầuthựcsự củakháchtừ 1 loạtcácyêucầu mà kháchhàngđề ra. • Hỏi "why" nhiềulần • Hỏicáccâuhỏimở (open-ended question) để giúphiểuđượcquytrìnhnghiệp vụ hiệnhànhcủangườidùngvà để thấyhệ thốngmới có thễ cảithiệnviệcthựcthinhưthế nào. • Điềutratìmhiểu (Inquire) nhữngthayđổixảyrachongườidùngkhihệ thốngmớiđượcđưavàosử dụng. • Thử đóngvaitrò ngườitậpsự (apprentice) họchỏitừ ngườidùngchính. BM HTTT Khoa CNTT - HUI

44. Vai trò của requirement analyst • Người phân tích yêu cầu (Requirements analyst) thường tham gia các hội thảo phân tích yêu cầu. • Facilitator đóng vai trò chính trong việc lên kế hoạch hội thảo, chọn người tham dự, dẫn dắt người tham dự để kết thúc thành công hội thảo. • Khi đội bắt đầu các phương pháp mới để phân tích yêu cầu nên có một facilitator ngoài đội hướng dẫn các workshop khởi đầu, nhờ đó các analyst có thể góp phần nhiều hơn vào các cuộc thảo luận. BM HTTT Khoa CNTT - HUI

45. Role of the Facilitator • Xáclập 1 phongcáchchuyênnghiệpvà mụctiêurõ ràngchocuộchọp • Bắtđầuvà kếtthúccuộchọpđúnggiờ • Xáclậpvà nhấnmạnhcácquytắccủacuộchọp. • Giớithiệumụctiêuvà lịchtrìnhcủacuộchọp • Điếuhànhcuộchọpvà giữ chomọingườiluônquantâmtheodõi • Tạođiềukiệnkhicầnbiểuquyếtnhất trí nhưngtránhthamgiavào. • Bảođảmmọi stakeholder đều có quyềnphátbiểugóp ý trongcuộchọp • Kiểmsoátcáchành vi gâyrốivà khôngphù hợp. BM HTTT Khoa CNTT - HUI

46. Workshop Agenda • Xâydựnglịchtrình (agenda) trướcchobuổihộithảovà côngbố nó cùngvớicáctàiliệuchuẩn bị trướccủa workshop. • Giữ ổnđịnhchobuổihộithảorấtquantrọng, cố gắngtheođúnglịchtrình, nhưngcũngkhôngnêntuântheo nó quá cứngnhắc, nhất là khiđang có thảoluậnsôinổi. • Đặtăntrưa (light working lunch). BM HTTT Khoa CNTT - HUI

47. Running the Workshop • Cư xử lịch thiệp và vui vẻ • Không nên “attack” thành viên khác. • Không nên diễn thuyết nhiều quá. • Đừng quay lại muộn sau khi giải lao • Thẻ phạt (Workshop tickets) • Cấp cho mỗi stakeholder một trong 3 loại thẻ phạt sau: đi muộn, gian lận (“cheap shot”) , phát biểu dài dòng (“soap box”) • Facilitator cũng có thể bị nhận thẻ phạt. BM HTTT Khoa CNTT - HUI

48. Một số nguyên tắc cơ bản để workshop thành công • Establish ground rules • Stay in scope • Use parking lots to capture items for later consideration • Timebox discussions • Keep the team small and include the right participants • Keep everyone engaged BM HTTT Khoa CNTT - HUI

49. Workshop Problems and Suggestions (đề nghị) Problems • Quản lý thời gian • Khó bắt đầu lại sau nghỉ giải lao và ăn trưa. • Stakeholders quan trọng thường quay lại muộn. • Giành quyền phát biểu quá lâu, • Thiều dữ liệu từ stakeholders • Phát biểu tiêu cực, hành động nhỏ nhen, gây gỗ • Mệt mỏi thiếu sinh lực sau khi ăn trưa Suggestions • Facilitator phải theo dõi thời gian nghỉ giải lao và phạt bất kỳ ai đến muộn, • Mỗi người chỉ được 5 phút để phát biểu. • Facilitator khuyến khích mọi người sử dụng 5 phút được phát biểu và ủng hộ các sáng kiến. • Dùng vé phạt (“Cheap Shot Tickets”) và buộc trả chi phí • Nên tổ chức ăn nhẹ buổi trưa, giải lao buổi chiều, sắp xếp lại chỗ ngồi BM HTTT Khoa CNTT - HUI

50. Product Position Statement • For [target end user] • Who wants/needs [compelling reason to buy] • The [product name] is a [product category] • That provides [key benefit]. • Unlike [main competitor], • The [product name] [key differentiation] BM HTTT Khoa CNTT - HUI