03 - Chuong 2 - Phat Hien Va Phan Tich Yeu Cau

CHƯƠNG 2:
PHÁT TRIỂN YÊU CẦU

Nội dung
2.1. Phát hiện yêu cầu
2.2. Phân tích và lập tài liệu đặc tả yêu cầu
2.3. Xác nhận yêu cầu
2.4. Các vấn đề khác
06/21/2023 Phân tích yêu cầu phần mềm 2

2.1. Phát hiện yêu cầu
2.1.1. Thiết lập các yêu cầu nghiệp vụ
2.1.2. Kết nối với người dùng
2.1.3. Phát hiện yêu cầu

Xác định các yêu cầu kinh doanh, nghiệp vụ
• Các yêu cầu kinh doanh nghiệp vụ (Business requirements) đề cập
đến một tập hợp các thông tin được tổng hợp lại, mô tả các yêu cầu
đối với một hoặc nhiều dự án nhằm đưa ra giải pháp và các kết quả
kinh doanh, nghiệp vụ mong đợi. Các cơ hội kinh doanh, các mục tiêu
kinh doanh, các chỉ số thành công và tầm nhìn của dự án tạo nên các
yêu cầu kinh doanh nghiệp vụ.
• Các vấn đề về yêu cầu kinh doanh nghiệp vụ phải được giải quyết
trước khi xác định các yêu cầu chức năng và phi chức năng. Việc xác
định phạm vi và giới hạn của dự án giúp ích rất nhiều cho các cuộc
thảo luận về các tính năng được đề xuất và các mục tiêu. Các yêu cầu
kinh doanh nghiệp vụ là tài liệu tham khảo để đưa ra quyết định về
các thay đổi và cải tiến yêu cầu được đề xuất cũng như xác định xem
liệu một yêu cầu được đề xuất có nằm trong phạm vi yêu cầu nghiệp
vụ hay không.
• Xác định các lợi ích kinh doanh, nghiệp vụ mong muốn:
- Chỉ nên bắt đầu một dự án khi đã hiểu rõ về giá trị mà dự
án mang lại
- Cần đặt ra các mục tiêu kinh doanh nghiệp vụ theo hướng
có thể đo lường được và xác định các chỉ số thành công
(success metrics) cho phép đo lường sự đáp ứng các mục
tiêu đề ra
- Yêu cầu kinh doanh nghiệp vụ thường đến từ các bên liên
quan như: nhà tài trợ tài chính, giám đốc điều hành công
ty, tiếp thị, … BA cần đảm bảo các bên liên quan tham gia
vào việc xác định mục tiêu và đồng ý với các mục tiêu đề
ra (nhằm tránh rủi ro, kiện tụng, hoặc loại bỏ các mục tiêu)
• Xác định Tầm nhìn sản phẩm và phạm vi dự án:
- Tầm nhìn sản phẩm và phạm vi dự án là 2 vấn đề cốt lõi
của yêu cầu nghiệp vụ
- Tầm nhìn sản phẩm mô tả ngắn gọn sản phẩm cuối cùng
(đạt được các mục tiêu kinh doanh nghiệp vụ), giúp
đảm bảo rằng tất cả các bên liên quan đều biết mình
đang muốn đi tới đâu và sẽ đạt được những gì.
- Phạm vi dự án tạo nên đường biên xác định những gì ở
trong và ngoài dự án, giúp đảm bảo chắc chắn rằng các
bên liên quan đang đề cập đến cùng một vấn đề của dự
án

• Sự xung đột giữa các yêu cầu nghiệp vụ
Ví dụ:

Tài liệu tầm nhìn và phạm vi
• Tài liệu tầm nhìn và phạm vi tập hợp các yêu cầu nghiệp vụ vào trong
một tài liệu duy nhất làm tiền đề cho các bước phát triển dự án tiếp theo
• Chủ sở hữu của tài liệu tầm nhìn và phạm vi là nhà tài trợ cho dự án,
đơn vị tài trợ hoặc những người có vai trò tương đương; BA có thể làm
việc với các cá nhân này để làm rõ các yêu cầu kinh doanh nghiệp vụ và
viết tài liệu tầm nhìn và phạm vi.
• Tài liệu tầm nhìn và phạm vi chỉ xác định phạm vi ở mức cao; các phạm
vi chi tiết sẽ được chỉ ra trong cơ sở phát hành (release baseline) do các
nhóm phát triển xác định
• Một số nội dung của tài liệu tầm nhìn và phạm vi như mục tiêu kinh
doanh, các rủi ro kinh doanh và hồ sơ của các bên liên quan, … có thể
được sử dụng lại từ dự án này sang dự án khác
• Các dự án lớn mới cần có cả một tài liệu tầm nhìn và phạm hoàn chỉnh
và một tài liệu đặc tả yêu cầu

Tài liệu tầm nhìn và phạm vi
• Mẫu tài liệu tầm nhìnvà
phạm vi:

Các kỹ thuật biểu diễn phạm vi
• Sử dụng Context diagram

• Sử dụng Ecosystem Map

• Sử dụng Feature tree

• Liệt kê Event list

Các lớp người dùng
• Lớp người dùng là tập con những người dùng sản phẩm,
tập con những khách hàng của sản phẩm hoặc tập con các
bên liên quan
• Một cá nhân có thể thuộc về nhiều lớp người dùng khác
nhau

• Phân lớp người dùng
Các lớp người dùng khác nhau ở những khía cạnh nhất định:
- Đặc quyền truy cập hoặc mức bảo mật của người dùng (như
người dùng thông thường, người dùng khách, quản trị viên)
- Các tác vụ mà người dùng thực hiện trong suốt các hoạt động
nghiệp vụ
- Các tính năng mà người dùng sử dụng
- Tần suất sử dụng sản phẩm
- Trải nghiệm thuộc miền ứng dụng và chuyên môn về hệ thống
máy tính
- Các nền tảng mà người dùng sẽ sử dụng (máy tính bàn, máy tính
xách tay, máy tính bảng, điện thoại thông minh, …)
- Ngôn ngữ mẹ đẻ
- Cách thức người dùng tương tác với hệ thống trực tiếp hay gián
tiếp
• Phân lớp người dùng
Ví dụ về một hệ thống phân cấp các bên liên quan, khách hàng, người
dùng và các lớp người dùng

• Xác định các lớp người dùng
- Một kỹ thuật xác định và đặc tả các lớp người dùng khác nhau là
“expand then contract” (Gottesdiener 2002):
+ Bắt đầu bằng cách đặt câu hỏi với nhà tài trợ dự án: ai là
người mà nhà tài trợ hy vọng sẽ sử dụng hệ thống.
+ Sau đó, cố gắng nghĩ tới tất cả các lớp người dùng, không bỏ
qua lớp người dùng nào.
+ Tiếp theo, tìm các nhóm có nhu cầu tương tự có thể kết hợp
lại hoặc coi là một lớp người dùng chính với một số lớp con.
Cố gắng giảm bớt danh sách lớp người dùng xuống khoảng
<= 15 lớp.

- Các mô hình phân tích khác nhau có thể giúp xác định các lớp
người dùng. Các thực thể bên ngoài được hiển thị bên ngoài hệ
thống trên biểu đồ ngữ cảnh là các ứng viên cho các lớp người
dùng. Sơ đồ tổ chức công ty cũng có thể giúp khám phá người
dùng tiềm năng và các bên liên quan khác. Trong khi thực hiện
phân tích các bên liên quan và người dùng, cần nghiên cứu sơ đồ
tổ chức để tìm ra:
+ Các phòng ban tham gia vào quy trình nghiệp vụ.
+ Các phòng ban bị ảnh hưởng bởi quy trình nghiệp vụ.
+ Bộ phận hoặc tên vai trò trong đó người dùng trực tiếp hoặc
gián tiếp có thể được tìm thấy.
+ Các lớp người dùng trải rộng trên nhiều phòng ban.
+ Các phòng ban có thể có tương tác với các bên liên quan bên
ngoài bên ngoài công ty.
- Ví dụ: Một phần sơ đồ tổ chức công ty dược phẩm:

