Product vision là gì

Software Requirements Full cóp nhặt trên In tờ néttt

.oi0lOI

4 years ago

X

Privacy & Cookies

This site uses cookies. By continuing, you agree to their use. Learn more, including how to control cookies.

Got It!

Advertisements

Mỗi người chỉ được 5 phút để phát biểu.Tài liệu tham khảo

Lời thông báo ngày 14/01/2021

Mình bắt đầu cop nhặt các slide và tổng hợp vào bài này từ tháng 3.2018. Nội dung nhiều cái đã out of date, nhưng với newbie có thể vẫn còn chút giá trị tham khảo. Ngày hôm nay đã thực hiện xong. Cảm ơn vì đã ghé qua đọc.

Nếu cần slide có thể gửi mail cho mình nhé:

Xin cám ơn

1/ Tầm quan trọng của Yêu cầu phần mềm

Rất quan trọng, nên skip

2/ Yêu cầu phần mềm (Software Requirements) là gì?
Requirements: là đặc tả của cái gì cần được thực thi, mô tả hệ thống sẽ hoạt động như thế nào hay hệ thống có thuộc tính gì.
Yêu cầu cũng có thể là các ràng buộc trong quá trình phát triển hệ thống.

2.1. Phân loại yêu cầu:

2.2.Đặc trưng của yêu cầu

• Feasible
• Valid
• Unambiguous
• Verifiable
• Modifiable
• Consistent
• Complete
• Traceable

2.3.Các mức yêu cầu

SR bao gồm 3 mức phân biệt:

2.3.1. Business requirements

Biễu diễn các mục tiêu nghiệp vụ mà khách hàng, công ty hay các stakeholders yêu cầu hệ thống phải thực thi.
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 marketing.
Thường được ghi nhận trong phần vision và scope của tài liệu, đôi khi còn được gọi là project charter hay market requirements document.

2.3.2. User requirements

Mô tả mục tiêu (goal) hay nhiệm 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 descriptions,
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.

2.3.3. Functional requirements

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à behavioral requirements
Ví dụ: The system shall e-mail a reservation confirmation to the user.

2.3.4.System requirements

Mô tả yêu cầu mức cao đối 1 sản phẩm, nó chứa các hệ thống con (subsystem) nào.
Một hệ thống có thễ là toàn bộ phần mềm hay bao gồm các hệ thống con của phần mềm cũng như phần cứng.
Con người cũng là 1 phần hệ thống, vì vậy các chức năng hệ thống cũng có thể chỉ định cả vai trò của con người.

Mối liên hệ giữa các mức yêu cầu

Phân loại tài liệu về yêu cầu

3/ Kỹ thuật thu thập yêu cầu (Requirements Engineering) là gì?

Kỹ thuật thu thập yêu cầu liên quan đến tất cả các hoạt động có chu kỳ :

• Xác định yêu cầu của người dùng,
• Phân tích yêu cầu để suy diễn thêm các yêu cầu khác
• Đặc tả yêu cầu
• Kiểm tra xem yêu cầu vừa đặc tả có phù hợp với nhu cầu người dùng không

Các thành phần của requirement engineering:

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

Bốn hoạt động này có thể xen vào nhau (interleaved), tăng tiến (incremental), và lặp lại (iterative)

Ranh giới giữa phát triển và quản lý yêu cầu

4/ Phát triển và quản lý yêu cầu?

Hậu quả khi xác định yêu cầu sai

Hậu quả do xác định yêu cầu không đúng là phải rework (làm lại ) doing over something that you thought was already done.

Rework có thể mất 30 50% tổng chi phí phát triển dự án và lỗi do yêu cầu chiếm tới 70 85% chi phí làm lại.

Nguyên nhân dẫn đến xác định yêu cầu không đúng

• Insufficient User Involvement
• Creeping User Requirements
• Ambiguous Requirements
• Gold Plating
• Minimal Specification
• Overlooked User Classes
• Inaccurate Planning

5/ Lợi ích từ quy trình xác định yêu cầu chất lượng cao

(skip)

6/ Yêu cầu theo quan điểm khách hàng

Các hoạt động đầu tiên củarequirements engineering

• Phâ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ống

Khách hàng là ai?

