1 of 7

5 - Phân tích yêu cầu

Kỹ thuật khai thác

1. Khái niệm Kỹ thuật Khai thác là gì?

Kỹ thuật khai thác (Elicitation Techniques) là những phương pháp, công cụ và cách tiếp cận mà Nhà phân tích kinh doanh (Business Analyst - BA) sử dụng để thu thập, làm rõ, và hiểu các yêu cầu, thông tin, dữ liệu từ các bên liên quan nhằm phục vụ cho dự án hoặc giải pháp kinh doanh.

Mục tiêu chính: Hiểu rõ nhu cầu thực sự của doanh nghiệp, người dùng, và các bên liên quan để đảm bảo giải pháp được xây dựng đúng và đủ yêu cầu.

2. Mục đích của Kỹ thuật Khai thác

Mục đích

Ý nghĩa

Thu thập thông tin chính xác

Hiểu rõ mong đợi, yêu cầu, vấn đề thực tế từ các bên liên quan.

Làm rõ và phân tích yêu cầu

Xác định yêu cầu rõ ràng, tránh hiểu sai, mâu thuẫn yêu cầu.

Tăng sự đồng thuận

Đảm bảo các bên liên quan đồng ý về các yêu cầu.

Phát hiện yêu cầu tiềm ẩn

Khám phá các yêu cầu chưa được diễn đạt hoặc chưa rõ ràng.

Hỗ trợ quá trình thiết kế và phát triển

Cung cấp thông tin đầu vào chính xác cho các giai đoạn sau.

3. Các Kỹ thuật Khai thác Phổ biến của BA

Kỹ thuật

Mô tả

Áp dụng khi

Phỏng vấn (Interviews)

Trò chuyện trực tiếp để thu thập thông tin.

Khi cần hiểu sâu nhu cầu của từng cá nhân.

Hội thảo (Workshops)

Nhóm họp nhiều bên liên quan để thảo luận yêu cầu.

Khi cần thống nhất yêu cầu, xử lý mâu thuẫn.

Khảo sát, bảng hỏi (Questionnaires/Surveys)

Gửi câu hỏi để thu thập thông tin từ nhiều người.

Khi có nhiều đối tượng hoặc cần thu thập nhanh.

Quan sát (Observation/Job Shadowing)

Theo dõi cách người dùng làm việc thực tế.

Khi cần hiểu quy trình, hành vi thực tế.

Xem xét tài liệu (Document Analysis)

Phân tích tài liệu hiện có (quy trình, báo cáo, hợp đồng...).

Khi có nhiều thông tin lịch sử, quy trình sẵn có.

Prototyping (Mẫu thử)

Xây dựng mẫu sản phẩm để lấy ý kiến.

Khi cần xác minh yêu cầu, giúp bên liên quan hình dung.

Brainstorming (Động não)

Khuyến khích nêu ý tưởng, giải pháp.

Khi cần nhiều ý tưởng mới, xác định yêu cầu ban đầu.

Focus Groups (Nhóm trọng tâm)

Tập hợp nhóm đại diện người dùng để thảo luận.

Khi cần ý kiến từ nhóm đại diện đa dạng.

Mind Mapping (Sơ đồ tư duy)

Vẽ sơ đồ liên kết ý tưởng, yêu cầu.

Khi cần tổ chức, phân loại các ý tưởng phức tạp.

Storyboarding (Trình bày theo kịch bản)

Minh họa chuỗi hành động qua hình ảnh hoặc kịch bản.

Khi cần diễn đạt quy trình, trải nghiệm người dùng.

Benchmarking

So sánh với quy trình, hệ thống tương tự.

Khi muốn tìm giải pháp tối ưu, học hỏi kinh nghiệm.

4. Quy trình Khai thác Yêu cầu Chuẩn

Bước

Mô tả

1. Chuẩn bị khai thác

Xác định mục tiêu, các bên liên quan, kỹ thuật sẽ dùng.

2. Tiến hành khai thác

Thực hiện phỏng vấn, khảo sát, hội thảo, quan sát, v.v.

3. Xác nhận thông tin thu thập

Làm rõ, xác nhận lại thông tin với bên liên quan.

4. Phân tích và tài liệu hóa yêu cầu

Ghi chép, phân tích thành tài liệu yêu cầu chi tiết.

5. Trình bày kết quả khai thác

Báo cáo yêu cầu cho khách hàng, quản lý dự án, nhóm kỹ thuật.