Ngoài ra cần kiểm tra lại các tài liệu về các lớp người dùng và các
đặc điểm, trách nhiệm và vị trí của họ trong đặc tả yêu cầu phần
mềm hoặc trong kế hoạch yêu cầu cho dự án; kiểm tra lại các tài
liệu tầm nhìn và phạm vi để tránh sự xung đột và trùng lặp.
Ví dụ: Các lớp người dùng của Hệ thống theo dõi hóa chất gồm:
- Các kỹ sư hóa học (Chemists)
- Người mua (Buyers)
- Nhân viên kho hóa chất (Chemical stockroom staff)
- Nhân viên phòng Sức khỏe và An toàn (Health and Safety
Department staff)

• Persona của người dùng
Để các lớp người dùng trở nên sống động, có thể tạo “persona” cho
từng lớp người dùng (Cooper 2004; Leffingwell 2011). Một
persona là một mô tả của một người giả định, chung chung, đại
diện cho một nhóm người dùng có các đặc điểm và nhu cầu tương
tự. Sử dụng persona cho phép hiểu các yêu cầu và thiết kế trải
nghiệm người dùng để đáp ứng tốt nhất nhu cầu của các cộng đồng
người dùng cụ thể.

• Persona của người dùng
Ví dụ: Bản mô tả một lớp người dùng Hệ thống theo dõi hóa chất:
Fred, 41 tuổi, đã trở thành một nhà hóa học tại Công ty Dược phẩm
Contoso kể từ khi nhận bằng Tiến sĩ 14 năm trước. Anh ấy không kiên
nhẫn với máy tính. Fred thường làm việc trên hai dự án cùng một lúc
trong các lĩnh vực hóa học liên quan. Phòng thí nghiệm của anh ấy chứa
khoảng 300 chai hóa chất và bình gas. Trong một ngày, trung bình anh
ấy sẽ cần bốn hóa chất mới. Hai trong số này sẽ là hóa chất thương mại
trong kho, một sẽ cần phải được đặt hàng, và một sẽ đến từ việc cung cấp
các mẫu hóa chất độc quyền của Contoso. Đôi khi, Fred sẽ cần một hóa
chất nguy hiểm cần được đào tạo đặc biệt để xử lý an toàn. Khi anh mua
hóa chất lần đầu tiên, Fred muốn bảng dữ liệu an toàn vật liệu được tự
động gửi đến cho anh qua email. Mỗi năm, Fred sẽ tổng hợp khoảng 20
hóa chất độc quyền mới. Fred muốn một báo cáo về việc sử dụng hóa
chất của anh ta cho tháng trước sẽ được tạo tự động và gửi cho anh ta
qua email để anh ta có thể theo dõi phơi nhiễm hóa chất của mình.
• Kết nối với đại diện người dùng
Mỗi loại dự án đều cần có đại diện phù hợp để cung cấp tiếng nói
của người dùng. Những người dùng này nên tham gia trong suốt
vòng đời phát triển chứ không phải chỉ trong giai đoạn xác lập yêu
cầu khi bắt đầu dự án. Mỗi lớp người dùng cần một người đại diện.
Đó có thể là người dùng đến từ chính công ty triển khai dự án, từ
các trang web thử nghiệm, … Thay vì phỏng đoán, cần gặp mặt và
hỏi trực tiếp những đại diện này. Chú ý: Cần cân nhắc thiết lập các
nhóm tập trung của những người dùng hiện tại của sản phẩm hoặc
sản phẩm của đối thủ cạnh tranh. Và phải chắc chắn rằng các nhóm
tập trung này đại diện cho các lớp người dùng có nhu cầu nhằm
thúc đẩy sự phát triển sản phẩm.

• Kết nối với đại diện người dùng
Một số cách thức giao tiếp giữa người dùng và nhà phát triển

• Product Champion
- Product champion (PC): Là người đứng giữa các thành viên của
một lớp người dùng và nhà phân tích kinh doanh dự án, chịu
trách nhiệm thu thập các yêu cầu từ các thành viên khác của các
lớp người dùng mà họ đại diện và điều hòa sự không nhất quán.
Lý tưởng nhất: PC là người dùng thực tế, có một tầm nhìn rõ
ràng về hệ thống mới  có sự nhiệt tình khi thấy được lợi ích mà
hệ thống mới sẽ đem lại cho chính PC và lớp người dùng mà PC
đại diện. PC cũng nên là những người giao tiếp hiệu quả, được
đồng nghiệp tôn trọng, có sự hiểu biết thấu đáo về miền ứng dụng
và môi trường vận hành giải pháp.
- External product champions: Thường khó tìm, đôi khi phải dựa
vào các chuyên gia tư vấn bên ngoài để thay thế cho người dùng
thực tế

Công việc của PC:
* Lập kế hoạch:
̵ Tinh chỉnh phạm vi và giới hạn của sản phẩm
̵ Xác định các hệ thống khác để tương tác
̵ Đánh giá tác động của hệ thống mới đối với hoạt động nghiệp vụ
̵ Xác định đường dẫn chuyển tiếp từ các ứng dụng hiện tại hoặc
thao tác thủ công
̵ Xác định các tiêu chuẩn và chứng nhận yêu cầu có liên quan

* Yêu cầu:
̵ Thu thập đầu vào theo yêu cầu từ người dùng khác
̵ Phát triển các kịch bản sử dụng, trường hợp sử dụng và câu
chuyện của người dùng
̵ Giải quyết xung đột giữa các yêu cầu được đề xuất trong lớp
người dùng
̵ Xác định các ưu tiên thực hiện
̵ Cung cấp đầu vào liên quan đến hiệu suất và các yêu cầu chất
lượng khác
̵ Đánh giá các nguyên mẫu
̵ Làm việc với những người ra quyết định khác để giải quyết
xung đột giữa các yêu cầu từ các bên liên quan khác nhau
̵ Cung cấp các giải pháp cụ thể
* Xác nhận:
̵ Xem xét bản đặc tả yêu cầu
̵ Xác định tiêu chí chấp nhận
̵ Phát triển các kiểm thử chấp nhận của người dùng từ các tình
huống sử dụng
̵ Cung cấp các bộ dữ liệu thử nghiệm
̵ Thực hiện kiểm thử beta hoặc kiểm thử chấp nhận của người
dùng

* Hỗ trợ người dùng:
̵ Viết các phần tài liệu người dùng và văn bản trợ giúp
̵ Đóng góp cho tài liệu đào tạo hoặc hướng dẫn
̵ Trình diễn hệ thống với các đồng nghiệp.

* Quản lý thay đổi:
̵ Đánh giá và ưu tiên sửa lỗi và yêu cầu nâng cao
̵ Tự động điều chỉnh phạm vi của các bản phát hành hoặc lặp lại
trong tương lai
̵ Đánh giá tác động của những thay đổi được đề xuất đối với
người dùng và quy trình nghiệp vụ
̵ Tham gia vào việc đưa ra quyết định thay đổi

2.1.3. Phát hiện yêu cầu
2.1.3.1. Phát hiện yêu cầu
2.1.3.2. Các kỹ thuật phát hiện yêu cầu
2.1.3.3. Lập kế hoạch phát hiện yêu cầu
2.1.3.4. Chuẩn bị cho phát hiện yêu cầu
2.1.3.5. Thực hiện các hoạt động phát hiện yêu cầu
2.1.3.6. Theo dõi sau khi phát hiện yêu cầu
2.1.3.7. Phân loại thông tin đầu vào từ khách hàng
2.1.3.8. Một số vấn đề khác

