Phân tích và quản lý yêu cầu phần mềm

Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
Đề cương ôn tập Chuyên đề 2: Phân tích và quản lý yêu cầu
phần mềm.
A. LÝ THUYẾT
Câu 1: Nêu tầm quan trọng và mục tiêu of hoạt động phân tích và quản lý yêu cầu
phần mềm ?
• Tầm quan trọng:
 Quản lý yêu cầu (RM) là một trong các thành phần quan trọng nhất của dự
án phát triển phần mềm:
o Chắt lọc,
o Tổ chức,
o Tư liệu hóa,
o Lưu vết các yêu cầu hệ thống.
=> giúp thẩm tra, thẩm định hệ thống, quản lý thay đổi và phân tích
các trạng thái của dự án.
Như vậy có thể quản lý được mọi thay đổi của yêu cầu dự án.
 Chi phí sửa lỗi do hiểu sai, bỏ sót yêu cầu là rất lớn nếu bỏ sót hay hiểu sai
các yêu cầu phần mềm có thể dẫn đến sai lầm nghiêm trọng ( Cái này nên
đưa vào một số con số).
 Tuy nhiên hoạt động phần tích và quản lý yêu cầu phần mềm thường bị coi
nhẹ.
o Mục tiêu:- Chém gió thôi chưa tìm được tài liệu nào
o Phân tích các yêu cầu của người sử dụng (Yêu cầu thô thường là ngôn
ngữ tự nhiên) thành các feature làm đầu vào để sinh các Use Case phục
vụ cho các pha sau trong tiến trình phát triển phần mềm.
o Sinh các test case phục vụ cho việc kiểm thử
o Tạo ra các tài liệu đặc tả phục cho phần mềm hay người sử dụng, phát
triển và bảo trì phần mềm.
Câu 2: Định nghĩa StackHolder và Actor của hệ thống ? Xác định các StackHolder
và Actor cho dự án phần mềm cụ thể.
- Đinh nghĩa StackHolder và Actor của hệ thống:

o StackHolder:
StackHolder được định nghĩa là 1 người hoặc 1 nhóm người bị tác động bởi
kết quả của dự án phát triều hệ thống hoặc có thể tác động đến các hoạt
1
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
động hoặc đầu ra của dự án (Có thể xem StackHolder là bất kỳ người nào
có thể có yêu cầu với hệ thống).
Các StackHolder có thể là:
 Các khách hàng;
 Người dùng cuối
 Người phát triển
 Nhà sản xuất
 Người kiểm thử
 Đảm bảo chất lượng
 Người quả trị Cơ sở dữ liệu
 Người quản lý cấu hình
 Nhà cung cấp
 Nhà tiếp thị
 Người bảo trì
 Người quản lý
 Các cơ quan quy định tính an toàn/ không nguy hiềm.
o Actor
Một tác nhân là một người hoặc một vật tương tác với hệ thống. Nó có thể
là một người nhưng nó cũng có thể là một hệ thống khác.
- Ví dụ về website của công ty du lịch:
o StackHolder có thể là :
 Khách hàng: là người chủ of Website ;
 Người dùng cuối là những người sử dụng Website qua Internet;
 Người tham gia vào hoạt động phát triển hệ thống
 Người cung cấp tri thức cho hệ thống

 Người quản lý hệ thống
 Người bảo trì và hỗ trợ hệ thống.
o Actor của hệ thống:
 User: Người trực tiếp sử dụng hệ thống.
 Travel Agency Owner: Có thể là một tác nhân nếu anh ta ban hành một
số UC cụ thể cho anh ấy. Phụ thuộc vào liệu anh ấy có quyền hạn cụ thể
gì và liệu có chức năng hệ thống nào là chỉ sẵn dùng cho anh ấy. Nếu
anh ấy truy cập đến các chức năng tương tự như quản trị viên, thì không
cần tạo tác nhân riêng cho Travel Agency Owner vì tác nhân quản trị
viên bao trùm nó.
 Content Manager là một tác nhân, người cung cấp nội dung qua giao
diện.
 Hotel Provider, Car Rental Agent, và Airline Representative có thể xem