5. Một số lưu ý khi sử dụng Kỹ thuật Khai thác

Lưu ý

Ý nghĩa

Hiểu rõ mục tiêu khai thác

Biết rõ cần tìm thông tin gì, tránh lan man.

Xác định đúng bên liên quan

Chọn đúng người có thể cung cấp thông tin cần thiết.

Sử dụng kết hợp nhiều kỹ thuật

Tăng tính đầy đủ, chính xác của thông tin.

Chuẩn bị trước khi khai thác

Có câu hỏi, nội dung, mục tiêu rõ ràng trước khi phỏng vấn/hội thảo.

Tạo môi trường thân thiện, cởi mở

Giúp bên liên quan chia sẻ thông tin một cách tự nhiên.

Kiểm tra lại thông tin (Validation)

Đảm bảo không hiểu sai, thông tin đầy đủ và chính xác.

6. Vai trò của BA trong Khai thác Yêu cầu

Lắng nghe và đặt câu hỏi đúng để hiểu đúng vấn đề.
Giao tiếp hiệu quả với nhiều bên liên quan khác nhau.
Nhận diện yêu cầu ẩn (ẩn ý), những nhu cầu mà người dùng chưa thể diễn đạt.
Giải quyết xung đột yêu cầu giữa các bên liên quan.
Chuyển hóa thông tin thu thập được thành tài liệu yêu cầu dễ hiểu cho nhóm phát triển và khách hàng.

7. Kết luận

👉 Kỹ thuật khai thác yêu cầu là một nhiệm vụ quan trọng và cốt lõi của Nhà phân tích kinh doanh, giúp đảm bảo hiểu đúng, đủ và rõ ràng yêu cầu của khách hàng và các bên liên quan. 🎯 Áp dụng hiệu quả các kỹ thuật khai thác sẽ giúp dự án thành công ngay từ bước khởi đầu.

Tài liệu yêu cầu

1. Khái niệm Tài liệu Yêu cầu là gì?

Tài liệu Yêu cầu (Requirement Document) là tài liệu chính thức ghi lại đầy đủ các yêu cầu chức năng, phi chức năng, và các ràng buộc của hệ thống, phần mềm, hoặc quy trình mà dự án cần đáp ứng. Đây là cơ sở giao tiếp giữa các bên liên quan (Business, Technical, QA) để đảm bảo cùng hiểu về những gì cần phát triển.

2. Mục đích của Tài liệu Yêu cầu

Mục đích

Ý nghĩa

Xác định rõ phạm vi dự án

Định nghĩa chính xác các yêu cầu và giới hạn công việc.

Làm cơ sở thiết kế, phát triển và kiểm thử

Cung cấp thông tin cho lập trình viên, tester thực hiện công việc.

Thống nhất giữa các bên liên quan

Đảm bảo các bên hiểu đúng, tránh hiểu sai hoặc mâu thuẫn yêu cầu.

Quản lý sự thay đổi

Làm căn cứ để xét duyệt các thay đổi về sau.

3. Nội dung chính của Tài liệu Yêu cầu

I. Thông tin chung

Mục

Nội dung

Tên dự án

Tên chính thức của dự án.

Mô tả tổng quan

Tóm tắt mục tiêu, ý nghĩa của dự án.

Phạm vi dự án

Những gì sẽ làm và sẽ không làm (In-scope/Out-of-scope).

Các bên liên quan

Danh sách những người/nhóm ảnh hưởng hoặc tham gia.

Thuật ngữ và định nghĩa (Glossary)

Giải thích các từ chuyên ngành, viết tắt.

II. Yêu cầu chức năng (Functional Requirements)

Yêu cầu

Mô tả

Yêu cầu nghiệp vụ

Mô tả chi tiết các chức năng hệ thống phải có.

Luồng nghiệp vụ (Business Flow)

Các bước, quy trình xử lý chính.

Luồng dữ liệu (Data Flow)

Dữ liệu vào, ra, cách xử lý.

Mô tả màn hình (nếu có)

Giao diện, chức năng tương tác.

🔑 Ví dụ:

"Hệ thống cho phép người dùng đăng ký tài khoản với các thông tin: Họ tên, Email, Mật khẩu."

III. Yêu cầu phi chức năng (Non-functional Requirements)

Loại yêu cầu

Ví dụ nội dung

Hiệu suất (Performance)