• Trọng tâm của phát triển yêu cầu là phát hiện yêu cầu. Đây là
quá trình xác định các nhu cầu và ràng buộc của các bên liên
quan khác nhau cho một hệ thống phần mềm.
• Phát hiện không giống như thu thập, cũng không đơn giản
chỉ là ghi chép lại chính xác những gì người dùng nói. Phát
hiện là một quá trình hợp tác và phân tích, bao gồm các hoạt
động thu thập, khám phá, trích xuất và xác định các yêu cầu.
• Phát hiện được sử dụng để khám phá các yêu cầu nghiệp vụ,
yêu cầu người dùng, yêu cầu chức năng và phi chức năng,
cùng với các loại thông tin khác.
• Đây là khía cạnh quan trọng nhưng lại đầy thách thức, dễ bị
lỗi và cần các kỹ năng giao tiếp chuyên sâu trong phát triển
phần mềm.
• Các hoạt động trong một phiên phát hiện yêu cầu:

• Việc lôi cuốn người dùng vào quá trình phát hiện yêu cầu
là hết sức cần thiết để có được sự hỗ trợ của người dùng.
• BA cần cố gắng hiểu quá trình suy nghĩ đằng sau các yêu
cầu của người dùng, theo quá trình này, người dùng sẽ đưa
ra quyết định về công việc của họ.
• Cần chắc chắn rằng mọi người đều hiểu tại sao hệ thống
phải thực hiện một số chức năng nhất định.
• Cần cố gắng tìm kiếm các yêu cầu được đề xuất phản ánh
các quy trình hoặc quy tắc nghiệp vụ đã lỗi thời hoặc
không hiệu quả, không nên đưa vào hệ thống mới.

• BA phải tạo ra một môi trường thuận lợi cho việc thăm dò
kỹ lưỡng sản phẩm.
• Để tạo điều kiện giao tiếp rõ ràng, cần sử dụng các thuật
ngữ của lĩnh vực nghiệp vụ thay vì các thuật ngữ kỹ thuật
(nên ghi lại ý nghĩa của các thuật ngữ nghiệp vụ thuộc
miền ứng dụng trong bảng chú giải).
• Cần giải thích cho khách hàng hiểu một cuộc thảo luận về
các chức năng có thể không phải là một cam kết sẽ đưa các
chức năng được thảo luận vào sản phẩm.
• Cần tích cực động não và tưởng tượng các khả năng để
phân tích các ưu tiên, tính khả thi và các hạn chế trong thực
tế, sau đó đề xuất danh sách ưu tiên với các bên liên quan.

• Chú ý: Đầu ra của phát triển yêu cầu là một sự hiểu biết
chung về các nhu cầu của các bên liên quan của dự án. Khi
các nhà phát triển hiểu những nhu cầu đó, họ có thể khám
phá các giải pháp thay thế để giải quyết chúng. Vì vậy,
không nên bắt tay vào thiết kế hệ thống cho đến khi thực sự
hiểu được vấn đề!

2.1.3.2. Các kỹ thuật phát hiện yêu cầu
• Phỏng vấn (Interviews)
• Hội thảo (Workshops)
• Nhóm tập trung (Focus groups)
• Quan sát (Observations)
• Bảng câu hỏi (Questionnaires)
• Phân tích giao diện hệ thống (System interface analysis )
• Phân tích giao diện người dùng (User interface analysis)
• Phân tích tài liệu (Document analysis )

Phỏng vấn (Interviews)
• Một cách rõ ràng, hiển nhiên nhất để tìm ra những gì mà người dùng của
một hệ thống phần mềm cần là trực tiếp hỏi họ. Các cuộc phỏng vấn chính
là nguồn yêu cầu đầu vào truyền thống cho cả các sản phẩm thương mại và
các hệ thống thông tin, trên tất cả các phương pháp phát triển phần mềm.
• Có thể tổ chức các cuộc phỏng vấn cá nhân hoặc phỏng vấn theo nhóm
nhỏ.
• Nếu mới bắt đầu làm việc với miền ứng dụng, các cuộc phỏng vấn với các
chuyên gia sẽ giúp người phỏng vấn chuẩn bị mô hình và dự thảo các yêu
cầu để sử dụng trong các cuộc phỏng vấn hoặc các hội thảo tiếp theo.
• Các cuộc phỏng vấn cũng thích hợp để phát hiện các yêu cầu nghiệp vụ từ
các giám đốc điều hành - những người không có nhiều thời gian.
• Nếu có thể thiết lập mối quan hệ với người được phỏng vấn, họ sẽ cảm
thấy an toàn khi chia sẻ suy nghĩ của mình trong các cuộc phỏng vấn một -
một hoặc phỏng vấn trong một nhóm nhỏ hơn là chia sẻ trong các cuộc hội
thảo lớn.

• Một số lời khuyên khi tổ chức các cuộc phỏng vấn:
- Thiết lập mối quan hệ: Để bắt đầu một cuộc phỏng vấn,
nên tự giới thiệu về bản thân (nếu người tham dự không
biết bạn); ngoài ra, cần xem lại chương trình, nhắc nhở
người tham dự về các mục tiêu của phiên và giải đáp bất
kỳ câu hỏi hoặc thắc mắc sơ bộ nào về người tham dự.
- Phỏng vấn trong phạm vi: Cần giữ cho cuộc thảo luận
tập trung vào các mục tiêu đề ra, tránh lạc đề.
- Chuẩn bị trước các câu hỏi: Chuẩn bị trước các tài liệu,
chẳng hạn như một danh sách các câu hỏi để hướng dẫn
cuộc trò chuyện.

• Một số lời khuyên khi tổ chức các cuộc phỏng vấn:
- Đề xuất ý tưởng: Không chỉ đơn giản là ghi lại những gì
khách hàng nói, một BA sáng tạo nên đề xuất các ý
tưởng và giải pháp thay thế trong quá trình phát hiện yêu
cầu. Người dùng có thể sẽ cảm thấy phấn khích khi BA
đề xuất các chức năng có thể làm cho hệ thống có giá trị
đặc biệt.
- Lắng nghe một cách tích cực: Luyện tập các kỹ thuật
lắng nghe tích cực (nghiêng người về phía trước, thể
hiện sự kiên nhẫn, đưa ra phản hồi bằng lời nói và hỏi
lại khi có điều gì đó không rõ ràng) và diễn giải (diễn
giải thông điệp của người nói để thể hiện sự hiểu biết
của người nghe về thông điệp đó).
Hội thảo (Workshops)
• Các cuộc hội thảo sẽ khuyến khích sự hợp tác của các bên liên quan
trong việc xác định các yêu cầu.
• Theo Ellen Gottesdiener (2002), một hội thảo về yêu cầu là một
cuộc họp có cấu trúc, trong đó một nhóm các bên liên quan và các
chuyên gia nội dung được lựa chọn cẩn thận sẽ làm việc cùng nhau
để xác định, tạo, tinh chỉnh và đạt đến kết quả là các sản phẩm (như
mô hình và tài liệu) thể hiện các yêu cầu của người dùng.
• Hội thảo thường bao gồm một số bên liên quan, từ người dùng đến
nhà phát triển và nhân viên kiểm thử.
• Facilitator (người điều hành/người hướng dẫn) đóng một vai trò
quan trọng trong việc lập kế hoạch hội thảo, lựa chọn những người
tham gia và dẫn dắt họ đạt được kết quả mong đợi.
• Có thể xem xét việc có thêm Facilitator bên ngoài hoặc BA thứ 2 để
BA thứ nhất dành toàn bộ sự chú ý của mình cho việc thảo luận.

• Với các hội thảo chuyên sâu, có nhiều người tham gia trong
thời gian dài (vài ngày): Cần lên kế hoạch cẩn thận để tránh
lãng phí thời gian; các tài liệu cho hội thảo cần được chuẩn
bị trước; cần sử dụng các kỹ thuật phát hiện yêu cầu trước
các hội thảo, sau đó tập hợp các bên liên quan để cùng
nhau làm việc về các vấn đề cần thiết.

