06 - Chuong 2 - Tiep - Lam The Nao de Viet Duoc Cac Yeu Cau Tot

CHƯƠNG 2:
2.2. Phân tích và lập tài liệu đặc tả yêu cầu

(tiếp)
2.2.4. Làm thế nào để viết được các yêu cầu tốt?
2.2.4.1. Đặc trưng của các yêu cầu tốt
2.2.4.2. Hướng dẫn viết yêu cầu
2.2.4.3. Một số ví dụ về chỉnh sửa, viết lại yêu cầu
06/21/2023 Phân tích yêu cầu phần mềm 2

Các đặc trưng của một yêu cầu tốt: 7 đặc trưng
• Đầy đủ: Mỗi yêu cầu phải chứa đựng đủ các thông tin để
người đọc có thể hiểu được. Đối với các yêu cầu chức năng,
cần cung cấp đủ các thông tin mà nhà phát triển cần để có thể
thực hiện một cách chính xác yêu cầu. Trường hợp còn thiếu
một số thông tin nhất định, nên sử dụng kí hiệu TBD (to be
determined) hoặc đưa vào hệ thống theo dõi các vấn đề để
theo dõi và phải bổ sung các thông tin còn thiếu trước khi nhà
phát triển xây dựng phần hệ thống liên quan đến yêu cầu đó.
• Chính xác: Mỗi yêu cầu phải mô tả chính xác một khả năng
đáp ứng nhu cầu của một số bên liên quan và phải mô tả rõ
ràng các chức năng của hệ thống sẽ được xây dựng. Nên liên
hệ với người đặt ra yêu cầu để kiểm tra tính đúng đắn của nó.
Các đặc trưng của một yêu cầu tốt (tiếp):
• Khả thi: Phải có khả năng thực hiện yêu cầu trong khả năng và giới
hạn đã biết của hệ thống và môi trường hoạt động của nó, cũng như
trong các hạn chế về thời gian, ngân sách và nhân viên của dự án. Nên
có sự tham gia của nhà phát triển trong quá trình phát hiện yêu cầu để
kiểm tra, đánh giá những yêu cầu nào có thể hoặc không thể thực hiện
được về mặt kỹ thuật, những yêu cầu nào chỉ có thể được thực hiện
với chi phí hoặc nỗ lực quá mức. Có thể sử dụng các phương pháp
phát triển tăng dần và chứng minh bằng nguyên mẫu để đánh giá tính
khả thi của yêu cầu. Nếu một yêu cầu cần được loại bỏ vì nó không
khả thi, cần xác định tác động đến tầm nhìn và phạm vi dự án.
• Cần thiết: Mỗi yêu cầu phải thực sự cần thiết với hệ thống, liên quan
đến một mục tiêu nghiệp vụ cụ thể và được đặt ra bởi những người có
thẩm quyền cung cấp yêu cầu.

Các đặc trưng của một yêu cầu tốt (tiếp):
• Mức ưu tiên: Việc ưu tiên cho các yêu cầu kinh doanh, nghiệp vụ
là rất quan trọng nhằm đạt được các giá trị mong muốn. Cần chỉ
định mức ưu tiên thực hiện cho từng yêu cầu chức năng, yêu cầu
người dùng, trường hợp sử dụng hoặc tính năng để chỉ ra mức độ
cần thiết của yêu cầu đối với hệ thống. Mức ưu tiên cần được
thảo luận, thống nhất giữa các bên liên quan.
• Rõ ràng: Các yêu cầu cần rõ ràng, không mơ hồ, để tránh gây
hiểu lầm, và có thể thực hiện được.
• Kiểm chứng được: Nhân viên kiểm thử có thể áp dụng được các
công cụ, phương pháp kiểm thử để xác định xem yêu cầu có được
thực hiện đúng hay không. Nếu một yêu cầu không thể kiểm
chứng được, cần kiểm tra lại xem nó có chính xác, đầy đủ, khả
thi, hoặc rõ ràng không.
Các đặc trưng của tập các yêu cầu: 4 đặc trưng
• Đầy đủ: Cần có đủ các yêu cầu và đủ thông tin của các yêu cầu
cần thiết.
• Nhất quán: Các yêu cầu không xung đột với các yêu cầu khác
cùng loại hoặc không xung đột với các yêu cầu mức cao hơn
như các yêu cầu nghiệp vụ, yêu cầu người dùng, yêu cầu hệ
thống.

