Bài Giảng Thu Thập Yêu Cầu

Vấn đề về người dùng và khách hàngNgười dùng không hiểu họ muốn gì Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa Người dùng nhất định đòi hỏi các yêu câ

Trang 1

Chapter 3: Thu thập yêu

Trang 2

Nội dung

 Thu thập yêu cầu

( Requirement elicitation) là

gì?

 Các kỹ thuật thu thập yêu cầu

 Chọn lựa kỹ thuật thu thập yêu

cầu

 Quy tắc nghiệp vụ và chính sách

 Quản lý mối quan hệ khách hàng

Trang 3

A major aspect of requirements

engineering is the elicitation of

requirements from the customer

It’s not just a simple matter of writing down what

the customer says he wants !!!

BM HTTT Khoa CNTT - HUI 3

Trang 4

Requirement elicitation

 Elicitation là quá trình xác định

yêu cầu và làm giảm sự khác

biệt giữa các nhóm có liên quan

để rút ra các yêu cầu đáp ứng

được nhu cầu của tổ chức hay

dự án trong khi vẫn giữ được các

ràng buộc

 Có rất nhiều kỹ thuâṭ elicitation

khác nhau

Trang 5

Phân biệt giữa elicitation và analysis

 Elicitation là sự tương tác với

stakeholders để nắm bắt được

nhu cầu của họ.

 Analysis là tinh chỉnh

(refinement) nhu cầu của

stakeholder thành các đặc tả sản phẩm chính thức

Trang 6

Tầm quan trọng

 Requirements elicitation is

perhaps the most difficult, most critical, most error-prone, and

most communication-intensive

aspect of software development

 Elicitation chỉ có thể thành công thông qua mối quan hệ hợp tác

giữa customer và đội

development

Trang 7

Mô hình song song của quy trình

yêu cầu

Trang 8

Why is it difficult to elicit requirements?

Customers and users often do not understand how software design and development works, and cannot specify their own software requirements in a way that works for developers

Software developers often do not understand the problems and needs of customers and users well enough to specify the requirements on their

Trang 9

Vấn đề về người dùng và khách hàng

Người dùng không hiểu họ muốn gì

Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa

Người dùng nhất định đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển

đã được hoạch định xong.

Mức độ giao tiếp với người dùng là thấp

Người dùng thường không tham gia các

đợt thẩm định hoặc không thể tham gia.

Người dùng không hiểu kỹ thuật

Người dùng không hiểu quy trình phát

triển.

Trang 10

Các hoạt động của yêu

cầu

Trang 11

Trước khi thu thập yêu cầu

Trang 12

Lược đồ ngữ cảnh

(boundary) và các mối nối kết giữa hệ thống đang phát triển và mọi thứ khác bên ngoài

đường biên này

Trang 13

(data flow diagram) theo cách phân tích hướng cấu trúc

phát triển nào

Có thể nằm trong tài liệu vision, trong phục vụ đặc tả yêu cầu (SRS)

Trang 14

Trang 15

Keeping Scope in Focus

steer the project toward satisfying evolving customer needs

Khi có ai đó kiến nghị 1 yêu cầu mới thì RA phải làm gì??

hay không??

thể hợp nhất yêu cầu mới vào dự án nếu có độ

ưu tiên cao so với yêu cầu hiện cócó thể phải trì hoãn hay hủy bỏ các yêu cầu hiện tại

Trang 16

Keeping Scope in Focus

thể có 1 trong các phương án sau:

◦ Nên đưa vào phiên bản sau hay trong dự án khác.

◦ Scope của dự án có thể thay đổi để đáp ứng yêu cầu

mới  cần có phản hồi từ phía người dùng và cần cập nhật lại tài liệu vision and scope (nếu đã phê duyệt thì cần giám sát mọi thay đổi)

◦ Khi phạm vi dự án tăng, thường phải thỏa thuận lại ngân sách(budget), tài nguyên (resource), thời gian (schedule)

Trang 17

Xác định StakeHolder

product

each user class and other stakeholder groups