• Một số lời khuyên để tổ chức các hội thảo phát hiện yêu cầu hiệu quả
- Thiết lập và thực thi các nguyên tắc cơ bản: Nên thống nhất một số
nguyên tắc hoạt động cơ bản, ví dụ: Hội thảo bắt đầu và kết thúc
đúng giờ; mọi người cần để điện thoại ở chế độ im lặng; tại một thời
điểm chỉ một người phát biểu; các cá nhân cần tích cực đóng góp ý
kiến; hội thảo tập trung vào các vấn đề chính hơn là các vấn đề cá
nhân; …
- Phân công nhiệm vụ cho các thành viên: Facilitator cần phải đảm bảo
rằng các nhiệm vụ đã được phân công cho các thành viên đảm nhiệm:
ghi chép, chú ý thời gian, quản lý phạm vi thảo luận, quản lý việc
thực hiện các nguyên tắc, và đảm bảo cho mọi người đều nghe được.
- Lập kế hoạch chương trình hội thảo: Mỗi hội thảo cần có một kế
hoạch rõ ràng được lập và gửi cho những người tham gia trước khi
bắt đầu hội thảo để họ biết các mục tiêu và kết quả mong đợi nhằm
có sự chuẩn bị phù hợp.

- Hội thảo trong phạm vi: Tham khảo các yêu cầu nghiệp vụ để xác nhận
xem các yêu cầu mà người dùng đề xuất có nằm trong phạm vi dự án
hay không. Cần giữ cho cuộc hội thảo tập trung vào các mục tiêu của
phiên hội thảo, tránh lạc đề.
- Lưu lại các vấn đề cần xem xét sau: Một loạt thông tin ngẫu nhiên
nhưng quan trọng có thể xuất hiện trong các cuộc thảo luận phát hiện
yêu cầu: các thuộc tính chất lượng, quy tắc nghiệp vụ, giao diện người
dùng, các ý tưởng, … Cần ghi lại các vấn đề này để thể hiện sự tôn
trọng đối với người đề xuất chúng và để thảo luận tiếp nếu cần.
- Thời gian thảo luận: Xem xét phân bổ khung thời gian cố định cho mỗi
chủ đề thảo luận. Cuộc thảo luận có thể cần phải kết thúc muộn song
khung thời gian được lập sẽ giúp tránh tình trạng một chủ đề kéo dài quá
lâu khiến các chủ đề quan trọng khác bị bỏ qua vì hết thời gian. Khi hết
thời gian thảo luận một chủ đề, cần tóm tắt trạng thái và các bước tiếp
theo trước khi rời khỏi chủ đề đó.
• Một số lời khuyên để tổ chức các hội thảo phát hiện yêu cầu
hiệu quả
- Duy trì các nhóm thảo luận nhỏ nhưng bao gồm các bên
liên quan phù hợp: Các nhóm nhỏ có thể làm việc nhanh
hơn nhiều so với các nhóm lớn. Các hội thảo đông thành
viên tham gia có thể bị sa lầy vào các cuộc trò chuyện hoặc
tranh cãi. Cần xem xét việc tổ chức song song nhiều hội
thảo để phát hiện các yêu cầu của các lớp người dùng khác
nhau. Những người tham gia hội thảo có thể bao gồm: PC
và các đại diện người dùng khác, có thể là chuyên gia về
chủ đề, BA, nhà phát triển và nhân viên kiểm thử. Kiến
thức, kinh nghiệm và thẩm quyền đưa ra quyết định là điều
kiện để tham gia các hội thảo phát hiện yêu cầu.
- Lôi cuốn các thành viên tham gia hội thảo: Đôi khi một số thành viên
tham gia sẽ ngừng đóng góp ý kiến cho cuộc thảo luận, có thể họ thất
vọng vì một số lý do nào đó, có thể do các thành viên khác không nhận
thấy mối quan tâm của họ, hoặc có thể họ không muốn phá vỡ công
việc mà nhóm đã hoàn thành đến thời điểm hiện tại. Cũng có thể do các
bên liên quan đã ngăn cản những người tham gia tích cực hoặc do nhà
phân tích quá độc đoán. Facilitator cần phải đọc được ngôn ngữ cơ thể
(thiếu giao tiếp bằng mắt, bồn chồn, thở dài, kiểm tra đồng hồ), nắm
bắt lý do tại sao một thành viên nào đó lại rút lui khỏi cuộc thảo luận,
và cố gắng thu hút lại thành viên đó. Với các cuộc hội thảo từ xa,
Facilitator càng cần phải chú ý lắng nghe để biết ai không tham gia vào
hội thảo, có thể hỏi trực tiếp những thành viên luôn im lặng để biết
được họ có bất kỳ suy nghĩ nào cần chia sẻ với cuộc thảo luận hay
không. Facilitator cũng phải đảm bảo rằng mọi người đều nghe rõ khi
các thành viên khác phát biểu.
Nhóm tập trung (Focus groups)
• Nhóm tập trung: Là một nhóm đại diện cho những người
dùng được triệu tập trong hoạt động phát hiện yêu cầu
nhằm tạo đầu vào và các ý tưởng về các yêu cầu chức năng
và các thuộc tính chất lượng của một sản phẩm. Các phiên
làm việc theo nhóm tập trung phải được thiết kế tương tác,
cho phép tất cả người dùng đều có cơ hội nói lên suy nghĩ
của họ. Các nhóm tập trung rất hữu ích cho việc khám phá
thái độ, ấn tượng, sở thích và nhu cầu của người dùng
(IIBA 2009). Chúng đặc biệt có giá trị khi phát triển các
sản phẩm thương mại không có sẵn quyền truy cập cho
người dùng cuối.

Nhóm tập trung (Focus groups)
• Thông thường, mỗi sản phẩm sẽ có một lớp người dùng lớn và đa
dạng, vì vậy cần chọn các thành viên cho nhóm tập trung một cách
cẩn thận. Nên chọn những người dùng đã sử dụng các phiên bản trước
đó hoặc các sản phẩm tương tự với sản phẩm đang phát triển. Có thể
chọn nhóm người dùng cùng loại (và giữ nhiều nhóm tập trung cho
các lớp người dùng khác nhau) hoặc chọn một nhóm đại diện cho toàn
bộ phổ các lớp người dùng để mọi người đều được đại diện như nhau.
• Các nhóm tập trung nên được khuyến khích. Các phiên làm việc với
nhóm tập trung có thể được ghi lại để xem xét. Tuy nhiên, không nên
mong đợi kết quả phân tích định lượng từ các nhóm tập trung, mà nên
chú ý đến các phản hồi chủ quan cần được đánh giá và ưu tiên khi
phát triển các yêu cầu. Những người tham gia trong các nhóm tập
trung cũng thường không có thẩm quyền ra quyết định cho các yêu
cầu.

Quan sát (Observations)
• Khi người dùng được yêu cầu mô tả chi tiết cách thức họ
thực hiện các công việc, có thể họ sẽ gặp khó khăn, họ có
thể mô tả thiếu hoặc không chính xác. Nguyên nhân
thường là do các nhiệm vụ rất phức tạp, khó có thể nhớ hết
mọi chi tiết, hoặc có thể do người dùng đã quá quen thuộc
với việc thực hiện một nhiệm vụ đến mức nó trở thành thói
quen, họ không nghĩ đến và khó có thể nói rõ mọi thứ họ
làm. Vì vậy, việc quan sát chính xác cách người dùng thực
hiện nhiệm vụ của họ là một giải pháp tốt.

• Việc quan sát rất tốn thời gian, vì vậy chúng không phù hợp với mọi
người dùng hay mọi nhiệm vụ. Nên chú ý, tránh làm gián đoạn các
hoạt động của người dùng, nên giới hạn thời gian quan sát (ví dụ:
trong hai giờ hoặc ít hơn). Nên chọn các nhiệm vụ quan trọng hoặc có
rủi ro cao và các lớp đông người dùng để quan sát.
• Việc quan sát quy trình làm việc của người dùng trong môi trường tác
vụ cho phép BA xác thực thông tin được thu thập từ các nguồn khác,
để xác định các chủ đề mới cho các cuộc phỏng vấn, để nhìn thấy các
vấn đề với hệ thống hiện tại và để xác định các cách mà hệ thống mới
có thể hỗ trợ tốt hơn cho quy trình làm việc.
• BA phải tóm tắt và tổng quát hóa các hoạt động của người dùng được
quan sát để đảm bảo rằng các yêu cầu được áp dụng cho toàn bộ lớp
người dùng, chứ không chỉ cho một cá nhân đó. BA cũng có thể đề
xuất ý tưởng để cải thiện quy trình nghiệp vụ hiện tại của người dùng.

