Thu nhận các yêu cầu

CHƯƠNG II Stakeholder-VisionAndScope

Thu nhận yêu cầu

TNYC

Nội dung

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àng 3. Thu nhận yêu cầu từ khách hàng 4. Mục tiêu (Goal) và yêu cầu 5. Product Vision và Project Scope 6. Phương pháp hệ thống mềm

Qui trình

1. Xác định những người liên quan

Thu nhận yêu cầu

(cid:153) 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

(cid:153) Stakeholder:

users, operators, bill payers, owners, regulatory agencies, victims, sponsors, maintainers, architects, managers, customers, surrogate customers …

Các stakeholder của Boeing 787

Thu nhận yêu cầu

(cid:153) Users: passengers that fly on the airplane (cid:153) Operators: fight crews and mechanics (cid:153) Bill payers: airline companies (cid:153) Owners: stockholders of these companies (cid:153) Regulators: FAA (cid:153) Sponsor: corporate headquarters (cid:153) Maintenance: ground crew (cid:153) Victims: people living near the airports…

5 © 2009 Bahill

Cần quan tâm tới qui trình

Thu nhận yêu cầu

Các stakeholder khác

Thu nhận yêu cầu

(cid:153) Users and operators: employees in the

manufacturing plant

(cid:153) Bill payer: Boeing (cid:153) Owner: stockholders of Boeing (cid:153) Regulators: OSHA (cid:153) Victims: physically and emotionally injured

workers

(cid:153) Air traffic control tower

Stakeholder

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 của hệ thống ATM

Thu nhận yêu cầu

(cid:153) Khách hàng của ngân hàng (cid:153) Đại diện của các ngân hàng khác (cid:153) Người quản lý ngân hàng (cid:153) Nhân viên thu tiền (cid:153) Người quản trị CSDL (cid:153) Người quản lý bảo mật (cid:153) Kỹ sư bảo trì phần cứng và phần mềm (cid:153) Những người điều phối ngân hàng…

Stakeholder

Thu nhận yêu cầu

(cid:153) Stakeholder không rõ những gì họ thật sự muốn (cid:153) Stakeholder diễn đạt yêu cầu theo những thuật

ngữ riêng của họ

(cid:153) Những stakeholder có thể có những yêu cầu tranh

chấp

(cid:153) Nhân tố quyền lực và tổ chức ảnh hưởng tới yêu

cầu hệ thống

(cid:153) Nhữ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ụ

Thực hành

Thu nhận yêu cầu

Xác định stakeholder

Qui trình

2. Hiểu nhu cầu của khách hàng

Thu nhận yêu cầu

(cid:153) 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ọ

(cid:153) 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

Phát biểu của khách hàng

Thu nhận yêu cầu

(cid:153) Khách hàng nói

(cid:153) Cái mà họ thật sự cần

Khách hàng là ai?

Thu nhận yêu cầu

(cid:153) 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.

(cid:153) Hai loại khách hàng phần mềm:

(cid:131) Khách hàng cấp quản lý (management level) (cid:131) Người dùng cuối (end user)

Khách hàng ở cấp quản lý

Thu nhận yêu cầu

(cid:153) Thường là những khách hàng trả tiền hay tài trợ

dự án phần mềm.

(cid:153) Khách hàng ở cấp quản lý có nhiệm vụ xác định

hay các stakeholder muốn hoàn thành.

(cid:131) Xác lập các thành phần chính cho phần còn lại của

dự án

yêu cầu nghiệp vụ (cid:131) Mô tả mục tiêu nghiệp vụ mà khách hàng, công ty

(cid:153) 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 là người dùng cuối

Thu nhận yêu cầu

(cid:153) Bao gồm tất cả những ai sẽ thực sự sử dụng sản

phẩm

(cid:153) 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

Đặc tính của khách hàng

Thu nhận yêu cầu

(cid:153) 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.

(cid:153) Đô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

Thu nhận yêu cầu

(cid:153) 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.

(cid:153) 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 (cid:198) 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ư ý…

(cid:153) 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.

(cid:153)

Quan hệ khách hàng và nhà phát triển

Thu nhận yêu cầu

(cid:153) Thường có sự mâu thuẫn giữa người phát triển và

khách hàng

(cid:153) 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ọ

Chất lượng dưới nhiều góc độ

Thu nhận yêu cầu

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

QUALITY SOFTWARE

Developer: easy to design; easy to maintain; easy to reuse its parts

Development manager: sells more and pleases customers while costing less to develop and maintain

Bill of Rights for Software Customers

Thu nhận yêu cầu

(cid:153) Expect analysts to speak your language. (cid:153) Expect analysts to learn about your business and

your objectives for the system.

(cid:153) Have analysts explain all work products created

from the requirements process.

(cid:153) Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product.

(cid:153) Describe characteristics of the product that will

make it easy and enjoyable to use...

3. Khách hàng với Thu nhận yêu cầu

Thu nhận yêu cầu

(cid:153) Xác định tầm quan trọng của quan điểm khách

hàng

(cid:153) Là một kỹ thuật đòi hỏi nhiều kiến thức

Các bước tìm hiểu khách hàng

Thu nhận yêu cầu

1. Nhận biết các lớp người dùng khác nhau 2. 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 khó khăn khi thu thập

Thu nhận yêu cầu

(cid:153) Việc không phù hợp giữa sản phẩm mà khách

thực sự cần

hàng mong đợi và sản phẩm mà nhà phát triển xây dựng thường do: (cid:131) Thiếu sự quan tâm của khách hàng. (cid:131) Khách hàng thường không biết chính xác cái họ

Nhiệm vụ của nhà phân tích

Thu nhận yêu cầu

(cid:153) 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

Phân loại người dùng

Thu nhận yêu cầu

(cid:131) Mức độ thường xuyên người dùng sử dụng sản

phẩm

(cid:131) Kinh nghiệm về miền ứng dụng của họ, sự thành

thạo về hệ thống máy tính

(cid:131) Các tính năng mà người dùng sử dụng (cid:131) Các tác vụ để hỗ trợ xử lý nghiệp vụ (cid:131) Quyền truy xuất và cấp độ bảo mật

(cid:153) Dựa vào các yếu tố sau:

Phân cấp người dùng

Thu nhận yêu cầu

Giao tiếp giữa user và developer

Thu nhận yêu cầu

Người dùng tiêu biểu PC

Thu nhận yêu cầu

(cid:153) 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.

(cid:153) 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ý …

Một PC tốt

Thu nhận yêu cầu

(cid:153) 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.

(cid:153) Là người cởi mở và được đồng nghiệp tín nhiệm. (cid:153) 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.

(cid:153) 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.

PC bên ngoài

Thu nhận yêu cầu

(cid:153) Khi phát triển phần mềm thương mại, rất khó tìm

PC từ bên ngoài.

(cid:153) 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.

(cid:153) 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

Cầu lưu ý

Thu nhận yêu cầu

(cid:153) 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. (cid:153) 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ẻ,…

Hệ thống theo dõi hóa chất (Chemical Tracking)

Thu nhận yêu cầu

Thực hành

Thu nhận yêu cầu

(cid:153) 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 (cid:131) Các stakeholder? (cid:131) Phân tích và đánh giá các stakeholder?

4. Mục tiêu (Goal) và yêu cầu

Thu nhận yêu cầu

(cid:131) Mức cao nhất: phát biểu về nhiệm vụ và mục tiêu (cid:131) Mức thấp nhất: những chức năng riêng biệt

(cid:153) Mục tiêu là cái mà stakeholder muốn thực thi. (cid:153) Mục tiêu có thể có nhiều mức độ khác nhau:

Mục tiêu và yêu cầu

Thu nhận yêu cầu