Khách hàng (customer) là một cá nhân hay 1 tổ chức mong muốn hoặc 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 (Software customer) :

• Khách hàng dạng quản lý (Customer at management level):
  • Là loại 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ụ (business requirement)
• End user
  • Bao gồm tầt cả những ai sẽ thực sự sử dụng sản phẩm dù trực tiếp hay gián tiềp.
  • Users có thể mô tả nhiệm vụ mà họ cần thực thi với sản phẩm và chất lượng mà họ mong đợi từ sản phẩm

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

• Thường cả hai loại khách hàng này đều không tin là họ có thời gian đển 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 cùng nhau.
• Thường xung đột (conflict) có thể xuất hiện 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 hạn chề về tài chính mà người dùng có thể không nhìn thấy được à người dù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ư ý

Việc giao tiếp rõ ràng về mục tiêu và các ràng buộc của dự án có thể làm dịu đi các căng thẳng bức xúc của người dùng.

Nhà phân tích (analyst) nên làm việc với các đại 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.

Mối quan hệ giữa khách hàng và nhà phát triển

• Yêu cầu chất lượng cao có được từ sự quan hệ giao tiếp hiệu quả giữa nhà phát triển và khách hàng.
• Thường mối quan hệ giữa người phát triển và customers hay trở nên đối kháng (adversarial)
• Managers thường vượt quá các yêu cầu do người dùng cung cấp để phù hợp với lịch làm viêc̣ của chính họ.

Trách nhiệm và quyền lợi khách hàng phần mềm

Bảng tuyên ngôn quyền và trách nhiệm dành cho khách hàng (Requirements Bill of Rights/Responsibilities for Software Customers) liệt kê 10 điều mong đợi mà khách hàng có quyền khi tiếp xúc với và phát triển dự án cũng như10 trách nhiệm mà khách hàng phải thực hiện trong suốt quá trình thu thập yêu cầu của nhà phân tích.

7/ Vai trò của người phân tích yêu cầu (requirement analyst)

• Analyst là người chuyển (translator) các suy nghĩ của người nào đó thành đặc tả yêu cầu.
• Analyst là người phản ánh (reflector) thông tin đến 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ầ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 stakeholders.
• Analyst như 1 cầu nối giữa cộng đồng khách hàng và đội phát triển phần mềm.
• Analyst đóng vai trò trung tâm trong việc thu thập và phổ biến thông tin, còn project manager giữ vai trò lãnh đạo trong việc truyên đạt thông tin dự án.

Nhiệm vụ của Requirements analyst

Analyst 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.

• Define business requirements.
• Identify project stakeholders and user classes.
• Elicit requirements
• Write requirements specifications
• Model the requirements
• Lead requirements validation
• Facilitate requirements prioritization
• Manage requirements

Kỹ năng của nhà phân tích

• Listening skill
• Interviewing and questioning skill
• Analytical skill,
• Facilitation skills.
• Observational skills.
• Writing skills
• Organizational skills
• Modeling skills
• Interpersonal skills
• Creativity

8/Phân biệt goal và requirement

8.1/ Goals

Goals 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): 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 (individual functions)
• Mụ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ể

Tầ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 dont have the time or money for more work.

8.2. Requirements

Yêu cầu (Requirements) là một đặc tả về cái phải được thi công. Chúng là các mô tả về hành vi của hệ thống phải như thế nào, hoặc về một thuộc tính của hệ thống phải như thế nào. Yêu cầu có thể là một ràng buộc về quy trình phát triển của hệ thống

Yêu cầu phần mềm gồm 3 mức phân biệt

• Yêu cầu kinh doanh (business requirements, BR)
  • Biểu diễn các mục tiêu ở mức cao của tổ chức hoặc của khách hàng đối với hệ thống. Chúng được trích ra (capture) từ một tài liệu mô tả tầm nhìn (vision) và phạm vi (scope) của dự án.
  • BR cần thiết để dự tính nguồn vốn cho dự án.
  • BR được thu thập từ những cá nhân có thể trả lời câu hỏi tại sao cần có dự án này. Các cá nhân như vậy có thể là nhà tài trợ, khách hàng hoặc nhà quản lý cao cấp của tổ chức, những người hỗ trợ sản phẩm (product champions), các thành viên của bộ phận marketing.