• Các quan sát có thể diễn ra trong im lặng hoặc có sự tương
tác. Quan sát im lặng sẽ là thích hợp khi người dùng bận
rộn không thể bị gián đoạn. Các quan sát tương tác cho
phép BA làm gián đoạn tác vụ giữa của người dùng và đặt
các câu hỏi. Điều này cho phép BA hiểu ngay tại sao người
dùng lại thực hiện một lựa chọn hoặc những gì người dùng
đã suy nghĩ khi thực hiện một số hành động. Cần ghi lại
những gì đã quan sát được để phục vụ cho việc phân tích
sau này. BA cũng có thể cân nhắc đến việc quay video nếu
được phép.

Bảng câu hỏi (Questionnaires)
• Bảng câu hỏi là một cách để khảo sát các nhóm người dùng
lớn để hiểu nhu cầu của họ. Phương pháp này không tốn
kém, lại dễ dàng triển khai trên diện rộng, được xem là một
lựa chọn hợp lý để phát hiện thông tin từ một lượng người
dùng lớn. Kết quả phân tích các bảng câu hỏi có thể được
sử dụng làm đầu vào cho các kỹ thuật phát hiện yêu cầu
khác. Ví dụ: Có thể sử dụng một bảng câu hỏi để xác định
các vấn đề lớn nhất của người dùng đối với hệ thống hiện
có, sau đó sử dụng các kết quả để thảo luận về thứ tự ưu
tiên với những người ra quyết định trong một hội thảo.
Bảng câu hỏi cũng có thể được sử dụng để khảo sát phản
hồi của người dùng về các sản phẩm thương mại.

• Việc chuẩn bị các câu hỏi tốt là thách thức lớn nhất với kỹ thuật
bảng câu hỏi. Một số lời khuyên quan trọng cần chú ý
(Colorado State University, 2013):
- Cung cấp các phương án trả lời bao gồm toàn bộ các phương
án có thể.
- Đưa ra các phương án trả lời đa dạng, bao gồm cả các
phương án loại trừ lẫn nhau và các phương án toàn diện (liệt
kê tất cả các lựa chọn có thể và/hoặc cho phép người dùng
viết một phương án lựa chọn khác mà BA chưa nghĩ tới).
- Không đặt câu hỏi theo cách bao hàm ngụ ý câu trả lời
“đúng".
- Nếu có sử dụng thang đo, cần sử dụng chúng một cách nhất
quán trong suốt bảng câu hỏi.

• Một số lời khuyên quan trọng cần chú ý (Colorado State University,
2013):
- Nếu muốn sử dụng kết quả của bảng câu hỏi cho việc phân tích
thống kê, nên sử dụng các câu hỏi đóng với hai hoặc một số lựa
chọn cụ thể. Các câu hỏi mở sẽ cho phép người dùng trả lời theo bất
kỳ cách nào mà họ muốn, do đó sẽ rất khó để tìm kiếm sự tương
đồng trong câu trả lời của những người dùng khác nhau.
- Xem xét, xin ý kiến tư vấn của chuyên gia trong việc thiết kế và
quản trị bảng câu hỏi để đảm bảo đã đặt đúng câu hỏi với đúng đối
tượng.
- Luôn kiểm tra bảng câu hỏi trước khi phân phát nhằm tránh trường
hợp các câu hỏi không rõ ràng hoặc có một số câu hỏi quan trọng bị
bỏ qua.
- Không đặt quá nhiều câu hỏi, nếu không người dùng sẽ không
muốn trả lời.
Phân tích giao diện hệ thống
• Phân tích giao diện là một kỹ thuật phát hiện yêu cầu độc lập đòi hỏi kiểm tra các
hệ thống kết nối với hệ thống đang phát triển.
• Phân tích giao diện hệ thống (System interface analysis) cho thấy các yêu cầu chức
năng liên quan đến việc trao đổi dữ liệu và các dịch vụ giữa các hệ thống (IIBA
2009). Biểu đồ ngữ cảnh và các bản đồ ecosystem nên được xem xét, nghiên cứu.
• Đối với mỗi hệ thống có giao tiếp với hệ thống đang phát triển, cần xác định các
chức năng trong hệ thống đó mà có thể dẫn đến các yêu cầu cho hệ thống mới.
Những yêu cầu này có thể mô tả những dữ liệu nào sẽ được chuyển đến các hệ
thống khác, những dữ liệu nào nhận được từ các hệ thống khác và các quy tắc về
dữ liệu, chẳng hạn như tiêu chí xác nhận dữ liệu.
• Việc phân tích còn cho phép khám phá những chức năng hiện có nhưng lại không
cần thực hiện trong hệ thống mới. Ví dụ, BA nghĩ rằng cần phải thực thi các quy
tắc xác thực cho đơn đặt hàng trong giỏ hàng trên trang web thương mại điện tử
trước khi chuyển nó đến hệ thống quản lý đơn hàng. Tuy nhiên, thông qua việc
phân tích giao diện hệ thống, BA có thể biết rằng nhiều hệ thống chuyển đơn hàng
đến hệ thống quản lý đơn hàng đã thực hiện việc xác thực, vì vậy không cần phải
xây dựng chức năng này.

Phân tích giao diện người dùng
• Phân tích giao diện người dùng (User interface analysis) là một kỹ thuật
phát hiện yêu cầu độc lập, dựa trên việc nghiên cứu các hệ thống hiện
có để khám phá các yêu cầu người dùng và các yêu cầu chức năng.
Cách tốt nhất là tương tác trực tiếp với các hệ thống hiện có. Tuy nhiên,
nếu cần có thể phân tích qua các hình chụp giao diện có trong cuốn
Hướng dẫn sử dụng phần mềm. Nếu không có bất kỳ hệ thống nào
trước đó, thì có thể phân tích qua giao diện của các hệ thống tương tự.
• Việc phân tích này có thể giúp BA khám phá các tính năng tiềm năng.
Dựa theo các giao diện người dùng hiện có, BA có thể biết được các
bước phổ biến mà người dùng thực hiện trong hệ thống và dự thảo các
trường hợp sử dụng để người dùng xem xét.
• Chú ý: Không phải chức năng nào trong hệ thống hiện có cũng là cần
thiết và nên đưa vào hệ thống mới. Giao diện người dùng trong hệ
thống mới cũng không nhất thiết phải được thiết kế theo cách tương tác
với người dùng như trong các hệ thống đã có.

Phân tích tài liệu
• Phân tích tài liệu (Document analysis) đòi hỏi phải kiểm tra bất
kỳ tài liệu hiện có nào về các yêu cầu phần mềm tiềm năng.
• Các tài liệu hữu ích nhất bao gồm: các bản đặc tả yêu cầu, quy
trình nghiệp vụ, các bài giảng và hướng dẫn sử dụng của các ứng
dụng hiện có hoặc các ứng dụng tương tự, các tài liệu mô tả các
quy định/tiêu chuẩn của công ty hoặc của ngành cần tuân theo
hoặc các quy định mà sản phẩm phải tuân thủ.
• Khi thay thế một hệ thống hiện có, các tài liệu trong quá khứ có
thể tiết lộ các chức năng cần phải được giữ lại, cũng như các
chức năng đã lỗi thời, nên lược bỏ.
• Đối với việc triển khai các giải pháp đóng gói, các tài liệu của
nhà cung cấp có thể đề cập đến các chức năng mà người dùng hệ
thống mới cần, nhưng BA cần phải tiếp tục khám phá cách thực
thi nó trong môi trường đích mới.
Phân tích tài liệu
• Việc đánh giá, so sánh cho phép chỉ ra những thiếu sót
trong các sản phẩm khác, hướng giải quyết trong hệ thống
mới để hệ thống mới có lợi thế cạnh tranh.
• Các báo cáo về các vấn đề và các yêu cầu nâng cấp được
thu thập từ người dùng có thể giúp BA đưa ra các ý tưởng
để cải thiện hệ thống trong các phiên bản tương lai.
• Việc phân tích tài liệu, nghiên cứu và soạn thảo sẵn một số
yêu cầu cho phép giảm thời gian dành cho các cuộc họp
phát hiện yêu cầu.
• Việc phân tích tài liệu còn có thể tiết lộ những thông tin mà
người dùng không nói ra, do họ không nghĩ đến hoặc
không nhận thức được chúng.

