PHÂN TÍCH VÀ QUẢN LÝ CÁC YÊU CẦU
PHẦN MỀM
(Requirements Analysis and Management)
Chuyên đề:
Giảng viên: Phạm Thị Thương
Bộ môn: CNPM
Số điện thoại: 0912838646
Email:
Tổng quan về phân tích và quản lý yêu cầu phần
mềm
Chương 1
Mục tiêu

Làm quen với các khái niệm cơ bản

Tổng quan về tiến trình quản lý yêu cầu theo cách tiếp cận hướng đối
tượng
Nội dung
Định nghĩa về yêu cầu và Stakeholder
Các kiểu yêu cầu & mối quan hệ
Dấu vết giữa các yêu cầu
Các đặc trưng của một yêu cầu tốt
Tổng quan về tiến trình phân tích và quản lý yêu cầu
Thảo luận
1. Định nghĩa về yêu cầu & Stakeholder
a.
Định nghĩa yêu cầu
◦
điều kiện ràng buộc hệ thống hoặc
◦
năng lực hệ thống phải có.

b. Định nghĩa Stakeholder

Người/nhóm người
◦
Bị tác động bởi kết quả của dự án phát triển hệ thống
◦
=> Có thể xem Stakeholder là bất kỳ người nào đưa ra yêu cầu đối với hệ
thống.
1. Định nghĩa về yêu cầu & Stakeholder

Các Stakeholder có thể là:
◦
Khách hàng;
◦
Người dùng cuối;
◦
Người phát triển;
◦
Nhà sản xuất;
◦
Nhà cung cấp tri thức cho hệ thống;
◦
Người bảo trì;
◦
Người quản lý;
◦
Những bộ phận cung cấp các luật và các quy tắc.
1. Định nghĩa về yêu cầu & Stakeholder

2 loại Stakeholder chính:

◦ Người dùng:

Những người sẽ sử dụng hệ thống
◦ Khách hàng:

Người yêu cầu phát triển hệ thống, có trách nhiệm phê chuẩn nó, và thường là người chi trả chi phí phát
triển dự án.
⇒
Phân biệt giữa hai loại Stakeholder này là quan trọng.
⇒
Các yêu cầu giữa họ có thể xung đột.
1. Định nghĩa về yêu cầu & Stakeholder

Ví dụ: Xét p/m Online Travel Agency:
1. Định nghĩa về yêu cầu & Stakeholder
Ví dụ: Xét p/m Online Travel Agency:
◦
Khách hàng:
=> Người chủ của Website
◦
Người dùng cuối:
=> Những người sử dụng Website qua internet.
◦
Người phát triển;
=> Người phân tích nghiệp vụ, các nhà thiết kế, người viết mã, những nhà quản lý dự án, người quản lý phát
hành vé, những người thiết kế UC, các nhà thiết kế đồ họa.
◦
Nhà sản xuất:
=> không có
◦

Nhà cung cấp tri thức cho hệ thống:
=> Các chuyên gia miền, tác giả của các tài liệu được sử dụng để suy luận các yêu cầu, các chủ sở hữu Website
cung cấp các link cho Website này).
Xác định Stakeholder
◦
Nhà tiếp thị: => Không có
◦
Người bảo trì và hỗ trợ hệ thống:
⇒
Công ty cung cấp Website hosting,
•
Người quản lý;
=> Lãnh đạo công ty du lịch, Giám đốc phòng Công nghệ thông tin của công ty thiết kế và phát triển Web.
◦ Những bộ phận cung cấp các luật và các quy tắc
=>Engine tìm kiếm: Các luật đối với nội dung website, các luật chính phủ, các luật về thuế quốc gia.
1. Định nghĩa về yêu cầu & Stakeholder
2. Kim tự tháp các yêu cầu
◦
Stakeholder need (nhu cầu Stakeholder):

Là yêu cầu được đề xuất bởi Stakeholder
◦
Feature (đặc trưng):

Là dịch vụ được cung cấp bởi hệ thống, thường được hình thành bởi hoạt động phân tích
nghiệp vụ;

Mục tiêu của đặc trưng là đáp ứng nhu cầu Stakeholder.
◦
Use case (ca sử dụng):


Mô tả về hành vi của hệ thống bằng một chuỗi các hành động.
2. Kim tự tháp các yêu cầu

Supplementary requirement (yêu cầu bổ sung):
◦ Yêu cầu khác (thường là yêu cầu phi chức năng, hoặc các yêu cầu chức năng không được thể
hiện qua UC).

Test case (ca kiểm thử):
◦ Đặc tả về các đầu vào kiểm thử, các điều kiện thực thi, và các kết quả mong đợi.
◦ => nhằm kiểm tra xem liệu các use case và các yêu cầu bổ sung đã được cài đặt một cách
đúng đắn chưa

Scenario (kịch bản):
◦ Chuỗi hành động cụ thể; một đường cụ thể qua một use case.
2. Kim tự tháp các yêu cầu

Càng ở mức dưới, mức độ trừu tượng của y/c càng thấp Ví dụ:
◦
Need: “dữ liệu nên được lưu trữ lâu dài”
◦
Feature: “hệ thống nên sử dụng cơ sở dữ liệu quan hệ”.
◦
Specification: “Hệ thống nên sử dụng CSDL Oracle 9i”.

Từ một yêu cầu mức trên, có thể ánh xạ thành nhiều yêu cầu mức dưới
◦
Tài liệu vision: 12 trang, tài liệu chi tiết: 200 trang
2. Kim tự tháp các yêu cầu
3. Dấu vết các yêu cầu


Dấu vết – Traceability:
◦
Là kỹ thuật cung cấp mối quan hệ giữa hai mức độ yêu cầu
◦
Giúp xác định nguồn gốc của một yêu cầu bất kỳ.

Ánh xạ giữa các kiểu yêu cầu trong kim tự tháp:
◦
Quan hệ n-m:

Need -> feature

Feature-> supplement

Feature->Use case
◦
Quan hệ 1-n:

Use case -> scenario

Scenario-> test case

Supplement-> test case
4. Các đặc trưng của một yêu cầu tốt

[HUL05][LEF03][LUD05][YOU01]- Các yêu cầu tốt nên có những đặc tính sau:
◦
Không mập mờ (Unambigious)
◦

Có thể kiểm thử (Testable, verifiable)
◦
Rõ ràng (clear: ngắn gọn - concise, súc tích-terse, đơn giản-simple, chính xác- precise)
◦
Đúng đắn (correct)
◦
Có thể hiểu (understandable)
◦
Khả thi (Feasible: hiện thực-realistic, có thể thực hiện-possible)
◦
Độc lập (Independent)
◦
Nguyên tử (atomic)
◦
Cần thiết (necessary)
◦
Độc lập với cài đặt (Inplementation-free: Trừu tượng:abstract)

Ba tiêu chuẩn sau áp dụng cho một tập các yêu cầu:
◦
Thống nhất (Consistent)
◦
Không dư thừa (Nonredundant)
◦
Đầy đủ (Complete)
4 Các đặc trưng của một yêu cầu tốt

Xét Website Công ty du lịch trực tuyến:
a.
Unambigious

- Yêu cầu nên dịch theo một nghĩa duy nhất
- Nguyên nhân dẫn đến mập mờ:

Sử dụng các từ viết tắt, các từ không rõ nghĩa

Sử dụng các từ chắc chắn: chỉ, một vài, bất kỳ,
-
Ví dụ 1:
REQ1 The system shall be implemented using ASP.
⇒
ASP có nghĩa là Active Server Pages hay Application Service Provider?
⇒
Correct:
Viết tên đầy đủ và cung cấp từ viết tắt trong ngoặc:
REQ1 The system shall be implemented using Active Server Pages (ASP).
4. Các đặc trưng của một yêu cầu tốt
a.
Unambigious
Ví dụ 2:
REQ2
The system shall not accept passwords longer than 15 characters.
⇒
Not accept:
•
not let the user enter more than 15 characters.
•
truncate the entered string to 15 characters.
•
display an error message if the user enters more than 15 characters.
⇒

Correct:
REQ2 The system shall not accept passwords longer than 15 characters. If the user enters
more than 15 characters while choosing the password, an error message
shall ask the user to correct it
4. Các đặc trưng của một yêu cầu tốt
a. Unambigious
Ví dụ 3:
•
REQ3 On the “Stored Flight” screen, the user can only view one record.
⇒
only view:

not delete or update,

view only one record, not two or three?
=> Correct:

REQ1 On the “Stored Flight” screen, the system shall display only one flight.
4. Các đặc trưng của một yêu cầu tốt
b. Testable, verifiable

Là yêu cầu có thể thẩm định liệu nó đã được cài đặt một cách đúng đắn chưa.
◦ Để có thể kiểm thử, các yêu cầu phải rõ ràng, chính xác và không mập mờ
4. Các đặc trưng của một yêu cầu tốt
b. Testable, verifiable

Một số từ ngữ sau có thể làm yêu cầu không thể kiểm thử [LUD05]:
◦
Một số tính từ:


mạnh, an toàn, chính xác, hiệu quả, hiệu xuất, có thể mở rộng, linh hoạt, có thể bảo trì, có thể tin cậy, thân
thiện người dùng, thỏa đáng.
◦
Các trạng từ và các cụm trạng từ:

Nhanh, an toàn, ứng xử đúng lúc.
◦
Các từ không xác định hoặc các từ viết tắt:

vv, and/or
4. Các đặc trưng của một yêu cầu tốt
b.
Testable, verifiable
◦
Ví dụ 1:

REQ1 The search facility should allow the user to find a reservation based on Last Name,
Date, etc.
=>Trong yêu cầu này, mọi tiêu chí tìm kiếm nên liệt kê rõ ràng. Người thiết kế và người phát triển không thể
hiểu ý người dùng bởi từ: vv ,
=> Correct: Liệt kê rõ ràng các tiêu chí.
4. Các đặc trưng của một yêu cầu tốt