• Yêu cầu người dùng (user requirements, UR)
  • UR mô tả các tác vụ(task) mà người dùng phải hoàn thành bằng cách sử dụng hệ thống như một công cụ làm việc. Chúng được trích ra trong các mô tả tình huống sử dụng (use case) hoặc kịch bản sử dụng
• Yêu cầu chức năng (functional requirements, FR) hoặc yêu cầu phi chức năng (NFR).
  • FR định nghĩa chức năng của phần mềm mà người phát triển cần phải đưa vào sản phẩm để người dùng hoàn thành tác vụ của họ, do đó mà đáp ứng các yêu cầu kinh doanh (BR). Một tính năng (feature) là một tập hợp logic các yêu cầu chức năng có liên quan lẫn nhau nhằm cung cấp cho người dùng khả năng (capability) đáp ứng một yêu cầu kinh doanh.

Một số rủi ro từ sự không đầy đủ của việc xác định Requirement

• Nếu các kiểu người dùng không được tính đến đầy đủ trong khi làm yêu cầu thì hệ thống có thể sẽ không được chấp nhận.
• Việc phát sinh các yêu cầu không chính thức (creeping user requirements) góp phần làm hỏng và giảm chất lượng sản phẩm.
• Các yêu cầu nhập nhằng dẫn tới tiêu phí nhiều thời gian để làm lại.
• Sự mạ vàng (gold plating) của người phát triển và người dùng sẽ thêm vào hệ thống các tính năng (features) không cần thiết.
• Các đặc tả tối thiếu dẫn tới các yêu cầu chính bị thiếu hụt (missing key requirements).
• Bỏ qua nhu cầu của một số kiểu người dùng nào đó sẽ dẫn tới sự không hài lòng của khách hàng.
• Các yêu cầu được định nghĩa không đầy đủ khiến đòi hỏi lập kế hoạch dự án chính xác và giám sát là không thể.

Các đặc tính của Requirement

• Đầy đủ(Complete): Mỗi yêu cầu cần mô tả đầy đủ chức năng được chuyển giao. Nó phải chứa tất cả các thông tin cần thiết để nhà phát triển thiết kế và thi công chức năng này.
• Đúng đắn (Correct): Mỗi yêu cầu cần mô tả chính xác chức năng được xây dựng
• Khả thi (Feasible): nghĩa là thực thi mỗi yêu cầu trong các khả năng và giới hạn đã biết của hệ thống và môi trường hoạt động của hệ thống.
• Cần thiết (Necessary): Mỗi yêu cầu cần phải tài liệu hoá một cái gì đó mà khách hàng thật sự cần hoặc một hệ thống khác bên ngoài cần
• Được xếp thứ tự ưu tiên (Prioritized): Gán một thứ tự ưu tiên cho mỗi yêu cầu, tính năng (feature), hoặc use-case để có thể hình dung lịch trình phát hành các phiên bản của sản phẩm.
• Không nhập nhằng (Unambigous): Tất cả những ai khi đọc bản báo cáo yêu cầu đều có cùng một cách hiểu, một cách diễn giải nhất quán về nội dung của các yêu cầu.
• Có thể kiểm tra (Verifiable) Hãy kiểm tra mỗi yêu cầu để xem liệu bạn có thể nghĩ ra một số lượng nhỏ các phép tests hoặc sử dụng một cách tiếp cận kiểm tra khác như thanh tra (inspection) hoặc chứng minh (demonstration) để biết liệu yêu cầu đó đã được cài đặt hợp lệ trong sản phẩm hay không.

Ví dụ về xung đột yêu cầu nghiệp vụ

Cần xây dựng phần mềm quản lý Kiosk:

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

• Generating revenue by leasing or selling the kiosk to the retailer
• Selling consumables through the kiosk to the customer
• Attracting customers to the brand
• Making a wide variety of products available

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

=> 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 (conflict) trước khi analyst có thể phân tích các yêu cầu phần mềm.

Finding Solutions to Goal Conflicts

Xung đột mục tiêu có thể dự đoán được sau khi phân tích mục tiêu và stakeholder nhưng chỉ có thể giải quyết được khi đưa ra được thiết kế phù hợp (candidate design).

Trong một số trường hợp chỉ cần phác thảo thiết kế là đã xác định được phương pháp có khả thi không.

Một vài trường hợp, không thể nào tìm ra được phương pháp khả thi

Phân biệt yêu cầu nghiệp vụ và yêu cầu phần mềm

Business requirements là các phát biểu về nghiệp vụ

Software requirements (functional requirements) xác định cái mà hệ thống sẽ làm.

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à nên đồng bộ với yêu cầu nghiệp vụ

Một số yêu cầu nghiệp vụ có thể tự động hóa: máy tính có thể làm mọi việc nhanh hơn, hiệu quả và đáng tin cậy hơn con người đối với hầu hết các nghiệp vụ thường kỳ (routine), như tính lương, quản lý điểm

Một số yêu cầu nghiệp vụ phải thực hiện bằng tay: ví dụ đánh giá tổn hại nhân thọ có thể tùy vào chủ quan của nhân viên bảo hiểm. Không phải tất cả các yêu cầu nghiệp vụ đều có thể số hóa; một số nghiệp vụ có thể cùng đồng hành với công nghệ máy tính. Ví dụ, máy tính không thể đánh giá rủi ro được nhưng có thề lưu trữ các đánh giá này.

9/ Khái niệm Product Vision và Project Scope

Vision (hay mission) mô tả thực chất sản phẩm sẽ là cái gì.

Project scope xác định một phần của mục đích lâu dài (long-term product vision) của sản phẩm mà dự án hiện hành đang thực thi.

Vision dùng để chỉ đến cả hệ thống phần mềm, nó phản ánh mục tiêu nghiệp vụ (business objectives) của hệ thống , còn scope chỉ liên quan đến từng dự án riêng lẻ hay một lần lặp trong quá trình phát triển tăng tiến các chức năng của hệ thống.

Scope of a project

Cần phải xác định scope (=boundary) của phần mềm.
Một trong các rủi ro lớn nhất của hệ thống là để cho scope phình ra (creep), 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.
10/ Xác định boundary bằng phương pháp soft system

Phương pháp soft system (SSM)

A soft system is one that involves social, political and emotional issues as well as technology: again, not just products or services but people, procedures and all the relationships between people that make real life complicated but practical.

=> Phương pháp SSM (Soft Systems Methodology của Checkland) khuyên chúng ta thay đổi cách nhìn thế giới, trong khi đó các kỹ thuật hệ thống hard cho chúng ta cách nhìn vấn đề một cách cố định.

Theo SSM 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.

• Bắt đầu bằng mô hình rich picture
• Từ stakeholder để xác định boundary
• Xác định giao diện (interface)
• Đánh giá chọn lựa boundary

1.Bắt đầu bằng rich picture

• Lược đồ chỉ ra những gì đang xảy ra trong nghiệp vụ,
• Biểu diễn context and scope thông dụng tuy không chính quy
• Chứa các khái niệm và vấn đề có liên quan mà được stakeholder đề cập đến.

Đặc điểm của Rich picture:

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.
• Soft system có thể xác định nhu cầu của sản phẩm 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.

2. Từ stakeholder đến boundary

• Một số stakeholder quan trọng (lớp ngoài của onion) 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 (autonomous) 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 đó. Thậm chí các sản phẩm tưởng chừng tự vận hành như máy bay, robot nhà máy, cũng cần được lắp đặt, cấu hình, kiểm thử và bảo trì bởi con người.

3. Xác định giao diện (interface)

Bằng cách kết hợp quan điểm của các stakeholder thích hợp lại với nhau, ví dụ đội bay và bảo trì, bạn cần phải đi đến quyết định quan trọng và cân đối giữa các phạm vi đã phác thảo ra. Những quyết định này sẽ xác định phạm vi và giao diện của hệ thống.

VD:Vì maintenance nằm bên trong phạm vi hệ thống operable aircraft, giao diện giữa maintenance và aircraft bây giờ là nội bộ.

• Maintenance và simulation/training là các hệ thống con.
• Dự án sẽ phải thiết kế giao diện cho cả maintenance và simulation/training

Giao diện maintenance nên:

• Tương tự như giao diện aircraft khác, để giảm thiểu nhu cầu tool mới.
• Có thiết kế đặc biệt phù hợp với máy bay mới, để tăng tối đa tính hiệu quả của bảo trì.

4.Đánh giá chọn lựa boundary

11/ Xác định yêu cầu chức năng bằng phương pháp hard system

Phương pháp hard system chỉ ra cách làm thề nào để xác định được yêu cầu chức năng (functional requirement) à kiểm soát các sự kiện (event) xảy ra thông qua ngữ cảnh và giao diện đã thỏa thuận.

Lược đồ ngữ cảnh(context diagram)

11.1 Lược đồ ngữ cảnh truyền thống(tradional context diagram)

Để xác định phạm vi công việc một cách tổng thể.
Tránh cho scope không bị phình ra creep (khi có 1 số vấn đề do lúc đầu không phát hiện được dần dần lộ ra gây phiền phức mà không có 1 cảnh báo nào trước đó).
Lược đồ ngữ cảnh thường không quan tâm đến mọi cái bên ngoài boundary nếu không trực tiếp ảnh hưởng đến giao diện hệ thống

Mũi tên hướng vào hình tròn trên lược đồ biểu diễn 1 event

=> Scope được xem như 1 tập các event được ta quyết định là sẽ quản lý nó.

=> Mỗi sự kiện mà được thỏa thuận nằm trong scope sẽ trở thành 1 yêu cầu

Hai loại sự kiện (event)

1.External (data or physical) event: the loại sự kiện xảy ra không dự báo trước được, xem như 1 tác nhân (stimulus), kích (wake up) cho hệ thống phải làm gì đó để đáp ứng lại. Tác nhân có thể là:

• Message (like a packet of data);
• Signal from a sensor
• Explicit control input (e.g. a button press, a mouse click, a touch on a touch-sensitive screen).

2.Time-triggered event: tín hiệu thời gian( a shared clock on a network) : sự kiện này cũng kích cho hệ thống phải làm gì đó để đáp ứng lại, giống như một tác nhân từ bên ngoài.

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

Chủ nhân của tài liệu vision and scope là:

• Người tài trơ chính (executive sponsor) của dự án
• Người chi tiền (funding authority)

Người phân tích yêu cầu (requirements analyst) có thể làm việc với owner để viết tài liệu vision and scope.

Yêu cầu nghiệp vụ nên thu thập từ những ai hiểu rõ vì sao họ quan tâm đến dự án. Họ là:

• Customer
• Senior management
• Project visionary
• Product manager
• Subject matter expert
• Members of the marketing department.

Finding the Voice of the Customer

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

Nhận biết các loại người dùng khác nhau
Xác định các nguồn của yêu cầu người dùng.
Chọn lựa cá nhân tiêu biểu cho mỗi loại người dùng hay các nhóm stakeholder khác nhau để làm việc với họ.
Thỏa thuận các yêu cầu với người ra quyết định dự án.

Khó khăn khi thu thập yêu cầu từ khách hàng

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

Nhà 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ọ.

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

• Ghi nhận khả năng và tính chất cần thiết của hệ thống mới.
• Trao đổi thông tin với các stakeholders.

Là quá trình lặp mất nhiều thời gian nhưng nếu không đầu tư thời gian thì có thể dẫn đến hậu quả: rework, delayed completion, và customer dissatisfaction.

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

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ẩm
• Their application domain experience and computer systems expertise
• Các tính năng người dùng sử dụng
• Nhiệm vụ mà họ thực thi khi xử lý nghiệp vụ
• Quyền truy xuất và cấp độ bảo mật

Tìm đại diện người dùng

Mỗ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ự án.

Cách giao tiếp giữa user và developer

THU THẬP YÊU CẦU

A major aspect of requirementsengineering is the elicitation of Requirements from the customer.

12/ Thu thập yêu cầu (Requirement elicitation) là gì?

Elicitation là quá trình xác định yêu cầu và làm giảmsự 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 nhau

Phân biệt giữa elicitation và analysis

Elicitation 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.

Tầm quan trọng

Requirements elicitation is perhaps the most difficult,most critical, most error-prone, and mostcommunication-intensive aspect of softwaredevelopment.

Elicitation chỉ có thể thành công thông qua mối quanhệ hợp tác giữa customer và đội development .

Các hoạt động của yêu cầu

13/ Các kỹ thuật thu thập yêu cầu

• Document Sampling
• Interviewing
• Survey and observation
• Questionnaires
• Workshop and Brainstorming
• JAD (Joint Application Development) sessions

Ba kỹ thuật phổ biến nhất là Document sampling, interviewing và questionnaires

Interviewing

Là kỹ thuật trực tiếp và đơn giản

Câu hỏi context-free có thể giúp hoàn thành các phỏng vấn bias-free interviews

Then, it may be appropriate to search for undiscovered requirements by exploring solutions.

Tập hợp lại 1 số nhu cầu chung sẽ tạo requirements repositoryđể dùng trong suốt dự án

Questionnaire không thể thay thế cho interview.

• Interview 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.

Interview: Context free question

Là 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.

Cá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 sẻ các thông tin khác.

Làm thế nào đề thực hiện interview?

Phả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 chung

Khô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.

Interview: Show time

Nên dành thời gian để:

• Establish Customer or User Profile
• Assessing the Problem
• Understanding the User Environment
• Recap the Understanding
• Analysts Inputs on Customers Problems
• Assessing Your Solution (if applicable)

Technique: Requirements Workshop

Có 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 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.

Preparing for the workshop

Bảo đảm có sự tham gia của các stakeholder phù hợp

Công tác hậu cần (Logistics)

• Cố và tránh luật Murphys law
• Bao 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ảo
• Out-of-box thinking preparation

Trong 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 glossary để các thành viên cùng dùng chung các định nghĩa
• Customer 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.

• Kỹ 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.

Vai trò của requirement analyst

• Ngườ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.

Role of the Facilitator

• Xác lập 1 phong cách chuyên nghiệp và mục tiêu rõ ràng cho cuộc họp
• Bắ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õi
• Tạ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ọp
• Kiểm soát các hành vi gây rối và không phù hợp.

Workshop Agenda

Xâ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).

Running the Workshop

Cư 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 lao

Thẻ 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.
• If you do not have a ticket create a fund to add to, like $1 to pot for after workshop activities.

Một số nguyên tắc cơ bản để workshop thành công

• Establish ground rules
• Stay in scope
• Use parking lots to capture items for later consideration
• Timebox discussions
• Keep the team small and include the right participants
• Keep everyone engaged

Product Position Statement

• For [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]

14/ Chọn lựa kỹ thuật thu thập yêu cầu

Brainstorming session

• Thườ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.
• Khi 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 niên (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ọ.
• Mụ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.

Các giai đoạn của Brainstorming Session

Tabular Elicitation Technique

• Việ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 table
  • State table

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ãn
• Tậ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.
• Mỗ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)

State 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.
• State 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)

Phương pháp điều tra (survey)- Ethnographic Techniques

• Mộ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ối quan tâm của khách hàng là Kano modeling.

Phương pháp Kano modeling : Cung cấp ba biến để đo lường mối quan tâm của khách hàng:

• One-dimensional quality(hay linear quality) được áp dụng ở những nơi mà tính năng của sản phẩm tăng tuyến tính cùng với 1 số ngữ cảnh nào đó của tính năng đó. Ví dụ tính tiết kiệm điện năng của tủ lạnh, nếu tính năng này càng hiệu quả thì khả năng khách hành đặt mua càng nhiều.
• Expected quality:là tính năng bắt buộc phải có đối với sản phẩm nào thànnh công trên thị trường.
• Attractive quality: là tính năng không được mong đợi nhưng bổ sung vào yếu tố tâm lý (emotional appeal) của sản phẩm. Ví dụ camera trong mobile là attractive quality trong nhiều năm trước nhưng bây giờ là expected quality trong hầu hết các thị trường.
• Một đo lường khác là yêu tố văn hóa. Ví dụ, ở Mỹ hầu hết các khách hàng đều muốn việc mua xe ô tô được chuyển giao tự động, trong khi đó ở châu Âu việc chuyển giao tự động là bình thường.
• Kano modeling được chấp nhận rộng rãi;một số công cụ quản lý requirements engineering có sẵn chức năng Kano analysis.

Joint Application Development (JAD)