• Ở giai đoạn đầu của dự án, BA nên lập kế hoạch tiếp cận dự
án để phát hiện các yêu cầu. Ngay cả một kế hoạch đơn
giản cũng làm tăng cơ hội thành công và đặt kỳ vọng thực
tế cho các bên liên quan.
• Với các cam kết rõ ràng về nguồn tài nguyên, lịch trình và
sản phẩm cần đạt trong kế hoạch phát hiện yêu cầu sẽ cho
phép tránh tình trạng những người tham gia bỏ đi làm việc
khác.
• Một kế hoạch phát hiện yêu cầu bao gồm các kỹ thuật được
sử dụng, thời điểm và mục đích sử dụng.
• Một kế hoạch giống như một bản hướng dẫn và nhắc nhở
trong suốt dự án, BA cũng có thể cần phải thay đổi kế
hoạch trong suốt dự án.
Cần lập kế hoạch phát hiện yêu cầu với các nội dung sau:
• Các mục tiêu phát hiện yêu cầu: Cần lập kế hoạch các mục tiêu
phát hiện yêu cầu cho toàn bộ dự án và các mục tiêu cho mỗi
hoạt động trong kế hoạch.
• Các chiến lược và kỹ thuật sử dụng trong kế hoạch: Quyết định
sử dụng các kỹ thuật nào với các nhóm thuộc các bên liên quan
khác nhau. Có thể kết hợp bảng câu hỏi, hội thảo, các chuyến
thăm khách hàng kết hợp phỏng vấn cá nhân và các kỹ thuật
khác, tùy thuộc vào khả năng tiếp cận với các bên liên quan, giới
hạn thời gian và kiến thức về hệ thống hiện có.
• Lịch trình và ước tính tài nguyên: Xác định các khách hàng và
những người tham gia phát triển cho các hoạt động phát hiện yêu
cầu khác nhau, cùng với ước tính về nỗ lực và lịch trình cần thiết.

• Các tài liệu và các nhu cầu hệ thống cho việc phát hiện yêu
cầu độc lập: Cần chuẩn bị sẵn tất cả các thứ cần thiết cho việc
phân tích tài liệu, phân tích giao diện hệ thống hoặc phân tích
giao diện người dùng để sử dụng khi cần.
• Các sản phẩm dự kiến của các nỗ lực phát hiện yêu cầu: Nhận
thức về việc sẽ tạo ra các use case, phân tích các kết quả bảng
câu hỏi hoặc đặc tả thuộc tính chất lượng, ... giúp đảm bảo
rằng BA đang nhắm đúng mục tiêu của các bên liên quan, các
chủ đề và các chi tiết trong quá trình phát hiện yêu cầu.
• Các rủi ro: Xác định các yếu tố có thể cản trở khả năng hoàn
thành các hoạt động phát hiện yêu cầu như dự định; ước tính
mức độ nghiêm trọng của từng rủi ro và quyết định cách để
giảm thiểu hoặc kiểm soát các rủi ro đó.
• Gợi ý về các kỹ thuật phát hiện yêu cầu sử dụng cho một số
loại dự án:

• Các hoạt động chuẩn bị cho một phiên phát hiện yêu cầu:

• Lên kế hoạch về phạm vi và chương trình của phiên phát
hiện yêu cầu: Quyết định về phạm vi của phiên có tính đến
lượng thời gian cho phiên. Có thể xác định phạm vi phiên
bằng cách sử dụng một tập các chủ đề hoặc câu hỏi, liệt kê
một tập hợp quy trình cụ thể hoặc các trường hợp sử dụng
sẽ được khám phá. Điều chỉnh phạm vi của phiên với phạm
vi tổng thể của dự án được xác định trong các yêu cầu
nghiệp vụ nhằm giữ vững chủ đề của cuộc trò chuyện.
Trong chương trình nên ghi rõ các chủ đề sẽ được đề cập,
thời gian cho từng chủ đề, và các mục tiêu cần đạt. Chia sẻ
chương trình với các bên liên quan trước khi bắt đầu.

• Chuẩn bị tài nguyên: Đăng ký lịch sử dụng các tài nguyên
vật lý cần thiết, ví dụ: phòng, máy chiếu, số điện thoại, và
các thiết bị hội nghị truyền hình. Ngoài ra, cần lên lịch cho
những người tham gia, chú ý sự khác biệt về múi giờ đối
với các thành viên không cùng địa điểm, và có thể thay đổi
lịch trình mỗi lần gặp để tránh tình trạng luôn gây bất tiện
cho một thành viên nào đó. Thu thập tài liệu từ nhiều
nguồn khác nhau, có thể tiếp cận với các hệ thống khi cần
thiết, tham gia các khóa đào tạo trực tuyến để tìm hiểu về
các hệ thống hiện có.

• Tìm hiểu về các bên liên quan: Xác định các bên liên quan
cho phiên, tìm hiểu về sở thích văn hóa và khu vực của các
bên liên quan. Nếu một số thành viên tham gia không biết
ngôn ngữ sử dụng trong phiên, cần xem xét việc cung cấp
trước cho họ các tài liệu hỗ trợ, chẳng hạn như các slide, để
họ có thể đọc trước hoặc theo dõi. Các slide có thể liệt kê
các câu hỏi cụ thể sẽ được hỏi trong phiên hoặc chỉ đơn
giản là cung cấp bối cảnh của phiên.
• Chuẩn bị câu hỏi: Cần chuẩn bị sẵn các câu hỏi. Với một
cuộc phỏng vấn hoặc hội thảo, nên sử dụng kết quả từ các
kỹ thuật phát hiện yêu cầu khác để xác định các câu hỏi
chưa được giải quyết.

Chú ý khi chuẩn bị các câu hỏi:
- Không nên đặt câu hỏi chung chung dạng “Bạn muốn gì?”
 Có thể hỏi “Bạn cần làm gì?”.
- Có thể đặt câu hỏi “Tại sao?” nhiều lần để hiểu quy trình
nghiệp vụ và để biết được làm thế nào để hệ thống mới có
thể cải thiện hiệu suất của họ.
- Thử tưởng tượng bạn đang học cách làm việc của người
dùng hoặc thực sự làm công việc đó theo hướng dẫn của
người dùng  Câu hỏi: Bạn sẽ thực hiện các tác vụ nào?
Bạn có câu hỏi gì?
- Một cách tiếp cận khác là thử đóng vai trò của một người
học việc từ một người dùng chính. Người dùng được phỏng
vấn sẽ hướng dẫn cuộc thảo luận và mô tả những gì họ thấy.

- Có thể sử dụng các câu hỏi thăm dò xung quanh các
ngoại lệ: "Điều gì có thể ngăn người dùng hoàn thành
thành công một nhiệm vụ?", "Làm thế nào để hệ thống
đáp ứng với các điều kiện lỗi khác nhau?", "Còn gì có
thể . . . " , "Chuyện gì xảy ra khi . . . ", "Bạn có bao giờ
cần . . . ", "Bạn nhận được . . . ở đâu?", "Tại sao bạn
(hoặc không phải bạn) . . . ", "Có ai từng . . . ", …
- Khi xây dựng một hệ thống mới thay thế cho hệ thống
cũ, có thể đặt câu hỏi dạng: "Ba điều làm bạn khó chịu
nhất với hệ thống hiện tại là gì?"

