CHƯƠNG 8: PHÂN TÍCH

YÊU CẦU

GV: HỒ THỊ LINH

NỘI DUNG

8.1. Ưu tiên các yêu cầu

8.2. Tổ chức các yêu cầu
8.3. Cụ thể hóa và mô hình các yêu cầu
8.4. Xác định các giả định và ràng buộc
8.5. Kiểm chứng yêu cầu
8.6. Xác nhận các yêu cầu
8.1. Ưu tiên các yêu cầu
8.1.1. Mục đích

• Đảm bảo rằng những nỗ lực phân tích và thực hiện tập trung
vào các yêu cầu quan trọng nhất.
8.1.2. Mô tả

• Là một quá trình ra quyết định được sử dụng để xác định tầm
quan trọng tương đối của các yêu cầu.
• Xác định các yêu cầu mục tiêu để phân tích xa hơn
• Xác định các yêu cầu cần được thực hiện đầu tiên.
8.1.3. Đầu vào

• Trường hợp kinh doanh

• Nhu cầu kinh doanh
• Các yêu cầu
• Kế hoạch quản lý yêu cầu
• Danh sách các bên liên quan, vai trò và trách nhiệm
8.1.4. Thành phần

1. Cơ sở cho việc ưu tiên

• Giá trị kinh doanh
• Dựa trên phân tích chi phí-lợi ích
• Rủi ro kinh doanh và kỹ thuật
• Chọn các yêu cầu thể hiện các nguy cơ cao nhất dẫn đến thất bại dự án
• Khó thực hiện
• Chọn yêu cầu dễ dàng nhất để thực hiện
• Khả năng thành công
• Chọn các yêu cầu có khả năng đưa ra sự thành công nhanh chóng và
tương đối chắc chắn
8.1.4. Thành phần

1. Cơ sở cho việc ưu tiên

• Tuân thủ quy định hoặc chính sách
• Mối quan hệ với các yêu cầu khác
• Sự chấp thuận của các bên liên quan
• Tính cấp thiết
8.1.4. Thành phần

2. Những thách thức

• Những nhu cầu không thể thương lượng
• Sự cân bằng không thực tế
• Đánh giá quá cao những khó khăn, phức tạp của việc thực hiện các
yêu cầu nhất định
8.1.5. Kỹ thuật

1. Các kỹ thuật chung

• Phân tích quyết định
• Phân tích rủi ro
8.1.5. Kỹ thuật

2. Phân tích MoSCoW

• Must
• Should
• Could
• Won’t
8.1.5. Kỹ thuật

3. Hộp thời gian (timeboxing) / Lên ngân sách

• Timeboxing ưu tiên yêu cầu dựa trên số lượng công việc mà
nhóm dự án có khả năng cung cấp trong một khoảng thời gian
• Ngược lại, ngân sách được sử dụng khi các nhóm dự án đã
được phân bổ một số tiền cố định.
8.1.5. Kỹ thuật

3. Hộp thời gian (timeboxing) / Lên ngân sách

Một số cách tiếp cận:
• All In
• All Out
• Selective
8.1.5. Kỹ thuật

4. Bỏ phiếu
• Các yêu cầu tiếp nhận các nguồn lực nhất sẽ được điều tra
hoặc phát triển đầu tiên.
8.1.6. Các bên liên quan

• Domain SME
• Implementation SME
• Project Manager
• Sponsor
8.1.7. Đầu ra

• Các yêu cầu [được sắp xếp thứ tự ưu tiên]

8.2. Tổ chức các yêu cầu
8.2.1. Mục đích

• Tạo ra một tập hợp các quan điểm toàn diện, đầy đủ, nhất
quán của các yêu cầu cho các giải pháp kinh doanh mới và
được hiểu từ tất cả các quan điểm các bên liên quan.
8.2.2. Mô tả

• Hiểu được mô hình phù hợp cho các lĩnh vực kinh doanh và
phạm vi giải pháp.
• Xác định mô hình mối quan hệ và phụ thuộc.
8.2.3. Đầu vào

• Tài sản quy trình của tổ chức

• Các yêu cầu [được phát biểu]
• Phạm vi giải pháp
8.2.4. Thành phần

1. Mức độ trừu tượng

