Giáo trình Thu nhận yêu cầu

Môn học Thu nhận yêu cầu (Requirement Engineering) Thu nhận yêu cầu TNYC 1 Khoa CNTT ĐH Công nghiệp Tp. HCM Thu nhận yêu cầu Giảng viên ™ Nguyễn Năm. Khoa CNTT. Bộ môn : HTTT ™ Email: namnguyen1962@yahoo.com 2 Thu nhận yêu cầu Môn học trước ™ Hệ cơ sở dữ liệu ™ Phân tích và thiết kế hệ thống ™ UML ™ Mô hình hóa dữ liệu Thu nhận yêu cầu Tài liệu ™ [1] Karl E. Wiegers, Software requirement, Second Edition Microsof t Press © 2003(ebook)- ™ [2] Brian Berenbach, Daniel J. Paulish, Juergen Kazmeier Arnold Rudorfer - Software & Systems, Requirements Engineering: In Practice- Mc GrawHill, 2009 (ebook) ™ [3] Ian Alexander, Ljerka Beus-Dukic – Discovering Requirements - John Wiley and Sons, Ltd., Publication , 2009 (ebook) ™ [4] Slide bài giảng môn Mô hình hóa dữ liệu của Khoa Công nghệ Thông tin 4 Thu nhận yêu cầu Lịch biểu ™ Lý thuyết: 11 tuần, 4 tiết/tuần ™ Bài tập lớn ƒ 3 sinh viên/nhóm ƒ Nhận đề tài vào tuần 2 ™ Thi giữa kỳ: ƒ Thi vào tuần 6 ™ Thi cuối kỳ: trắc nghiệm chung 5 Thu nhận yêu cầu Nội dung 1. Tổng quan về thu nhận yêu cầu 2. Kỹ thuật thu nhận yêu cầu 3. Phân tích yêu cầu 4. Mô hình hệ thống 5. Đặc tả yêu cầu (giữa kỳ) 6. Thẩm định yêu cầu 7. Quản lý yêu cầu 8. Các vấn đề khác 6 CHƯƠNG I YÊU CẦU PHẦN MỀM Thu nhận yêu cầu TNYC 1 Thu nhận yêu cầu Nội dung 1. Tầm quan trọng của xác định yêu cầu ê ầ ầ ề à ì2. Y u c u ph n m m (software requirement) l g ? 3. Phân loại yêu cầu 4 Kỹ h ậ ê ầ là ì?. t u t y u c u (Requirements Engineering - RE) g 5. Lợi ích từ quy trình xác định yêu cầu chất lượng cao 6 Yê ầ th điể khá h hà. u c u eo quan m c ng 7. Vai trò của người phân tích yêu cầu 2 Thu nhận yêu cầu 1. Tầm quan trọng trong XĐ yêu cầu? ™ Công nghệ và xã hội không ngừng thay đổi một á h h h hó à ả h hưở t lớ ủ hệc c n an c ng, v n ng o n c a thống thông tin trong một môi trường vô cùng phức tạp ƒ Kỹ thuật yêu cầu (requirements engineering - RE) đóng một vai trò vô cùng quan trọ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 Hệ thống nghiệp vụ - Hệ thống thông tin – Phần mềm 3 Thu nhận yêu cầu Một số đặc trưng ™ Sản phẩm phát triển với tốc độ chóng mặt. Ngày khá h hà thườ đòi hỏi hiê bả ới ủnay c ng ng p n n m c a sản phẩm trong khoảng thời gian dưới 1 năm Ví dụ: theo Siemens thì 20 năm trước 55% hàngƒ , bán là từ sản phẩm tuổi <5. Ngày nay, 75% hàng bán được là từ sản phẩmcó tuổi <5. 4 5 Thu nhận yêu cầu Một số đặc trưng ™ Thay đổi không ngừng của công nghệ ểƒ Các kỹ sư không th sống cả đời với nghề nghiệp của mình trong 1 công ty nào đó 6 Thu nhận yêu cầu Một số đặc trưng ™ Gia công phần mềm đóng một vai trò vô cùng t ó tí h t à ầquan rọng c n o n c u ƒ Vai trò quan trọng của đặc tả. VD: Đặc tả cho máy giặt cho đội ngũ xây dựng nó chưa từng nhìn thấy máy giặt lần nào 7 Thu nhận yêu cầu Một số đặc trưng ™ Việc phát triển phần mềm thường liên kết chặt hẽ ới hiệ à hiệ thì biế đổic v ng p vụ m ng p vụ n không ngừng nên các phiên bản mới của sản phẩm thường được tạo bằng cách thay đổi phần mềm nhằm hạ thấp chi phí biến đổi 8 Thu nhận yêu cầu 2. Yêu cầu (requirement) Theo IEEE 1990, yêu cầu là: 1. A condition or capability needed by a user to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract standard specification or other , , , formally imposed document. 3 A documented representation of a condition or. capability as in 1 or 2. 9 Thu nhận yêu cầu Yêu cầu ™ Yêu cầu có thể được ràng buộc bởi hợp đồng hay ă bảv n n ™ Có những yêu cầu ngầm định (implicit) ộ ê ầ ó ể ậ ế™ M t y u c u c th được nh n bi t (known, spoken)/ không nhận biết (forgotten, unspoken…) Thu nhận yêu cầu Đặc trưng của yêu cầu ™ Feasible (khả thi) ™ Valid ™ Unambiguous ™ Verifiable ™ Modifiable ™ Consistent ™ Complete ™ Traceable 11 Thu nhận yêu cầu 3. Phân loại yêu cầu ……. 12 Thu nhận yêu cầu Yêu cầu hệ thống ™ Yêu cầu chức năng: chức năng dịch vụ hệ thống cung cấp ™ Yêu cầu phi chức năng: những ràng buộc về tiêu chuẩn, thời gian, qui trình phát triển…, chủ yếu là những yêu cầu về chất lượng ™ Ràng buộc: phản ảnh những đặc trưng của miền ứng dụng. Chúng có thể là những yêu cầu chức năng hay yêu cầu phi chức năng. 13 Thu nhận yêu cầu Yêu cầu chức năng ™ Yêu cầu chức năng chỉ ra những gì hệ thống làm, chúng thường quan hệ các use-case hay những qui tắc nghiệp vụ (business rule) ™ Một số yêu cầu chức năng ƒ Chức năng tính toán ƒ Chức năng lưu trữ ƒ Chức năng tìm kiếm ƒ Chức năng kết xuất ƒ Chức năng backup, restore ƒ Chức năng đa người dùng ƒ Chức năng đa phương tiện… Thu nhận yêu cầu Ví dụ ™ Trong hệ thống quản lý thư viện ƒ Người dùng có thể tìm kiếm download in những bài , , báo ƒ Người dùng được cấp một vùng lưu trữ riêng để có thể copy để lưu trữ tài liệu lâu dài… 15 Thu nhận yêu cầu Yêu cầu phi chức năng ™ Một số yêu cầu phi chức năng ƒ Độ tin cậy thời gian đáp ứng các yêu cầu về lưu trữ , , … ƒ Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình… ƒ Yêu cầu của người sử dụng: dễ sử dụng, thân thiện ƒ Ràng buộc về ngân sách ổƒ Phù hợp với các chính sách của t chức sử dụng hệ thống ƒ Yêu cầu tương thích giữa phần cứng và phần mềm ƒ Các yêu cầu từ các tác nhân ngoài khác… Thu nhận yêu cầu Yêu cầu phi chức năng 17 CNPM/NN Thu nhận yêu cầu Ví dụ Trong hệ thống quản lý thư viện ™ Yêu cầu sản phẩm: giao diện người dùng không chứa frame và applet java ™ Yêu cầu tổ chức: qui trình phát triển hệ thống và tài liệu phân phối phải phù hợp theo tiêu chuẩn “STAN-07” (sử dụng ngôn ngữ, phương pháp thiết kế…) ™ Yêu cầu ngoài: hệ thống không được lộ thông tin của khách hàng (tên, số tham chiếu…) 18 Thu nhận yêu cầu Các mức yêu cầu ™ Yêu cầu nghiệp vụ (Business requirements) ™ Yêu cầu người dùng (User requirements) ™ Yêu cầu chức năng (Functional requirements) 19 Thu nhận yêu cầu Yêu cầu nghiệp vụ ™ Biễu diễn các mục tiêu của tổ chức hay khách hàng yêu cầu hệ thống phải có ™ Yêu cầu nghiệp vụ thường do người tài trợ cho dự án, khách mua phần mềm, người quản lý các người dùng, bộ phận tiếp thị (maketing)… ™ Thường được ghi nhận trong phần đặc tả (vision) và phạm vi (scope) của tài liệu, đôi khi còn được gọi là tuyên bố dự án (project charter) hay tài liệu yêu cầu thị trường (market requirements document) 20 Thu nhận yêu cầu Yêu cầu người dùng ™ Mô tả mục tiêu (goal) hay tác vụ (task) của người dùng đối với hệ thống . ™ Các cách để biểu diễn yêu cầu người dùng: use cases scenarioƒ , ƒ Bảng event-response. ™ Yêu cầu người dùng mô tả cái (what) mà người dùng có thể làm đối với hệ thống. ƒ Ví dụ: use case "Make a Reservation" dùng trong các website của hàng không, thuê xe, hay khách sạn. 21 Thu nhận yêu cầu Yêu cầu chức năng ™ Xác định chức năng của phần mềm mà các nhà phát triển phải xây dựng để giúp người dùng hoàn thành nhiệm vụ của họ, thỏa mãn được yêu cầu nghiệp vụ. ™ Đôi khi còn được gọi là yêu cầu về hành vi (behavioral requirements) ™ Ví dụ: Hệ thống sẽ gởi một xác nhận giữ chỗ cho khách hàng… 22 Thu nhận yêu cầu Mối liên hệ ̣ giữa các mức yêu cầu Thu nhận yêu cầu 4. Kỹ thuật yêu cầu (RE) ™ Nhấn mạnh tới tính cộng tác và lặp lại ƒ Tạo tài liệu cho những kết quả quan sát ƒ Kiểm tra ™ Nó còn nhấn mạnh tới vai trò của kinh nghiệm và tính xã hội 24 Thu nhận yêu cầu Sơ đồ kỹ thuật yêu cầu 25 Thu nhận yêu cầu Ranh giới yêu cầu 26 Thu nhận yêu cầu Xác định yêu cầu không thành công ™ Insufficient User Involvement ™ Creeping User Requirements ™ Ambiguous Requirements ™ Gold Plating ™ Minimal Specification ™ Overlooked User Classes ™ Inaccurate Planning 27 Thu nhận yêu cầu 5. Lợi ích khi thu thập yêu cầu hiệu quả Lợi ích của việc tạo yêu cầu có chất lượng thường khô dễ thấ ê hiề ười thườ hầ lẫng y n n n u ng ng n m n là tiêu tốn thời gian khi bàn luận về yêu cầu sẽ dẫn đến làm chậm trễ việc hoàn thành sản phẩm ™ Giảm việc phải làm lại ™ Thu thập yêu cầu cho phép đội phát triển hiểu rõ về người dùng và thị trường một nhân tố quan , trọng cho sự thành công của bất kỳ dự án nào 28 Thu nhận yêu cầu Lợi ích ™ Khi người dùng cùng tham gia trong giai đoạn thu thậ ê ầ ẽ â dự đượ iề ti à lòp y u c u s x y ng c n m n v ng trung thành của khách hàng ™ Đội phát t iển ó thể t ánh iết những đo n mã r c r v ạ thừa khi nắm vững nhiệm vụ của người dùng ™ Sự quan tâm của khách hàng giảm được khoảng cách giữa cái người dùng cần và cái người phát triển tạo ra. 29 Thu nhận yêu cầu Những lợi ích không định lượng 1. Lỗi liên quan đến yêu cầu ít hơn 2 Giảm được việc phải làm lại trong bước phát triển. 3. Ít hơn trong việc tạo tính năng không cần thiết 4 Giảm chi phí mở rộng. 5. Quá trình phát triển hệ thống sẽ nhanh hơn 6 Giảm bớt các giao tiếp sai lầm với khách hàng. 7. Hạn chế phạm vi hệ thống bị phình rộng 8. Hạn chế được những hỗn độn dự án 9. Các ước lượng về hệ thống chính xác hơn 10.Mức độ thỏa mãn khách hàng và thành viên của đội sẽ cao hơn 30 Thu nhận yêu cầu 6. Yêu cầu theo quan điểm khách hàng ™ Giới thiệu một số vấn đề trong phân tích yêu cầu à lấ khá h hà là t tâm y c ng m rọng m 31 Thu nhận yêu cầu Các hoạt động đầu tiên ™ Phân tích thông tin nghiệp vụ, nhận ra những ười liê ( t k h ld ) à á đị h h ầng n quan s a e o er v x c n n u 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 và 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 32 Thu nhận yêu cầu Khách hàng là ai? ™ Khách hàng là một cá nhân hay 1 tổ chức mong ố t ự tiế h ặ iá tiế ó lợi từ ả hẩmu n r c p o c g n p c s n p 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) 33 Thu nhận yêu cầu Khách hàng ở cấp quản lý ™ Thường những 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ụ ƒ 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 ™ Tất cả các tính chất và yêu cầu khác phải đáp ứng h á ê ầ h ệt eo c c y u c u ng i p vụ. ™ Các yêu cầu nghiệp vụ không đủ chi tiết để giúp á hà hát t iể biết hải â dự thể ái ìc c n p r n p x y ng cụ c g 34 Thu nhận yêu cầu 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 hẩp m ™ Người dùng có thể mô tả việc dùng sản phẩm cho ông iệ ủ họ à những mong đợi ề hấtc v c c a v v c lượng từ sản phẩm 35 Thu nhận yêu cầu Đặc tính của khách hàng ™ Thường cả hai loại khách hàng này đều cho rằng h khô ó hiề thời i để là iệ ới áọ ng c n u g an m v c v c c nhà phân tích yêu cầu. ™ Đôi lú họ nghĩ là nhà phân tí h ẽ hình d ng c c s u ra được cái người dùng cần mà không cần phải thảo luận với nhau . 36 Thu nhận yêu cầu Đặc tính của khách hàng ™ Thường xuất hiện những xung đột giữa yêu cầu hiệ à ê ầ ười dùng p vụ v y u c u ng ng. ™ Yêu cầu nghiệp vụ phản ánh chiến lược của tổ hứ à á àng b ộ ề tài hính mà người dùngc c v c c r u c v c có thể không nhìn thấy được Æ người dùng thường thất vọ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ông như ý… 37 Thu nhận yêu cầu Đặc tính của khách hàng ™ Việc trao đổi cẩn thận về mục tiêu và các ràng b ộ ủ dự á ó thể là dị đi á ă thẳu c c a n c m u c c c ng ng bức xúc của người dùng. ™ Nhà phân tí h ( n l t) nên làm iệ ới á đ i c a a ys v c v c c ạ diện chính của người dùng (key user representative) và các nhà tài trợ để hòa giải các xung đột. 38 Thu nhận yêu cầu Quan hệ khách hàng và nhà phát triển ™ Yêu cầu chất lượng cao có được từ giao tiếp hiệu ả iữ hà hát t iể à khá h hàqu g a n p r n v c ng. ™ Thường có sự đối kháng giữa người phát triển và khá h hàngc ™ 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ọ 39 Thu nhận yêu cầu Chất lượng dưới nhiều góc độ User: easy to learn; Customer: solves problems at an acceptable cost in efficient to use; helps get work done terms of money paid and resources used QUALITY SOFTWARE Developer: easy to design; Development manager: sells more and pleases customerseasy to maintain; easy to reuse its parts while costing less to develop and maintain Thu nhận yêu cầu Stakeholder • Customers • Users • Requirements analysts • Developers T• esters • Documentation writers • Project managers • Legal staff • Manufacturing people • Sales, marketing, field support, help desk, … 41 Thu nhận yêu cầu Ví dụ ™ You are a product manager for a machine tool Th di t h k d tcompany. e rec ors ave as e you o develop a new cutting machine to cut cloth for fashionable dresses of all sizes and patterns The . machine will be sold to clothing makers around the world: ƒ Who are your key stakeholders? ƒ How will you analyse and validate your stakeholder list? 42 Thu nhận yêu cầu Stakeholder ™ Stakeholders không rõ những gì họ thật sự muốn ễ™ Stakeholders di n đạt yêu cầu theo những thuật ngữ riêng của họ ó ể ó ê ầ™ Những stakeholders c th c những y u c u tranh chấp ™ Nhâ tố ề lự à tổ hứ ả h hưở tới ên quy n c v c c n ng y u cầu hệ thống ™ Nhữ ê ầ ó thể th đổi t á t ì hng y u c u c ay rong qu r n 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ụ Thu nhận yêu cầu 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 Thu nhận yêu cầu Quy trình phát triển yêu cầu ™ Bốn hoạt động này có thể đan xen (interleave), Gia tăng (increment), và lặp (iterative) 45 Thu nhận yêu cầu 7. Nhà phân tích yêu cầu ™ 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) 46 Thu nhận yêu cầu Vai trò của nhà phân tích ™ Nhà phân tích là người chuyển các ý tưởng thành hữ đặ tả ê ần ng c y u c u. ™ Nhà phân tích là người có quan hệ truyền thông ới á t keholde giúp á t keholde tìm thấv c c s a r, c c s a r 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 47 Thu nhận yêu cầu Vai trò của nhà phân tích ™ Họ như là một cầu nối giữa cộng đồng khách hà à đội hát t iể hầ ềng v p r n p n m m. ™ Nhà phân tích đóng vai trò trung tâm trong việc th thập à phổ biến thông tin òn người q ản lýu v , c u dự án (project manager) giữ vai trò lãnh đạo trong việc truyền đạt thông tin dự án 48 Thu nhận yêu cầu Các mối quan hệ 49 Thu nhận yêu cầu Nhiệm vụ tổng quát ™ Nhà phân tích trước tiên phải hiểu mục tiêu của ười dù đó á đị h á ê ầ hứng ng, sau x c n c c y u c u c c năng; cho phép người quản lý dự án xây dựng các ước lượng; người phát triển (developer) thiết kế , xây dựng và kiểm định sản phẩm. 50 Thu nhận yêu cầu Nhiệm vụ ™ Xác định yêu cầu nghiệp vụ. ™ Xác định các stakeholder và các lớp người dùng ™ Rút ra những yêu cầu (Elicit) ™ Viết đặc tả yêu cầu ™ Mô hình hóa yêu cầu ™ Điều hành việc đánh giá yêu cầu ™ Phân loại ưu tiên các yêu cầu ™ Quản lý yêu cầu 51 Thu nhận yêu cầu Kỹ năng của nhà phân tích ™ Kỹ năng lắng nghe ™ Kỹ năng phỏng vấn ™ Kỹ năng phân tích ™ Kỹ ă điề khiể (h ) n ng u n ọp ™ Kỹ năng quan sát ỹ ă ế™ K n ng vi t ™ Kỹ năng tổ chức ™ Kỹ năng mô hình hóa ™ Kỹ năng giao tiếp ™ Tính sáng tạo Nhập nhằng Create a means to transport a single Requirement: individual from home to place of work. Management Interpretation I T Interpretation User Interpretation Thu nhận yêu cầu 54 CNPM/NN CHƯƠNG II Product Vision và Project Scope Thu nhận yêu cầu TNYC 1 Thu nhận yêu cầu Tạo Đặc tả yêu cầu (Specification) 1. Phân biệt mục tiêu (goal) và yêu cầu 2 Xác định sản phẩm được tạo (Product Vision). và phạm vi dự án (Project Scope) 3 Xác định biên bằng phương pháp “Soft system”. 4. Xác định yêu cầu chức năng bằng phương pháp “Hard system” 5. Xác định yêu cầu từ khách hàng 2 Thu nhận yêu cầu 1. Mục tiêu (Goal) và yêu cầu ™ Mục tiêu là cái mà stakeholder muốn thực thi. ể™ Mục tiêu có th có nhiều mức độ khác nhau: ƒ Mức cao nhất: phát biểu về nhiệm vụ và mục tiêu ƒ Mức thấp nhất: những chức năng riêng biệt 3 Thu nhận yêu cầu Mục tiêu và yêu cầu ™ Mục tiêu chi tiết sẽ trở thành yêu cầu nó cần có đặ tí hc n : ƒ Có thể kiểm chứng được Phâ l i ư tiêƒ n oạ u n 4 Thu nhận yêu cầu Mục tiêu và đo lường (measure) ™ Những yêu cầu phi chức năng khó phát biểu chính xác, mơ hồ cần bổ sung bằng mục tiêu và một số đo lường ™ Ví dụ ƒ Một mục tiêu của hệ thống • Hệ thống dễ sử dụng cho những người đã có kinh nghiệm và người dùng có thể tùy biến được giao diện làm việc ƒ Một yêu cầu phi chức năng có thể kiểm tra (đo lường) • Người dùng có kinh nghiệm có thể sử dụng tất cả các chức năng sau 2 giờ huấn luyện. Sau khi huấn luyện người dùng có kinh nghiệm sẽ không có lỗi trung 5 bình quá 2 lỗi /ngày Thu nhận yêu cầu Mục tiêu và yêu cầu Dr 54-75 6 Thu nhận yêu cầu Yêu cầu nghiệp vụ ™ Phân biệt giữa yêu cầu nghiệp vụ và yêu cầu phần ềm m ™ Thường các yêu cầu phần mềm được lưu trữ cho á hệ thống phần mềm hiện ó hoặ tương l i àc c c c a v phải phù hợp với yêu cầu nghiệp vụ. ™ Yêu cầu nghiệp vụ ƒ Tự động hóa ƒ Bằng tay 7 Thu nhận yêu cầu Ví dụ ™ Tự động hóa: các nghiệp vụ thường kỳ như tính lươ ả lý điểng, qu n m… ™ Thực hiện bằng tay: ví dụ đánh giá tổn hại nhân thọ đánh giá ủi o (nhưng ó thể lư t ữ) , r r c u r … 8 Thu nhận yêu cầu Phần mềm quản lý Kiosk srse ™ Mục tiêu nghiệp vụ của người quản lý kiosk: ƒ Generating revenue (tạo ra doanh thu) by leasing or selling the kiosk to the retailer S lli bl (hà tiê dù ) th h thƒ e ng consuma es ng u ng roug e kiosk to the customer ƒ Attracting customers to the brand ƒ Making a wide variety of products available 9 Thu nhận yêu cầu Phần mềm quản lý Kiosk ™ Mục tiêu nghiệp vụ của người bán lẻ (retailer): ƒ Maximizing revenue from the available floor space ƒ Attracting more customers to the store ƒ Increasing sales volume and profit margins if the kiosk replaces manual operations 10 Thu nhận yêu cầu Xung đột ™ Người quản lý muốn tạo 1 hướng mới năng động, kỹ th ật h khá h hà ò ười bá lẻ thì u cao c o c ng, c n ng n muốn 1 hệ thống chuyển giao đơn giản, còn khách hàng thì chỉ thích thuận tiện và nhiều tính năng. ™ Ba nhóm người với các mục tiêu khác nhau Người . tài trợ dự án cần giải quyết các xung đột trước khi nhà phân tích phân tích yêu cầu phần mềm. 11 Thu nhận yêu cầu Giải quyết xung đột ™ Xung đột mục tiêu nên được phát hiện sớm từ các t k h ld à iệ hâ tí h tiê á h iảis a e o er v v c p n c mục u, c c g quyết sẽ được khi đưa ra trong dự thảo thiết kế ™ T ong một ố t ường hợp hỉ ần một phá thảor s r c c c đơn giản là đã xác định được một hướng tiếp cận có khả thi không? ™ Một vài trường hợp, không thể nào tìm ra được giải pháp khả thi giải quyết xung đột mục tiêu 12 Thu nhận yêu cầu Quy trình phát triển yêu cầu ™ Trước khi thực hiện quy trình này, analyst cần phải xác định : ƒ Product Vision ≅ product goal (mục tiêu) ƒ Project scope ≅ boundaries (phạm vi dự án) 13 Thu nhận yêu cầu 3. Product Vision và Project Scope ™ Vision (hay mission) mô tả thực chất sản hẩ ẽ là ìp m s g ™ Project scope xác định một phần của product i ion dài h nv s ạ ™ Vision dùng để chỉ đến cả hệ thống phần mềm, nó phản ánh mục tiêu nghiệp vụ của h