are for you project

what they want and then start coding If the developers build exactly what customers initially request, they’ll probably have to build it again because customers often don’t know what they really need.

Trang 18

Xác định StakeHolder

đầu thường không đủ để trở thành chức năng của hệ thống

Để có cái nhìn chính xác hơn nhu cầu người dùng, RA phải tập hợp các yêu cầu người dùng, phân tích và xác định chỉ nên xây dựng cái gì để người dùng làm tốt được công việc của họ

Trang 19

Phân loại StakeHolder

phẩm)

sản phẩm)

cầu và làm việc với đội phát triển phần mềm)

trì sản phẩm)

thực thi như mong muốn)

Trang 20

Phân loại StakeHolder

người dùng, hệ thống trợ giúp)

án, quản lý đội phát triển phần mềm)

hợp với luật và quy chế)

sản phẩm có chứa phần mềm)

những người khác sẽ làm việc với sản phẩm và khách hàng

Trang 21

Các kỹ thuật thu thập yêu cầu

Document Sampling

Interviewing

Survey and observation

Questionaires

Workshop and Brainstorming

JAD (Joint Application Development)

Trang 22

Trang 23

Trang 24

 Là kỹ thuật trực tiếp và đơn giản

 Phỏng vấn để thu nhận từ các cá thể thao tác và các vấn đề trong hệ thống hiện hành, chính sách, nhu cầu mong muốn trong hệ thống mới.

 Câu hỏi context-free có thể giúp hoàn thành các phỏng vấn bias-free interviews

 Tập hợp lại 1 số nhu cầu chung sẽ tạo

“requirements repository”để dùng trong suốt dự án

 Questionnaire không thể thay thế cho

interview.

Trang 25

nguồn thu thập yêu cầu kiều truyến thống cho cả sản phẩm thương mại cũng như các hệ thống thông tin

các yêu cầu, rút ra các quyết định có tính logic của người dùng Để mô tả quá trình đưa ra các quyết định logic có thể dùng flowchart và cây quyết định (decision tree) bảo đảm mọi người hiểu được tại sao hệ thống phải thực hiện các chức năng này

quy trình nghiệp vụ đã lỗi thời hay không hiệu quả nữa và không nên đưa vào hệ thống mới

Trang 26

Một số hướng dẫn để phỏng

vấn thành công

Trang 27

Interview: Context free

 Được dùng trong mỗi giai đoạn

khác nhau của cuộc phỏng vấn

Trang 28

Cá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ẽ giúp khởi đầu cuộc phỏng vấn và vượt qua được các lúng túng ban đầu

 Redirection: có thể được dùng để chuyển hướng

phỏng vấn khi nội dung cuộc đối thoại ra ngoài chủ đề hay quá sâu không cần thiết, đưa cuộc đối thoại về lại vị trí trung lập để hướng đến chủ đề mong muốn

 Closing: dùng để kết thú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 chủ động và chia xẻ̃ các thông tin khác

Trang 29

Các dạng câu hỏi

Trang 30

Làm thế nào đề thực hiện

interview

 Phải chuẩn bị một danh sách các câu hỏi context free trước khi phỏng vấn Có thể đặt cùng 1 hay 2 câu hỏi cho người được phỏng vấn (interviewee) để tìm ra điểm khác biệt

 Thông qua câu hỏi context free để giúp người tham gia phỏng vấn có hiểu biết chung

 Không bận tâm vào câu trả lời “right/wrong” Nhiều câu hỏi dùng gây ấn tượng hơn là để thu nhận dữ liệu, dùng để thu thập chi tiết hơn yêu cầu đang khảo sát

Trang 31

Các chiến lược phỏng vấn

 Top-down: bắt đầu bằng các câu hỏi tổng quát, tiếp đến là các câu hỏi cụ thể

 Bottom-up: ngược lại

Trang 32

Interview: Show time

Nên dành thời gian để:

Establish Customer or User Profile

Assessing the Problem

Understanding the User Environment

Recap the Understanding

Analyst’s Inputs on Customer’s

Problems

Assessing Your Solution (if

applicable)

Trang 33

Thường dùng khi cần thu thập

thông tin và ý kiến từ số đông.

Trang 34

So sánh giữa Questionaries

và Interview

Trang 35

Chọn người tham gia phiếu

điều tra

cũng đều hoàn tất nó, trung bình chỉ thu lại được 30-50% phiếu điều tra bằng giấy hay email, chỉ 5 – 30% phiếu điều tra qua Web

Trang 36

Thiết kế phiếu điều tra

closed-ended

không nên chừa quá nhiều khoảng trống dễ gây hiểu nhầm

Trang 37

người trả lời phải cho biết mức độ mà họ đồng tình hay phản đối

lời là một giá trị cụ thể

Trang 38

nhiều điều tra sẽ được phân tích và dùng như thế nào, tránh tình trạng phân phối điều tra xong rồi mới phát hiện điều tra có vấn đề.

về định dạng, người trả lời không cần đọc hướng dẫn mỗi câu hỏi trước khi trả lời

điều tra và test lại trước khi phân phối

Trang 39

Giám sát phiếu điều tra

gia của người trả lời:

 Giải thích rõ ràng tại sao cần thực hiện phiếu điều tra và tại sao người trả lời được chọn.

 Cho 1 khích lệ để người trả lời hoàn tất phiếu điều tra.

sau 1 hay 2 tuần

Trang 40

Technique: Requirements

Workshop

thu thập yêu cầu

cùng với nhau trong 1 giai đoạn, tuy ngắn nhưng rất tập trung

kinh nghiệm từ bên ngoài trong quản lý yêu cầu có thể bảo đảm cho sự thành công của workshop.

 Brainstorming là phần quan

trọng nhất của workshop.

Trang 41

Preparing for the

workshop

stakeholder phù hợp

chiều (“afternoon sugar filled snacks.”)

materials)

Trang 42

Trong lúc Workshop

từ ngữ của miền ứng dụng thay vì bắt khách hàng hiểu các thuật ngữ máy tính.

vào danh sách các từ khó (glossary) để các thành viên cùng dùng chung các định nghĩa

về chức năng không hẳn là 1 nhiệm vụ phải có trong sản phẩm

Trang 43

Trong lúc workshop

• Kỹ năng để dẫn dắt các cuộc thảo luận phân tích yêu cầu phải có được từ kinh nghiệm, tập huấn phỏng vấn, hỗ trợ nhóm, giải quyết xung đột,

cầu thực sự của khách từ 1 loạt các yêu cầu mà khách hàng đề ra

– Hỏi "why" nhiều lần

– Hỏi các câu hỏi mở (open-ended question) để giúp hiểu được quy trình nghiệp vụ hiện hành của người dùng và để thấy hệ thống mới có thễ cải thiện việc thực thi như thế nào

– Điều tra tìm hiểu (Inquire) những thay đổi xảy ra cho người dùng khi hệ thống mới được đưa vào sử dụng

– Thử đóng vai trò người tập sự (apprentice) học hỏi từ người dùng chính.

Trang 44

Vai trò của requirement

analyst

• Người phân tích yêu cầu (Requirements analyst) thường tham gia các hội thảo phân tích yêu cầu

• Facilitator đóng vai trò chính trong việc lên

kế hoạch hội thảo, chọn người tham dự, dẫn dắt người tham dự để kết thúc thành công hội thảo

• Khi đội bắt đầu các phương pháp mới để phân tích yêu cầu nên có một facilitator ngoài đội hướng dẫn các workshop khởi đầu, nhờ đó các analyst có thể góp phần nhiều hơn vào các cuộc thảo luận

Trang 45

Role of the Facilitator

rõ ràng cho cuộc họp

quan tâm theo dõi

tránh tham gia vào

góp ý trong cuộc họp

Trang 46