như 3 tác nhân riêng rẽ, hoặc xem như một tác nhân được gọi là Service
Provider. Phụ thuộc vào việc họ thực hiện các UC khác nhau như thế
nào. Quyết định này có thể được tạo trong tiến trình sau hơn.
2
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
Câu 3: Trình bày phương pháp suy luận yêu cầu. Ưu và nhược điểm của từng
phương pháp?
ST
T
Phương
pháp
Mô tả Ưu điểm Nhược điểm
1 Phỏng vấn Phương pháp phỏng
vấn 1 nhóm
Stackholder đã được
lựa chọn.
- Tính tự nhiên trong

giao tiếp.
- Là cách tốt nhất cho
việc thu thập các yêu
cầu về khả năng sử
dụng, độ tin cậy hiệu
năng và khả năng hỗ
trợ củ hệ thống.
- Mất nhiều thời gian,
căng thẳng, phụ thuộc
nhiều vào điều kiện
của người được hỏi .
2 Bản câu hỏi
thăm dò.
Bản câu hỏi thăm dò
là hữu ích nhất nếu
chúng ta có thể hỏi
nhiều stackholder các
câu hỏi tương tự và
chúng ta không mong
đợi sinh them các câu
hỏi.
- Nhanh và rẻ hơn
phỏng vấn.
- Dễ tổng kết
- Đào tạo người điều tra
ít tốn kém hơn cả về
thời gian và chi phí
Kết quả có độ chính xác
thấp và được đánh giá
bằng con số trung bình

thống kê
3 Hội thảo Nhóm stackeholder
được lựa chọn gặp gỡ
nhóm dự án. Họ thảo
luận tập trung trong
một khoảng thời gian.
- Có thể áp dụng các kỹ
thuật suy luận yêu cầu
khác nhau.
- Có thể thu thập các
yêu cầu mới xét duyệt,
phân loại và đánh thứu
tự ưu tiên cho các yêu
cầu đang tồn tại
- Mất thời gian nếu
hội thảo về 1 vấn đề
quá lâu.
- Thiếu dữ liệu về
stackeholder có thể
khiến cho buổi hội thảo
thất bại.
- Những phát biểu
tiêu cực, không có tính
xây dựng có thể làm
thất bại buổi hội thảo
hay kéo dài thời gian.
4 Thẻ sự kiện -Sử dụng công cụ đồ
họa, trực quan để mô
tả hành vi hệ thống.
- Bộ tiện ích chỉ ra

thẻ sự kiện ban đầu
cho nhóm.
- Sau đó, dựa trên các
lời bình từ những
người tham gia, thẻ
sự kiện được thay đổi
- Nhanh và chính xác cho
mỗi thẻ sự kiện.
- Thuận tiện cho các quá
trình lặp (nếu muốn lấy
lại ý kiên ).
- Trực quan , dễ tưởng
tượng.
- Phải design lại nếu các
yêu cầu có sự thay đổi.
- Việc cập nhật thẻ sự
kiện là 1 tiến trình lặp
hay thẻ sự kiện sẽ thay
đổi để mô phỏng hệ
thống ngày một chính
xác theo yêu cầu của
stackeholder.
3
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
và được biểu diễn lại.
5 Phân vai Các thành viên trong
nhóm được gán cho
vai trò liên quan đến
hệ thống được xây
dựng.Thông thường

nhất, các vài trò
thường là người sử
dụng hệ thống hoặc
các tác nhân khác
tương tác với hệ
thống
- Mô tả tương đối
chính xác các yêu cầu
của stackeholder.
- Có thể thiếu sót đi
yêu cầu do chưa mới
khảo sát trên phương
diện của một
stackeholder.
- Tốn thời gian và mất
chi phí đào tạo.
6 Các phiên
làm việc tập
trung.
Những người tham
gia tập hợp lại trong
thời gian ngắn. Khi
bắt đầu, người chỉ
đạo thông báo mục
đích của phiên. Các
yêu cầu mới có thể
sinh ra liên quan đến
một số phần của hệ
thống hoặc liên quan
đến việc giải quyết

vấn đề. Mỗi người
tham gia cung cấp 1
số ý kiến và các ý
kiến không được
phép bình phẩm. Sau
khi mọi ý kiến đã
được viết, chọn ngẫu
nhiên hoặc tạo sự kết
hợp các ý kiến này.
- Phương pháp này đặc
biệt hữu ích khi một
vấn đề cần được giải
quyết – hoặc là một
phần đáng kể của yêu
cầu bị bỏ sót, hoặc
yêu cầu là xung độtrr
- Tốn thời gian và chi
phí.
- Thời gian cho 1 phiên
rất lâu nếu các yêu cầu
được sinh ra càng
nhiều.
- Không thích hợp cho
các biểu đồ quan hệ vì
nó chỉ sinh ra một số
lượng nhỏ các ý kiến.
7 Sử dụng
các biểu đổ
quan hệ
Gồm 4 bước:

B1: Tạo các thẻ.
B2.Sắp xếp các thẻ
B3.Thảo luận mô
hình
B4. Tạo các tiêu đề.
B5. Cấu trúc mô
hình.
Phương pháp này đặc
biệt hữu ích khi:
- Có một số lớn các ý
kiến.
- Mối quan hệ giữa các
mục không rõ rang.
- Các vấn đề là phức
tạp
- Sự nhất trí nhóm là
cần thiết.
Phương pháp này không
thích hợp trong trường
hợp chỉ có một số lượng
nhỏ các ý kiến.
8 Mẫu thử Mẫu thử là một - Đem lại những ý kiến - Chi phí lớn do phải
4
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
phương pháp tiềm lực
để có được các phản
hồi từ người dùng và
khách hàng.
đầy đủ về hệ thống
khi đưa ra mẫu thử để

chính khách hàng
kiểm thử.
phát hành một phiên
bản mới của hệ thống
là tón chi phí.
- Nhiều chức năng của
hệ thống thường được
hóa cứng , nên mẫu
thử như bản sự kiên
phức tạp.
9 Các ca sử
dụng (UC)
Các UC là một kiểu
yêu cầu trong kim tự
tháp. Chúng ta cũng
là khuôn dạng để các
stackeholder phát
biểu các nhu cầu của
họ.
- Mô tả chính xác hệ
thống từ các
stackeholder.
10 Phân tích
các tài liệu
Trích rút thông tin từ
các tài liệu word, các
email và các ghi chú
- Tiết kiệm chi phí (Do
chỉ phải tìm tài liệu
và trích rút).

- Chưa đầy đủ nếu
thiếu tài liệu.
- Cần người có kinh
nghiệm để parse dữ
liệu.
11 Quan sát và
mô phỏng
nhiệm vụ.
Quan sát người dùng
thực thi những nhiệm
vụ cụ thể.
- Người dùng có thể
mô phỏng nhiệm vụ,
trong khi người phân
tích ghi chú và tạo
các quan sát.
- Tốn chi phí do cần
người mô phỏng và
người quan sát.
12 Phân tích
các hệ
thống đang
tồn tại
- Thu thập các yêu
cầu từ hệ thống bị
thay thế hoặc từ
các hệ thống cạnh
tranh đã được xây
dựng.
- Nếu chúng ta đang

phát triển 1 hệ thống
tương tự 1 hệ thống
đã tồn tại và chúng ta
có quyền truy cập đến
sản phẩm cuối cùng,
rất đáng giá cho việc
phân tích công việc
của các hệ thống này
để học hỏi rút ra kinh
nghiệm từ các thành
công cũng như các lỗi
của chúng.
- Không thích hợp
cho những hệ thống
mới.
- Có thể mất sự sang
tạo nếu quá phụ
thuộc vào các hệ
thống cũ (I thinks so
^_^)
Kết luận: Tùy thuộc vào từng dự án đang phát triển chúng ta có thể lựa chọn một phương
án hay kết hợp lại nhằm đưa ra 1 kết quả tốt nhất nhé !!!!
5
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
Câu 4: Trình bày ngắn gọn tiến trình phân tích và quản lý yêu cầu phần mềm.
1. Thiết lập kế hoạch quản lý các yêu cầu
Một trong các nhiệm vụ đầu tiên trong dự án là phát triển kế hoạch quản lý các yêu
cầu (Requirements Management Plan - RPM). RPM mô tả cách tiếp cận tổng quan để
quản lý các yêu cầu trong dự án.
Sau đây là một số câu hỏi có thể được trả lời trong RPM:

 Công cụ RM gì sẽ được sử dụng?
 Các kiểu yêu cầu gì sẽ được lưu dấu vết trong dự án?
 Các thuộc tính của các yêu cầu này là gì?
 Các yêu cầu sẽ được tạo ở đâu – chỉ trong CSDL hay trong các tài liệu?
 Giữa các yêu cầu nào chúng ta cần triển khai dấu vết?
 Các tài liệu gì được yêu cầu?
 Những yêu cầu và những tài liệu gì sẽ được sử dụng như là bản hợp đồng với
khách hàng?
 Nếu một phần của dự án được đặt mua, các yêu cầu và các tài liệu gì sẽ được sử
dụng như là bản hợp đồng với nhà cung cấp?
 Chúng ta tuân theo phương pháp luận RUP hay phương pháp luận khác?
 Khách hàng có cần tài liệu gì để tuân theo tiến trình phát triển của họ?
 Quản lý thay đổi sẽ được triển khai như thế nào?
 Giả sử rằng RequisitePro được sử dụng, toàn bộ hệ thống sẽ được lưu trữ trong
một dự án RequisitePro hay lưu trữ ở nhiều dự án?
 Tiến trình nào sẽ đảm bảo rằng mọi yêu cầu đã được cài đặt và đã được kiểm thử?
 Các yêu cầu và các khung nhìn nào mà chúng ta cần để sinh ra các báo cáo?
2. Suy luận các yêu cầu
6
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
- Suy luận các yêu cầu, còn được gọi là thu thập các yêu cầu, là một bước rất quan
trọng. Bỏ sót hoặc hiểu sai một yêu cầu ở trạng thái này sẽ lan truyền vấn đề xuyên
qua suốt vòng đời của phát triển phần mềm.
- Sau đây là một số kỹ thuật được sử dụng để thu thập các yêu cầu từ các Stakebolder:
 Phỏng vấn.
 Bảng các câu hỏi.
 Hội thảo.
 Bảng tường thuật.
 Đóng vai.
 Các phiên làm việc tập thể (Brainstorming sesions).

 Các biểu đồ quan hệ.
 Mẫu thử.
 Phân tích các tài liệu.
 Các trường hợp sử dụng (Use case).
 Phân tích hệ thống đang tồn tại.
3. Phát triển tài liệu trực quan
Trong khi phát triển tài liệu trực quan, một trong các mục đích chính của phân tích
nghiệp vụ là sinh ra các đặc trưng từ các nhu cầu Stakeholder .
Tài liệu trực quan phải chứa thông tin bản chất về hệ thống sẽ được phát triển. Bên
cạnh việc liệt kê mọi đặc trưng, nó lên chứa một mô tả tổng quan về sản phẩm, mô tả
người dùng và tóm lược các khả năng của hệ thống, và các thông tin khác để có thể hiểu
mục tiêu của hệ thống. Nó cũng liệt kê mọi nhu cầu Stakeholder trong trường hợp chúng
không được nắm bắt trong các tài liệu riêng lẻ.
4. Tạo các Use case
7
Hình 1.5 Các đặc trung được sinh ra từ các nhu cầu
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
Một use case là một mô tả về hệ thống theo một chuỗi các hành động. Nó nên sinh
ra kết quả có thể quan sát hoặc trả về giá trị cho tác nhân (tác nhân là một người
hoặc một thứ mà tương tác với hệ thống). Các use case:
 Được khởi tạo bởi một tác nhân.
 Một hình hóa một sự tương tác giữa tác nhân và hệ thống.
 Mô tả một chuỗi các hành động.
 Nắm bắt các yêu cầu chức năng.
 Nên cung cấp một số giá trị cho tác nhân.
 Trình bày luồng sự kiện đầy đủ và có ý nghĩa đầy đủ.
5. Đặc tả bổ sung
Đặc tả bổ sung nắm bắt các yêu cầu phi chức năng (khả năng sử dụng, độ tin cậy, sự thực
thi, khả năng hỗ trợ, ) và một số yêu cầu chức năng mà xuyên xuốt hệ thống, vì nó
không được nắm bắt cứng nhắc trong các use case.

6. Tạo các Test Case từ các Use Case
Các Test Case sẽ chỉ cho người kiểm thử các bước nên thực hiện để kiểm tra mọi yêu
cầu. Trong bước này, chúng ta sẽ tập trung tạo các Test Case từ các Use Case. Nếu chúng
ta chưa tạo các kịch bản trong khi sinh ra các Use Case, chúng ta cần định nghĩa chúng
bây giờ.
7. Tạo các Test Case từ Đặc tả bổ sung
Cách tiếp cận được sử dụng trong bước trước không áp dụng để kiểm thử các yêu cầu bổ
sung. Vì các yêu cầu này không được phát biểu như một chuỗi các hành động, khái niệm
về các kịch bản không áp dụng cho chúng. Một cách tiếp cận riêng nên được áp dụng cho
mỗi yêu cầu bổ sung, vì các kỹ thuật được sử dụng để kiểm tra các yêu cầu thực thi là
khác so với kỹ thuật được sử dụng để kiểm tra các yêu cầu về khả năng sử dụng. Trong
bước này chúng ta cũng thiết kế các vấn đề liên quan đến cơ sở hạ tầng và nền tảng/môi
trường vận hành hệ thống.
8. Thiết kế hệ thống
8
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
Các yêu cầu là nền tảng cho thiết kế hệ thống, mà thường được tạo thuận lợi bởi việc sử
dụng ngôn ngữ mô hình hóa thống nhất (UML – Unified Modeling Language) [BOO98].
Nhiều công cụ như Rational Rose, Rational Software Architect, Rational Data Architect,
và Rational Software Modeler, có thể tạo thuận lợi đáng kế trong việc tạo mọi biểu đồ
được yêu cầu.
Câu 5: Trình bày mối quan hệ giữa yêu cầu trong kim tự tháp yêu cầu. Tại
sao phải quản lý dấu vế các kiểu yêu cầu. Tại sao đối với các dự án phần mềm lớn
và phức tạp phải quản lý các yêu cầu phần mềm theo mô hình kim tự tháp.
1. Mối quan hệ giữa yêu cầu trong kim tự tháp yêu cầu.
- Các kiểu yêu cầu thường được sử dụng trong các dự án:
 Stakeholder need (nhu cầu Stakeholder): Một yêu cầu được để xuất bởi
Stakeholder
 Feature (đặc trưng): Một 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 một đặc trưng là để thỏa

mãn một nhu cầu Stakeholder.
 Use case (ca sử dụng): Một mô tả về hành vi của hệ thống theo các thuật ngữ về
một chuỗi các hành động.
 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) và không thể được thể hiện trong các use cases
 Test case (ca kiểm thử): một đặ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.
 Scenario (kịch bản): Một chuỗi hành động cụ thể; một đường cụ thể qua một use
case.
Các yêu cầu này có thể được biểu diễn theo hình của một kim tự tháp .
9
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
Ở mức đỉnh của nó là các nhu cầu Stackeholder, ở các mức thấp hơn là các đặc trưng, các
ca sử dụng, các yêu cầu bổ sung.
Thông thường ở các mức yêu cầu khác nhau, các mức độ chi tiết cũng khác nhau. Càng ở
mức thấp, mức độ chi tiết càng cao.
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.
2. Phải quản lý dấu vết các yêu cầu là vì:
- Dấu vết – Traceability:
o Là kỹ thuật cung cấp mối quan hệ giữa hai mức độ yêu cầu
o Giúp xác định nguồn gốc của một yêu cầu bất kỳ.
o Mỗi nhu cầu thương được ánh xạ từ một số đặc trưng.
- Vai trò của kỹ thuật Traceability:
o Thẩm tra rằng bản cài đặt là thỏa mãn đầy đủ mọi yêu cầu: Mọi thứ mà khách
hàng yêu cầu đã được cài đặt.
o Thẩm tra rằng ứng dụng chỉ đáp ứng những gì được yêu cầu: Không cài đặt
những thứ mà khách hàng không yêu cầu.
10
Hình 1.2 – Kim tự tháp các yêu cầu
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa

o Phân tích ảnh hưởng: Những phần tử gì sẽ bị tác động khi thêm một yêu cầu
mới hoặc thay đổi một yêu cầu đang tồn tại?
o Giúp quản lý thay đổi: Khi một số yêu cầu thay đổi, chúng ta muốn biết những
test case nào nên được thực hiện lại để kiểm tra sự thay đổi này.
Đó chính là lý do tại sao phải quản lý dấu vết các yêu cầu.
3. Đối với các dự án phần mềm lớn và phức tạp phải quản lý các yêu cầu phần
mềm theo mô hình kim tự tháp là vì:
- Dự án lớn luôn có nhưng yêu cầu thay đổi và càng cần được quản lý, mô hình kim tự
tháp tỏ ra là 1 mô hình rất dễ dùng để quản lý.
- Mọi các yêu cầu của hệ thông đều được ánh xạ từ các yêu cầu ở mức trên.
- Nếu có sự thay đổi thì sẽ bổ sung trên đỉnh kim tự tháp đồng thời sẽ được bổ sung ở
mức sau
- Với những dự án lớn thường nhiều người cùng xây dựng mô hình kim tự tháp dễ
dàng cho việc phân công công việc theo từng mức kết quả mức này là đầu vào cho
mức khác sử dụng.
Câu 6: Nêu các đặc trưng của yêu cầu tốt ? Cho ví dụ minh họa?:
- Đặc trưng của yêu cầu tốt và ví dụ minh họa cho từng yêu cầu đó:
o Tính không mập mờ: Yêu cầu chỉ nên được thông dịch theo 1 nghĩa duy nhất.
ví dụ: REQ: Hệ thống sẽ được cài đặt sử dụng ASP
câu hỏi được đặt ra : ASP ? Active Server Pages or Application Service
Provider? => sự mập mờ => giải quyết:
REQ: Hệ thống sẽ được cài đặt sử dụng Application Service Provider.
o Có thể kiểm thử ( Có thể thẩm định): yêu cầu mà kiểm thử viên có thể thẩm
định liệu nó đã được càu đặt một cách đúng đắn.
Ví dụ:
REQ1: Mã sân bay sẽ được nhập bởi người dùng.
REQ2: Mã sân bay sẽ được nhập vào.
 REQ 1 và REQ2 đều ở thể bị động nhưng REQ2 tác nhân thực hiện
hành động bị lờ đi. Điều này sẽ sinh câu hỏi: “ Ai sẽ nhập mã này – Hệ
thống or người sử dụng ?”

Nên thay REQ2 bằng REQ1
o Rõ ràng ( ngắn gọn, xúc tích, đơn giản, chính xác)
Các yêu cầu không nên chứa các từ hoặc những thông tin không cần thiết.
Chúng nên được phát biểu rõ rang vầ đơn giản.
Ví dụ:
11
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
REQ: Đôi khi người dùng sẽ nhập vào mã sân bay, mà hệ thống sẽ hiểu nhưng
đôi khi thành phố gần nhất có thể thay thể cho nó, do đó người dùng không cần
biết mã sân bay là gì, và nõ sẽ vẫn được hiểu bời hệ thống.
Câu này có thể được thay thế bằng 1 câu đơn giản hơn;
REQ: Hệ thống sẽ xác định sân bay hoặc là đưa vào mã sân bay, hoặc dựa vào
tên thành phố.
o Tính đúng đắn:
Nếu một yêu cầu chứa các sự kiện này phải đúng.
Ví dụ:
REQ: Các thuế giá thuê xe ô tô phải hiển thị mọi thứ thuế (gồm 6 % thuế quốc
gia).
o Khả năng hiểu:
Các yêu cầu phải đúng ngữ pháp và được viết một cách nhất quán.
Ví dụ: từ “shall” được sử dụng thay cho từ “will”, “must”.
o Tính khả thi:
Yêu cầu phải có thể thực hiện giới hạn trong các ràng buộc đang tồn tại như
thời gian, tiền bạc, và các nguồn tài nguyên có thể.
Ví dụ:
REQ: Hệ thống sẽ có giao diện bằng ngôn ngữ tự nhiên và sẽ hiện các mệnh
lệnh bằng ngôn ngữ tiếng anh.
Yêu cầu này là không khả thi trong 1 khoảng thời gian phát triển ngắn.
o Tính độc lập:
Tính độc lập của yêu cầu thỏa mãn khi, để hiểu yêu cầu đó, ta sẽ không cần

