1.

Nguyễn Văn Hưng

2. Nguyễn Văn Hải
3. Hoàng Đức Hùng

Ví dụ 1: Trình quản lý tác vụ nền sẽ cung cấp thông báo trạng thái đều
đặn không ít hơn mỗi 60 giây.

Thông báo trạng thái là gì? Trong những điều kiện nào và trong thời trang nào chúng
sẽ được cung cấp cho người sử dụng? Nếu được hiển thị trên màn hình, chúng sẽ
hiển thị trong bao lâu? Nếu thông báo chỉ xuất hiện trong nửa giây thì sẽ ra sao?
Người viết đã sử dụng từ “không ít hơn”, đó là khoảng thời gian không rõ ràng, và từ
"mỗi" chỉ làm rối vấn đề thêm. Một cách để đánh giá một yêu cầu là để xem liệu một
giải thích chưa được rõ nhưng phù hợp với các yêu cầu người dùng đã liệt kê. Chúng
ta cần làm rõ hơn. Trong ví dụ này, là khoảng cách giữa các thông báo trạng thái
được cho là ít nhất 60 giây, vậy nếu 2 thông báo cách nhau 1 năm đã thỏa mãn yêu
cầu trên? Ngoài ra, nếu mục đích là để khoảng cách nhiều nhất giữa các tin nhắn là
60 giây, thì có phải 1 mili giây là khoảng thời gian quá ngắn không? Những cách giải
thích này có thể phù hợp với yêu cầu ban đầu, nhưng chắc chắn điều đó chưa chắc
đã hoàn toàn đúng với những gì khách hàng muốn. Vì những vấn đề này,
yêu cầu này nên được ghi cụ thể rõ ràng khoảng thời gian.
Dưới đây là một cách để viết lại yêu cầu trước để giải quyết những thiếu sót đó, sau
khi chúng tôi nhận được một số thông tin khác từ khách hàng:

1. Trình quản lý tác vụ nền (BTM) sẽ hiển thị thông báo trạng thái trong một khu
vực được chỉ định giao diện người dùng.
1.1. BTM sẽ cập nhật các tin nhắn mỗi 60 cộng hoặc trừ 5 giây sau khi nhiệm vụ nền
quá trình xử lý bắt đầu.
1.2. Các tin nhắn sẽ vẫn hiển thị liên tục trong quá trình xử lý nền.
1.3. BTM sẽ hiển thị phần trăm nhiệm vụ nền đã hoàn thành.
1.4. BTM sẽ hiển thị thông báo "Xong" khi hoàn thành nhiệm vụ nền.
1.5. BTM sẽ hiển thị thông báo nếu tác vụ nền bị đình trệ.

Viết một yêu cầu thiếu sót thường làm cho nó dài hơn vì thông tin bị thiếu. Nếu
những tài liệu này được ghi lại ở một nơi nào khác, chẳng hạn như trong một đặc
điểm kỹ thuật giao diện, hãy kết hợp thông tin ở đây bằng cách tham khảo thay vì
sao chép nó.

Ví dụ 2: Corporate project charge numbers should be validated online

against the master corporate charge number list, if possible.
 Số phí dự án của công ty phải được xác nhận trực tuyến dựa trên công ty chủ
danh sách số phí, nếu có thể Cụm từ "nếu có thể" là mơ hồ.
 Nó có nghĩa là "nếu nó khả thi về mặt kỹ thuật" (câu hỏi dành cho nhà phát
triển) hoặc "nếu danh sách số khoản phí chính có thể được truy cập tại thời
 điểm làm việc"? Nếu bạn không chắc chắn liệu khả năng được yêu cầu có thể
được phân phối hay không, hãy sử dụng TBD để chỉ ra rằng vấn đề chưa được
giải quyết. Sau khi điều tra, TBD sẽ biến mất hoặc yêu cầu biến mất. Yêu cầu
này không chỉ định phải làm gì khi xác thực đạt hoặc không thành công.
Ngoài ra, hãy tránh những từ không chính xác như “nên”. Dưới đây là phiên
bản sửa đổi của yêu cầu này:
 “At the time the requester enters a charge number, the system shall display
an error message if the charge number is not in the master corporate charge
number list”
 Tại thời điểm người yêu cầu nhập khoản phí , hệ thống sẽ hiển thị thông báo
lỗi nếu số phí không có trong danh sách số phí chính của chủ đầu tư. Một yêu
cầu liên quan sẽ giải quyết điều kiện ngoại lệ của số phí công ty chính danh
sách không có sẵn tại thời điểm xác thực được cố gắng.
 Ban đầu: Khoản phí phải được check trực tiếp với bên chủ đầu tư , nếu có
thể(không chắc chắn).
 Sau sửa đổi: Yêu cầu check khoản phí ngay tại thời điểm thực hiện làm việc
với khoản đó, cần hiển thị ra thông báo nếu khoản phí đó không nằm trong
danh sách khoản phí mà nhà đầu tư đã đề ra lúc ban đầu.
 Nếu có thể ? Thay thế vào đó là cần phải chắc chắn hơn. Việc này giúp đảm
bảo, quản lý chặt chẽ hơn trong việc quản lý những số dư trong ngân sách
công ty.

Ví dụ 3: Máy đo thiết bị phải cho phép người dùng dễ dàng kết nối các
thành phần bổ sung, bao gồm,bộ tạo xung, vôn kế, đồng hồ đo điện dung
và các thẻ đầu dò tùy chỉnh.

Yêu cầu này dành cho một sản phẩm có chứa phần mềm nhúng được sử dụng để
kiểm tra một số loại
thiết bị đo lường. Từ “dễ dàng” ngụ ý một yêu cầu về khả năng sử dụng, nhưng nó
không thể đo lường
hoặc xác minh được. “Bao gồm” không nói rõ liệu đây có phải là danh sách đầy đủ
các thiết bị bên ngoài
phải được kết nối với người thử nghiệm hay không. Có lẽ còn nhiều người khác mà
chúng ta không biết.
Hãy xem xét các yêu cầu thay thế sau, có chứa một số ràng buộc thiết kế có chủ ý:
1. Máy đo thiết bị phải kết hợp cổng USB để cho phép người dùng kết nối bất kỳ
thiết bị đo nào có kết nối USB.
2. Cổng USB phải được lắp trên bảng điều khiển phía trước để cho phép người vận
hành được đào tạo kết nốithiết bị đo trong 10 giây hoặc ít hơn.
Một nhà phân tích kinh doanh không nên viết lại các yêu cầu theo cách áp đặt các
ràng buộc về thiết kế theo
sáng kiến của mình . Thay vào đó, hãy phát hiện các yêu cầu còn thiếu sót và thảo
luận với các bên liên quan thích hợp
để chúng có thể được làm rõ.