- Ghi nhớ: BA có thể không có hoặc không cần một kịch
bản với các câu hỏi hoàn hảo cho một cuộc phỏng vấn
hoặc hội thảo. Việc chuẩn bị các câu hỏi là để giúp BA
chủ động hơn và có thể cần đến khi gặp khó khăn. Các
câu hỏi cần được đặt ra một cách tự nhiên và thoải mái -
như một cuộc trò chuyện - không nên như một cuộc
thẩm vấn. Tùy vào diễn biến của cuộc thảo luận, có thể
bỏ qua các câu hỏi đã chuẩn bị sẵn.

• Chuẩn bị các mô hình nếu cần: Việc phân tích các mô hình
có thể được sử dụng trong các phiên phát hiện yêu cầu để
giúp người dùng cung cấp các yêu cầu tốt hơn. Một số mô
hình hữu ích nhất là các biểu đồ use cases và các biểu đồ
process flows bởi vì chúng rất gần với cách nghĩ của mọi
người về việc thực hiện các công việc của họ.

• Thực hiện các hoạt động phát hiện yêu cầu trong phiên
phát hiện yêu cầu:

Các vấn đề cần chú ý:

• Giáo dục các bên liên quan: Cần chỉ dẫn cho các bên liên
quan về cách tiếp cận phát hiện yêu cầu của BA và lý do vì
sao BA chọn phương pháp đó. Giải thích các kỹ thuật thăm
dò sẽ được sử dụng, chẳng hạn như use cases và process
flows. Điều đó giúp các bên liên quan cung cấp các yêu cầu
tốt hơn, đồng thời cho phép mô tả cách BA sẽ nắm bắt
thông tin và gửi cho họ các tài liệu để kiểm tra lại sau phiên
phát hiện yêu cầu.


• Ghi chép tốt: Cần chỉ định một người chịu trách nhiệm ghi
chép chính xác các nội dung trong cuộc thảo luận. Các ghi
chép bao gồm cả danh sách người tham dự, những người
được mời nhưng không tham dự, những quyết định được
đưa ra, những hành động được thực hiện và ai là người
chịu trách nhiệm, những vấn đề nổi bật, những vấn đề then
chốt của cuộc thảo luận. Nếu không bố trí được người
chuyên ghi chép, BA cần chuẩn bị để viết tốc ký, ghi chép
thật nhanh hoặc sử dụng thiết bị ghi âm (nếu người tham
gia đồng ý) và các thiết bị hỗ trợ khác nếu có thể (audio
pen, bảng, máy ảnh, …)


• Nên chuẩn bị trước các câu hỏi, tuy nhiên nếu có các câu
hỏi bất chợt nảy sinh trong quá trình thảo luận, có thể ghi
lại bằng ký hiệu viết tắt để dễ dàng quay lại khi cần. Với
các biểu đồ phức tạp, không nên cố gắng nắm bắt mà nên
chụp hình lại hoặc phác thảo nhanh ra giấy.
• Khai thác không gian vật lý: Có thể sử dụng các bức tường
trong phòng hội thảo để treo các bảng, các sơ đồ hoặc dán
ghi chú, … Nên mời những người tham gia cùng tham gia
vào việc vẽ sơ đồ, tạo danh sách, … Nếu có hiện vật (các
mô hình, các yêu cầu hiện có hoặc các hệ thống hiện có,
…) hãy chiếu chúng lên tường (theo kỹ thuật “Wall of
Wonder” - Gottesdiener (2002))

• Việc tạo điều kiện cho các phiên hợp tác với những người
tham gia ở nhiều địa điểm đòi hỏi sự sáng tạo hơn. Cần cân
nhắc đến việc sử dụng các công cụ hội nghị trực tuyến để
chia sẻ các slide và cho phép tương tác, hoặc sử dụng các
công cụ tổ chức hội nghị truyền hình nếu cần.

• Sau khi hoàn tất hoạt động phát hiện yêu cầu, cần tổ chức
và chia sẻ các ghi chú, lập tài liệu về các vấn đề mở và
phân loại các thông tin mới được thu thập.

• Tổ chức và chia sẻ các ghi chú: Đối với các cuộc phỏng vấn
hoặc hội thảo, việc tổ chức các ghi chú sẽ mất nhiều thời gian
và nỗ lực hơn so với việc phát hiện yêu cầu độc lập do phải
tổng hợp các ghi chú từ nhiều nguồn.
Cần xem lại và các cập nhật ghi chú ngay sau khi phiên
hoàn tất.
Ngay sau đó, chia sẻ bản tổng hợp các ghi chú với
những người tham gia và yêu cầu họ xem xét chúng để
đảm bảo rằng bản ghi chú đã đầy đủ và chính xác.
Có thể tổ chức các cuộc thảo luận tiếp theo để giải quyết
bất kỳ mâu thuẫn và những vấn đề còn thiếu sót nếu có.
Chia sẻ bản tổng hợp ghi chú với những người vắng mặt
để họ nhận thức được tiến độ.
• Lập tài liệu về các vấn đề mở: Trong các hoạt động phát
hiện yêu cầu, có thể có các vấn đề cần được khám phá
thêm, các lỗ hổng kiến thức hoặc các câu hỏi mới nảy sinh.
Các vấn này cần được ghi lại trong một công cụ theo dõi
các vấn đề. Đối với mỗi vấn đề, cần ghi lại bất kỳ các ghi
chú có liên quan đến việc giải quyết chúng; ghi lại tiến độ
đã thực hiện, người chịu trách nhiệm và thời hạn giải quyết
các vấn đề.

• Đừng mong đợi các khách hàng sẽ trình bày một danh sách ngắn
gọn, đầy đủ và được tổ chức tốt về các nhu cầu của họ! BA luôn phải
phân loại vô số các thông tin yêu cầu từ khách hàng thành nhiều loại
khác nhau để có thể ghi chép và sử dụng chúng một cách thích hợp

Một số gợi ý phân loại các thông tin yêu cầu:

• Yêu cầu kinh doanh/nghiệp vụ (Business requirements): Bất cứ điều
gì mô tả về tài chính, thị trường hoặc lợi ích kinh doanh nghiệp vụ
mà các khách hàng hoặc tổ chức muốn đạt được từ sản phẩm. Hãy
lắng nghe các phát biểu về giá trị mà người mua hoặc người dùng
phần mềm muốn nhận được, ví dụ:
“Cần nâng cao thị phần tại khu vực X thêm Y phần trăm trong
vòng Z tháng”
“Cần tiết kiệm X $ tiền điện đang bị lãng phí mỗi năm bởi các
bộ phận hoạt động kém hiệu quả”


• Yêu cầu người dùng (User requirements): Tuyên bố chung về các
mục tiêu của người dùng hoặc các tác vụ, nhiệm vụ mà người dùng
cần thực hiện, thường được trình bày dưới dạng các trường hợp sử
dụng, các tình huống hoặc các câu chuyện của người dùng. Khi
khách hàng nói: “Tôi cần <làm gì đó>”, tức là họ đang mô tả yêu cầu
của người dùng, ví dụ:
̵ “Tôi cần in hóa đơn bán hàng cho khách”


• Quy tắc nghiệp vụ: Khi một khách hàng nói rằng chỉ một số người
dùng nhất định có thể thực hiện một hoạt động trong các điều kiện cụ
thể, tức là có thể khách hàng đang trình bày về một quy tắc nghiệp
vụ. Chúng không phải là yêu cầu phần mềm, nhưng từ đó có thể rút
ra một số yêu cầu chức năng để thực thi các quy tắc. Một số cụm từ
như: “Phải tuân thủ . . .”, “Nếu <một số điều kiện là đúng> thì <một
cái gì đó xảy ra>”, “Phải được tính theo . . .” sẽ thường được nhắc
đến, ví dụ:
̵ “Một khách hàng mới sẽ phải trả 30% phí tư vấn và chi phí đi
lại”.
̵ “Việc phê duyệt thời gian nghỉ phép phải tuân thủ chính sách
nghỉ phép HR của công ty”, …


• Yêu cầu chức năng (Functional requirements): Mô tả các hành vi có
thể quan sát được của hệ thống trong những điều kiện nhất định và
các hành động mà hệ thống sẽ cho phép người dùng thực hiện. Ví dụ:
“Nếu áp suất vượt quá 40.0 psi, đèn cảnh báo áp suất cao sẽ bật
sáng”
“Người dùng phải có khả năng sắp xếp danh sách các dự án theo
thứ tự bảng chữ cái tăng dần hoặc giảm dần”