2.2.4.1. Các đặc trưng của một yêu cầu tốt
Các đặc trưng của tập các yêu cầu (tiếp):
• Sửa đổi được: Một yêu cầu có thể viết lại hoặc chỉnh sửa, nhưng nên
duy trì lịch sử thay đổi được thực hiện cho từng yêu cầu, đặc biệt là sau
khi chúng đã được công nhận. Ngoài ra cần nắm vững các mối liên kết,
những sự phụ thuộc giữa các yêu cầu để có thể tìm thấy tất cả những
yêu cầu phải được thay đổi cùng nhau. Tất cả các phiên bản của yêu
cầu đều phải được sửa đổi cùng một lúc để tránh tạo ra sự không nhất
quán. Tham chiếu chéo đến các mục liên quan trong tài liệu SRS nhằm
đồng bộ chúng khi thực hiện việc sửa đổi. Mỗi yêu cầu riêng lẻ chỉ lưu
một lần trong công cụ quản lý yêu cầu để tránh dư thừa và tạo điều
kiện tái sử dụng các yêu cầu chung cho nhiều dự án.
• Truy vết được: Yêu cầu truy vết được vừa liên kết theo chiều lùi với
nguồn gốc của nó và liên kết theo chiều tiến đến các yêu cầu được phát
triển từ nó, đến các thành phần thiết kế, chương trình và các kiểm thử
xác nhận yêu cầu.
2.2.4.1. Các đặc trưng của một yêu cầu tốt
Các đặc trưng của tập các yêu cầu (tiếp):
• Lưu ý: Rất khó để tạo ra một bản đặc tả yêu cầu hoàn hảo với
tất cả các đặc trưng lý tưởng, song khi viết và xem xét các yêu
cầu, cần luôn ghi nhớ các đặc trưng kể trên nhằm tạo ra một bản
đặc tả tốt hơn, từ đó sẽ xây dựng được một phần mềm tốt hơn

• Không có một công thức chung để viết được các yêu cầu
thực sự tốt. BA cần dựa vào các kinh nghiệm cá nhân và
phản hồi của những người nhận/đánh giá các yêu cầu.
Những phản hồi mang tính xây dựng từ đồng nghiệp luôn
là sự hỗ trợ tốt. Vì vậy, nên trao đổi, tìm kiếm nhận xét,
đánh giá và lời khuyên từ các đồng nghiệp, các BA khác.
• “Viết các yêu cầu” không có nghĩa là “ghi lại các yêu cầu”
bằng văn bản sử dụng ngôn ngữ giao tiếp thông thường mà
nên hiểu là cần “biểu diễn kiến thức về các yêu cầu”. Trong
nhiều trường hợp, các kỹ thuật biểu diễn yêu cầu cho phép
diễn đạt thông tin hiệu quả hơn phương pháp diễn đạt bằng
văn bản.

Một số lời khuyên khi viết yêu cầu:
• Viết yêu cầu theo khía cạnh người dùng hoặc hệ thống:
- Nên viết các yêu cầu chức năng theo cách Hệ thống thực
hiện hoặc người dùng có thể thực hiện (một số việc nhất
định). Cần sử dụng lối diễn đạt nhất quán cho các yêu cầu,
ví dụ: “Hệ thống sẽ …” hay “Người dùng sẽ”, tiếp theo là
một động từ chỉ hành động, rồi đến kết quả quan sát được.
Ngoài ra, cần đặc tả các hành động hoặc điều kiện ràng
buộc để hệ thống thực hiện các hành vi được chỉ định.
- Ví dụ về yêu cầu được viết theo khía cạnh hệ thống: Nếu
tìm thấy hóa chất được yêu cầu trong kho hóa chất, hệ
thống sẽ hiển thị danh sách tất cả các thùng trong kho
chứa hóa chất đó.
Một số lời khuyên khi viết yêu cầu (tiếp):
• Viết yêu cầu theo khía cạnh người dùng hoặc hệ thống
(tiếp):
- Khi viết yêu cầu theo khía cạnh người dùng, sử dụng cú
pháp sau:
[Lớp người dùng hoặc tác nhân] sẽ có thể [thực hiện việc
gì đó] [với một số đối tượng] [các điều kiện cần đáp ứng,
thời gian đáp ứng hoặc yêu cầu chất lượng]
Ví dụ:
Nhà hóa học sẽ có thể sắp xếp lại danh sách các hóa chất
mà anh ta đã đặt hàng trong quá khứ bằng cách truy xuất
và chỉnh sửa các chi tiết đơn đặt hàng.