"Hệ thống xử lý 1000 giao dịch/giờ."

Bảo mật (Security)

"Thông tin người dùng được mã hóa AES-256."

Khả dụng (Availability)

"Hệ thống hoạt động 24/7 với 99.9% uptime."

Khả năng mở rộng (Scalability)

"Hỗ trợ thêm 5000 người dùng mà không giảm tốc độ."

IV. Ràng buộc và giả định (Constraints & Assumptions)

Loại

Mô tả

Giả định (Assumptions)

"Người dùng có Internet khi sử dụng hệ thống."

Ràng buộc (Constraints)

"Phải dùng nền tảng .NET Core và Azure Cloud."

V. Phụ lục (Appendix)

Loại nội dung

Ví dụ

Sơ đồ luồng (Flowchart, BPMN)

Mô hình quy trình nghiệp vụ.

Mockups, Wireframes

Bản vẽ giao diện mẫu.

ERD, Sơ đồ dữ liệu

Mô hình hóa quan hệ dữ liệu.

4. Các loại tài liệu yêu cầu theo tiêu chuẩn BA

Loại tài liệu

Ý nghĩa / Trường hợp sử dụng

Business Requirements Document (BRD)

Yêu cầu ở mức độ kinh doanh, mục tiêu tổng thể.

System Requirements Specification (SRS)

Yêu cầu hệ thống chi tiết, dành cho đội kỹ thuật.

Functional Specification Document (FSD)

Tài liệu chi tiết về chức năng của hệ thống.

User Stories/Use Cases

Mô tả tình huống sử dụng từ góc nhìn người dùng.

Product Requirements Document (PRD)

Tài liệu yêu cầu sản phẩm (gần với FSD).

5. Nguyên tắc khi viết tài liệu yêu cầu

Nguyên tắc

Giải thích

Rõ ràng, dễ hiểu

Tránh dùng từ ngữ mơ hồ, diễn giải ngắn gọn, dễ đọc.

Đầy đủ và chi tiết

Đảm bảo bao phủ toàn bộ yêu cầu cần thiết.

Có thể kiểm chứng (testable)

Yêu cầu phải đo lường và kiểm thử được.

Nhất quán (Consistent)

Không mâu thuẫn giữa các yêu cầu.

Có thể thực hiện được (Feasible)

Yêu cầu phải phù hợp với nguồn lực, công nghệ.

Có thể theo dõi (Traceable)

Có thể gán mã số và liên kết với các yêu cầu khác.

6. Vai trò của Business Analyst khi làm tài liệu yêu cầu

Thu thập và tổng hợp thông tin từ các bên liên quan.
Phân tích và làm rõ các yêu cầu phức tạp.
Xác nhận yêu cầu với khách hàng và đội dự án.
Chuyển hóa yêu cầu thành tài liệu chi tiết, dễ hiểu.
Cập nhật tài liệu khi có thay đổi.

7. Mẫu Template đơn giản cho Tài liệu Yêu cầu

rCopyEdit1. Thông tin chung
   1.1. Tên dự án
   1.2. Mô tả tổng quan
   1.3. Phạm vi dự án
   1.4. Các bên liên quan

2. Yêu cầu chức năng
   2.1. Yêu cầu nghiệp vụ
   2.2. Luồng xử lý
   2.3. Mô tả màn hình

3. Yêu cầu phi chức năng
   3.1. Hiệu suất
   3.2. Bảo mật
   3.3. Khả dụng

4. Ràng buộc và giả định

5. Phụ lục

8. Kết luận

✅ Tài liệu yêu cầu là xương sống của mọi dự án, giúp đảm bảo phát triển đúng và đủ, hạn chế sai sót và tranh chấp trong quá trình làm việc.

Các trường hợp sử dụng

1. Khái niệm Use Case là gì?

Use Case (Trường hợp sử dụng) là mô tả cụ thể về cách người dùng (hoặc hệ thống khác) tương tác với hệ thống để đạt được mục tiêu nhất định. Use Case giúp làm rõ yêu cầu chức năng, mô tả các tình huống thực tế mà hệ thống cần xử lý, và minh họa luồng hoạt động từ góc nhìn của người dùng.

📌 Use Case thường được biểu diễn qua văn bản mô tả và sơ đồ Use Case (Use Case Diagram) trong UML.

2. Mục đích của Use Case

Mục đích

Ý nghĩa

Xác định chức năng của hệ thống

