Chương 3: Khám phá yêu cầu

3.1 Các dạng yêu cầu

3.1.1 Yêu cầu kinh doanh
3.1.2 Yêu cầu người dùng
3.1.3 Yêu cầu chức năng và phi chức năng
3.2 Phương pháp thu thập (khám phá) yêu cầu
3.2.1 Nguồn yêu cầu
3.2.2 Thu thập yêu cầu thông qua phỏng vấn trực tiếp
3.2.3 Thu thập yêu cầu thông qua trao đổi nhóm tập trung
3.2.4 Thu thập yêu cầu thông qua tài liệu
3.2.5 Yêu cầu Agile
3.1.1 Yêu cầu kinh doanh
ØYêu cầu chung và cấp cao hoặc mong đợi mà một tổ
chức hoặc doanh nghiệp có từ một dự án hoặc sản
phẩm.
ØYêu cầu này thường được phát triển từ mục tiêu kinh
doanh và chiến lược tổng thể của tổ chức.
q Công ty cần giảm tỷ lệ thoát hàng trong quá trình thanh toán
trực tuyến xuống dưới mức trung bình ngành trong vòng 6
tháng tới.
3.1.2 Yêu cầu người dùng
Ø Yêu cầu cụ thể và chi tiết về những gì người dùng cuối cùng
muốn và cần từ sản phẩm.
q Người dùng cần một chức năng tìm kiếm trong ứng dụng quản lý thư viện
để có thể nhanh chóng tìm thấy một quyển sách dựa trên tiêu đề, tác giả,
hoặc từ khóa liên quan.
q User Story: Là một thành viên của thư viện, tôi muốn tìm kiếm quyển
sách dựa trên tiêu đề, tác giả, hoặc từ khóa, để tôi có thể nhanh chóng tìm
thấy và mượn sách mình muốn đọc.
3.1.3 Yêu cầu chức năng và phi chức năng
ØYêu cầu chức năng là sự mô tả của chức năng hoặc dịch
vụ của phần mềm hay hệ thống; có thể nhìn thấy và trực
tiếp sử dụng trên sản phẩm cuối.
Sơ lược Chi tiết

Người dùng có thể nhập từ khóa liên quan đến
tiêu đề, tác giả, hoặc chủ đề của sách để tìm
kiếm. Hệ thống sẽ trả lại danh sách sách phù
hợp với tiêu chí tìm kiếm.
Yêu cầu chức năng:
Tên chức năng: Tìm kiếm sách
Mô tả:
Người dùng có thể nhập một hoặc nhiều từ khóa vào ô tìm kiếm.
Từ khóa có thể liên quan đến tiêu đề, tác giả, hoặc chủ đề của sách.
Hệ thống sẽ trả lại danh sách sách phù hợp với tiêu chí tìm kiếm.
Mỗi kết quả tìm kiếm sẽ hiển thị tiêu đề sách, tác giả, và một đoạn mô tả ngắn.
Yêu cầu chi tiết:
Ô tìm kiếm phải cho phép nhập tối thiểu 3 và tối đa 255 ký tự.
Kết quả tìm kiếm sẽ được sắp xếp theo mức độ phù hợp và thời gian xuất bản.
Hệ thống phải trả lời yêu cầu tìm kiếm trong vòng 3 giây.
Nếu không có kết quả phù hợp, hệ thống sẽ thông báo "Không tìm thấy sách theo tiêu chí của bạn".
3.1.3 Yêu cầu chức năng và phi chức năng
ØYêu cầu phi chức năng là tập hợp các ràng buộc giúp
nâng cao chất lượng hệ thống phần mềm
q Khi người dùng truy cập ứng dụng và tìm kiếm sản phẩm, thời
gian phản hồi từ khi gửi yêu cầu đến khi nhận được danh sách
sản phẩm không được vượt quá 2 giây.
3.2.1 Nguồn yêu cầu
Ø Người dùng cuối: người sẽ sử dụng sản phẩm, và họ thường có
nhu cầu và mong đợi riêng về cách sản phẩm hoạt động.
Ø Các bên liên quan (chủ đầu tư): thường có những yêu cầu liên
quan đến kinh doanh, chi phí, thời gian, và quản lý rủi ro.
Ø Nhóm phát triển: đưa ra những yêu cầu dựa trên kỹ thuật và khả
năng thực hiện.
Ø Quy định pháp luật: yêu cầu có thể đến từ các quy định, tiêu
chuẩn hoặc luật pháp liên quan đến sản phẩm hoặc ngành công
nghiệp.
3.2.1 Nguồn yêu cầu
• Hiểu rõ mong muốn của khách hàng.
• Hiểu rõ hiện trạng hệ thống phần cứng, phần mềm, trình độ
nhân viên, các nghiệp vụ đang thực hiện, các mẫu, nội dung
Khởi đầu: tài liệu, biểu mẫu, báo cáo đang sử dụng, luật cần tuân thủ.

