Tải bản đầy đủ (.ppt) (68 trang)

Bài giảng chương 3 Thu thập yêu cầu

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.63 MB, 68 trang )

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


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.

Requirements elicitation is perhaps the most
difficult, most critical, most error-prone, and
most communication-intensive aspect of
software development.

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




Document Sampling

Interviewing

Survey and observation

Questionaires

Workshop and Brainstorming

JAD (Joint Application Development) sessions
Ba kỹ thuật phổ biến nhất là Document
sampling, interviewing và questionaires


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

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.

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 xẽ các thông tin khác.

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

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.

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 Murphy’s 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

Để 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.

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.

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.

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

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.

×