Bài giảng Thu nhận yêu cầu - Chương 2: Phát triển yêu cầu phần mềm - Trần Thị Kim Chi

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

ppt147 trang | Chia sẻ: candy98 | Lượt xem: 446 | Lượt tải: 0download
Bạn đang xem trước 20 trang tài liệu Bài giảng Thu nhận yêu cầu - Chương 2: Phát triển yêu cầu phần mềm - Trần Thị Kim Chi, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Chương 2PHÁT TRIỂN YÊU CẦU PHẦN MỀMXây dựng tầm nhìn và phạm vi dự ánEstablishing the Product Vision and Project ScopeBM HTTT - Khoa CNTT - HUI1Nội dungXác định những người liên quan (stakeholder)Hiểu nhu cầu khách hàngThu nhận yêu cầu từ khách hàngPhân biệt goal và requirementKhái niệm Product Vision và Project ScopeXá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 systemLược đồ ngữ cảnhBM HTTT - Khoa CNTT - HUI2Qui TrìnhBM HTTT - Khoa CNTT - HUI3Stakeholder: 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. Stakeholder là gì4CustomersUsers Requirements analystsDevelopersTestersDocumentation writersProject managersLegal staff – nhóm người làm việc hợp phápManufacturing people – người sản xuấtSales, marketing, field support, help desk, Stakeholder5Xác định những người liên quanStakeholder:Bao gồm những người, tổ chức mà là một phần của môi trườ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ốngStakeholder:Users, operators, bill payers, owners, regulatory agencies, victims, sponsors, maintainers, architects, managers, customers, surrogate customers BM HTTT - Khoa CNTT - HUI6Các stakeholder của Boeing 787Users: passengers that fly on the airplaneOperators: fight crews and mechanicsBill payers: airline companiesOwners: stockholders of these companiesRegulators: FAASponsor: corporate headquartersMaintenance: ground crewVictims: people living near the airportsBM HTTT - Khoa CNTT - HUI7Cần quan tâm tới qui trìnhBM HTTT - Khoa CNTT - HUI8Các stakeholder khácUsers and operators: employees in the manufacturing plantBill payer: BoeingOwner: stockholders of BoeingRegulators: OSHAVictims: physically and emotionally injured workersAir traffic control towerBM HTTT - Khoa CNTT - HUI9Stakeholder của hệ thống ATMKhách hàng của ngân hàngĐại diện của các ngân hàng khácNgười quản lý ngân hàngNhân viên thu tiềnNgười quản trị CSDLNgười quản lý bảo mậtKỹ sư bảo trì phần cứng và phần mềmNhững người điều phối ngân hàngBM HTTT - Khoa CNTT - HUI10StakeholderStakeholder không rõ những gì họ thật sự muốnStakeholder 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ấpNhân tố quyền lực và tổ chức ảnh hưởng tới yêu cầu hệ thốngNhữ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 - HUI11Phâ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ốngCác hoạt động đầu tiên của requirements engineering 12Hiểu nhu cầu của khách hàngNhà phân tích phải ở trong môi trường của khách hà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àngBM HTTT - Khoa CNTT - HUI13Phát biểu của khách hàngBM HTTT - Khoa CNTT - HUI14Khá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 - HUI15Khá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ự ánCá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 - HUI16Khách hàng là người dùng cuốiBao gồm tất cả những ai sẽ thực sự sử dụng sản phẩmNgười dùng có thể mô tả việc dùng sản phẩm cho công việc của họ và những mong đợi về chất lượng từ sản phẩmBM HTTT - Khoa CNTT - HUI17Đặc tính của khách hàngThường cả hai loại khách hàng này đều cho rằng họ 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 - HUI18Đặc tính của khách hàngThường xuất hiện những xung đột 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 ràng buộc về tài chính mà người dùng có thể không nhìn thấy được  người dùng thườ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ư ý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.BM HTTT - Khoa CNTT - HUI19Quan hệ khách hàng và nhà phát triểnThường có sự mâu thuẫn giữa người phát triển và khách hàngNgườ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 - HUI20Chất lượng dưới nhiều góc độBM HTTT - Khoa CNTT - HUI21Bill of Rights for Software CustomersExpect 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 - HUI22Khách hàng với Thu nhận yêu cầuXác định tầm quan trọng của quan điểm khách hàngLà một kỹ thuật đòi hỏi nhiều kiến thứcBM HTTT - Khoa CNTT - HUI23Các bước tìm hiểu khách hàngNhận biết các lớp người dùng khác nhauXá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 - HUI24Các khó khăn khi thu thậpViệ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ển xâ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ầnNhà 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 - HUI25Managing the Customer RelationshipCần phải bảo đảm được sự hợp tác của khách hàng để có thể thu nhận được chuyên môn nghiệp vụ (domain expertise)Ví dụ: nếu 1 dự án có lịch biểu cố định và mối quan hệ với khách hàng không được tốt  việc tiếp nhận về chuyên môn bị hạn chế, dẫn đến kết thúc dự án bị quá hạnIt is out experience that constant communication with the customerBM HTTT - Khoa CNTT - HUI26Phân loại yêu cầu của khách hàngKhô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 - HUI27Chín loại yêu cầu của khách hàngBM HTTT - Khoa CNTT - HUI28Tránh làm phiền đến đời sống và công việc thường ngày của khách hàngChuẩ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ếtKhông được tùy tiện để lộ thông tin của khách hàng ra ngoài.Nguyên tắc khi thu thập thông tin khách hàng29Cá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 analystNhà phân tích yêu cầu - Requirements analyst 30Nhà phân tích là người chuyển các ý tưởng thành nhữ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ầnLà 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 stakeholderHọ như là một cầu nối giữa cộng đồng khách hàng và đội phát triển phần mềm.Nhà phân tích đóng vai trò trung tâm trong việc thu 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 đạo trong việc truyền đạt thông tin dự ánVai trò của analyst31Requirements analyst 32Nhiệm vụ của nhà phân tíchAnalyst 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ãnBM HTTT - Khoa CNTT - HUI33Xá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 requirementsViết đặc tả yêu cầu-Write requirements specificationsMô 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 validationPhân loại ưu tiên các yêu cầu- Facilitate requirements prioritizationQuản lý yêu cầu - Manage requirementsAssignment ?? Nhiệm vụ của Requirements analyst 34Kỹ năng lắng nghe - Listening skillKỹ năng phỏng vấn - Interviewing and questioning skillKỹ 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 skillsKỹ năng tổ chức - Organizational skillsKỹ năng mô hình hóa - Modeling skillsKỹ năng giao tiếp - Interpersonal skillsTính sáng tạo - CreativityAssignment ?? Kỹ năng của nhà phân tích 35Phân loại người dùngDự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ẩmKinh nghiệm về miền ứng dụng của họ, sự thành thạo về hệ thống máy tínhCác tính năng mà người dùng sử dụngCác tác vụ để hỗ trợ xử lý nghiệp vụQuyền truy xuất và cấp độ bảo mậtBM HTTT - Khoa CNTT - HUI36Phân cấp người dùngBM HTTT - Khoa CNTT - HUI37Kinh nghiệm phân loại người dùngNê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ùngKhô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 reworkGhé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 - HUI38Tài liệu người dùngGhi 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 - HUI39Các lớp người dùng trong hệ thống Chemical trackingBM HTTT Khoa CNTT - HUI40Tìm đại diện người dùngMỗ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ự ánBM HTTT Khoa CNTT - HUI41Đại diện lớp người dù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ênNê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 - HUI42Focus GroupPhả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ệmNế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ĩ đếnBM HTTT Khoa CNTT - HUI43Người dùng tiêu biểu PCPC (Product champion) dùng để chỉ những thành viê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ông phải là người đại diện như nhà tài trợ, nhân viên tiếp thị, người quản lý BM HTTT - Khoa CNTT - HUI44Vai trò của Product Champiom(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 - HUI45Một PC tốtCó 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ôi trườ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 - HUI46PC bên ngoàiKhi 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ệcBM HTTT - Khoa CNTT - HUI47Quyền hạn của product championPhươ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 minhNế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ấtBM HTTT - Khoa CNTT - HUI48Hạn chế tử PCLà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ần nhận biết yêu cầu cơ bản chung cho mọi khách hàng, sau đó xác định các yêu cầu khác từ các loạ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 - HUI49Hệ thống theo dõi hóa chất (Chemical Tracking)BM HTTT - Khoa CNTT - HUI50Giao tiếp giữa user và developerBM HTTT - Khoa CNTT - HUI51Vấ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 - HUI52Vấn đề về kỹ sư/nhà phát triểnTrong quá trình phân tích yêu cầu, các vấn đề sau có thể nảy sinh từ phía các kỹ sư và nhà phát triển:Nhân viên kỹ thuật và người dùng cuối có thể có ngôn từ khác nhau. Kết quả là họ có thể tin rằng họ hoàn toàn đồng thuận cho đến khi sản phẩm hoàn thiện được đưa ra.Các kỹ sư và nhà phát triển có thể cố lái cho các yêu cầu khớp với một hệ thống hay mô hình sẵn có, thay vì phát triển một hệ thống theo sát nhu cầu của khách hàngViệc phân tích có thể do các kỹ sư hoặc lập trình viên thực hiện, thay vì các nhân viên có kỹ năng và kiến thức miền ứng dụng để có thể hiểu các nhu cầu của khách hàng một cách đúng đắnBM HTTT - Khoa CNTT - HUI53Một số hướng giao tiếp giữa người dùng và nhà phát triểnCó một số lớp trung gian (intervening layers) giữa người dùng cuối và nhà phát triển.Có những lớp trung gian làm tăng khả năng hiểu sai lệch yêu cầuVí dụ; yêu cầu đến từ người quản lý người dùng cuối có thể phản ánh không chính xác nhu cầu thực của người dùng.BM HTTT - Khoa CNTT - HUI54Một số hướng giao tiếp giữa người dùng và nhà phát triểnCó những lớp trung gian làm tăng giá trị của các yêu cầu thu thập đượcVí dụ: RA khi giao tiếp với người dùng đã thu thập, đánh giá, tinh chỉnh và sắp xếp lại yêu cầu thu thập được.BM HTTT - Khoa CNTT - HUI55Một số hướng giao tiếp giữa người dùng và nhà phát triểnĐể thuận tiện trong giao tiếp, nên sử dụng từ vựng miền nghiệp vụ của khách hàng thay vì cố buộc khách hàng phải hiểu thuật ngữ máy tính.Nên dưa các thuật ngữ nghiệp vụ (domain terms) vào glossary.BM HTTT - Khoa CNTT - HUI56You are a product manager for a machine tool company. The directors have asked you to 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:a. Who are your key stakeholders?b. How will you analyse and validate your stakeholder list?Exercise57Thực hànhBạn là người quản lý sản phẩm cho một công ty công cụ máy. Giám đốc yêu cầu bạn phát triển một máy cắt mới quần áo để may váy thời trang theo các kích cỡ và mẫu. Máy được bán cho những người làm quần áo khắp thế giớiCác stakeholder?Phân tích và đánh giá các stakeholder?BM HTTT - Khoa CNTT - HUI58Answer #1Key stakeholders are:Giám đốc và các cổ đông trong công tyNhân viên bán hàng và tiếp thị của công tyKhách hàng (những người vận hành máy cắt và chủ của họ)Quan chức chính quyền phụ trách về sức khỏe và an toàn trong mỗi quốc gia mà ta dự định bán máy cho họ. Các đối thủ cạnh tranh (negative stakeholders).Nếu công ty có ý định đảm nhận thêm khâu bảo trì máy móc thì đội bảo hành cũng là stakeholder chính. Answer #1How will you analyse and validate your stakeholder list?Kiểm tra (check) và cập nhật (update) danh sách một cách thường xuyên; duyệt lại (review) và theo dõi (follow) thông qua các cuộc tiếp xúc gặp gỡ với stakeholder chínhTrang 34Goal và requirementGoals là cái mà stakeholders muốn thực thi. Goals có thể có nhiều mức độ khác nhau:Mức cao nhất (highest level): phát biểu về nhiệm vụ và mục tiêu, chính là mission statements and objectives.(Có thể dùng Mission = vision = objective) Mục tiêu lâu dài thì được gọi là policies.Mức thấp nhất (lowest level): gọi là chức năng cơ bản riêng biệt (individual functions)BM HTTT - Khoa CNTT - HUI61Goal và requirementMục tiêu chi tiết sẽ trở thành requirement khi:Có thể kiểm chứng được (fully verifiable)Được xếp loại ưu tiên trong 1 dự án cụ thểBM HTTT - Khoa CNTT - HUI62Tầm quan trọng của goal• Projects that lack clear goals struggle constantly to understand what their real requirements are, and are unlikely to discover them.• Projects without goals are vulnerable to pressure to add requirements, even if they don’t have the time or money for more work.BM HTTT - Khoa CNTT - HUI63Mục tiêu - Ví dụGame cho phép các thành viên trong gia đình chơi dễ dàng. Game dành cho những gia đình có trẻ 5-7 tuổi, họ có thể bắt đầu chơi sau 3 phút khởi động. Tiêu chuẩn chấp nhận: qua kiểm thử tính sử dụngNhững người phát hành game cho phép khách hàng thỏa mãn nhiều hơn bằng cách sử dụng SOA (service-oriented architecture)BM HTTT - Khoa CNTT - HUI64Question 2You are a product manager for a machine tool company. The directors have asked you to 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.a. What are the major goals for this project?b. Using the list of stakeholders for this project, identify the likely sources of tension (possible conflict) between stakeholders’ goals.Answer #2Major goals: Đưa máy cắt ra thị trường đúng lúc và trong ngân sách dự tínhPhát triển 1 dòng sản phẩm mới.Đạt được chứng nhận an toàn (safety certificate) ở tất cả các quốc gia dư định bán máy. Hiểu được yêu cầu trong từng quốc gia mà ta dự định bán máy,Chuẩn bị tài liệu cho người dùng và người bán hàng bằng nhiều thứ tiếng tương ứng với các quốc gia mà ta dự định bán máy. Bảo đảm là bộ phận bảo hà