• Các thuộc tính chất lượng (Quality attributes): Mô tả hệ thống cần
làm tốt một cái gì đó như thế nào, thường chứa các từ mô tả đặc điểm
mong muốn của hệ thống: nhanh, dễ dàng, thân thiện với người
dùng, đáng tin cậy, an toàn, ví dụ:
“Phần mềm cho thiết bị di động cần đáp ứng nhanh các thao tác
chạm màn hình”
“Chức năng giỏ hàng phải đơn giản, dễ sử dụng”
 BA cần phải làm việc với người dùng để có thể viết rõ ràng các
thuộc tính chất lượng nhằm kiểm chứng được chúng sau này.


• Yêu cầu giao diện bên ngoài (External interface requirements): Mô
tả các kết nối giữa hệ thống với thế giới bên ngoài, bao gồm giao
diện cho người dùng, phần cứng và các hệ thống phần mềm khác.
Thường gặp các cụm từ như: “Phải đọc tín hiệu từ . . .”, “Phải gửi
thông điệp tới . . .”, “Phải có khả năng đọc tệp theo định dạng …”,
“Giao diện phải tuân theo chuẩn …”, … Ví dụ:
“Ứng dụng di động sẽ gửi hình ảnh kiểm tra tới ngân hàng sau
khi tôi chụp hình đang ký gửi”
“Hệ thống phải gửi thông tin đặt hàng vào hòm thư của tôi sau
khi tôi nhấn nút Gửi đơn hàng”


• Các ràng buộc (Constraints): Các ràng buộc thiết kế và triển khai sẽ
hạn chế các tùy chọn của nhà phát triển. Các thiết bị với các phần
mềm nhúng thường có các ràng buộc vật lý như kích thước, trọng
lượng và giao diện kết nối. Các cụm từ thường gặp: “Phải được viết
bằng <một ngôn ngữ lập trình cụ thể>”, “Không thể vượt quá <một
số giới hạn>”, “Phải sử dụng ...”. Ví dụ:
“Kích thước các tập tin được gửi không vượt quá 10 MB”
“Trình duyệt phải sử dụng mã hóa 256 bit cho tất cả các giao
dịch an toàn”


• Yêu cầu dữ liệu (Data requirements): Các yêu cầu về định dạng, kiểu
dữ liệu, miền giá trị hoặc giá trị mặc định, thành phần của một cấu
trúc dữ liệu nghiệp vụ phức tạp, hoặc một báo cáo sẽ được tạo, … Ví
dụ:
“ZIP code có 5 chữ số, theo sau là dấu gạch nối và bốn chữ số
mặc định là 0000”
“Một đơn hàng bao gồm: định danh khách hàng, thông tin vận
chuyển và một hoặc nhiều sản phẩm với mã sản phẩm, số lượng
theo đơn vị tính, đơn giá, thành tiền”


• Ý tưởng giải pháp (Solution ideas): Nhiều yêu cầu từ người dùng lại
là những ý tưởng thực sự. Chẳng hạn, khi họ mô tả cụ thể cách thức
tương tác với hệ thống để thực hiện một số hành động tức là họ đang
đề xuất một giải pháp. Ví dụ:
“Sau đó tôi chọn Tỉnh mà tôi muốn gửi gói hàng đến từ một
danh sách các tỉnh được thả xuống”
“Điện thoại phải cho phép người dùng vuốt ngón tay để điều
hướng giữa các màn hình”

2.1.3.8. Một số vấn đề khác
• Nhận biết thời điểm hoàn thành việc phát hiện yêu cầu
• Một số điểm cần lưu ý khi phát hiện yêu cầu
• Các yêu cầu giả định và yêu cầu ngầm
• Tìm kiếm các yêu cầu còn thiếu

03 - Chuong 2 - Phat Hien Va Phan Tich Yeu Cau

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

03 - Chuong 2 - Phat Hien Va Phan Tich Yeu Cau

Uploaded by

Copyright:

Available Formats

CHƯƠNG 2:

PHÁT TRIỂN YÊU CẦU

06/21/2023 Phân tích yêu cầu phần mềm 2

06/21/2023 Phân tích yêu cầu phần mềm 3

06/21/2023 Phân tích yêu cầu phần mềm 6

06/21/2023 Phân tích yêu cầu phần mềm 7

06/21/2023 Phân tích yêu cầu phần mềm 8

06/21/2023 Phân tích yêu cầu phần mềm 9

06/21/2023 Phân tích yêu cầu phần mềm 10

06/21/2023 Phân tích yêu cầu phần mềm 11

06/21/2023 Phân tích yêu cầu phần mềm 12

06/21/2023 Phân tích yêu cầu phần mềm 13

06/21/2023 Phân tích yêu cầu phần mềm 14

06/21/2023 Phân tích yêu cầu phần mềm 16

06/21/2023 Phân tích yêu cầu phần mềm 17

06/21/2023 Phân tích yêu cầu phần mềm 19

06/21/2023 Phân tích yêu cầu phần mềm 20

06/21/2023 Phân tích yêu cầu phần mềm 21

06/21/2023 Phân tích yêu cầu phần mềm 23

06/21/2023 Phân tích yêu cầu phần mềm 24

06/21/2023 Phân tích yêu cầu phần mềm 25

06/21/2023 Phân tích yêu cầu phần mềm 26

06/21/2023 Phân tích yêu cầu phần mềm 28

06/21/2023 Phân tích yêu cầu phần mềm 29

06/21/2023 Phân tích yêu cầu phần mềm 30

06/21/2023 Phân tích yêu cầu phần mềm 31

06/21/2023 Phân tích yêu cầu phần mềm 33

06/21/2023 Phân tích yêu cầu phần mềm 34

06/21/2023 Phân tích yêu cầu phần mềm 35

06/21/2023 Phân tích yêu cầu phần mềm 36

06/21/2023 Phân tích yêu cầu phần mềm 37

06/21/2023 Phân tích yêu cầu phần mềm 38

06/21/2023 Phân tích yêu cầu phần mềm 39

06/21/2023 Phân tích yêu cầu phần mềm 41

06/21/2023 Phân tích yêu cầu phần mềm 42

06/21/2023 Phân tích yêu cầu phần mềm 43

06/21/2023 Phân tích yêu cầu phần mềm 47

06/21/2023 Phân tích yêu cầu phần mềm 48

06/21/2023 Phân tích yêu cầu phần mềm 49

06/21/2023 Phân tích yêu cầu phần mềm 50

06/21/2023 Phân tích yêu cầu phần mềm 51

06/21/2023 Phân tích yêu cầu phần mềm 52

06/21/2023 Phân tích yêu cầu phần mềm 53

06/21/2023 Phân tích yêu cầu phần mềm 55

06/21/2023 Phân tích yêu cầu phần mềm 56

06/21/2023 Phân tích yêu cầu phần mềm 58

06/21/2023 Phân tích yêu cầu phần mềm 60

06/21/2023 Phân tích yêu cầu phần mềm 62

06/21/2023 Phân tích yêu cầu phần mềm 63

06/21/2023 Phân tích yêu cầu phần mềm 64

06/21/2023 Phân tích yêu cầu phần mềm 65

06/21/2023 Phân tích yêu cầu phần mềm 66

06/21/2023 Phân tích yêu cầu phần mềm 67

06/21/2023 Phân tích yêu cầu phần mềm 68

06/21/2023 Phân tích yêu cầu phần mềm 69

06/21/2023 Phân tích yêu cầu phần mềm 70

06/21/2023 Phân tích yêu cầu phần mềm 71

Các vấn đề cần chú ý:

06/21/2023 Phân tích yêu cầu phần mềm 72

Các vấn đề cần chú ý:

06/21/2023 Phân tích yêu cầu phần mềm 73

Các vấn đề cần chú ý:

Các vấn đề cần chú ý: