Requirements Elicitation
Or
Requirement gathering

Thu thập yêu cầu (Requirement elicitation) là
gì?

Các kỹ thuật thu thập yêu cầu

Chọn lựa kỹ thuật thu thập yêu cầu

Quy tắc nghiệp vụ và chính sách

Quản lý mối quan hệ khách hàng
A major aspect of
requirements engineering is
the elicitation of
requirements from the
customer.

Elicitation là quá trình xác định yêu cầu và
làm giảm sự 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

Elicitation là sự tương tác với stakeholders để
nắm bắt được nhu cầu của họ.


Assignment 13: Document Sampling
◦
Nhóm???

Assignment 14: Questionaires

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ể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.
Nên dà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)

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

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

là khi đang có thảo luận sôi nổi.

Đặt ăn trưa (
light
working lunch).

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.