CASE STUDY ELICIT REQUIREMENT (OVERALL

MEETING WITH CUSTOMER TO ELICITE OVERAL ABOUT REQUIRE

QUESTIONNAIRES
- Business hiện tại của bên mình ntn?
=> Cái này nếu biết business rồi cũng cần confirm lại ý hiểu với KH.
Question 1 => Theo em hiểu bên mình đang kinh doanh/hoạt động về lĩnh vực xxx chuyên về yyy... không biết e
lại ý hiểu của em?

- Những khó khăn bên mình đang gặp phải với current business là gì?
- Mong muốn sắp tới của anh/chị ntn? điều đó mang lại benefit gì cho bên mình (tiết kiệm chi phí, th
Question 2 => Hiểu được current business, hiểu được khó khăn hiện tại, mong muốn sắp tới, và điều mong muố
đầu phân tích.

- Đối tượng sử dụng apps/tools đó là ai? (who?) họ có vai trò gì trong hệ thống?
=> Câu hỏi này giúp ta hiểu được các actors nào tham gia và họ giữ vai trò gì trong business process
- Hiện tại anh/chị đã có y/c cụ thể về app/tool mình muốn xây dựng chưa?
Question 3 => Khai thác tiếp từ câu trả lời của KH (rất nhiều KH đã có sẵn yêu cầu cụ thể)
=> Nếu KH đã có requirement cụ thể (sơ khai) rồi thì nhờ họ transfer hoặc gửi lại để mình xem và ph
bên trên để làm rõ.

- Ps: Có được anwsers từ KH giúp chúng ta hiểu được:

+ Business hiện tại của KH hoạt động thế nào, với business đó KH đang gặp khó khăn gì?
+ Mong muốn và định hướng sắp tới của họ ra sao? giải quyết được vấn đề gì, benefit mang lại cho họ ntn?
=> Từ đây mới nghĩ (or tìm kiếm) solution giải quyết vđ cho KH.
=> Đây là điều tối quan trọng khi first meeting với KH, elicit requirement ở mức sơ khai (overall)

After understanding overview requirement, we continue…

- App/tool anh/chị run trên nền tảng (environments) nào, web (firefox, chrome, ie, safari.. version o
Question 4 - Nếu run trên nền tảng web thì có responsive với mobility không?
- Hoặc thậm chí hỏi KH có yêu cầu gì về technical, security, database, performance, etc. không? (nếu K

- Anh/chị mong muốn app/tool khi nào được triển khai và đi vào hoạt động?
Question 5 - Ngoài ra anh/chị có lưu ý đặc biệt gì thêm không?
- App/tool hiện tại Anh/Chị muốn xây dựng có integrate đến other system nào khác với system bên
Question 6 => Phần này rất quan trọng vì nhiều bạn missed -> không rõ được scope ban đầu -> risk sau này tron

- Sau giai đoạn này -> ta hiểu được overview về KH -> đây là tiền đề để chúng ta tìm kiếm solutions.
+ Solution có thể cty chúng ta có sẵn hoặc chưa có -> chưa có thì cần phát triển mới hoặc tìm kiếm giải pháp có sẵn ở doa
+ Tham khảo những apps/tools hiện tại trên thị trường có the same business để suggest, refer..
Ps:
=> Tham khảo bằng cách download/setup những tools/apps có sẵn rồi run thử và trải nghiệm cũng như liệt kê danh sách
=> Liệt kê danh sách các function list của từng apps/tools có chung business để xem sự khác biệt
=> Dựa vào đó nghĩ ra solutions, function, features apps/tools giải quyết vđ cho KH.
=> Cái gì hay hợp lý thì học hỏi và cải tiến (đây là nguồn tham khảo hữu ích)
Tiếp đến hỏi họ xem những yêu cầu về nghiệp vụ…
- Những business nào quan trọng Anh/Chị nhất và muốn ưu tiên xử lý trước?
Question 7 => những thứ đó sẽ giúp bạn forcus vào nó để phân tích trong giai đoạn tiếp theo
Trường hợp KH biết rõ các tính năng họ muốn/chúng ta có solution trong đầu rồi thì tiếp tục hỏi
- Function/Features nào của app/tool quan trọng và muốn ưu tiên xử lý trước?
Question 8 => Cái này rất quan trọng vì chúng ta sẽ biết được priority của các function, features.
=> Priority list đôi khi cũng là main business của system, bạn có thể biết được luôn và focus vào nó đ
 - Function/Features nào của app/tool quan trọng và muốn ưu tiên xử lý trước?
Question 8 => Cái này rất quan trọng vì chúng ta sẽ biết được priority của các function, features.
=> Priority list đôi khi cũng là main business của system, bạn có thể biết được luôn và focus vào nó đ

- Dựa vào các câu trả lời của KH sau đó đánh giá xem mức độ hiểu requirement của BA thế nào, lúc đó ta sẽ có những qu
mentioned trong course).
- Sau khi đi qua được toàn bộ common questions bên trên, Business Analyst cần lên plan công việc sắp tới cần phải làm a
- Về mặt plan thì các bạn có thể tham khảo sheet "Planning" để view chi tiết...

- Ngoài việc lên plan tổng quan về công việc trong dự án, BA cũng nên apply mô hình scrum vào cuộc sống và đặc biệt là d

=> Daily task -> có thể sử dụng One Notes của Microsoft (prefer) or something like that…

Note: Phần này sẽ được mentoring detail trong course.

REMENT (OVERALL)

OVERAL ABOUT REQUIREMENT

AIRES

huyên về yyy... không biết em hiểu vậy đã đúng và đầy đủ chưa, nhờ anh/chị xác nhận

n mình (tiết kiệm chi phí, thời gian, nhân lực, etc.)?
sắp tới, và điều mong muốn đó giúp ích gì được cho KH là điều tối quan trọng khi bắt

thống?
ò gì trong business process của KH.
a?
thể)
c gửi lại để mình xem và phân tích, nếu chưa có thì cần xoáy sâu vào bộ #Question 2

cho họ ntn?

hrome, ie, safari.. version of browser?), mobile (ios, android) ?

rmance, etc. không? (nếu KH biết và có requirement về technical)

ng?

m nào khác với system bên mình không? Hay là độc lập?
ban đầu -> risk sau này trong quá trình develop.

tions.
iếm giải pháp có sẵn ở doanh nghiệp khác rồi kết nối
.

cũng như liệt kê danh sách các function, features, giao diện, behavior, etc.
ệt

ước?
tiếp theo
ỏi
rước?
on, features.
được luôn và focus vào nó để analysis trước.
 rước?
on, features.
được luôn và focus vào nó để analysis trước.

o, lúc đó ta sẽ có những question và ứng biến cụ thể sau đó (phần này sẽ được

việc sắp tới cần phải làm after first meeting.

o cuộc sống và đặc biệt là daily tasks.

 CASE STUDY ELICIT REQUIREMENT (DE

ANALYSIS DETAIL ABOUT REQUIREMENT (FUNCTION, FEAT

- CASE STUDY 1 (Elicit Overal Requirement) chúng ta đã hiểu tương đối nhiều về yêu cầu của Khách Hàng.
- Tiếp đến ta sẽ phân tích xem để xử lý được yêu cầu đó của Khách Hàng thì cần có Function, Features gì?

=> Tính năng của hệ thống thì áp dụng phương pháp phân tích từ general to details

Thường thì ta sẽ đặt câu hỏi cho chính chúng ta trước những điều dưới đây, nếu ta không tự trả lời được thì có t
(Case Study: LEAVE REQUEST)

QUESTIONNAIRES
- Để tạo được 1 đơn xin nghỉ phép (leave request) thì trước tiên chúng ta cần phải làm gì?
Question 1 => Tưởng tượng thử xem, ví dụ: nếu bạn muốn sử dụng hoặc post 1 status trên facebook
- Điều đầu tiên cần phải làm là gì? có phải là cần login?

AUTHENTICATION:
- Có phải chúng ta cần login vào hệ thống? vậy làm thế nào chúng ta có thể login được vào h
+ Có phải chúng ta cần phải có account để login?
+ Vậy account đó chúng ta lấy ở đâu? tự tạo mới hay được provided? nếu tạo mới thì tạo m
+ Ngoài ra login thì có thông qua third party không? (Google, facebook, zalo, etc.)
Question 2 - Chú ý:
+ Toàn bộ những question trên trong quá trình phân tích hoặc hỏi sẽ cần BA đưa ra các sugg
đó thay vì đẩy toàn bộ mọi thứ về phía Khách Hàng để trả lời.
+ Kỹ năng đặt câu hỏi cho đúng trọng tâm sẽ được mentoring ở buổi số 2 của course.

- Login xong thì logout được không?

- Logout rồi mà quên mật khẩu thì làm thế nào?
- Có phải chúng ta cần phải lấy lại mật khẩu? Khi lấy lại mật khẩu nhập những thông tin gì? (
Question 3 - Busines lấy lại mk thế nào? có send email, sms không? nếu có thì template thế nào?
- Format của việc reset password ntn? khi reset password xong có được mk rồi thì login với pa
login được? (cái này tùy yêu cầu của KH hoặc chúng ta có thể suggest).

- Giống như việc chúng ta đứng ngoài tòa nhà quan sát trước, sau đó ta sẽ biết tòa nhà bao nhiêu tầng? màu gì? c
- Sau đó chúng ta biết được cách đi vào nhà -> rồi bước chân vào cửa thì ta nhìn thấy cái gì đầu tiên (phòng khách

=> Áp dụng cách liên tưởng này ta sẽ hình dung về hệ thống nhanh và dễ dàng hơn.

Chúng ta tiếp tục theo luồng đó đối với những phần tiếp theo của system…
- Từ homepage có những gì? hình thù thế nào? menu ra làm sao? cách sắp xếp menu thế nà
=> Menu, homepage có những cái gì thì dựa vào requirement của những câu hỏi trước đó ta s
chúng ta có thể suggest rồi get confirmation từ phía KH hoặc thậm chí ta có thể hỏi trực tiếp m

Exp: Với bài toán Leave Request, cái KH mong muốn nhất là khi nhân viên có nhu cầu xin nghỉ
Question 4 sẽ được inform và họ có thể Approve hoặc Decline request đó. Thêm nữa đối với General Ma
có bao nhiêu người xin nghỉ phép, tình trạng đơn nghỉ phép thế nào, etc..

--> Tiếp tục đặt câu hỏi??

Đoạn này chúng ta cần xoáy sâu vào main business để tìm hiểu quy trình hiện tại của Khách Hàng thế nào.

Question 5: Nếu không có app/tool này thì hiện tại Anh/Chị đang thực hiện/xử lý thế nào? quy trình hiện tại bên
=> Question này KH thường sẽ nói ra cái current process của họ, điều này giúp ta hiểu được business process của KH
Question 5.1: Quy trình gồm bao nhiêu bước? actors nào thao gia cụ thể vào các step nào? họ có quyền cụ thể làm

=> Thông qua các question trên, chúng ta hiểu rõ hơn về process của KH --> ta sẽ đặt tiếp những question để han

- Create leave request ta cần input những thông tin gì? Thông tin gì bắt buộc/không?
- Create xong có Edit được không? có View lại được không? ai có quyền edit/view?
- Có Delete được không? delete xóa khỏi database hay only change status?
Question 6 - Có Cancel được không? cancel/delete khi nào? cần lý do không?
- Chú ý: Có những data mà relationship với nhau việc delete cần chú ý chỗ này (liên quan tới b

- Ta sẽ xoáy sâu vào màn hình create new để xem ngoài thông tin leave request thì có cần qu
Điều này rất quan trọng trong quá trình phân tích thiết kế ORD (Object Relationship Diagram
- Ví dụ:
+ Trên màn hình "Create new leave request" ta có những thông tin: [Request type], [Start d
[Reason], [Reason detail], [Supervisor], [Approver], [Expected approval date], [Expected appro
+ Ta xác định xem những fields nào thuộc nhóm dropdown-list --> xét xem dropdown đó fix
+ Để xác định được field dropdown-list là fix cứng hay load động ta chú ý điểm sau, value củ
suggest load động để dễ manage, còn lại nếu hầu như hoặc không thay đổi theo thời gian thì
Question 6.1 + Nếu load động thì load từ đâu? Table nào? field nào trong database?
+ Exp: có 2 fields [Request type] và [Reason] được load đồng --> từ đây ta có thể phát sinh t
Management" --> gồm những tính năng Create/View/Update/Delete/Active/Deactive, etc.

Ps: Cụ thể tất cả những phần này sẽ được mentoring trong course.

- Cancel có thông báo cho ai biết không, thông báo qua mail hay notification (hay cả 2), thôn
bcc cho ai? title email và contents thế nào?
Question 7 => BA hoàn toàn có thể suggest ra template và get confirmation từ phía KH, hoặc có thể hỏi K

- Sau khi created leave request thì làm thế nào để request đó được manager xem xét? có ph
- Submit thì submit cho manager nào? manager được chỉ định sẵn hay optional?
- Submit xong thì hệ thống sẽ làm gì? có send email hay notification cho manager không? --> n
Question 8 - Ngoài ra có send email hay notification cho requester hay không? --> nếu có thì quay lại bướ

- Sau khi Manager nhận được thông báo về leave request mới rồi thì đối với leave request đ
- Có edit, cancel, delete được request đó không? Nếu được thì được trong hoàn cảnh nào?
Ví dụ:
+ Request đã ở trạng thái "Submitted" mà Manager chưa approve hoặc reject --> Requeste
Question 9 + Ngoài ra thì sẽ không được phép edit hoặc cancel.
- Tiếp tục: nếu được edit/cancel trong tình huống này thì sau khi save có cần submit lại hoặc

TỔNG KẾT:
- Chúng ta sẽ dựa theo cách phân tích này kết hợp với bộ common question bên trên và apply cho toàn bộ những
hệ thống Leave Request những phần liên quan tới User Management, Entitle Day Management, Notification, Ema
- Lưu ý: Trong quá trình phân tích sẽ phát sinh thêm những question detail khác nữa, điều này phụ thuộc vào các
tình huống sẽ được giải quyết ở quá trình thực hành xuyên suốt quá học.

=> Cuối cùng khi ra được danh sách các tính năng của hệ thống rồi, ta cần liệt kê toàn bộ vào trong file "Function
Refer sheet "Function List" for more detail.
TỔNG KẾT:
- Chúng ta sẽ dựa theo cách phân tích này kết hợp với bộ common question bên trên và apply cho toàn bộ những
hệ thống Leave Request những phần liên quan tới User Management, Entitle Day Management, Notification, Ema
- Lưu ý: Trong quá trình phân tích sẽ phát sinh thêm những question detail khác nữa, điều này phụ thuộc vào các
tình huống sẽ được giải quyết ở quá trình thực hành xuyên suốt quá học.

=> Cuối cùng khi ra được danh sách các tính năng của hệ thống rồi, ta cần liệt kê toàn bộ vào trong file "Function
Refer sheet "Function List" for more detail.
T REQUIREMENT (DETAILS)

REMENT (FUNCTION, FEATURES, SCOPING)

cầu của Khách Hàng.

unction, Features gì?

không tự trả lời được thì có thể hỏi KH

ESTIONNAIRES
ên chúng ta cần phải làm gì?
ost 1 status trên facebook

úng ta có thể login được vào hệ thống? login được vào hệ thống thì cần cái gì?

ovided? nếu tạo mới thì tạo mới thế nào ? gồm những thông tin gì ? Validate ra làm sao?
acebook, zalo, etc.)

hỏi sẽ cần BA đưa ra các suggestion trong quá trình hỏi để đảm bảo chúng ta có sự tư vấn trong

ở buổi số 2 của course.

ẩu nhập những thông tin gì? (email hay sđt, etc. ?)

thì template thế nào?
có được mk rồi thì login với password mới có được không? hay phải change lại password thì mới
ggest).

nhà bao nhiêu tầng? màu gì? cửa ở đâu? đi lại thế nào?
ấy cái gì đầu tiên (phòng khách), tương tự như vậy với system (homepage)

o? cách sắp xếp menu thế nào?

ủa những câu hỏi trước đó ta sẽ có, hoặc có thể tham khảo other system with the same business
ậm chí ta có thể hỏi trực tiếp mong muốn của KH.

nhân viên có nhu cầu xin nghỉ phép, họ được phép tạo leave request, sau đó Manager trực thuộc
Thêm nữa đối với General Manager/HR họ muốn làm báo cáo xem trong tuần, tháng, quý, năm
nào, etc..
a Khách Hàng thế nào.

ế nào? quy trình hiện tại bên mình ra sao? Anh/Chị có thể mô tả cho em biết được không?
được business process của KH, từ đây ta sẽ biết được app/tool có workflow hay không.
p nào? họ có quyền cụ thể làm gì?

t tiếp những question để handle được process đó...

tin gì bắt buộc/không?

có quyền edit/view?
nge status?
g?
chú ý chỗ này (liên quan tới bảo toàn dữ liệu)

tin leave request thì có cần quản lý thêm thông tin gì khác hay không?
(Object Relationship Diagram), ERD (Entity Relationship Diagram) sau này.

ng tin: [Request type], [Start date], [End date], [Leaving time], [Coming time], [Working duration],
pproval date], [Expected approval time], etc.
t --> xét xem dropdown đó fix cứng value hay load động?
ộng ta chú ý điểm sau, value của dropdown-list nào mà thường thay đổi nhiều theo thời gian thì
ng thay đổi theo thời gian thì suggest fix cứng để giảm work-load.
atabase?
-> từ đây ta có thể phát sinh thêm tính năng " Request Type Management" hoặc "Reason
elete/Active/Deactive, etc.

urse.

y notification (hay cả 2), thông báo với nội dung gì? template thế nào? nếu là email thì to, cc,

từ phía KH, hoặc có thể hỏi KH trong tình huống này luôn.

được manager xem xét? có phải ta sẽ cần tính năng "Submit Leave Request"?
sẵn hay optional?
tion cho manager không? --> nếu có thì quay lại bước #Question 7 để hỏi detail về đoạn này.
ng? --> nếu có thì quay lại bước #Question 7 để hỏi detail về đoạn này.

rồi thì đối với leave request đó thì Requester có được làm gì khác với leave request đó không?
được trong hoàn cảnh nào?

rove hoặc reject --> Requester có thể edit hoặc cancel leave request được.

hi save có cần submit lại hoặc có mention gì cho Manager để họ biết không?

n và apply cho toàn bộ những business khác hoặc các tính năng khác của hệ thống. Cụ thể trong
anagement, Notification, Email, Reques Type Management, Reason Management, etc.
a, điều này phụ thuộc vào cách trả lời của khách hàng. Lúc đó chúng ta sẽ ứng biến tiếp, cụ thể

n bộ vào trong file "Function List" rồi mang đi confirm với Khách Hàng để chốt scope dự án.
n và apply cho toàn bộ những business khác hoặc các tính năng khác của hệ thống. Cụ thể trong
anagement, Notification, Email, Reques Type Management, Reason Management, etc.
a, điều này phụ thuộc vào cách trả lời của khách hàng. Lúc đó chúng ta sẽ ứng biến tiếp, cụ thể

n bộ vào trong file "Function List" rồi mang đi confirm với Khách Hàng để chốt scope dự án.
 # Task name Duration Start

1 LEAVE REQUEST PROJECT 3 days 3/23/2020

1.1 Study requirements 10 hours 3/23/2020
1.1.1 Tìm hiểu phiếu yêu cầu của KH 4 hours 3/23/2020
1.1.2 Tìm hiểu về business của doanh nghiệp 2 hours 3/23/2020
Tìm giải pháp giải hỗ trợ KH (research, refer to existing
1.1.3 apps/tools) 4 hours 3/23/2020
1.2 Make Q&A 2 hour 3/24/2020
1.2.1 Làm Q&A trong quá trình study 2 hour 3/24/2020
1.3 Meeting With Customer 5 hours 3/24/2020
1.3.1 Gặp KH lấy yêu cầu tổng quan ban đầu 2 hours 3/24/2020
1.3.2 Viết MOM confirm nội dung meeting 1 hour 3/24/2020
1.3.3 Gặp KH lấy thông tin, tìm hiểu yêu cầu chi tiết buổi n.. 1 hour 3/24/2020
1.3.4 Viết MOM confirm nội dung meeting 1 hour 3/24/2020
Số lượng buổi meeting tùy thuộc after elicit requirement..
Tobe define…
1.4 Analysis Requirement 8 hours 3/24/2020
1.4.1 Liệt kê danh sách function list (User Story) của hệ thống 4 hours 3/25/2020
1.4.2 Q&A và Confirm function list với customer round 1 2 hours 3/24/2020
1.4.3 Update function list (User Story) sau khi KH feedback 1 hours 3/24/2020
1.4.4 Q&A và Confirm function với customer round n 1 hours 3/24/2020
1.5 High level requirements (diagram) 10 hours 3/24/2020
1.5.1 Thiết kế ORD diagram 2 hours 3/24/2020
1.5.2 Thiết kế Workflow digram 2 hours 3/24/2020
1.5.3 Thiết kế State Transition digram 2 hours 3/24/2020
1.5.4 Thiết kế Use Case diagram 2 hours 3/24/2020
1.5.5 Thiết kế Permission Matrix 2 hours 3/24/2020
1.5 Writing Wireframe Document 8 hours 3/24/2020
1.5.1 Vẽ mockup screen chức năng A 2 hours 3/24/2020
1.5.2 Mô tả màn hình chức năng A 2 hours 3/24/2020
1.5.3 Vẽ mockup screen chức năng N 2 hours 3/24/2020
1.5.4 Mô tả màn hình chức năng N 2 hours 3/24/2020
1.6 Reviewing Wireframe 8 hours 3/24/2020
1.6.1 Review wireframe/mockup round 1 2 hours 3/24/2020
1.6.2 Review wireframe/mockup round 1 2 hours 3/24/2020
1.6.3 Review wireframe/mockup round 2 2 hours 3/24/2020
1.6.4 Review wireframe/mockup round 2 2 hours 3/24/2020
1.7 Writing SRS Document 8 hours 3/25/2020
1.7.1 Viết Use Case Specification chức năng A 2 hours 3/24/2020
1.7.2 Update Use Case Specification chức năng A 2 hours 3/24/2020
1.7.3 Viết Use Case Specification chức năng N 2 hours 3/24/2020
1.7.4 Update Use Case Specification chức năng N 2 hours 3/24/2020
1.8 Reviewing Wireframe 8 hours 3/24/2020
1.8.1 Review wireframe/mockup round 1 2 hours 3/24/2020
1.8.2 Review wireframe/mockup round 1 2 hours 3/24/2020
1.8.3 Review wireframe/mockup round 2 2 hours 3/24/2020
1.8.4 Review wireframe/mockup round 2 2 hours 3/24/2020
1.9 Development Support 8 hours 3/24/2020
1.9.1 Transfer Requirement to development team 2 hours 3/24/2020
1.9.2 Update SRS after transfer 2 hours 3/24/2020
2 UAT Support 2 hours 3/24/2020
2.0.1 Join UAT walkthrough session 2 hours 3/24/2020
 % Work
End Predecessors Resources Note
complete
3/25/2020 QuangNX2
3/23/2020 QuangNX2
3/23/2020 1 QuangNX2
3/23/2020 2 QuangNX2

3/23/2020 4 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 3 QuangNX2

3/25/2020 QuangNX2
3/25/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/25/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/25/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2
3/24/2020 QuangNX2