Làm rõ hệ thống cần thực hiện những gì từ góc nhìn người dùng.

Giao tiếp hiệu quả với các bên liên quan

Giúp mọi người hiểu rõ chức năng qua các tình huống cụ thể.

Làm cơ sở cho thiết kế, phát triển, kiểm thử

Làm đầu vào cho lập trình và kiểm thử phần mềm.

Quản lý phạm vi dự án

Giúp nhận diện đầy đủ chức năng và các giới hạn hệ thống.

3. Cấu trúc chuẩn của một Use Case

Mục nội dung

Giải thích

Tên Use Case

Tên đại diện cho chức năng hoặc quy trình.

Mã Use Case (ID)

Mã số định danh duy nhất (ví dụ: UC-01).

Mô tả ngắn gọn

Giải thích ngắn về mục đích của Use Case.

Tác nhân (Actor)

Ai sử dụng chức năng này (người dùng, hệ thống khác).

Điều kiện tiên quyết (Pre-condition)

Điều kiện phải có trước khi thực hiện Use Case.

Luồng chính (Main Flow)

Các bước chính để thực hiện Use Case.

Luồng phụ (Alternative Flow)

Các trường hợp ngoại lệ, bước thay thế.

Điều kiện sau (Post-condition)

Kết quả sau khi Use Case hoàn tất.

Ghi chú khác

Các yêu cầu đặc biệt, hạn chế, lưu ý thêm.

4. Ví dụ một Use Case cụ thể

Use Case: Đăng nhập vào hệ thống

Mục nội dung

Nội dung

Tên Use Case

Đăng nhập vào hệ thống

UC-01

Mô tả

Người dùng nhập thông tin để đăng nhập hệ thống

Tác nhân (Actor)

Người dùng (User)

Điều kiện tiên quyết

Người dùng đã có tài khoản hợp lệ

Luồng chính (Main Flow)

1. Người dùng nhập tên đăng nhập và mật khẩu. 2. Hệ thống kiểm tra thông tin. 3. Nếu hợp lệ, hệ thống cho phép truy cập.

Luồng phụ (Alternative Flow)

3a. Nếu thông tin sai, hệ thống hiển thị thông báo lỗi.

Điều kiện sau (Post-condition)

Người dùng được đăng nhập vào hệ thống.

Ghi chú khác

Mật khẩu được mã hóa khi kiểm tra.

5. Sơ đồ Use Case (Use Case Diagram)

Ví dụ sơ đồ Use Case đơn giản cho hệ thống quản lý tài khoản

cssCopyEdit[User] ---> (Đăng nhập)  
[User] ---> (Đăng ký tài khoản)  
[Admin] ---> (Quản lý người dùng)

Actor (Tác nhân): Đại diện cho người hoặc hệ thống tương tác.
Use Case (Hình oval): Các chức năng chính mà hệ thống thực hiện.
Mối quan hệ: Đường nối giữa tác nhân và Use Case cho thấy sự tương tác.

6. Phân loại Use Case theo mức độ chi tiết

Loại Use Case

Mô tả

Use Case cấp cao (High-level)

Mô tả tổng quát các chức năng chính của hệ thống.

Use Case chi tiết (Detailed)

Mô tả cụ thể từng bước, từng tương tác trong một quy trình.

7. Các mối quan hệ giữa Use Case

Loại quan hệ

Giải thích

Ký hiệu UML

Include

Một Use Case luôn bao gồm một Use Case khác.

<<include>>

Extend

Một Use Case có thể mở rộng thêm theo điều kiện.

<<extend>>

Generalization (Kế thừa)

Use Case con kế thừa các hành vi từ Use Case cha.

Mũi tên rỗng

Ví dụ về mối quan hệ Include và Extend

pgsqlCopyEdit(Thanh toán) <<include>> (Xác nhận đơn hàng)
(Thanh toán) <<extend>> (Áp dụng mã giảm giá)

8. Lợi ích của việc sử dụng Use Case

Lợi ích

Giải thích

Giúp dễ hình dung chức năng hệ thống

Mô tả các chức năng từ góc nhìn người dùng.

Tăng cường giao tiếp với các bên liên quan

Giúp khách hàng, đội phát triển hiểu rõ chức năng mong đợi.

Hỗ trợ kiểm thử dễ dàng

Cơ sở viết các Test Case chi tiết.

Giúp phát hiện sớm thiếu sót yêu cầu

Nhận diện chức năng bị thiếu hoặc chưa hợp lý.

9. Vai trò của BA khi làm Use Case

Thu thập và phân tích yêu cầu từ người dùng.
Xây dựng và tài liệu hóa các Use Case chi tiết.
Thảo luận với khách hàng, lập trình viên, tester để xác nhận.
Vẽ sơ đồ Use Case để minh họa rõ ràng.

10. Kết luận

✅ Use Case là công cụ quan trọng giúp làm rõ các chức năng của hệ thống từ góc nhìn người dùng. ⚙️ Business Analyst (BA) cần sử dụng Use Case để giao tiếp hiệu quả, đảm bảo yêu cầu đúng và đủ, và giúp đội phát triển hiểu chính xác những gì cần làm.

Xác nhận và ưu tiên yêu cầu

1. Khái niệm Xác nhận và Ưu tiên Yêu cầu

✅ Xác nhận yêu cầu (Requirement Validation)

Là quá trình đảm bảo rằng các yêu cầu đã thu thập là chính xác, đầy đủ, phù hợp và được các bên liên quan chấp nhận. ➡️ Xác nhận yêu cầu giúp tránh hiểu sai và giảm rủi ro khi triển khai dự án.

✅ Ưu tiên yêu cầu (Requirement Prioritization)

Là quá trình xác định thứ tự quan trọng của các yêu cầu dựa trên giá trị kinh doanh, mức độ rủi ro, chi phí và tầm ảnh hưởng. ➡️ Giúp tập trung phát triển các yêu cầu cần thiết nhất và có giá trị cao nhất trước.

2. Mục tiêu của Xác nhận và Ưu tiên Yêu cầu

Hoạt động

Mục tiêu

Xác nhận yêu cầu

Đảm bảo yêu cầu phản ánh đúng mong đợi của các bên liên quan.

Ưu tiên yêu cầu

Lựa chọn yêu cầu quan trọng để phát triển trước, phù hợp nguồn lực.

3. Quy trình Xác nhận Yêu cầu

Bước

Mô tả

1. Rà soát các yêu cầu đã thu thập

Kiểm tra lại danh sách yêu cầu cùng các bên liên quan.

2. Xác định rõ ràng tính khả thi

Đánh giá xem yêu cầu có thực hiện được trong phạm vi dự án không.

3. Xác nhận sự đồng thuận

Lấy ý kiến đồng thuận của các bên liên quan (khách hàng, nhà quản lý, đội phát triển).

4. Tài liệu hóa các yêu cầu đã xác nhận

Ghi nhận các yêu cầu đã được phê duyệt để làm cơ sở cho các bước sau.

📌 Các tiêu chí xác nhận yêu cầu:

Đầy đủ (Complete): Không thiếu yêu cầu quan trọng.
Rõ ràng (Clear): Dễ hiểu, không mơ hồ.
Nhất quán (Consistent): Không xung đột với yêu cầu khác.
Có thể kiểm tra (Testable): Có thể kiểm chứng khi hoàn thành.
Khả thi (Feasible): Có thể thực hiện được với nguồn lực và thời gian có sẵn.

4. Quy trình Ưu tiên Yêu cầu

Bước

Mô tả

1. Xác định tiêu chí ưu tiên

Các tiêu chí như giá trị kinh doanh, rủi ro, chi phí, tác động.

2. Đánh giá từng yêu cầu theo tiêu chí

Gán mức độ ưu tiên cho từng yêu cầu (cao, trung bình, thấp).

3. Thống nhất với các bên liên quan

Xác nhận lại thứ tự ưu tiên để phù hợp mục tiêu dự án.

4. Cập nhật tài liệu yêu cầu

Ghi nhận mức độ ưu tiên để làm cơ sở cho phát triển và kiểm thử.

5. Các Kỹ thuật Xác nhận và Ưu tiên Yêu cầu

Kỹ thuật

Mô tả

Workshop

Cuộc họp tập trung với các bên liên quan để thảo luận yêu cầu.

Phỏng vấn (Interview)

Gặp trực tiếp để làm rõ yêu cầu với người dùng/khách hàng.

Nguyên mẫu (Prototype)

Dùng mô hình giao diện để kiểm chứng yêu cầu.

Danh sách kiểm (Checklist)

Rà soát yêu cầu theo tiêu chí chuẩn để đảm bảo hợp lệ.

MoSCoW

Phân loại yêu cầu: Must have (Phải có), Should have (Nên có), Could have (Có thể có), Won’t have (Không cần).

100 Dollar Test

Phân bổ "ngân sách" tưởng tượng (100 điểm) để ưu tiên yêu cầu.

Kano Model

Phân loại theo sự hài lòng khách hàng: Cần thiết, Mong muốn, Làm hài lòng.

6. Ví dụ về Ưu tiên yêu cầu bằng MoSCoW

Yêu cầu

Mức ưu tiên

Đăng nhập bằng tài khoản Email

Must have (Phải có)

Đăng nhập bằng mạng xã hội (Google)

Should have (Nên có)

Giao diện tối (Dark mode)

Could have (Có thể có)

Tích hợp AI tự động trả lời

Won’t have (Không cần cho phiên bản đầu)

7. Lợi ích của Xác nhận và Ưu tiên Yêu cầu

Lợi ích

Giải thích

Đảm bảo đúng yêu cầu

Đúng ý định người dùng, tránh hiểu sai.

Tối ưu hóa nguồn lực

Tập trung vào yêu cầu quan trọng nhất trước.

Tăng tính minh bạch và đồng thuận

Các bên liên quan hiểu và đồng thuận các yêu cầu.

Giảm rủi ro phát triển sai hoặc thiếu chức năng

Hạn chế các yêu cầu không khả thi hoặc không cần thiết.

Làm cơ sở cho kiểm thử và nghiệm thu

Kiểm thử dựa trên yêu cầu đã xác nhận.

8. Vai trò của Business Analyst (BA) trong giai đoạn này

Tổ chức và điều phối các buổi họp xác nhận và ưu tiên yêu cầu.
Làm cầu nối giữa khách hàng và nhóm phát triển để giải đáp thắc mắc về yêu cầu.
Sử dụng các kỹ thuật phù hợp để hỗ trợ ra quyết định về yêu cầu.
Cập nhật tài liệu yêu cầu chính thức sau khi xác nhận.

9. Kết luận

✅ Xác nhận và ưu tiên yêu cầu là bước quan trọng đảm bảo dự án phát triển theo đúng hướng và tối ưu hóa giá trị mang lại. 💡 Một Business Analyst giỏi cần khéo léo kết nối các bên liên quan, lắng nghe nhu cầu thực tế và biết cách sắp xếp yêu cầu hợp lý để đảm bảo thành công cho dự án.

Yêu cầu chức năng và phi chức năng

1. Khái niệm Yêu cầu Chức năng và Phi chức năng

Loại Yêu cầu

Định nghĩa

Yêu cầu Chức năng (Functional Requirements)

Những gì hệ thống phải làm – mô tả các chức năng, hành vi, và tính năng mà hệ thống cần đáp ứng.

Yêu cầu Phi chức năng (Non-functional Requirements)

Cách hệ thống thực hiện chức năng – mô tả các tiêu chuẩn chất lượng, hiệu suất, bảo mật, và giới hạn.

2. Vai trò của Yêu cầu Chức năng và Phi chức năng

Yêu cầu Chức năng

Yêu cầu Phi chức năng

Định nghĩa hành động, chức năng cụ thể của hệ thống.

Định nghĩa tiêu chuẩn và giới hạn khi thực hiện chức năng.

Mô tả tác vụ, quy trình nghiệp vụ.

Mô tả hiệu suất, bảo mật, khả năng mở rộng, độ tin cậy.

Trả lời câu hỏi: Hệ thống sẽ làm gì?

Trả lời câu hỏi: Hệ thống làm việc như thế nào?

3. Yêu cầu Chức năng (Functional Requirements)

3.1. Đặc điểm

Xác định các hành động, luồng công việc hệ thống cần thực hiện.
Mô tả chi tiết các tương tác giữa người dùng và hệ thống.
Xuất phát từ mục tiêu nghiệp vụ và nhu cầu người dùng.

3.2. Ví dụ về Yêu cầu Chức năng

STT

Yêu cầu Chức năng

Hệ thống cho phép người dùng đăng nhập bằng email và mật khẩu.

Người dùng có thể tạo, chỉnh sửa, xóa bài viết.

Hệ thống gửi email xác nhận khi người dùng đăng ký tài khoản mới.

Quản trị viên có thể duyệt hoặc từ chối bài viết.

4. Yêu cầu Phi chức năng (Non-functional Requirements)

4.1. Đặc điểm

Mô tả cách thức hoạt động của hệ thống.
Liên quan đến hiệu suất, bảo mật, khả dụng, khả năng mở rộng, tính tương thích, tiêu chuẩn pháp lý.
Không gắn với hành động cụ thể mà hệ thống thực hiện.

4.2. Ví dụ về Yêu cầu Phi chức năng

STT

Loại

Yêu cầu Phi chức năng

Hiệu suất

Hệ thống phải xử lý tối thiểu 500 yêu cầu mỗi giây.

Bảo mật

Dữ liệu người dùng phải được mã hóa theo chuẩn AES-256.

Khả năng mở rộng

Hệ thống có thể mở rộng để phục vụ 1 triệu người dùng đồng thời.

Tính sẵn sàng

Hệ thống đảm bảo uptime 99.9% trong 1 năm.

Khả năng tương thích

Hệ thống hỗ trợ mọi trình duyệt phổ biến (Chrome, Firefox, Safari).

5. Sự khác biệt giữa Yêu cầu Chức năng và Phi chức năng

Tiêu chí

Yêu cầu Chức năng

Yêu cầu Phi chức năng

Mục đích

Xác định hệ thống phải làm gì

Xác định cách hệ thống hoạt động như thế nào

Tập trung

Hành vi, chức năng, quy trình nghiệp vụ

Hiệu suất, bảo mật, chất lượng, giới hạn kỹ thuật

Kết quả

Đầu ra cụ thể, hành động, dịch vụ

Tiêu chuẩn chất lượng, điều kiện vận hành

Ví dụ

Đăng nhập, đăng ký, mua hàng, tìm kiếm

Tốc độ phản hồi, mã hóa dữ liệu, yêu cầu pháp lý

6. Phân loại Yêu cầu Phi chức năng theo nhóm chính

Nhóm Yêu cầu Phi chức năng

Ví dụ

Hiệu suất (Performance)

Hệ thống trả lời trong vòng 2 giây cho mỗi yêu cầu.

Bảo mật (Security)

Hệ thống yêu cầu xác thực 2 lớp (2FA).

Khả dụng (Availability)

Hệ thống hoạt động 24/7 với thời gian chết < 1 giờ/tháng.

Khả năng mở rộng (Scalability)

Hệ thống mở rộng để phục vụ thêm 10,000 người dùng/tháng.

Khả năng phục hồi (Reliability)

Khôi phục hệ thống sau lỗi trong vòng 10 phút.

Khả năng sử dụng (Usability)

Giao diện thân thiện, dễ sử dụng cho mọi đối tượng.

Tính tương thích (Compatibility)

Hoạt động tốt trên các trình duyệt phổ biến.

Pháp lý (Legal/Compliance)

Tuân thủ GDPR về bảo vệ dữ liệu cá nhân.

7. Vai trò của BA trong việc xác định yêu cầu

Hoạt động

Vai trò của BA

Thu thập yêu cầu chức năng

Làm việc với các bên liên quan để hiểu rõ chức năng mong muốn.

Thu thập yêu cầu phi chức năng

Xác định các yếu tố về hiệu suất, bảo mật, chất lượng.

Phân tích và phân loại yêu cầu

Phân tách rõ ràng giữa chức năng và phi chức năng.

Làm rõ và xác nhận yêu cầu

Đảm bảo yêu cầu rõ ràng, không mâu thuẫn, khả thi.

Tài liệu hóa yêu cầu

Ghi lại chi tiết để nhóm phát triển và kiểm thử sử dụng.

8. Kết luận

✅ Yêu cầu Chức năng và Phi chức năng đều cần thiết và bổ trợ lẫn nhau để phát triển một hệ thống hoàn chỉnh, hiệu quả và đáp ứng mong đợi của khách hàng. 🎯 Business Analyst (BA) đóng vai trò cầu nối, đảm bảo thu thập, phân loại và mô tả chính xác các yêu cầu này, góp phần giảm rủi ro và đảm bảo thành công của dự án.

Tạo Tài liệu Yêu cầu Kinh doanh (BRD)

2. Mục tiêu và Phạm vi dự án

2.1 Mục tiêu Dự án

Mô tả ngắn gọn và rõ ràng về mục tiêu kinh doanh mà dự án hướng đến.
Ví dụ:
- Tăng hiệu quả quy trình quản lý đơn hàng.
- Tự động hóa hệ thống báo cáo doanh thu.