• Phong cách trình bày:
- Nên bắt đầu trình bày với tên chức năng hoặc nhu cầu rồi
đến các chi tiết (lý do, nguồn gốc, mức độ ưu tiên và các
thuộc tính khác của các yêu cầu). Nên kết hợp sử dụng các
bảng biểu, danh sách, sơ đồ, biểu đồ, … nhằm làm giảm
tính đơn điệu của các yêu cầu và giúp người đọc dễ tiếp
cận, hình dung.
- Không nên đặt mục tiêu tạo ra một tài liệu yêu cầu thú vị,
hấp dẫn; không nên sử dụng lối viết văn trong tài liệu yêu
cầu; không sử dụng đan xen câu chủ động và bị động; và
không dùng nhiều thuật ngữ khác nhau để diễn đạt một
khái niệm. Nên viết các yêu cầu sao cho dễ đọc và dễ hiểu.
• Phong cách trình bày (tiếp):
- Trình bày rõ ràng và cụ thể: Sử dụng các câu hoàn chỉnh, đúng
ngữ pháp, đúng chính tả, và dấu câu để diễn đạt các yêu cầu.
Nên sử dụng các câu, đoạn ngắn diễn đạt trực tiếp yêu cầu. Giữ
câu và đoạn văn ngắn và trực tiếp. Viết theo cách đơn giản, sử
dụng ngôn ngữ phù hợp với miền người dùng, tránh dùng biệt
ngữ. Xác định thuật ngữ chuyên ngành trong bảng chú giải.
- Trình bày các yêu cầu một cách chính xác, cô đọng, và súc
tích.
- Để mô tả khả năng của hệ thống, nên dùng từ “sẽ”, không nên
dùng nhiều từ khác nhau như “phải”, “có thể”, “nên”, “cần
phải”, “nên cung cấp”, …

• Sử dụng mẫu câu chủ động: Dùng câu chủ động để làm rõ
thực thể đang thực hiện hành động nào.
Ví dụ câu bị động:
Khi giao bản nâng cấp của sản phẩm, số sê-ri sẽ được cập
nhật trên dòng hợp đồng.
Sửa lại thành câu chủ động:
Khi hoàn thành việc xác nhận đã giao bản nâng cấp của
sản phẩm, hệ thống sẽ cập nhật số seri sản phẩm mới vào
hợp đồng khách hàng.

• Tách riêng các yêu cầu:
- Tránh viết các đoạn văn tường thuật dài có chứa nhiều
yêu cầu, sẽ mất thời gian và gây khó khăn cho người đọc
khi muốn nắm bắt từng yêu cầu riêng, thậm chí có thể bị
nhầm lẫn.

• Tách riêng các yêu cầu (tiếp):
- Việc sử dụng những từ như “và”, “hoặc”, “thêm vào đó”, “cũng” chỉ
ra một số yêu cầu được kết hợp với nhau, nên tránh sử dụng cách diễn
đạt này.
- Cần đảm bảo từ “và” được sử dụng để nối hai phần của một yêu cầu
chứ không phải để nối hai yêu cầu riêng biệt. Nếu sử dụng các bài test
khác nhau để xác minh hai phần, cần tách thành hai yêu cầu riêng.
Tránh sử dụng “và/hoặc” trong một yêu cầu vì có thể gây nhầm lẫn.
Xét ví dụ về yêu cầu sau: “Hệ thống phải cho phép tìm kiếm theo số
đơn hàng (order number), số hóa đơn (invoice number) và/hoặc số
đơn đặt hàng của khách hàng (customer purchase order number)”. 
Yêu cầu này có thể bị hiểu nhầm thành hệ thống phải cho phép người
dùng nhập một, hai hoặc ba số trên cùng một lúc khi thực hiện một
thao tác tìm kiếm duy nhất  Điều này là không đúng.

• Tách riêng các yêu cầu (tiếp):
- Các từ “trừ khi”, “ngoại trừ”, “nhưng” cũng chỉ ra sự hiện diện của
nhiều yêu cầu, nên tránh sử dụng. Xét ví dụ:
“Thẻ tín dụng của người mua trong hồ sơ sẽ bị tính phí thanh toán,
trừ khi thẻ tín dụng đã hết hạn.”
 Việc không xác định điều gì xảy ra khi mệnh đề “trừ khi” là đúng
là một yêu cầu thiếu thông tin. Cần chia yêu cầu này thành hai yêu
cầu riêng để xác định hành vi cho hai trường hợp: thẻ tín dụng đang
hoạt động và thẻ tín dụng đã hết hạn:
“Nếu thẻ tín dụng của người mua trong hồ sơ đang hoạt động, hệ
thống sẽ tính phí thanh toán cho thẻ đó.” và
“Nếu thẻ tín dụng của người mua trong hồ sơ đã hết hạn, hệ thống
sẽ cho phép người mua cập nhật thông tin thẻ tín dụng hiện tại hoặc
nhập thẻ tín dụng mới để thanh toán.”
• Mức độ chi tiết:
- Các yêu cầu cần được đặc tả chính xác nhằm cung cấp đủ thông tin cho
các nhà phát triển và các nhân viên kiểm thử để thực hiện đúng các yêu
cầu.
- Mức chi tiết thích hợp: Một nội dung quan trọng của phân tích yêu cầu
là phân tách một yêu cầu cấp cao thành các yêu cầu chi tiết đủ để làm
rõ và giải quyết nó. Không có một câu trả lời đúng duy nhất cho câu
hỏi thường gặp “Những yêu cầu chi tiết đến mức nào?”. Việc cung cấp
đủ các chi tiết đặc tả sẽ làm giảm thiểu rủi ro do hiểu lầm hay do việc
thực hiện dựa trên kiến thức và kinh nghiệm của nhóm phát triển. Càng
ít cơ hội thảo luận thường xuyên về các vấn đề yêu cầu, càng cần phải
đặc tả các yêu cầu một cách chi tiết hơn. Nếu một nhà phát triển có thể
nghĩ ra một số cách để đáp ứng một yêu cầu và tất cả đều được chấp
nhận, tức là đã đặc tả đúng yêu cầu đó ở mức chi tiết thích hợp.