• Yêu cầu thường mô tả khi cần nói làm cái gì «What», không
phải làm như thế nào «How»
• Có một số cấu trúc chính thức cho các mức độ trừu tượng,
bao gồm cả những phác thảo trong khuôn khổ kiến trúc doanh
nghiệp.
• Ngoài ra, các BA có thể không chính thức chỉ định một tập
các yêu cầu mức "cao" hay "thấp", dựa trên mức độ chi tiết.
8.2.4. Thành phần

2. Chọn lựa mô hình

Một số khái niệm mô hình liên quan đến phân tích kinh doanh:
• User Class, Profiles hoặc Roles
• Các khái niệm và mối quan hệ
• Các sự kiện
• Các quy trình
• Các quy tắc (Rule)
8.2.5. Kỹ thuật

• Phân tích quy tắc kinh doanh

• Sơ đồ dòng dữ liệu (DFD)
• Mô hình hóa dữ liệu
• Phân rã chức năng
• Mô hình tổ chức
• Mô hình quy trình
• Kịch bản và use cases
• Mô hình phạm vi
• Câu chuyện người dùng
8.2.6. Các bên liên quan

• Domain SME, End User, Implementation SME, và Sponsor

• Project Manager
8.2.7. Đầu ra

• Cấu trúc các yêu cầu

8.3. Cụ thể hóa và mô hình các
yêu cầu
8.3.1. Mục đích

• Để phân tích mong muốn các bên liên quan được thể hiện và /
hoặc tình trạng hiện tại của các tổ chức sử dụng một sự kết
hợp của báo cáo văn bản, ma trận, sơ đồ, mô hình chính thức.
8.3.2. Mô tả

• Thông số kỹ thuật và các mô hình được tạo ra để phân tích

các hoạt động của một tổ chức và cung cấp cái nhìn sâu sắc
vào các cơ hội để cải thiện.
8.3.3. Đầu vào

• Các yêu cầu [được phát biểu]

• Cấu trúc các yêu cầu
8.3.4. Thành phần
1. Văn bản (Text)
Hướng dẫn viết văn bản yêu cầu bao gồm:
• Thể hiện một và chỉ một yêu cầu tại một thời điểm.
• Tránh các khoản điều kiện phức tạp.
• Đừng cho rằng người đọc có kiến thức miền.
• Sử dụng thuật ngữ phù hợp.
• Thể hiện yêu cầu như một động từ hoặc cụm động từ
• Viết theo giọng tích cực, mô tả rõ ai hoặc cái gì chịu trách nhiệm thực
hiện các yêu cầu.
• Sử dụng thuật ngữ quen thuộc với các bên liên quan mà phải xem xét lại
hoặc sử dụng yêu cầu.
8.3.4. Thành phần

2. Tài liệu ma trận (Matrix Document)

• Một bảng là hình thức đơn giản nhất của một ma trận.
• Các thuộc tính của yêu cầu và từ điển dữ liệu thường được
biểu diễn dưới dạng bảng.
• Một ma trận phức tạp hơn cũng sẽ thể hiện thông tin trong
các hàng của bảng
8.3.4. Thành phần

3. Mô hình
a. Các hình thức của mô hình
• Mô hình có thể là văn bản hoặc đồ họa, hoặc kết hợp cả hai.
Mô hình đồ họa thường được gọi là sơ đồ.
8.3.4. Thành phần

3. Mô hình
Mô hình có thể:
• Mô tả một tình huống hoặc xác định một vấn đề
• Xác định ranh giới cho lĩnh vực kinh doanh và tiểu lĩnh vực, và
mô tả các thành phần bên trong mỗi ranh giới được xác định
• Mô tả quy trình và dòng hành động theo suy nghĩ
• Phân loại và tạo hệ thống phân cấp của các mục
• Chỉ ra các thành phần và các mối quan hệ của chúng
• Chỉ ra logic kinh doanh
8.3.4. Thành phần

3. Mô hình
b. Chú thích
c. Mô hình chính thức với mô hình không chính thức
8.3.4. Thành phần

4. Nắm bắt các thuộc tính yêu cầu

8.3.4. Thành phần

5. Các cơ hội cải tiến

• Tự động hóa hoặc đơn giản hóa công việc con người thực
hiện
• Cải tiến truy xuất thông tin
• Giảm sự phức tạp của các giao tiếp
• Tăng tính nhất quán của hành vi
• Loại bỏ dư thừa
8.3.5. Kỹ thuật

• Acceptance and Evaluation Criteria Definition