2.2 Phạm vi Dự án (In Scope)

Các chức năng, dịch vụ, quy trình sẽ được thực hiện trong phạm vi dự án.
Ví dụ:
- Xây dựng hệ thống quản lý đơn hàng online.
- Cung cấp dashboard quản trị báo cáo.

2.3 Ngoài Phạm vi (Out of Scope)

Những yếu tố, chức năng không thuộc phạm vi thực hiện.
Ví dụ:
- Không bao gồm tích hợp với hệ thống thanh toán quốc tế.

3. Mục tiêu Kinh doanh Cụ thể (Business Objectives)

Mã

Mục tiêu

Mô tả chi tiết

OBJ-01

Tăng hiệu quả quản lý đơn hàng

Hệ thống giúp rút ngắn 30% thời gian xử lý đơn.

OBJ-02

Cải thiện trải nghiệm người dùng

Giao diện thân thiện, dễ sử dụng, hỗ trợ mobile responsive.

OBJ-03

Giảm sai sót dữ liệu

Tự động hóa nhập liệu, giảm 90% lỗi thủ công.

4. Yêu cầu Kinh doanh (Business Requirements)

Mã Yêu cầu

Yêu cầu Kinh doanh

Mô tả chi tiết

BR-01

Hệ thống cho phép đặt hàng trực tuyến

Người dùng có thể chọn sản phẩm và đặt hàng qua web/app.

BR-02

Hệ thống thông báo trạng thái đơn hàng

Gửi email/sms thông báo khi đơn được xác nhận, giao hàng.

BR-03

Quản lý thông tin khách hàng

Lưu trữ thông tin khách hàng an toàn, dễ truy xuất.

5. Yêu cầu Chức năng (Functional Requirements)

Mã

Yêu cầu Chức năng

Mô tả chi tiết

FR-01

Người dùng đăng ký và đăng nhập hệ thống

Sử dụng email/mật khẩu hoặc tài khoản mạng xã hội.

FR-02

Chức năng giỏ hàng và thanh toán

Thêm/bớt sản phẩm vào giỏ, chọn phương thức thanh toán.

FR-03

Quản lý đơn hàng cho Admin

Admin xem, chỉnh sửa, cập nhật tình trạng đơn hàng.

6. Yêu cầu Phi chức năng (Non-functional Requirements)

Mã

Yêu cầu Phi chức năng

Mô tả chi tiết

NFR-01

Bảo mật thông tin người dùng

Dữ liệu được mã hóa chuẩn SSL/TLS.

NFR-02

Khả năng mở rộng hệ thống

Hỗ trợ 10,000 đơn hàng/ngày.

NFR-03

Thời gian phản hồi hệ thống

Không quá 2 giây cho mỗi thao tác người dùng.

7. Các bên liên quan (Stakeholders)

Tên

Vai trò

Trách nhiệm

Nguyễn Văn A

Quản lý dự án

Phê duyệt yêu cầu, giám sát tiến độ.

Trần Thị B

Người dùng cuối

Cung cấp thông tin về quy trình thực tế.

Lê Văn C

Developer

Triển khai giải pháp kỹ thuật.

8. Ràng buộc và Giả định (Constraints and Assumptions)

Loại

Nội dung

Ràng buộc

- Hệ thống phải hoàn thành trong 6 tháng.

Giả định

- Người dùng có sẵn thiết bị di động để sử dụng hệ thống.

9. Tiêu chí Chấp nhận (Acceptance Criteria)

STT

Tiêu chí

Người dùng có thể đăng ký và đăng nhập thành công.

Đơn hàng được xử lý và gửi thông báo qua email.

Admin có thể cập nhật trạng thái đơn hàng.

Hệ thống đáp ứng tốc độ phản hồi dưới 2 giây.

10. Phê duyệt (Approval)

Tên

Vai trò

Chữ ký

Nguyễn Văn A

Quản lý Dự án

Trần Thị B

Đại diện Người dùng

Lê Văn C

Đại diện Nhóm Kỹ thuật

📜 11. Phụ lục (nếu có)

Sơ đồ luồng quy trình (Process flow).
Wireframe hoặc prototype.
Danh sách từ viết tắt, thuật ngữ chuyên ngành.

✅ Ghi chú

Tài liệu BRD này là cơ sở chính thức để phát triển hệ thống.
Mọi thay đổi về yêu cầu cần được cập nhật và phê duyệt lại.