• JAD được như 1 kỹ thuật để phát triển yêu cầu của 1 hệ thống và trong các giai đoạn đầu của dự án phần mềm.
• Mục đích: tập hợp MIS và người dùng cuối trong cơ chế của 1 workshop, để cùng thống nhất (consensus) với nhau các yêu cầu của hệ thống.

JAD và phương pháp cũ?

• Bằng cách kết hợp các workshop và nhấn mạnh tinh thần cộng tác (spirit of partnership)
• Bằng cách kết hợp công nghệ và nhu cầu nghiệp vụ trong 1 quy trình thống nhất, lặp lại và hiệu quả
• => JAD giúp thu thập yêu cầu hệ thống nhanh hơn, chính xác hơn các phương pháp cổ điển.
• => Giảm 1 cách đáng kể thời gian, chi phí và lỗi cho dự án.

Dự án nào nên dùng JAD?

• Liên quan đến nhiều nhóm người dùng khác nhau
• Rất quan trọng đến sự thành công trong tương lai của tổ chức.
• Là dự án mới của tổ chức
• Có trở ngại trong dự án cũ hay mối quan hệ giữa hệ thống và tổ chức

Ai tham dự JAD?

• Executive Sponsor
• Facilitator
• User ( từ 3 5)
• IT Representative
• Scribe ( 1 hay 2)
• Observer ( 2 hay 3)

15/ Quy tắc nghiệp vụ và chính sách

• Một tổ chức có thể ban hành, chỉnh sửa hay hủy bỏ các quy tắc nghiệp vụ mà các quy tắc này sẽ chi phối và hướng dẫn tổ chức.
• Chính sách (business policy) là yếu tố quản lý, không trực tiếp được thi hành mà dùng để hướng dẫn tổ chức hoạt động. Chính sách không đòi hỏi phải diễn tả có cấu trúc (không cần thuật ngữ tiêu chuẩn) như là quy tắc nghiệp vụ.

Why Are Customer-Specific Business Rules Important?

• Các quy tắc nghiệp vụ do người dùng xác định phải tách riêng khỏi các yêu cầu thông thường, vì chúng không thực sự là yêu cầu.
• Yêu cầu khách hàng có thể được suy diễn từ quy tắc nghiệp vụ, các yêu cầu có thể khác với quy tắc mà chúng được suy diễn.
• Chính quy tắc nghiệp vụ do khách hàng xác định dùng để thực thi chính sách (policy) của công ty, nhưng quy tắc nghiệp vụ có thể thay đổi sau khi hệ thống đã được phân phối.

🡺 Nên xây dựng hệ thống sao cho khách hàng có khả năng thay đổi quy luật mà không làm cho hệ thống bị sửa đổi theo.

Ví dụ:

• Policy: The hospital shall be able to define the difference between adult and child patients for check-in and medical records purposes.
• Rule: Any patient under the age of 14 checking in shall be considered a child. When a child checks into the hospital, depending on the hospitals business policy, a parent or guardian may have to accompany the child and sign all the admission forms. Detailed rules explain under what circumstances (e.g., an accident, emergency, or life-threatening situation) a child may be checked in without a parents or guardians consent.
• Requirement: A facility shall be provided with the system such that the hospital check-in process for adults and children can be changed by hospital administrators without the need for system or software modifications.

16/ Quản lý mối quan hệ khách hàng

• Quản lý mối quan hệ khách hàng là quan trọng trong suốt chu kỳ dự án, và là chủ yếu trong suốt quá trình phân tích.
• Cả người tiêu dùng lẫn nhà cung cấp cần phải hiểu biết về sản phẩm.
• Cần tiếp tục tương tác với khách hàng để duy trì mối quan hệ; e.g., thông báo cho họ tin xấu sớm tốt hơn là báo muộn. Tốt hơn là nên giao tiếp thường xuyên với khách hàng có thể tránh được các rắc rối nghiêm trọng có thể xảy ra sau đó.
• 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, vì vậy 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.
• Cầ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).
• 🡺 It is our experience that constant communication with the customer

Advertisements

Chia sẻ:

Related

• Chap4: Brainstoming
• 05.11.2021
• In "UX"

• 2015.
• 05.11.2021
• In "Than thở nhiều lắm cơ"

• Chap3: Researching
• 05.11.2021
• In "Khác"

Categories: Khác

Tags: BA

Leave a Comment

Video liên quan

Related posts: