Bài giảng Thu nhận yêu cầu - Chương 3: Thu thập yêu cầu - Trần Thị Kim Chi

Chapter 3: Thu thập yêu cầuRequirements ElicitationOrRequirement gatheringBM HTTT Khoa CNTT - HUI1Nội dungThu thập yêu cầu (Requirement elicitation) là gì?Các kỹ thuật thu thập yêu cầuChọn lựa kỹ thuật thu thập yêu cầuQuy tắc nghiệp vụ và chính sáchQuản lý mối quan hệ khách hàngBM HTTT Khoa CNTT - HUI2A 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 - HUI3Requirement elicitationElicitation 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 nhauBM HTTT Khoa CNTT - HUI4Phân biệt giữa elicitation và analysisElicitation 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 - HUI5Tầm quan trọngRequirements 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 - HUI6Mô hình song song của quy trình yêu cầuBM HTTT Khoa CNTT - HUI7Why 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 - HUI8Vấn đề về người dùng và khách hàngNgườ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óaNgườ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ấpNgườ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ậtNgười dùng không hiểu quy trình phát triển.BM HTTT Khoa CNTT - HUI9Các hoạt động của yêu cầuBM HTTT Khoa CNTT - HUI10Trước khi thu thập yêu cầuĐã viết “vision and scope”Vẽ lược đồ ngữ cảnh (context diagram)Xác định stakeholderXác định người dùng và đại diện người dùngBM HTTT Khoa CNTT - HUI11Lược đồ ngữ cảnhPhạ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 - HUI12Lược đồ ngữ cảnhLà 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àoCó thể nằm trong tài liệu vision, trong phục vụ đặc tả yêu cầu (SRS)BM HTTT Khoa CNTT - HUI13Lược đồ ngữ cảnhBM HTTT Khoa CNTT - HUI14Keeping Scope in FocusScope change isn’t a bad thing if it helps you steer the project toward satisfying evolving customer needsKhi 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ạiBM HTTT Khoa CNTT - HUI15Keeping Scope in FocusNế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 - HUI16Xác định StakeHolderIdentify the different classes of users for your productIdentify source of user requerimentsSelect and work with individual who represent each user class and other stakeholder groupsAgree on who the requirements decision makers are for you projectIt’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 - HUI17Xác định StakeHolderNhữ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 - HUI18Phân loại StakeHolderCustomers (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 - HUI19Phân loại StakeHolderDocumentation 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 - HUI20Các kỹ thuật thu thập yêu cầuDocument SamplingInterviewingSurvey and observationQuestionairesWorkshop and BrainstormingJAD (Joint Application Development) sessionsBa kỹ thuật phổ biến nhất là Document sampling, interviewing và questionairesBM HTTT Khoa CNTT - HUI21Các kỹ thuật thu thập yêu cầuBM HTTT Khoa CNTT - HUI22Các kỹ thuật thu thập yêu cầuAssignment 12: Document SamplingNhóm???Assignment 13: QuestionairesBM HTTT Khoa CNTT - HUI23InterviewingLà kỹ thuật trực tiếp và đơn giảnPhỏ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 interviewsTập hợp lại 1 số nhu cầu chung sẽ tạo “requirements repository”để dùng trong suốt dự ánQuestionnaire không thể thay thế cho interview.BM HTTT Khoa CNTT - HUI24InterviewsInterview cá nhân hay nhóm các người dùng là nguồn thu thập yêu cầu kiều truyến thống cho cả sản phẩm thương mại cũng như các hệ thống thông tin. Tìm hiểu cách nghĩ của người dùng khi họ trình bày các yêu cầu, rút ra các quyết định có tính logic của người dùng. Để mô tả quá trình đưa ra các quyết định logic có thể dùng flowchart và cây quyết định (decision tree) bảo đảm mọi người hiểu được tại sao hệ thống phải thực hiện các chức năng này. Đôi khi các yêu cầu của người dùng phản ánh các quy trình nghiệp vụ đã lỗi thời hay không hiệu quả nữa và không nên đưa vào hệ thống mới. BM HTTT Khoa CNTT - HUI25Một số hướng dẫn để phỏng vấn thành côngBM HTTT Khoa CNTT - HUI26Interview: Context free questionLà 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 - HUI27Các dạng câu hỏi context free Opening Questions: khi bắt đầu phỏng vấn, câu hỏi context free sẽ giúp khởi đầu cuộc phỏng vấn và vượt qua được các lúng túng ban đầu.Redirection: có thể được dùng để chuyển hướng phỏng vấn khi nội dung cuộc đối thoại ra ngoài chủ đề hay quá sâu không cần thiết, đưa cuộc đối thoại về lại vị trí trung lập để hướng đến chủ đề mong muốn. Closing: dùng để kết thúc cuộc phỏng vấn “Is there anything else you would like to tell me?”  cho người được phỏng vấn (interviewee) cơ hội được chủ động và chia xẻ̃ các thông tin khác. BM HTTT Khoa CNTT - HUI28Các dạng câu hỏiBM HTTT Khoa CNTT - HUI29Làm thế nào đề thực hiện interviewPhả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 chungKhô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 - HUI30Các chiến lược phỏng vấnTop-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ạiBM HTTT Khoa CNTT - HUI31Interview: Show timeNên dành thời gian để:Establish Customer or User ProfileAssessing the ProblemUnderstanding the User EnvironmentRecap the UnderstandingAnalyst’s Inputs on Customer’s ProblemsAssessing Your Solution (if applicable)BM HTTT Khoa CNTT - HUI32QuestionariesThường dùng khi cần thu thập thông tin và ý kiến từ số đông.BM HTTT Khoa CNTT - HUI33So sánh giữa Questionaries và InterviewBM HTTT Khoa CNTT - HUI34Chọn người tham gia phiếu điều traChọn người đại diện cho mỗi nhómKhô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 WebBM HTTT Khoa CNTT - HUI35Thiết kế phiếu điều traThường dùng câu hỏi dạng closed-endedCâ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ầmBM HTTT Khoa CNTT - HUI36Thiết kế phiếu điều traHai 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 - HUI37Thiết kế phiếu điều traPhả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ờiNên để các đồng nghiệp xem lại phiếu điều tra và test lại trước khi phân phốiBM HTTT Khoa CNTT - HUI38Giám sát phiếu điều traKỹ 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ồiCho 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 traGặp riêng những ai không trả lại phiếu điều tra sau 1 hay 2 tuầnCử giám sát viên cho từng nhóm người trả lờiBM HTTT Khoa CNTT - HUI39Technique: Requirements WorkshopCó thể là kỹ thuật năng động nhất để thu thập yêu cầu. Tập hợp tất cả các stakeholder chính cùng với nhau trong 1 giai đoạn, tuy ngắn nhưng rất tập trung. Sử dụng người trợ giúp (facilitator) có kinh nghiệm từ bên ngoài trong quản lý yêu cầu có thể bảo đảm cho sự thành công của workshop.Brainstorming là phần quan trọng nhất của workshop.BM HTTT Khoa CNTT - HUI40Preparing for the workshopBảo đảm có sự tham gia của các stakeholder phù hợpCông tác hậu cần (Logistics)Cố và tránh luật Murphy’s lawBao gồm cả du lịch, giải trí và ăn nhẹ buổi chiều (“afternoon sugar filled snacks.”)Tài liệu đầu buổi hội thảo (Warm-up materials)Thông tin của buổi hội thảoOut-of-box thinking preparationBM HTTT Khoa CNTT - HUI41Trong lúc WorkshopĐể dễ dàng giao tiếp, nên sử dụng từ ngữ của miền ứng dụng thay vì bắt khách hàng hiểu các thuật ngữ máy tính.Nên đưa các thuật ngữ nghiệp vụ vào danh sách các từ khó (glossary) để các thành viên cùng dùng chung các định nghĩaCustomer nên hiểu là việc thảo luận về chức năng không hẳn là 1 nhiệm vụ phải có trong sản phẩm. BM HTTT Khoa CNTT - HUI42Trong lúc workshopKỹ năng để dẫn dắt các cuộc thảo luận phân tích yêu cầu phải có được từ kinh nghiệm, tập huấn phỏng vấn, hỗ trợ nhóm, giải quyết xung đột, ..Người phân tích phải khảo sát cẩn thận (probe) nhu cầu thực sự của khách từ 1 loạt các yêu cầu mà khách hàng đề ra. Hỏi "why" nhiều lần Hỏi các câu hỏi mở (open-ended question) để giúp hiểu được quy trình nghiệp vụ hiện hành của người dùng và để thấy hệ thống mới có thễ cải thiện việc thực thi như thế nào. Điều tra tìm hiểu (Inquire) những thay đổi xảy ra cho người dùng khi hệ thống mới được đưa vào sử dụng. Thử đóng vai trò người tập sự (apprentice) học hỏi từ người dùng chính.BM HTTT Khoa CNTT - HUI43Vai trò của requirement analystNgườ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 - HUI44Role of the FacilitatorXác lập 1 phong cách chuyên nghiệp và mục tiêu rõ ràng cho cuộc họpBắt đầu và kết thúc cuộc họp đúng giờXác lập và nhấn mạnh các quy tắc của cuộc họp.Giới thiệu mục tiêu và lịch trình của cuộc họpĐiếu hành cuộc họp và giữ cho mọi người luôn quan tâm theo dõiTạo điều kiện khi cần biểu quyết nhất trí nhưng tránh tham gia vào.Bảo đảm mọi stakeholder đều có quyền phát biểu góp ý trong cuộc họpKiểm soát các hành vi gây rối và không phù hợp. BM HTTT Khoa CNTT - HUI45Workshop AgendaXây dựng lịch trình (agenda) trước cho buổi hội thảo và công bố nó cùng với các tài liệu chuẩn bị trước của workshop.Giữ ổn định cho buổi hội thảo rất quan trọng, cố gắng theo đúng lịch trình, nhưng cũng không nên tuân theo nó quá cứng nhắc, nhất là khi đang có thảo luận sôi nổi.Đặt ăn trưa (light working lunch). BM HTTT Khoa CNTT - HUI46Running the WorkshopCư 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 laoThẻ 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 - HUI47Một số nguyên tắc cơ bản để workshop thành côngEstablish ground rulesStay in scopeUse parking lots to capture items for later considerationTimebox discussionsKeep the team small and include the right participantsKeep everyone engagedBM HTTT Khoa CNTT - HUI48Workshop Problems and Suggestions (đề nghị)ProblemsQuản lý thời gianKhó 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ừ stakeholdersPhá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ưaSuggestionsFacilitator 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ồiBM HTTT Khoa CNTT - HUI49Product Position StatementFor [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 - HUI50Brainstorming SessionsThường được dùng để phân tích tìm các yêu cầu ban đầu của stakeholder đối với sản phẩm. Phương pháp này được thực hiện với nhiều stakeholders hay customers và các phiên giao tiếp này thường được dẫn dắt bởi 1 facilitators có kinh nghiệm, mỗi phiên (session) thường kéo dài tối đa 1 hay 2 ngày. Mục tiêu của brainstorming session là đưa ra các ý tưởng mới hay các tính năng của sản phẩm trong 1 thời gian rất ngắn. BM HTTT Khoa CNTT - HUI51Brainstorming SessionsKhi xác định ý tưởng, điều quan trọng là phải tránh xung đột, e.g., một thành viên chê bài ý tưởng của người khác. Nếu có thành viên lâu năm (senior) tham gia session thì điều quan trọng là giữ cho họ không được đe dọa các thành viên ít kinh nghiệm hơn họ.BM HTTT Khoa CNTT - HUI52Vai trò của facilitatorBM HTTT Khoa CNTT - HUI53Vai trò của facilitator rất quan trọng, quyết định session có thành công hay không?BrainstormingMục tiêu và thời gian của brainstorming session cần phải được thỏa thuận trước bởi tất cả các thành viên, tốt nhất là ngay trước khi bắt đầu session. Session nên bắt đầu với việc tự do đưa ra các ý kiến, tạo thành 1 tập hợp các kiến nghị về sản phẩm. Nên dùng “sticky notes” và dán vào bảng. BM HTTT Khoa CNTT - HUI54Các giai đoạn của Brainstorming Session BM HTTT Khoa CNTT - HUI55Tabular Elicitation TechniqueViệc dùng bảng có thể giúp nắm bắt được yêu cầu của stakeholder rõ ràng và chặt chẽ hơn. Có 2 loại bảng hay được dùng: Decision tableState tableBM HTTT Khoa CNTT - HUI56Decision tableBảng quyết định (Decision table) thông dụng nhất khi: Tập các điều kiện là rời rạc, có thể được xác định bằng “yes” hay “no,” Hành động sẽ thực hiện khi các điều kiện thỏa mãnTập các rule khi tập các điều kiên là duy nhất và tương ứng với mỗi rule là 1 hành động. BM HTTT Khoa CNTT - HUI57Decision tableMỗi hàng biều diễn một condition, mỗi cột biểu diễn 1 rule, i.e,. Một điều kiện và 1 tập các hành động tương ứng. Khi cần phân tích bản phác thảo các yêu cầu lúc đầu của stakeholder thì bảng quyết định được dùng rất hiệu quả để nắm bắt các quy tắc nghiệp vụ. (business rule)BM HTTT Khoa CNTT - HUI58Ví dụ bảng quyết địnhBM HTTT Khoa CNTT - HUI59State tables Được dùng khi đối tượng đang khảo sát có thể có các trạng thái khác nhau ở các thời điểm khác nhau và các sự kiện đơn giản nhưng rõ ràng nào đó có thễ kích khởi việc đổi từ trạng thái này sang trạng thái khác. State machine: là 1 đối tượng mà việc chuyển đổi trạng thái chỉ dựa vào các sự kiện rời rạc và số trạng thái của đối tượng đã biết trước. Ví dụ: bảng người nộp thuế (taxpayer) không phải là bảng trạng thái vì chỉ có 1 trạng thái duy nhất là “about to pay taxes.”BM HTTT Khoa CNTT - HUI60State tableState tables chỉ ra hành vi của state machine, thường có 1 trạng thái khởi đầu và một tập các trạng thái mà đối tượng sẽ trải qua và cuối cùng là trạng thái exit thành công hay 1 trong các trạng thái “error”. Mỗi lần thay đổi trạng thái đều có liên quan đến 1 hay nhiều sự kiện (event) BM HTTT Khoa CNTT - HUI61Ví dụBM HTTT Khoa CNTT - HUI62ButtonPhương pháp điều tra (survey)-Ethnographic TechniquesMột số phương pháp điều tra được dùng rất nhiều để đánh giá các yêu cầu thị trường, mối quan tâm về sản phẩm.Khi số lượng khách hàng tương đồi lớn, có thể thực hiện thống kê trên kết quả điều tra đề đo lường mức độ quan tâm của khách hàng đối với các tính năng của sản phẩm. Một trong các phương pháp điều tra thông dụng nhất để phân tích mố