(cid:153) Mục tiêu chi tiết sẽ trở thành yêu cầu nó cần có

đặc tính: (cid:131) Có thể kiểm chứng được (cid:131) Phân loại ưu tiên

Mục tiêu - Ví dụ

Thu nhận yêu cầu

(cid:153) 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ụng

(cid:153) Nhữ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)

Dr 54-75

Mục tiêu và yêu cầu

Thu nhận yêu cầu

Yêu cầu nghiệp vụ

Thu nhận yêu cầu

(cid:153) Phân biệt giữa yêu cầu nghiệp vụ và yêu cầu phần

mềm

(cid:153) Thườ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ụ.

(cid:153) Yêu cầu nghiệp vụ (cid:131) Tự động hóa (cid:131) Bằng tay

Ví dụ

Thu nhận yêu cầu

(cid:153) Tự động hóa: các nghiệp vụ thường kỳ như tính

lương, quản lý điểm…

(cid:153) 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ữ)…

srse

Phần mềm quản lý Kiosk

Thu nhận yêu cầu

(cid:131) 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ẻ

(cid:131) Bán hàng tiêu dùng (cid:131) Thu hút khách hàng đến các thương hiệu hàng hóa (cid:131) Cung cấp các hàng hóa đa dạng

(cid:153) Mục tiêu nghiệp vụ của người quản lý kiosk:

Phần mềm quản lý Kiosk

Thu nhận yêu cầu

(cid:131) Thu lợi nhuận cao nhất từ diện tích mặt bằng đang

có

(cid:131) Thu hút khách hàng (cid:131) Áp dụng hệ thống thông tin để tăng doanh số và

lợi nhuận

(cid:153) Mục tiêu nghiệp vụ của người bán lẻ:

Xung đột

Thu nhận yêu cầu

(cid:153) 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.

(cid:153) 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.

Giải quyết xung đột

Thu nhận yêu cầu

(cid:153) 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ế (cid:153) 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?

(cid:153) 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

Quy trình phát triển yêu cầu

Thu nhận yêu cầu

(cid:153) Trước khi thực hiện quy trình này, analyst cần

phải xác định : (cid:131) Product Vision ≅ product goal (mục tiêu) (cid:131) Project scope ≅ boundaries (phạm vi dự án)

5. Product Vision và Project Scope

Thu nhận yêu cầu

(cid:153) Vision (hay mission) mô tả thực chất sản

phẩm sẽ là gì

(cid:153) Project scope xác định một phần của product

vision dài hạn

(cid:153) 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ệ 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

Thu nhận yêu cầu

Product vision và Project scope

Thu nhận yêu cầu

Tài liệu về vision và scope

Thu nhận yêu cầu

(cid:153) 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ển

(cid:131) Project charter (cid:131) Business case document (cid:131) Market requirements document (MRD)

(cid:153) Các tài liệu khác có cùng mục đích:

Tài liệu về vision và scope

Thu nhận yêu cầu

(cid:131) Người tài trợ (sponsor) của dự án (cid:131) Người chi tiền (funding authority)

(cid:153) Chủ nhân của tài liệu vision và scope là:

(cid:153) 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.

Người tham gia

Thu nhận yêu cầu

(cid:153) Khách hàng (cid:153) Người có trách nhiệm trong bô phận quản lý (cid:153) Người hình dung của dự án (cid:153) Quản lý sản phẩm (cid:153) Các chuyên gia lãnh vục (cid:153) Thành viên của bộ phận marketing

Lưu ý

Thu nhận yêu cầu

(cid:153) 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

srse

Mẫu tài liệu vision và scope

Thu nhận yêu cầu

Thực hành

Thu nhận yêu cầu

(cid:153) 1.1 Lý do chính khi đưa ra sản phẩm? (cid:153) 1.2 Sự hấp dẫn đối với thị trường (cid:153) 1.3 Mục tiêu thị trường và những điều

