Upload
buicong
View
231
Download
5
Embed Size (px)
Citation preview
Thu nhận yêu cầu
1. Xác định những người liên quan (stakeholder)2. Hiểu nhu cầu khách hàng3. Thu nhận yêu cầu từ khách hàng4. Mục tiêu (Goal) và yêu cầu5. Product Vision và Project Scope6. Phương pháp hệ thống mềm
Nội dung
2
Thu nhận yêu cầu
1. 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ô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ống Stakeholder:users, operators, bill payers, owners, regulatory agencies, victims, sponsors, maintainers, architects, managers, customers, surrogate customers …
4
Thu nhận yêu cầu
© 2009 Bahill
Các stakeholder của Boeing 787
Users: passengers that fly on the airplane Operators: fight crews and mechanicsBill payers: airline companiesOwners: stockholders of these companies Regulators: FAASponsor: corporate headquartersMaintenance: ground crewVictims: people living near the airports…
5
Thu nhận yêu cầu
Các stakeholder khác
Users and operators: employees in the manufacturing plantBill payer: BoeingOwner: stockholders of BoeingRegulators: OSHAVictims: physically and emotionally injured workersAir traffic control tower
7
Thu nhận yêu cầu
• Customers• Users • Requirements analysts• Developers• Testers• Documentation writers• Project managers• Legal staff• Manufacturing people• Sales, marketing, field support, help desk, …
Stakeholder
8
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á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àng…
Thu nhận yêu cầu
Stakeholder
Stakeholder 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ụ
Thu nhận yêu cầu
2. 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á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àng
13
Thu nhận yêu cầu
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)
Khách hàng là ai?
15
Thu nhận yêu cầu
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ì
Khách hàng ở cấp quản lý
16
Thu nhận yêu cầu
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 cho công việc của họ và những mong đợi về chất lượng từ sản phẩm
Khách hàng là người dùng cuối
17
Thu nhận yêu cầu
Thườ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.
Đặc tính của khách hàng
18
Thu nhận yêu cầu
Thườ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 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.
Đặc tính của khách hàng
19
Thu nhận yêu cầu
Thườ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ọ
Quan hệ khách hàng và nhà phát triển
20
Thu nhận yêu cầu
Chất lượng dưới nhiều góc độ
QUALITY SOFTWARE
Developer:easy to design; easy to maintain; easy to reuse its parts
User: easy to learn; efficient to use; helps get work done
Customer:solves problems at an acceptable cost in terms of money paid and resources used
Development manager:sells more and pleases customers while costing less to develop and maintain
Thu nhận yêu cầu
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...
22
Thu nhận yêu cầu
3. 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àngLà một kỹ thuật đòi hỏi nhiều kiến thức
23
Thu nhận yêu cầu
1. Nhận biết các lớp người dùng khác nhau2. Xác định các nguồn của yêu cầu người dùng. 3. 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.4. Thỏa thuận các yêu cầu với người ra quyết định
của dự án.
Các bước tìm hiểu khách hàng
24
Thu nhận yêu cầu
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ể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ần
Các khó khăn khi thu thập
25
Thu nhận yêu cầu
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
Nhiệm vụ của nhà phân tích
26
Thu nhận yêu cầu
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ẩ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ật
Phân loại người dùng
27
Thu nhận yêu cầu
PC (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ý …
Người dùng tiêu biểu PC
30
Thu nhận yêu cầu
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ô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.
Một PC tốt
31
Thu nhận yêu cầu
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
PC bên ngoài
32
Thu nhận yêu cầu
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ầ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ẻ,…
Cầu lưu ý
33
Thu nhận yêu cầu
Bạn là người quản lý sản phẩm cho một công ty công cụ máy. Gáim đố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ới
Các stakeholder?Phân tích và đánh giá các stakeholder?
Thực hành
35
Thu nhận 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
4. Mục tiêu (Goal) và yêu cầu
36
Thu nhận yêu cầu
Mục tiêu chi tiết sẽ trở thành yêu cầu nó cần có đặc tính:
Có thể kiểm chứng đượcPhân loại ưu tiên
Mục tiêu và yêu cầu
Thu nhận yêu cầu
Mụ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)
Thu nhận yêu cầu
Phân biệt giữa yêu cầu nghiệp vụ và yêu cầu phần mềmThường các yêu cầu phần mềm được lưu trữ cho các hệ thống phần mềm hiện có hoặc tương lai 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óaBằng tay
Yêu cầu nghiệp vụ
41
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ương, quản lý điểm…Thực hiện bằng tay: ví dụ đánh giá tổn hại nhân thọ, đánh giá rủi ro (nhưng có thể lưu trữ)…
42
Thu nhận yêu cầu
Mục tiêu nghiệp vụ của người quản lý kiosk:Tạo ra doanh thu bằng cách cho thuê hay bán các kiosk cho ngững người bán lẻBán hàng tiêu dùngThu hút khách hàng đến các thương hiệu hàng hóaCung cấp các hàng hóa đa dạng
Phần mềm quản lý Kiosk
43
srse
Thu nhận yêu cầu
Mục tiêu nghiệp vụ của người bán lẻ:Thu lợi nhuận cao nhất từ diện tích mặt bằng đang cóThu hút khách hàngÁp dụng hệ thống thông tin để tăng doanh số và lợi nhuận
Phần mềm quản lý Kiosk
44
Thu nhận yêu cầu
Người quản lý muốn tạo 1 hướng mới năng động, kỹ thuật cao cho khách hàng, còn người bán lẻ thì 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.
Xung đột
45
Thu nhận yêu cầu
Xung đột mục tiêu nên được phát hiện sớm từ các stakeholder và việc phân tích mục tiêu, cách giải quyết sẽ được khi đưa ra trong dự thảo thiết kếTrong một số trường hợp chỉ cần một phác thảo đơ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
Giải quyết xung đột
46
Thu nhậ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)
Quy trình phát triển yêu cầu
47
Thu nhận yêu cầu
Vision (hay mission) mô tả thực chất sản phẩm sẽ là gìProject scope xác định một phần của product vision dài hạnVision 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ệ thống, còn scope trong quá trình phát triển tăng tiến chỉ liên quan đến một lần lặp
5. Product Vision và Project Scope
48
Thu nhận yêu cầu
Tài liệu về vision và scope chứa các yêu cầu nghiệp vụ, xác định các giai đoạn phát triểnCác tài liệu khác có cùng mục đích:
Project charter Business case documentMarket requirements document (MRD)
Tài liệu về vision và scope
51
Thu nhận yêu cầu
Chủ nhân của tài liệu vision và scope là:Người tài trợ (sponsor) của dự ánNgười chi tiền (funding authority)
Người phân tích yêu cầu có thể làm việc với người chủ để viết tài liệu vision và scope.
Tài liệu về vision và scope
52
Thu nhận yêu cầu
Khách hàngNgười có trách nhiệm trong bô phận quản lýNgười hình dung của dự ánQuản lý sản phẩmCác chuyên gia lãnh vụcThành viên của bộ phận marketing
Người tham gia
53
Thu nhận yêu cầu
Một trong các rủi ro lớn nhất của hệ thống là để cho phạm vi “phình dần ra”, không ai biết chính xác hệ thống bao gồm những gì, mất bao lâu và chi phí bao nhiêu để hoàn tất
Lưu ý
54
Thu nhận yêu cầu
Thực hành
1.1 Lý do chính khi đưa ra sản phẩm?1.2 Sự hấp dẫn đối với thị trường1.3 Mục tiêu thị trường và những điều kiện cho thành công1.4 Nhu cầu (marketplace competition, timing issues, user acceptance, implementation issues…)2.1 For [target customer]Who [statement of the need or opportunity]The [product name]Is [a product category]That [key benefit, compelling reason to buy or use]Unlike [primary competitive alternative, current system, or current business process],Our product [statement of primary differentiation and advantages of new product].
56
Thu nhận yêu cầu
Thực hành
2.2 những khác biệt, những đặc trưng mới2.3 giả định: dự định thay thế hệ thống nào đó…, phụ thuộc vào qui định chờ ban hành, chính sách…3.3 giới hạn và loại trừ4.1 những nhóm người nào được những lợi ích gì4.2 những gì là bắt buộc, có thể điều chỉnh… (features (or scope), quality, schedule, cost, and staff)
57
Thu nhận yêu cầu
6. Phương pháp hệ thống mềm
Hệ thống mềm (soft system) bao gồm những vấn đề nhạy cảm về xã hội, chính trị cũng như kỹ thuật. Nó bao gồm không chỉ sản phẩm hay dịch vụ mà cả con người các thủ tục và các mối quan hệ của con người với nhau
58
Thu nhận yêu cầu
Phương pháp luận hệ thống mềm SSM (Soft Systems Methodology - Checkland)Khuyên chúng ta nhìn hệ thống một cách mềm dẽo Ta nên luôn tự hỏi liệu chúng ta có sai không, và nên triển khai các mô hình và khả năng khác nhau.
Phương pháp SSM
60
Thu nhận yêu cầu
1. Bắt đầu bằng mô hình bức tranh phong phú (rich picture)
2. Từ những người liên quan xác định biên3. Xác định giao tiếp4. Đánh giá chọn lựa biên
Các bước SSM
61
Thu nhận yêu cầu
1. Bắt đầu bằng mô hình bức tranh phong phúMô hình chỉ ra những gì đang xảy ra trong nghiệp vụBiểu diễn ngữ cảnh và phạm vi thông dụng không chính quyChứa các khái niệm và vấn đề có liên quan được stakeholder đề cập đến.
Bước 1
62
Thu nhận yêu cầu
1. Bạn là 1 phần của hệ thống mềm mà bạn đang quan sát.
Bạn có thể đưa vào sự can thiệp của bạn và cải thiện chính hệ thống đang quan sát.SSM có thể xác định nhu cầu sản phẩm của hệ thống rộng hơn. Nếu đường biên của hệ thống càng rộng thì hệ thống càng trở nên mềm hơn.
Đặc điểm của Bức tranh phong phú
64
Thu nhận yêu cầu
2. Từ stakeholder đến biênMột số stakeholder quan trọng tuy không trực tiếp vận hành sản phẩm như giám đốc công ty nhưng có thể gây áp lực cho người quản lý phần mềm. Chỉ 1 ít sản phẩm là thực sự độc lập còn hầu hết được vận hành bởi con người và tuân theo các quy tắc và thủ tục nào đó. • Máy bay, robot sản xuất, cũng cần được lắp đặt,
cấu hình, kiểm thử và bảo trì bởi con người.
Đặc điểm của Bức tranh phong phú (2)
65
Thu nhận yêu cầu
Hệ thống thường gồm những thành phần sau cùng làm việc với nhau:
Một hay nhiều sản phẩmMột số người vận hànhCác quy tắc và thủ tục cho biết làm cái gì trong những hoàn cảnh khác nhau.
Thường có nhiều người vận hành và kết hợp với nhau để cung cấp các dịch vụ.
B2. Xác định biên: Hệ thống
66
Thu nhận yêu cầu
Tùy vào ngữ cảnh, dự án có thể mở rộng phạm vi hơn, chứa nhiều khả năng hơn bên trong phạm vi.
Xác định phạm vi hệ thống
68
Thu nhận yêu cầu
Kết hợp các stakeholder thích hợp lại với nhau, ví dụ đội bay và đội bảo trìQuyết định chọn lựa và cân đối các phạm vi đã phác thảoXác định phạm vi và giao tiếp của hệ thống.
B3. Xác định giao tiếp
69
Thu nhận yêu cầu
Giao tiếp giữa hệ thống bảo trì và hệ thống aircraft bây giờ là nội bộ.
Hệ thống Bảo trì và giả lập/ huấn luyện là các hệ thống conDự án sẽ phải thiết kế giao diện cho cả Hệ thống Bảo trì và giả lập/ huấn luyện
Ví dụ về giao tiếp
70
Thu nhận yêu cầu
Giao diện với hệ thống bảo trì nên:Tương tự như các giao diện của aircraft khác, nhằm tối thiểu hóa nhu cầu xây dựng công cụ mới, trang thiết bị và huấn luyện Nó có thể có thiết kế đặc biệt thích hợp nhằm tối đa hóa tính hiệu quả của việc bảo trì
Ví dụ về giao tiếp
71