• Mức độ chi tiết (tiếp):
̵ Các trường hợp cần đặc tả các yêu cầu một cách chi tiết
hơn:
+ Công việc đang được thực hiện cho một khách hàng bên
ngoài.
+ Việc phát triển hoặc kiểm thử sẽ được thuê ngoài
(outsource).
+ Các thành viên trong nhóm dự án phân tán về mặt địa lý.
+ Kiểm thử hệ thống dựa trên các yêu cầu.
+ Cần các ước tính chính xác.
+ Cần truy xuất nguồn gốc các yêu cầu.

̵ Các yêu cầu ít chi tiết hơn sẽ là an toàn trong các trường
hợp:
+ Công việc đang được thực hiện trong nội bộ công ty.
+ Khách hàng được tham gia rộng rãi.
+ Nhà phát triển có kinh nghiệm đáng kể trong miền ứng
dụng.
+ Xây dựng ứng dụng thay thế cho một ứng dụng hiện có.
+ Sử dụng giải pháp trọn gói khi xây dựng hệ thống.

̵ Nhất quán mức chi tiết: Các tác giả yêu cầu thường đấu
tranh để tìm mức độ chi tiết phù hợp để viết các yêu cầu
chức năng. Việc đặc tả tất cả các yêu cầu đến cùng một
mức độ chi tiết là không cần thiết. Ví dụ, các một khu vực
có rủi ro cao hơn những khu vực khác cần đi sâu, đặc tả
chi tiết hơn. Tuy nhiên, trong một tập hợp các yêu cầu
liên quan, một ý tưởng tốt là cố gắng viết các yêu cầu
chức năng ở mức độ chi tiết nhất quán.

̵ Một gợi ý tốt là nên viết các yêu cầu có thể kiểm thử riêng
rẽ. Nếu bạn có thể nghĩ ra một lượng nhỏ các trường hợp
kiểm thử để xác minh rằng một yêu cầu đã được thực hiện
chính xác, thì yêu cầu đó đã ở mức độ chi tiết phù hợp. Nếu
bạn hình dung ra nhiều trường hợp kiểm thử, có lẽ một số
yêu cầu đang được kết hợp và cần được tách riêng ra.
̵ Xét ví dụ sau:
+ Hệ thống sẽ thông dịch tổ hợp phím Ctrl+S là lưu tệp.
+ Hệ thống sẽ thông dịch tổ hợp phím Ctrl+P là in tệp.
+ Sản phẩm sẽ đáp ứng các chỉ thị chỉnh sửa được nhập
bằng giọng nói.
• Các kỹ thuật biểu diễn yêu cầu:
- Một văn bản lớn hay một danh sách dài các yêu cầu
thường gây khó khăn trong người đọc. Nên tìm cách
truyền đạt từng yêu cầu đến đối tượng đọc một cách hiệu
quả nhất. Một số lựa chọn thay thế cho các yêu cầu được
viết bằng ngữ tự nhiên là sử dụng danh sách liệt kê, bảng,
mô hình phân tích trực quan, biểu đồ, công thức toán học,
hình ảnh, clip âm thanh và video clip. Trong nhiều trường
hợp, những lựa chọn này không đủ để thay thế được các
yêu cầu bằng văn bản nhưng chúng đóng vai trò là thông
tin bổ sung rất tốt để nâng cao sự hiểu biết của người đọc.

• Các kỹ thuật biểu diễn yêu cầu (tiếp):
Ví dụ: Xét tập yêu cầu theo định dạng
The Text Editor shall be able to parse <format> documents
that define <jurisdiction> laws.
trong đó:
- <format> có thể nhận 3 giá trị: Tagged format, UnTagged
format và ASCII format
- <jurisdiction> có thể nhận 4 giá trị: Federal, State,
Territorial, International
 có 12 yêu cầu với cú pháp tương tự nhau

Ví dụ: (tiếp) Thay vì liệt kê một loạt 12 yêu cầu, có thể
biểu diễn như sau: Editor.DocFormat The Text Editor shall
be able to parse documents in several formats that define
laws in the jurisdictions shown in Table 11-1.