phải biết bất kỳ yêu cầu nào khác.
Ví dụ:
REQ: Danh sách các chuyến bay có thể sẽ gồm các thông tin số lượng chuyến
bay, thời gian cất cánh, thời gian đến của mọi chặng đường.
o Nguyên tử:
Yêu cầu nên chứa một phần tử đơn có thể theo dõi qua dấu vết.
Ví dụ:
Xét các yêu cầu sau:
REQ: Hệ thống sẽ cung cấp cơ hội đặt phòng trước và cung cấp thông tin về sự
hấp dẫn của nơi du lịch.
Yêu cầu này chưa nguyên thủy nên tách ra thành 2 yêu cầu riêng biệt;
REQ1: Hệ thống sẽ cung cấp cơ hội đặt phòng trước.
REQ2: Hệ thống sẽ cung cấp cơ hội cung cấp thông tin về sự hấp dẫn của nơi
du lịch.
o Tính cần thiết:
Một yêu cầu không cần thiết khi:
- Không Stackeholder nào cần yêu cầu
12
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
- Xóa yêu cầu sẽ không ảnh hưởng đến hệ thống.
Ví dụ:
REQ: Mọi yêu cầu đã xác định trong tài liệu trực quan phải được cài đặt và
được kiểm thử.
Đây là một yêu cầu không cần thiết vì nó không cung cấp bất kỳ một thông tin
mới nào.
o Độc lập với cài đặt( trừu tượng)
Các yêu cầu không nên chứa thông tin cài đặt và thông tin thiết kế không cần
thiết.
Ví dụ:
REQ: Thông tin nội dung các chuyến bay sẽ được lưu trức trong 1 file văn bản.

Cách thông tin được lưu trưc là trong suốt đối với người dùng và nên là quyết
định của kiến trúc sư hoặc người thiết kế.
o Thống nhất( Khớp nhau):
KHông nên có bất kỳ sự xung đột nào giữa các yêu cầu. Các xung đột trực tiếp
hoặc gián tiếp. Các xung đột trực tiếp xảy ra khi trong tình huống tương tự,
hành vi khác nhau xảy ra.
Ví dụ:
REQ1: Các ngày tháng sẽ đươc hiển thị theo định dang mm/dd/yyyy.
REQ2: Các ngày tháng sẽ được hiển thị theo định dạng dd/mm/yyyy.
Nếu REQ1 được gửi đi từ người dùng Mỹ và REQ2 được gửi đi từ người dùng
Việt Nam thì sẽ nảy sinh xung đột định dạng thời gian.
Giải quyết:
REQ3: Các ngày tháng sẽ được hiển thị dựa vào định dạng được xác định trong
trình duyệt web của người dùng.
o Không dư thừa:
Mỗi yêu cầu nên được phát biểu một lần duy nhất và không được phủ lên yêu
cầu khác.
Ví dụ:
REQ1: Một lịch biểu sẽ sẵn sang để trợ giúp việc nhập vào ngày bay.
REQ2: Hệ thống sẽ hiển thị lịch biểu đẩy lên khi nhập ngày bất kỳ.
REQ1 là tập con của REQ2 do đó REQ2 phủ lên REQ1. ^_^
o Tính đầy đủ:
Yêu cầu nên được phát biểu một lần duy nhất và không được phủ lên yêu cầu
khác.
Ví dụ:
REQ1: Không cần thiết hiện thị đất nước bay đến với những chuyến bay trong
phạm vi nước Việt Nam
REQ2: Với những chuyến bay vượt qua đại dương, hệ thống sẽ hiển thị đất
nước bay đến.
13

Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa
Câu hỏi đặt ra: “ Vậy với chuyến bay đến Lào và Thái Lan thì sao? Chúng
không trong nước Việt Nam mà cũng vượt đại dương (chúng là hàng xóm
mừ ???))”.
14