Workshop Agenda

 Xây dựng lịch trình (agenda) trước cho buổi hội thảo và công bố nó cùng với các tài liệu chuẩn bị trước của workshop.

 Giữ ổn định cho buổi hội thảo rất quan trọng, cố gắng theo đúng lịch trình, nhưng cũng không nên tuân theo nó quá cứng nhắc, nhất là khi đang có thảo luận sôi nổi.

 Đặt ăn trưa (light working lunch)

Trang 47

Running the Workshop

 Cư xử lịch thiệp và vui vẻ

 Thẻ phạt (Workshop tickets)

thẻ phạt sau: đi muộn, gian lận (“cheap shot”) , phát biểu dài dòng (“soap box”)

◦

Trang 48

Một số nguyên tắc cơ bản để workshop thà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

Trang 49

Workshop Problems and

Suggestions (đề nghị)

Problems

 Quản lý thời gian

◦ Khó bắt đầu lại sau nghỉ giải lao

và ăn trưa.

◦ Stakeholders quan trọng

thường quay lại muộn

 Giành quyền phát biểu quá lâu,

 Thiều dữ liệu từ stakeholders

 Phát biểu tiêu cực, hành động nhỏ

nhen, gây gỗ

 Mệt mỏi thiếu sinh lực sau khi ăn

trưa

Suggestions

 Facilitator phải theo dõi thời gian nghỉ giải lao và phạt bất kỳ ai đến muộn,

 Mỗi người chỉ được 5 phút để phát biểu.

 Facilitator khuyến khích mọi người sử dụng 5 phút được phát biểu và ủng hộ các sáng kiến.

 Dùng vé phạt (“Cheap Shot Tickets”) và buộc trả chi phí

 Nên tổ chức ăn nhẹ buổi trưa, giải lao buổi chiều, sắp xếp lại chỗ ngồi

Trang 50

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]

Trang 51

Brainstorming Sessions

• Thường được dùng để phân tích tìm các yêu cầu ban đầu của stakeholder đối với sản phẩm Phương pháp này được thực hiện với nhiều stakeholders hay customers và các phiên giao tiếp này thường được dẫn dắt bởi

1 facilitators có kinh nghiệm, mỗi phiên (session) thường kéo dài tối đa 1 hay 2 ngày

• Mục tiêu của brainstorming session là đưa

ra các ý tưởng mới hay các tính năng của sản phẩm trong 1 thời gian rất ngắn

Trang 52

Brainstorming Sessions

 Khi xác định ý tưởng, điều quan

trọng là phải tránh xung đột, e.g., một thành viên chê bài ý tưởng

của người khác

 Nếu có thành viên lâu năm

(senior) tham gia session thì điều quan trọng là giữ cho họ không

được đe dọa các thành viên ít

kinh nghiệm hơn họ.

Trang 53

Vai trò của facilitator

Vai trò của facilitator rất quan trọng, quyết định session có thành công hay không?

Trang 54

brainstorming session cần phải

được thỏa thuận trước bởi tất cả

các thành viên, tốt nhất là ngay

trước khi bắt đầu session

đưa ra các ý kiến, tạo thành 1 tập

hợp các kiến nghị về sản phẩm

Nên dùng “sticky notes” và dán vào bảng

Trang 55

Các giai đoạn của

Brainstorming Session

Trang 56

Tabular Elicitation

Technique

• Việc dùng bảng có thể giúp nắm

bắt được yêu cầu của stakeholder

rõ ràng và chặt chẽ hơn

• Có 2 loại bảng hay được dùng:

Trang 57

Decision table

• Bảng quyết định (Decision table) thông dụng nhất khi:

được xác định bằng “yes” hay “no,”

kiện thỏa mãn

duy nhất và tương ứng với mỗi rule

là 1 hành động

Trang 58

Decision table

mỗi cột biểu diễn 1 rule, i.e, Một

điều kiện và 1 tập các hành động

tương ứng

các yêu cầu lúc đầu của

stakeholder thì bảng quyết định

được dùng rất hiệu quả để nắm bắt các quy tắc nghiệp vụ (business

rule)

Định dạng
Số trang	133
Dung lượng	4,56 MB