Ví dụ: (tiếp)
- Các ô trong bảng chỉ chứa hậu tố để nối vào định danh
của yêu cầu chính, ví dụ: yêu cầu thứ ba trong hàng trên
cùng được mở rộng thành:
Editor.DocFormat.3 The Text Editor shall be able to
parse ASCII documents that define federal laws.
- Các trường hợp không áp dụng yêu cầu chức năng do có
lý do hợp lý, cần đặt giá trị N/A (not applicable) cho ô
tương ứng trong bảng.

• Tránh sự mơ hồ:
- Tránh dùng các thuật ngữ mơ hồ: Sử dụng nhất quán các thuật ngữ như
đã được định nghĩa trong bảng chú giải. Không nên sử dụng các từ
đồng nghĩa và gần đồng nghĩa khi không cần thiết.
- Nếu sử dụng một đại từ để chỉ một đối tượng nào đó, hãy chắc chắn
rằng đối tượng này đã được đề cập rõ ràng trước đó. Các trạng từ
thường mang tính chủ quan và mơ hồ. Tránh sử dụng các từ như “hợp
lý”, “phù hợp”, “nói chung”, “xấp xỉ”, “thông thường”, “một cách có
hệ thống” và “nhanh chóng”
- Ngôn ngữ tự nhiên mơ hồ dẫn đến các yêu cầu không thể kiểm chứng,
vì vậy nên tránh sử dụng các thuật ngữ mơ hồ và mang tính chủ quan.
Một số thuật ngữ có thể được chấp nhận khi viết các yêu cầu nghiệp
vụ, nhưng không nên dùng khi viết các yêu cầu của người dùng hoặc
các yêu cầu chức năng.
Một số thuật ngữ nên tránh và các gợi ý thay thế:
- chấp nhận được, đầy đủ: Nên xác định những gì cấu thành sự
chấp nhận và làm thế nào để hệ thống có thể đánh giá được điều
đó.
- và/hoặc: Chỉ định rõ các trường hợp “và”, “hoặc”, hay bất kỳ sự
kết hợp nào để người đọc không phải suy đoán.
- khả năng thực hiện nhiều nhất: Không nên để cho các nhà phát
triển xác định khả năng thực hiện là gì, cần xác định một cách rõ
ràng (có thể gán nhãn TBD và thiết lập thời điểm để tìm ra nó).
- ít nhất, ở mức tối thiểu, không quá, không vượt quá: Chỉ định các
giá trị tối thiểu và tối đa chấp nhận được.
- tốt nhất, lớn nhất, hầu hết: Xác định mức độ mong muốn và mức
độ tối thiểu chấp nhận được
Một số thuật ngữ nên tránh và các gợi ý thay thế (tiếp):
- nằm giữa, từ X đến Y: Xác định xem các điểm cuối có nằm trong
miền xác định không.
- phụ thuộc vào: Mô tả bản chất của sự phụ thuộc, ví dụ: Có một
hệ thống khác cung cấp đầu vào cho hệ thống này, phần mềm
khác phải được cài đặt trước khi chạy phần mềm này hoặc hệ
thống của bạn dựa vào phần mềm khác để thực hiện một số thao
tác tính toán hoặc cung cấp các dịch vụ khác?
- hiệu quả: Xác định hệ thống có thể sử dụng hiệu quả các tài
nguyên, thực hiện các tính toán hoặc các tác vụ nhất định nhanh
như thế nào.
- nhanh: Chỉ định thời gian tối thiểu chấp nhận được để hệ thống
thực hiện một số hành động
- linh hoạt: Mô tả các cách thức mà hệ thống có khả năng thích
ứng với việc thay đổi điều kiện, nền tảng vận hành hoặc thay đổi
các nhu cầu nghiệp vụ.
- cải thiện, tốt hơn, nhanh hơn, vượt trội, chất lượng cao hơn:
Định lượng rõ mức độ cải thiện hơn, tốt hơn, nhanh hơn, ..
- bao gồm, bao gồm nhưng không giới hạn, vân vân, …: Liệt kê
đầy đủ tất cả các giá trị có thể.
- trong hầu hết các trường hợp, nói chung, thông thường, hầu như
luôn luôn: Làm rõ khi các điều kiện hoặc tình huống đã nêu
không được áp dụng và những gì xảy ra sau đó. Mô tả cách người
dùng hoặc hệ thống có thể phân biệt trường hợp này với trường
hợp khác.
- khớp, phù hợp, bằng, đồng ý, giống nhau: Xác định xem việc so sánh
văn bản có phân biệt chữ hoa - chữ thường hay không và liệu nó có
nghĩa là so sánh có chứa, bắt đầu với, chính xác, … hay không. Đối
với việc xác định các số thực, cần xác định mức độ chính xác (ví dụ
chính xác đến mấy chữ số phần thập phân) khi so sánh.
- tối đa hóa, tối thiểu hóa, tối ưu hóa: Nêu rõ các giá trị tối đa và tối
thiểu chấp nhận được.
- thông thường, lý tưởng: Xác định các điều kiện bất thường hoặc
không lý tưởng và mô tả cách hệ thống nên hoạt động trong những
tình huống đó.
- tùy chọn: Làm rõ tùy chọn ở đây có nghĩa là tùy chọn nhà phát triển,
tùy chọn hệ thống hay tùy chọn người dùng.
- có lẽ, nên: Thay bằng hệ thống sẽ hoặc hệ thống sẽ không …
- hợp lý, khi cần, ở nơi thích hợp, nếu có thể, có thể áp dụng:
Giải thích cách nhà phát triển hoặc người dùng có thể đưa ra
phán quyết này.
- mạnh mẽ: Xác định cách hệ thống xử lý các trường hợp ngoại
lệ và phản ứng với điều kiện vận hành bất ngờ.
- liền mạch, rõ ràng, lôi cuốn: Diễn giải kỳ vọng của người dùng
thành các đặc trưng cụ thể, quan sát được của sản phẩm.
- một vài, một số, nhiều, rất nhiều, ít, rất ít: Nêu rõ là bao nhiêu,
hoặc cung cấp phạm vi giới hạn tối thiểu/tối đa.
- không nên, sẽ không: Cố gắng chuyển thành các yêu cầu tích
cực, mô tả những gì hệ thống sẽ làm.

- đủ: Chỉ định rõ bao nhiêu là đủ.
- hỗ trợ, cho phép: Xác định chính xác các chức năng mà hệ
thống sẽ hỗ trợ thực hiện.
- thân thiện với người dùng, đơn giản, dễ dàng: Mô tả các đặc
điểm hệ thống sẽ đáp ứng nhu cầu sử dụng và khả năng sử dụng
mà khách hàng kỳ vọng.

• Cấu trúc A/B: Nhiều tài liệu đặc tả yêu cầu chứa các biểu
thức dạng A/B, trong đó A, B hoặc đồng nghĩa hoặc có
nghĩa trái ngược. Cách biểu diễn này thường là không rõ
ràng. Đôi khi các BA sử dụng cấu trúc này vì họ không
chắc chắn chính xác những gì họ nghĩ, điều đó khiến người
đọc phải diễn giải theo nghĩa mà họ nghĩ đến và có thể nó
không đúng.

• Giá trị biên: Nhiều sự mơ hồ xảy ra ở ranh giới của các phạm
vi số trong cả các yêu cầu và quy tắc nghiệp vụ.
Ví dụ: Yêu cầu nghỉ phép tối đa 5 ngày không cần phê duyệt.
Yêu cầu nghỉ phép từ 5 đến 10 ngày cần được người giám sát
phê duyệt. Yêu cầu nghỉ phép 10 ngày hoặc lâu hơn cần
được người quản lý cấp cao hơn phê duyệt. Như vậy với yêu
cầu nghỉ phép 5 hoặc 10 ngày, ta không biết chính xác yêu
cầu sẽ thuộc loại nào.
 Sửa lại: Yêu cầu nghỉ phép từ 5 ngày trở xuống không cần
phê duyệt. Yêu cầu nghỉ phép nhiều hơn 5 ngày đến 10 ngày
cần được người giám sát phê duyệt. Yêu cầu nghỉ phép dài
hơn 10 ngày cần được người quản lý cấp cao hơn phê duyệt.
• Yêu cầu tiêu cực: Đối với các yêu cầu cho biết hệ thống sẽ
không làm gì (không mô tả những gì hệ thống sẽ thực hiện)
 khó thực hiện yêu cầu  nên cố gắng viết lại dưới dạng
yêu cầu mang tính tích cực, có mô tả rõ ràng các hành vi
hạn chế.
Ví dụ: Ngăn cản người dùng kích hoạt hợp đồng nếu hợp
đồng không cân bằng lợi ích.
 Sửa lại: Hệ thống sẽ cho phép người dùng kích hoạt hợp
đồng chỉ khi hợp đồng cân bằng lợi ích.

• Tránh sự không đầy đủ: Để tránh xác định thiếu yêu cầu,
nên tập trung phát hiện các yêu cầu dựa trên các tác vụ của
người dùng thay vì dựa trên các tính năng hệ thống; ngoài
ra, việc sử dụng các mô hình phân tích sẽ giúp phát hiện
các yêu cầu còn thiếu
• Phân tích tính đối xứng: Xét ví dụ: Trong một tài liệu đặc
tả có yêu cầu sau: Người dùng có thể lưu hợp đồng tại bất
kỳ thời điểm nào trong quá trình thiết kế hợp đồng một
cách thủ công. Nếu trong tài liệu đặc tả không có bất kỳ
yêu cầu nào cho phép tiếp tục công việc thiết kế hợp đồng
chưa được hoàn thành  Thiếu yêu cầu.

• Logic phức tạp: Xét ví dụ về một yêu cầu sau:
Nếu gói Premium không được chọn và minh chứng bảo hiểm không được
cung cấp, khách hàng nên tự động mặc định chọn gói Basic.
 Có 4 trường hợp có thể xảy ra, nhưng yêu cầu trên đã không đề cập
đến việc gì sẽ xảy ra trong 3 trường hợp còn lại:
̵ Gói Premium được chọn và minh chứng bảo hiểm không được cung
cấp.
̵ Gói Premium được chọn và minh chứng bảo hiểm được cung cấp.
̵ Gói Premium không được chọn và minh chứng bảo hiểm được cung
cấp.
Dù người đọc có thể hiểu là trong 3 trường hợp còn lại sẽ không thực hiện
bất kỳ hành động nào, nhưng tốt nhất là cần mô tả rõ ràng chứ không nên
ngầm định. Có thể sử dụng bảng quyết định hoặc cây quyết định để mô tả
các logic phức tạp và cần đảm bảo đã liệt kê đủ các trường hợp.

• Các trường hợp ngoại lệ: Nên có các yêu cầu đi kèm để mô
tả hệ thống nên như thế nào khi có ngoại lệ xảy ra. Ví dụ:
Nếu người dùng đang làm việc với một tệp đã có và chọn
lưu tệp, hệ thống sẽ lưu nó vào tệp cùng tên.
Yêu cầu này không cho biết hệ thống nên làm gì nếu nó
không thể lưu vào tệp cùng tên  Có thể bổ sung yêu cầu
thứ 2:
Nếu hệ thống không thể lưu một tệp dưới một tên cụ thể, hệ
thống sẽ cung cấp cho người dùng tùy chọn lưu tệp dưới
một tên khác hoặc hủy hoạt động lưu.

• Ví dụ 1: Trình quản lý tác vụ nền sẽ cung cấp các thông

báo trạng thái theo định kỳ không dưới 60 giây.
Phân tích: Các thông báo trạng thái là gì? Trong những
điều kiện và tình huống nào chúng sẽ được cung cấp cho
người dùng? Nếu hiển thị trên màn hình, chúng sẽ hiển thị
trong bao lâu, có ổn không nếu chỉ xuất hiện trong nửa
giây? ...
 Yêu cầu này cần được bổ sung thêm thông tin từ các
khách hàng.

Viết lại yêu cầu ở Ví dụ 1:

1. Trình quản lý tác vụ nền (BTM - Background Task Manager)
sẽ hiển thị các thông báo trạng thái trong một khu vực được chỉ
định của giao diện người dùng.
1.1. BTM sẽ cập nhật tin nhắn cứ sau 60 giây hoặc trừ 5 giây
sau khi quá trình xử lý tác vụ nền bắt đầu.
1.2. Các thông điệp 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 của tác vụ nền được hoàn thành.
1.4. BTM sẽ hiển thị thông báo “Done" khi tác vụ nền được
hoàn thành.
1.5. BTM sẽ hiển thị một thông báo nếu tác vụ nền bị đình trệ.

• Ví dụ 2:
Các chi phí cho dự án của các công ty nên được xác nhận
trực tuyến so với danh sách chi phí của tổng công ty, nếu có
thể.
Cụm từ nếu có thể là không rõ ràng  khả năng được thực
hiện về mặt kỹ thuật? Danh sách chi phí liệu có được truy
cập? Yêu cầu cũng không chỉ ra các hành động được thực
hiện khi việc xác nhận thành công hay thất bại. Từ nên là
không rõ ràng, …
Cần thêm thông tin và chỉnh sửa lại.

Viết lại yêu cầu ở Ví dụ 2: Tại thời điểm có yêu cầu nhập chi
phí, hệ thống sẽ hiển thị thông báo lỗi nếu chi phí không có
trong danh sách chi phí của tổng công ty

Ví dụ 3: Trình kiểm tra 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 cả máy phát
xung, vôn kế, máy đo điện dung và thẻ dò tùy chỉnh.
Từ “dễ dàng”  khó đo lường, kiểm chứng.
Từ “bao gồm”  không biết còn thiết bị nào chưa được
liệt kê trong danh sách?

Viết lại yêu cầu ở Ví dụ 3:

1. Trình kiểm tra 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 đặt trên mặt trước bảng để cho phép
người vận hành kết nối được với thiết bị đo trong vòng 10
giây hoặc ít hơn.

Ví dụ 4:
Hệ thống phải kiểm tra sự không nhất quán trong dữ liệu tài khoản
giữa trình Đăng nhập (với tài khoản đang hoạt động - active account)
và trình Quản lý tài khoản. Logic được sử dụng để tạo ra các phép so
sánh này nên dựa trên logic trong công cụ kiểm tra tính nhất quán hiện
có. Nói cách khác, mã nguồn chương trình kiểm tra mới không cần
được phát triển từ đầu. Các nhà phát triển nên sử dụng mã nguồn
chương trình kiểm tra tính nhất quán hiện tại làm nền tảng. Tuy nhiên,
logic bổ sung phải được thêm vào để xác định cơ sở dữ liệu nào là
nguồn xác định quyền truy cập. Chức năng mới sẽ bao gồm cả việc ghi
dữ liệu vào các bảng để chỉ ra cách giải quyết mâu thuẫn như thế nào/ở
đâu. Ngoài ra, chương trình cũng nên kiểm tra các tình huống ngoại lệ
đối với các công cụ bảo mật cơ sở dữ liệu. Cảnh báo tự động qua email
nên được gửi đến Nhóm đảm bảo an ninh bất cứ khi nào có sự khác biệt
được tìm thấy.
Nên phân tách các yêu cầu lớn

Từ “dựa trên” cần làm rõ hơn
“Logic bổ sung” là gì?
Làm thế nào để xác định CSDL nào cho phép xác định
quyền truy cập.
Từ “nên” là không rõ ràng
“Tình huống ngoại lệ” và “sự khác biệt” có đồng nghĩa với
nhau không? Nếu không, cần tạo bảng chú giải
Hệ thống cần gửi thông tin gì đến Nhóm đảm bảo an ninh
khi có sự khác biệt được tìm thấy.
Viết lại yêu cầu ở Ví dụ 4: ???

06 - Chuong 2 - Tiep - Lam The Nao de Viet Duoc Cac Yeu Cau Tot

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

06 - Chuong 2 - Tiep - Lam The Nao de Viet Duoc Cac Yeu Cau Tot

Uploaded by

Copyright:

Available Formats

CHƯƠNG 2:

2.2. Phân tích và lập tài liệu đặc tả yêu cầu

06/21/2023 Phân tích yêu cầu phần mềm 2

06/21/2023 Phân tích yêu cầu phần mềm 4

06/21/2023 Phân tích yêu cầu phần mềm 6

06/21/2023 Phân tích yêu cầu phần mềm 8

06/21/2023 Phân tích yêu cầu phần mềm 9

06/21/2023 Phân tích yêu cầu phần mềm 11

06/21/2023 Phân tích yêu cầu phần mềm 13

06/21/2023 Phân tích yêu cầu phần mềm 14

06/21/2023 Phân tích yêu cầu phần mềm 15

06/21/2023 Phân tích yêu cầu phần mềm 16

06/21/2023 Phân tích yêu cầu phần mềm 18

06/21/2023 Phân tích yêu cầu phần mềm 19

06/21/2023 Phân tích yêu cầu phần mềm 20

06/21/2023 Phân tích yêu cầu phần mềm 21

06/21/2023 Phân tích yêu cầu phần mềm 23

06/21/2023 Phân tích yêu cầu phần mềm 24

06/21/2023 Phân tích yêu cầu phần mềm 25

06/21/2023 Phân tích yêu cầu phần mềm 26

06/21/2023 Phân tích yêu cầu phần mềm 32

06/21/2023 Phân tích yêu cầu phần mềm 33

06/21/2023 Phân tích yêu cầu phần mềm 34

06/21/2023 Phân tích yêu cầu phần mềm 36

06/21/2023 Phân tích yêu cầu phần mềm 37

06/21/2023 Phân tích yêu cầu phần mềm 38

06/21/2023 Phân tích yêu cầu phần mềm 39

• Ví dụ 1: Trình quản lý tác vụ nền sẽ cung cấp các thông

06/21/2023 Phân tích yêu cầu phần mềm 40

Viết lại yêu cầu ở Ví dụ 1:

06/21/2023 Phân tích yêu cầu phần mềm 41

06/21/2023 Phân tích yêu cầu phần mềm 42

06/21/2023 Phân tích yêu cầu phần mềm 43

Ví dụ 3: Trình kiểm tra thiết bị phải cho phép người dùng dễ

06/21/2023 Phân tích yêu cầu phần mềm 44

Viết lại yêu cầu ở Ví dụ 3:

06/21/2023 Phân tích yêu cầu phần mềm 45

Nên phân tách các yêu cầu lớn

Viết lại yêu cầu ở Ví dụ 4: ???

06/21/2023 Phân tích yêu cầu phần mềm 47

You might also like