• Hiểu đúng, đủ, chi tiết từng yêu cầu.

Phát triển (và • Kiểm soát rủi ro thay đổi (Quản lý thay đổi).
quản lý) yêu cầu
3.2.1 Nguồn yêu cầu
ØChuẩn bị cho khám phá yêu cầu
q Tìm hiểu thông tin đầu vào dự án
n Tìm hiểu tải liệu mô tả dự án cung cấp thông tin về mục tiêu, phạm vi,
ràng buộc của phần mềm.
q Tìm hiểu lĩnh vực nghiệp vụ
n Nghiên cứu thông tin sẵn có liên quan tới sản phẩm hoặc lĩnh vực
nghiệp vụ.
q Lập danh sách các bên liên quan
n Xác định ai tham gia vào quá trình khám phá yêu cầu, cung cấp thông
tin quan trọng.
3.2.1 Nguồn yêu cầu
ØChuẩn bị cho khám phá yêu cầu
q Lập danh sách câu hỏi
n Chuẩn bị sơ bộ các ý hỏi cơ bản
q Lựa chọn kỹ thuật
n Lựa chọn các kỹ thuật khám phá: phỏng vấn, trao đổi nhóm tập trung,
quan sát, thu thập tài liệu, prototype v..v
q Lên kế hoạch thực hiện
n Đặt mục tiêu, lịch trình, xác định nguồn lực cho mỗi phần (buổi) khám
phá yêu cầu
3.2.1 Nguồn yêu cầu
ØTìm hiểu lĩnh vực nghiệp vụ
q Kiến thức liên quan tới ngành cụ thể: ngân hàng, giáo dục, y tế
v..v. Kiến thức rộng, ưu tiên tìm hiểu các nội dung có liên quan
đến dự án.
q Nguồn để tìm hiểu: internet (Google), tài liệu khách hàng cung
cấp, trao đổi chuyên gia.
q Nội dung tìm hiểu: khái niệm - thuật ngữ, mô hình kinh doanh,
nghiệp vụ, sản phẩm liên quan, sản phẩm đối thủ tương tự.
3.2.1 Nguồn yêu cầu
Hãy xây dựng một mind map về lĩnh vực nghiệp vụ liên
quan tới ứng dụng chấm công
3.2.2 Thu thập yêu cầu thông qua phỏng vấn trực tiếp

Chuẩn bị Thực hiện Sau phỏng vấn

• Câu hỏi phỏng vấn • Phỏng vấn • Hoàn thiện biên bản
• Biên bản phỏng vấn • Ghi nhận biên bản • Lưu trữ tài liệu
3.2.2 Thu thập yêu cầu thông qua phỏng vấn trực tiếp

Ø Một số câu hỏi hỗ trợ khi chuẩn bị :

q Sẽ hỏi về nghiệp vụ gì ? (căn cứ vào hợp đồng/ thỏa thuận)
q Liệu nghiệp vụ đó thế nào ?
n Có quy trình gì liên quan ?
n Có biểu mẫu gì liên quan ?
n Cần có loại báo cáo gì ? Theo yêu cầu của ai/tổ chức nào?
q Dựa trên văn bản nào ? (Luật/ thông tư/nghị định)
q Công ty đã có sp gì tương tự đáp ứng được nghiệp vụ đó
q Thị trường đang có xu hướng ?
q Giải pháp dự kiến sẽ thế nào ? Sau khi áp dụng thì nghiêp vụ điều chỉnh
như thế nào ?
3.2.2 Thu thập yêu cầu thông qua phỏng vấn trực tiếp

ØMột số nguyên tắc khi thực hiện

q Tác phong: chuyên nghiệp (trang phục, đầu tóc, giờ giấc, chào
hỏi)
q Hỏi như câu hỏi phỏng vấn/kịch bản đã chuẩn bị. Kiểm soát nội
dung kịch bản khảo sát
q Kiểm soát thời gian
q Kiểm soát thái độ, hành vi
q Ghi nhận chính xác nội dung
3.2.2 Thu thập yêu cầu thông qua phỏng vấn trực tiếp