• Business Rules Analysis
• Data Dictionary and Glossary
• Data Flow Diagrams
• Data Modeling
• Functional Decomposition
• Interface Analysis
• Metrics and Key Performance Indicators
8.3.5. Kỹ thuật

• Non-functional Requirements Analysis

• Organization Modeling
• Process Modeling
• Prototyping
• Scenarios and Use Cases
• Sequence Diagrams
• State Diagrams
• User Stories
8.3.6. Các bên liên quan

• Các bên liên quan bất kỳ

8.3.7. Đầu ra

• Các yêu cầu [được phân tích]

8.4. Xác định các giả định và
ràng buộc
8.4.1. Mục đích

• Xác định các yếu tố khác hơn các yêu cầu mà có thể ảnh
hưởng đến các giải pháp khả thi.
8.4.2. Mô tả

• Giả định là những yếu tố được cho là đúng, nhưng chưa được
xác nhận
• Ràng buộc được định nghĩa là hạn chế hoặc giới hạn trên giải
pháp có thể.
• Giả định và hạn chế thường được ghi nhận với các thuộc tính
liên quan (như ngày xác nhận, chủ sở hữu, tác động, rủi ro
liên quan và thông tin giải thích khác).
8.4.3. Đầu vào

• Mối quan tâm của các bên liên quan

8.4.4. Thành phần

1. Giả định
• Một giả thiết là bất cứ điều gì được cho là đúng nhưng chưa thực
sự được xác minh.
• Giả thiết có thể liên quan đến một cái gì đó trong hiện tại hoặc
trong tương lai.
• Chứa rủi ro tiềm tàng
Ví dụ, các bên liên quan có thể tin rằng khách hàng sẽ phản ứng
theo một cách nhất định đến sự thay đổi trong cách thức một sản
phẩm được phân phối, nhưng có thể có bằng chứng để hỗ trợ
niềm tin đó.
8.4.4. Thành phần

2. Các ràng buộc kinh doanh

• Những hạn chế trên các giải pháp có sẵn, hoặc một khía cạnh
của tình trạng hiện tại mà không thể được thay đổi bằng việc
triển khai các giải pháp mới
• Ngân sách, thời gian, số lượng các nguồn lực sẵn có, kỹ năng
của nhóm dự án hoặc các bên liên quan, ...
8.4.4. Thành phần

3. Các ràng buộc kỹ thuật

• Gồm quyết định kiến trúc bất kỳ được thực hiện có thể ảnh
hưởng đến việc thiết kế các giải pháp.
• Ngôn ngữ phát triển, nền tảng phần cứng và phần mềm, các
phần mềm ứng dụng phải được sử dụng
• Hạn chế sử dụng tài nguyên, kích thước tin nhắn và thời gian,
kích thước phần mềm, số lượng tối đa và kích thước của các
tập tin, hồ sơ và các thành phần dữ liệu
8.4.5. Kỹ thuật

• Theo dấu vấn đề

• Phân tích rủi ro
8.4.6. Các bên liên quan

• Implementation SME
• Project Manager
• Tất cả các bên liên quan
8.4.7. Đầu ra

• Các giả định và ràng buộc

8.5. Kiểm chứng yêu cầu
8.5.1. Mục đích

• Đảm bảo rằng các thông số kỹ thuật yêu cầu và các mô hình
đáp ứng các tiêu chuẩn cần thiết về chất lượng để cho phép
chúng được sử dụng một cách hiệu quả để hướng dẫn công
việc tiếp theo.
8.5.2. Mô tả

• Kiểm chứng yêu cầu tạo thành sự kiểm tra cuối cùng bởi các
nhà BA và các bên liên quan để xác định yêu cầu:
• Sẵn sàng để xem xét chính thức và xác nhận bởi khách hàng và
người sử dụng
• Cung cấp tất cả các thông tin cần thiết cho công việc tiếp theo dựa
trên các yêu cầu được thực hiện.
8.5.3. Đầu vào

• Các yêu cầu [ngoại trừ đã được phát biểu]

8.5.4. Thành phần

1. Các đặc tính chất lượng yêu cầu

• Gắn kết (Cohesive)
• Đầy đủ
• Phù hợp
• Đúng
• Tính khả thi
• Có thể chỉnh sửa
• Rõ ràng
• Có thể kiểm tra
8.5.4. Thành phần

2. Các hoạt động xác nhận

• Kiểm tra tính đầy đủ trong mỗi mô hình yêu cầu
• So sánh từng mô hình yêu cầu được chuẩn bị (văn bản hoặc đồ
họa) với tất cả các mô hình yêu cầu khác.
• Chắc chắn rằng tất cả các biến thể của quy trình được viết đã
được xác định và viết tài liệu.
• Chắc chắn rằng tất cả trigger và kết quả đã được tính đến cho tất
cả các biến thể.
• Chắc chắn rằng các thuật ngữ sử dụng trong thể hiện các yêu cầu
có thể hiểu được bởi các bên liên quan và phù hợp với việc sử
dụng những thuật ngữ trong tổ chức.
8.5.5. Kỹ thuật

1. Các kỹ thuật chung

• Định nghĩa các tiêu chí chấp nhận và đánh giá
• Theo dõi vấn đề
• Walkthrough có cấu trúc
8.5.5. Kỹ thuật

2. Checklist
• Có ích như một kỹ thuật kiểm soát chất lượng cho các tài liệu
yêu cầu.
• Có thể bao gồm một tập hợp các yếu tố chất lượng mà các
BA hoặc người nhận xét khác sử dụng để xác nhận các yêu
cầu hoặc được phát triển đặc biệt để nắm bắt vấn đề liên quan
đến dự án
8.5.6. Các bên liên quan

• Tất cả các bên liên quan

8.5.7. Đầu ra

• Các yêu cầu [được kiểm chứng]

8.6. Xác nhận các yêu cầu
8.6.1. Mục đích

• Đảm bảo rằng tất cả các yêu cầu hỗ trợ việc cung cấp các giá
trị cho doanh nghiệp, thực hiện các mục tiêu và mục đích của
nó, và đáp ứng nhu cầu các bên liên quan.
8.6.2. Mô tả

• Là một quá trình liên tục để đảm bảo rằng các yêu cầu các
bên liên quan, giải pháp, và sản phẩm chuyển giao phù hợp
với các yêu cầu kinh doanh.
8.6.3. Đầu vào

• Trường hợp kinh doanh (business case)

• Các yêu cầu của các bên liên quan, giải pháp và chuyển giao
[được kiểm chứng]
8.6.4. Thành phần

1. Xác định các giả định

• Trong nhiều trường hợp, có thể không thể chứng minh việc
thực hiện các yêu cầu sẽ dẫn đến các lợi ích mong muốn
8.6.4. Thành phần

2. Xác định tiêu chí đánh giá đo lường

• Xác định các tiêu chí đánh giá sử dụng để đánh giá mức độ
thành công với kết quả thay đổi đạt được sau khi giải pháp
được triển khai
• Số đo và KPI và đánh giá hiệu suất giải pháp
8.6.4. Thành phần

3. Xác định các giá trị kinh doanh

• Các trường hợp kinh doanh xác định giá trị cung cấp bởi một
giải pháp đáp ứng phạm vi giải pháp
• Các trường hợp kinh doanh cũng có thể đánh giá các yêu cầu
cá nhân hoặc các tính năng để xác định xem liệu chúng cũng
mang lại giá trị kinh doanh
8.6.4. Thành phần

4. Xác định phụ thuộc cho việc nhận diện các lợi ích
• Không phải tất cả các yêu cầu đều đóng góp trực tiếp đến kết
quả cuối cùng mong muốn của tổ chức và được mô tả trong
các trường hợp kinh doanh
8.6.4. Thành phần

5. Đánh giá phù hợp với trường hợp kinh doanh và chi phí cơ hội
• Một yêu cầu có thể có giá trị cho một bên liên quan và vẫn không
phải là một phần mong muốn của một giải pháp.
• Một yêu cầu không được liên kết với các trường hợp kinh doanh
cần được xác định và phê duyệt trong một trường hợp kinh doanh
riêng, hoặc xem xét để xóa khỏi phạm vi giải pháp.
• Mỗi yêu cầu phải theo dõi các mục tiêu trong trường hợp kinh
doanh, và cũng nên giảm thiểu các chi phí cơ hội của việc thực
hiện.
8.6.5. Kỹ thuật

• Định nghĩa tiêu chuẩn chấp nhận và đánh giá

• Số đo và KPI
• Tạo mẫu
• Phân tích rủi ro
• Walkthrough có cấu trúc
8.6.6. Các bên liên quan

• Tất cả các bên liên quan

8.6.7. Đầu ra

• Các yêu cầu được xác nhận

HẾT CHƯƠNG 8!!!