kiện cho thành công (cid:153) 1.4 Nhu cầu (marketplace

competition, timing issues, user acceptance, implementation issues…)

(cid:153) 2.1 (cid:153) For [target customer] (cid:153) Who [statement of the need or opportunity] (cid:153) The [product name] (cid:153) Is [a product category] (cid:153) That [key benefit, compelling reason to buy or use] (cid:153) Unlike [primary competitive alternative, current

system, or current business process],

(cid:153) Our product [statement of primary differentiation

and advantages of new product].

Thực hành

Thu nhận yêu cầu

(cid:153) 2.2 những khác biệt, những đặc trưng

mới

(cid:153) 2.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…

(cid:153) 3.3 giới hạn và loại trừ (cid:153) 4.1 những nhóm người nào được

những lợi ích gì

(cid:153) 4.2 những gì là bắt buộc, có thể điều chỉnh… (features (or scope), quality, schedule, cost, and staff)

6. Phương pháp hệ thống mềm

Thu nhận yêu cầu

(cid:153) 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.

(cid:153) 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

Quá trình phát triển

Thu nhận yêu cầu

Phương pháp SSM

Thu nhận yêu cầu

(cid:153) Phương pháp luận hệ thống mềm SSM (Soft

Systems Methodology - Checkland)

(cid:153) Khuyên chúng ta nhìn hệ thống một cách mềm

dẽo

(cid:153) 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.

Các bước SSM

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ên 3. Xác định giao tiếp 4. Đánh giá chọn lựa biên

Bước 1

Thu nhận yêu cầu

(cid:131) Mô hình chỉ ra những gì đang xảy ra trong nghiệp

vụ

(cid:131) Biểu diễn ngữ cảnh và phạm vi thông dụng không

chính quy

(cid:131) Chứa các khái niệm và vấn đề có liên quan được

stakeholder đề cập đến.

1. Bắt đầu bằng mô hình bức tranh phong phú

Đặc điểm của Bức tranh phong phú

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

thiện chính hệ thống đang quan sát.

(cid:131) 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.

quan sát. (cid:131) Bạn có thể đưa vào sự can thiệp của bạn và cải

Đặc điểm của Bức tranh phong phú (2)

Thu nhận yêu cầu

(cid:131) Mộ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.

(cid:131) 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,

2. Từ stakeholder đến biên

cấu hình, kiểm thử và bảo trì bởi con người.

B2. Xác định biên: Hệ thống

Thu nhận yêu cầu

(cid:153) Hệ thống thường gồm những thành phần sau

những hoàn cảnh khác nhau.

cùng làm việc với nhau: (cid:131) Một hay nhiều sản phẩm (cid:131) Một số người vận hành (cid:131) Các quy tắc và thủ tục cho biết làm cái gì trong

(cid:153) 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ụ.

Ví dụ một vài hệ thống

Thu nhận yêu cầu

Xác định phạm vi hệ thống

Thu nhận yêu cầu

(cid:153) 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.

B3. Xác định giao tiếp

Thu nhận yêu cầu

(cid:153) 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ì

(cid:153) Quyết định chọn lựa và cân đối các phạm vi đã

phác thảo

(cid:153) Xác định phạm vi và giao tiếp của hệ thống.

Ví dụ về giao tiếp

Thu nhận yêu cầu

(cid:153) Giao tiếp giữa hệ thống bảo trì và hệ thống

aircraft bây giờ là nội bộ. (cid:131) Hệ thống Bảo trì và giả lập/ huấn luyện là các

hệ thống con

(cid:131) Dự á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

Thu nhận yêu cầu

(cid:153) Giao diện với hệ thống bảo trì nên:

(cid:131) 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

(cid:131) 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ì

B4. Đánh giá chọn lựa biên

Thu nhận yêu cầu

(cid:131) Tại sao khó khăn? (cid:131) Tại sao then chốt?

(cid:153) Là nhiệm vụ khó khăn và then chốt