Ø Cách hỏi khi thực hiện phỏng vấn

q Nên hỏi các câu hỏi mở “Quy trình ... của Phòng ... thực hiện thế nào ạ?”
q Kỹ thuật hỏi 5W1H: Ai? Làm gì? Khi nào? Như thế nào? Tại sao?
q Các câu hỏi gợi ý: Liệu có phải là? Có đến 10 hồ sơ/tháng không?
q Lắng nghe, đặt lại câu hỏi để xác nhận “Em xin phép nhắc lại ý anh có
phải là .../ em hiểu là .../ có nghĩa là ...”
q Nghiên cứu TRƯỚC và SỚM những nội dung mình sẽ hỏi, cố gắng
KHÔNG HỎI LẠI những điều có thể tự tìm hiểu được mà chỉ hỏi để xác
nhận các thông tin đã tìm hiểu.
3.2.2 Thu thập yêu cầu thông qua phỏng vấn trực tiếp

ØLưu ý sau khi phỏng vấn:

q Xác nhận từng phần nội dung khảo sát và đọc biên bản cho
khách hàng nghe và xác nhận trước khi in ra ký.
q Xin các file/hồ sơ giấy liên quan trong hoặc sau quá trình khảo
sát.
3.2.2 Thu thập yêu cầu thông qua phỏng vấn trực tiếp

Ø Phiếu phỏng vấn (khảo sát)

q Tên Dự Án/Chủ Đề: [Tên dự án hoặc chủ đề cần phỏng vấn]
q Mục tiêu của cuộc phỏng vấn: [Mô tả mục tiêu cụ thể của cuộc phỏng vấn]
q Ngày Phỏng Vấn: [Ngày thực hiện]
q Người Phỏng Vấn: [Tên của người hoặc người tiến hành phỏng vấn]
q Người Được Phỏng Vấn: [Tên của người được phỏng vấn]
q Danh sách câu hỏi
n [Câu hỏi 1]
q Ghi chú: [Không gian dành cho ghi chú]

n [Câu hỏi 2]
q Ghi chú: [Không gian dành cho ghi chú]

q Kết luận và ghi chú tổng quát: [Không gian dành cho người phỏng vấn ghi chú về những điểm
quan trọng hoặc nhận xét chung về cuộc phỏng vấn]
q Người Phỏng Vấn: [Chữ ký, nếu cần]
q Người Được Phỏng Vấn: [Chữ ký, nếu cần]
3.2.2 Thu thập yêu cầu thông qua phỏng vấn trực tiếp

Ø Biên bản phỏng vấn (khảo sát)

q Tên Dự Án/Chủ Đề: [Tên dự án hoặc chủ đề của cuộc phỏng vấn]
q Mục tiêu của cuộc phỏng vấn: [Mô tả mục tiêu cụ thể của cuộc phỏng vấn]
q Ngày Phỏng Vấn: [Ngày thực hiện]
q Thời gian: [Thời gian bắt đầu] - [Thời gian kết thúc]
q Địa điểm: [Địa điểm phỏng vấn]
q Người Phỏng Vấn: [Tên của người hoặc người tiến hành phỏng vấn]
q Người Được Phỏng Vấn: [Tên của người được phỏng vấn]
q NỘI DUNG PHỎNG VẤN: [Phản hồi từ người được phỏng vấn]
q Nhận xét và ghi chú:
q [Không gian dành cho người phỏng vấn ghi chú hoặc nhận xét chung về cuộc phỏng vấn]
q Xác nhận của các bên:
q Tôi xác nhận rằng nội dung trên là phản ánh trung thực của cuộc phỏng vấn.
q Người Phỏng Vấn: [Chữ ký, ngày tháng]
q Người Được Phỏng Vấn: [Chữ ký, ngày tháng]
3.2.3 Thu thập yêu cầu thông qua trao đổi nhóm tập
trung
Chuẩn bị
• Lựa chọn nhóm Sau trao đổi
• Câu hỏi, chủ đề thảo luận • Phân tích ý kiến ghi nhận
• Thông báo với thành viên • Xác nhận ý kiến

Thực hiện
• Trao đổi đóng góp ý kiến
• Ghi nhận ý kiến
3.2.4 Thu thập yêu cầu thông qua tài liệu

Chuẩn bị Thực hiện Sau thu thập tài liệu

• Xác định tài liệu cần • Thu thập xem xét tài • Xác nhận và theo dõi
thiết liệu yêu cầu
• Phân tích rút ra yêu cầu
3.2.5 Yêu cầu Agile
ØUser Story
q User story là một câu chuyện có người dùng, hành động và kết
quả.
q Được mô tả theo cấu trúc sau:
n Là một [người dùng], Tôi muốn [làm gì đó] để tôi có thể [nhận được một
kết quả nào đó]
q Vai trò US đối với nhóm: giúp ghi nhớ những nhu cầu của
người dùng trong suốt quá trình phát triển tính năng.
3.2.5 Yêu cầu Agile
Ø Các bước xác định US :
q Thông qua cuộc thảo luận với người dùng/Khách hàng, BA lắng
nghe, hiểu vấn đề và nhu cầu.
q Viết ta nhu cầu người dùng/Khách hàng dưới dạng US.
Ø Tất cả các US được tập hợp lại thành bộ nguồn các yêu cầu
q User story có thể được nhóm thành Epic (Loại)
q Epic liên quan có thể được nhóm thành Theme (Chủ đề)
Ø Chi tiết hoá User Story
q Phác thảo với các bên liên quan để hiểu rõ hơn về yêu cầu.
q Liệt kê các tác vụ có thể lập trình được để thực hiện User Story.
q Sử dụng sơ đồ luồng hoặc biểu đồ hoạt động UML để giải thích
Câu hỏi ôn tâp
ØĐịnh nghĩa về yêu cầu kinh doanh. Làm thế nào yêu cầu
này được phát triển trong ngữ cảnh của một tổ chức?
ØSo sánh sự khác biệt giữa Yêu cầu kinh doanh và Yêu
cầu người dùng. Tại sao hai loại yêu cầu này cần thiết và
làm thế nào chúng ảnh hưởng đến quyết định và thiết kế
sản phẩm phần mềm ?
ØGiải thích sự khác biệt giữa yêu cầu chức năng và yêu
cầu phi chức năng. Ví dụ, một yêu cầu chức năng và một
yêu cầu phi chức năng cho một ứng dụng di động.
Câu hỏi ôn tâp
ØTrình bày một tình huống thực tế mà anh/chị biết, trong
đó việc không hiểu rõ Yêu cầu người dùng đã dẫn đến
hậu quả không mong muốn cho sản phẩm. Đề xuất cách
giải quyết vấn đề này.
ØTại sao việc hiểu rõ nhu cầu và mong đợi của người dùng
cuối là quan trọng trong quá trình phát triển phần mềm?
Ø Mô tả một ví dụ cụ thể về yêu cầu phần mềm dựa trên kỹ
thuật mà một nhóm phát triển có thể đề xuất. Giải thích lý
do tại sao yêu cầu đó lại quan trọng.
Câu hỏi ôn tập
ØTrình bày một tình huống mà quy định pháp luật có thể
ảnh hưởng đến việc đưa ra yêu cầu cho một sản phẩm
phần mềm. Làm thế nào các nhà phát triển có thể đảm
bảo rằng sản phẩm của họ tuân thủ những quy định này?
ØTheo anh/chị, trong một dự án phần mềm, nhóm nào
trong số Người dùng cuối, Các bên liên quan, Nhóm phát
triển và Quy định pháp luật nên có ưu tiên cao nhất khi
xem xét yêu cầu? Giải thích lựa chọn của anh/chị.
Câu hỏi ôn tập
Ø Giả sử anh/chị là BA trong ngành ngân hàng. Mô tả quy trình
khám phá yêu cầu, từ chuẩn bị, chọn kỹ thuật, đến hiểu về nghiệp
vụ anh/chị ưu tiên gì và lý do?
Ø Giải thích tầm quan trọng của việc hiểu về mô hình kinh doanh và
sản phẩm liên quan khi tìm hiểu lĩnh vực nghiệp vụ. Anh/chị sẽ sử
dụng nguồn thông tin nào để đảm bảo tính đáng tin cậy ?
Ø Trình bày quy trình xác định User Story (US) từ khi tiếp xúc với
người dùng cho đến việc mô tả US. Giải thích sự quan trọng của
việc nhóm US thành Epic và Theme và vai trò của BA trong quá
trình này.