Phân tích yêu cầu phần mềm

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
----------

Báo cáo bài tập

Môn học: Phân tích yêu cầu phần mềm
Giảng viên: PGS.TS. Huỳnh Quyết Thắng
Danh sách sinh viên: (nhóm 3 )
Lê Trung Hiếu

20111568

CNTT-TT 2.3 K56

Đàm Văn Hoài

20111600

CNTT-TT 2.3 K56

Nguyễn Đức Cương

20111203

CNTT-TT 2.3 K56

Đoàn Văn Đạt

20111370

CNTT-TT 2.3 K56

Hà Nội – 4/2014


IT4460

Nhóm 3

Mục lục

Phân tích yêu cầu phần mềm.

Page 2


IT4460

Nhóm 3

I. Mười đặc tính chất lượng của một bản đặc tả yêu cầu phần mềm
tốt.
1.1.

Tính đúng đắn (correct)

- Một đặc tả yêu cầu phần mềm tốt là mọi yêu cầu được xác định đều
phải được phần mềm đáp ứng. Mỗi yêu cầu cần mô tả chính xác chức năng
được xây dựng. Sự đảm bảo cho tính đúng đắn đó là tham chiếu đến nguồn
của yêu cầu, đó có thể là khách hàng hoặc một đặc tả yêu cầu hệ thống mức

cao hơn. Một yêu cầu phần mềm mà xung đột với một yêu cầu hệ thống
tương ứng thì là không đúng đắn. Chỉ sự trình bày của người dùng mới có
thể xác định tính đúng đắn của yêu cầu người dùng, điều đó cho biết tại sao
khi rà soát yêu cầu ta cần sự có mặt của chính người dùng hoặc người đại
diện của họ.
- Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement
Specification (SRS) với đặc tính này để đảm bảo phần mềm đáp ứng đầy đủ
các đặc tả yêu cầu phần mềm. Đây cũng là tiêu chí để đánh giá phần mềm có
đáp ứng được các yêu cầu của người dùng hay không.
1.2.

Tính hoàn chỉnh (complete)

- Mỗi yêu cầu cần mô tả đầy đủ chức năng được chuyển giao. Nó phải
chứa tất cả các thông tin cần thiết để nhà phát triển thiết kế và thực thi chức
năng này. Nếu yêu cầu phần mềm nào đó còn chưa rõ ràng, và ai đó có cảm
giác còn thiếu khi nói về yêu cầu đó, họ sẽ đánh dấu yêu cầu đó là "TBD To Be Determined" - đây là ký hiệu chuẩn trong IEEE 830. Như vậy khi rà
soát toàn bộ tài liệu SRS, chúng ta tìm các yêu cầu bị đánh dấu TBD để tiếp
tục hoàn thiện SRS.
- Phải xác định được kết quả của các dữ liệu đầu vào, đặc biệt là phải
xác định được kết quả của những dữ liệu đầu vào hợp lệ và dữ liệu đầu vào
không hợp lệ.
- Phải có đầy đủ nhãn và tài liệu tham khảo cho tất cả các số liệu, bảng
biểu, sơ đồ trong SRS và định nghĩa của tất cả các điều khoản và đơn vị đo
lường.
Phân tích yêu cầu phần mềm.

Page 3

IT4460

Nhóm 3

- Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement
Specification (SRS) với đặc tính này để đảm bảo mỗi yêu cầu đã được mô tả
đầy đủ.
1.3.

Tính nhất quán (consistent)

-Các yêu cầu phần mềm không xung đột với các yêu cầu phần mềm khác
hoặc các yêu cầu cấp cao hơn (hệ thống hoặc kinh doanh). Tất cả các mâu
thuẫn trong yêu cầu cần phải được phân giải trước khi quá trình phát triển
diễn ra. Bạn có thể không biết một yêu cầu đơn nhất (single requirement)
nào đó là đúng đắn cho đến tận khi bạn tiến hành một số nghiên cứu nào đó
về yêu cầu này.
- Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement
Specification (SRS) với đặc tính này để đảm bảo các yêu cầu của phần mềm
không xung đột lẫn nhau, đảm bảo được tính nhất quán của các yêu cầu phần
mềm.
1.4.

Tính khả thi (Feasible)

- Khả thi có nghĩa là có thể thực thi mỗi yêu cầu trong các 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 hệ thống. Một
yêu cầu không có tính khả thi nếu nó không thể thực hiện được hoặc có thể
thực hiện nhưng yêu cầu chi phí lớn (về nhân lực, về tài chính, về tài nguyên
phần cứng, phần mềm, hoặc về độ phức tạp tính toán).

- Để tránh các yêu cầu không khả thi, cần một thành viên của nhóm dự án
làm việc với những nhân viên bán hàng hoặc các nhà phân tích yêu cầu
trong quá trình xử lý yêu cầu (elicitation process). Người này sẽ đánh giá về
tính khả thi của các yêu cầu về mặt kỹ thuật hoặc chỉ ra các yêu cầu có thể
thực thi nhưng với một chi phí lớn.
- Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement
Specification (SRS) với đặc tính này để đảm bảo các yêu cầu được đưa ra có
thể thực hiện được trong thực tế. Nếu một yêu cầu không thể hoàn thành thì
nó sẽ ảnh hưởng tới toàn bộ dự án. Yêu cầu đó có thể làm lãng phí một
lượng lớn công sức, tài nguyên mà đem lại lợi ích quá nhỏ cho dự án. Thêm
Phân tích yêu cầu phần mềm.

Page 4


IT4460

Nhóm 3

vào đó, việc không thể hoàn thành yêu cầu ảnh hưởng rất lớn tới uy tín của
người phát triển phần mềm. Vì vậy, một SRS tốt cần đảm bảo mọi yêu cầu
đề có tính khả thi.
1.5.

Tính có thể thay đổi (Modifiable)

- Một SRS có thể thay đổi cần đảm bảo mỗi khi cần bổ sung, sửa đổi hay
loại bỏ một yêu cầu nào đó thì công việc này cần được thực hiện một cách
nhanh chóng, chính xác và vẫn đảm bảo tính nhất quán với các yêu cầu còn
lại.

- Để tăng tính thay đổi được của yêu cầu phần mềm, viết các yêu cầu thật
rõ ràng, mạch lạc (fine grain fashion), gán nhãn khác nhau cho mỗi yêu cầu.
Người đọc không thích nhìn thấy các dấu chấm đầu hàng trong tài liệu, vì
khi dò tìm các yêu cầu, phải dò qua từng yêu cầu cụ thể một - tốn thời gian
và không rõ ràng (vì không có nhãn). Một trong những cách để loại bỏ các
dấu chấm, đó là sắp xếp các yêu cầu theo bảng chữ cái - như thế dùng chữ
cái để gán nhãn.
- SRS có thể được nghiên cứu lại khi cần thiết và cần phải duy trì thông
tin diễn biến thay đổi của mỗi yêu cầu. Điều này đòi hỏi mỗi yêu cầu được
dán nhãn duy nhất và được diễn giải riêng rẽ với các yêu cầu khác sao cho
mỗi yêu cầu đều được tham chiếu chính xác. Mỗi yêu cầu chỉ được xuất hiện
duy nhất 1 lần trong SRS để tránh sự không nhất quán giữa các thể hiện
(instance) của cùng 1 yêu cầu tại những nơi khác nhau. Một bảng nội dung
(table of contents), một index, một danh sách tham chiếu chéo (cross –
reference listing) sẽ làm SRS dễ sửa chữa hơn.
- IEEE 830-1998 hỗ trợ xây dựng SRS với đặc tính chất lượng này để có
thể tiết kiệm thời gian, chi phí cho quá trình đàm phán và quản lý yêu cầu
phần mềm. Một SRS có đặc tính “có thể sửa đổi” sẽ giúp việc sửa đổi chỉ
cần làm ở một số ít nơi của SRS, đồng thời không cần lo lắng về việc những
thay đổi này mâu thuẫn với các yêu cầu trước đó.
Phân tích yêu cầu phần mềm.

Page 5


IT4460
1.6.

Nhóm 3

Tính cần thiết (Necessary)

- Mỗi yêu cầu cần phải tài liệu hoá một cái gì đó mà khách hàng thật sự
cần hoặc một hệ thống khác bên ngoài cần. Một cách khác để xác nhận “tính
cần thiết” là yêu cầu đó được đề xuất từ một bên mà bạn biết rất rõ rằng
người đó có thầm quyền đề ra yêu cầu.
- Nếu một yêu cầu phần mềm không đáp ứng nguyện vọng của bất kì
khách hàng hay hệ thống nào thì nó là yêu cầu không cần thiết, cần phải loại
bỏ. Việc thực hiện yêu cầu này không mang lại lợi ích nào cho dự án phần
mềm, chỉ làm lãng phí công sức, tài nguyên.
- IEEE 839-1998 hỗ trợ xây dựng SRS với đặc tính chất lượng này để
đảm bảo mọi yêu cầu được đưa ra trong SRS đều cần thiết cho dự án phần
mềm. Chỉ các yêu cầu thật sự cần thiết mới cần đầu tư thời gian, công sức để
hoàn thành.
1.7.

Có độ ưu tiên (Prioritized)

- Gán mỗi thứ tự ưu tiên cho mỗi yêu cầu, tính năng (feature), hoặc use
case để có thể hình dung lịch trình phát triển các phiên bản phần mềm. Nếu
tất cả các yêu cầu được coi là quan trong như nhau thì quản trị dự án sẽ
không xác định được cách thức thi công khi một yêu cầu mới phát sinh trong
quá trình thi công của dự án, anh ta sẽ không kiểm soát được ngân sách, lịch
biểu và nhân lục của sự án.
- Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement
Specification (SRS) với đặc tính này để đảm bảo người quản trị dự án đánh
giá được chính xác mức độ quan trong của mỗi yêu cầu. Tù đó có sự đánh
giá, kiểm soát được tất cả các yêu cầu hiện có và các yêu cầu phát sinh thêm.
Người quản trị sẽ đầu tư đúng mức với từng yêu cầu tương ứng với mức độ
ưu tiên của nó.

1.8.

Có thể truy vết (Traceable)
- Bạn cần phải liên kết các yêu cầu tới nguồn phát sinh của nó, tới các

Phân tích yêu cầu phần mềm.

Page 6


IT4460

Nhóm 3

phần tử thiết kế, mã nguồn, các test cases thực thi và kiểm tra sự đúng đắn
trong việc thi công các yêu cầu. Các yêu cầu có thể theo vết được gán nhãn
duy nhất và được viết theo một cách có cấu trúc, chi tiết và được thuyết
minh đầy đủ.
- Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement
Specification (SRS) với đặc tính này để người làm dự án tìm được đường đi
của mỗi yêu cầu phần mềm từ nguyên nhân phát sinh đến lúc thiết kế để đáp
ứng được yêu cầu đó trong phần mềm. Mỗi yêu cầu cần xác định một cách
rõ ràng nguồn phát sinh, vị trí của nó trong khâu thiết kế. Truy viết được
giúp người làm dự án tìm ra lỗi sai hay những thiếu sót của yêu cầu một
cách nhanh chóng nhất do đã biết được vết đi của yêu cầu đó.
1.9.

Không nhập nhằng (Unambiguous).

- Tất cả những ai khi đọc bản báo cáo yêu cầu đều có cùng một cách hiểu,

một cách diễn giải nhất quán về nội dung của các yêu cầu. Do ngôn ngữ tự
nhiên là có tính nhập nhằng cao nên viết một yêu cầu rõ ràng, cụ thể, đơn
nghĩa không phải là dễ. Cách hiệu quả để loại bỏ tính nhập nhằng là mô tả
các báo cáo yêu cầu bằng các ngôn ngữ hình thức như use-case chẳng hạn,
qua các kịch bản sử dụng cụ thể.
- Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement
Specification (SRS) với đặc tính này để giúp cho SRS trình bày rõ ràng
nhất,tường minh nhất. Tất cả các yêu cầu không có sự trùng lặp hay trùng ý
nghĩ với nhau vì nếu điều này có trong SRS thì dự án rất dễ dẫn đến thất bại.
Một phần mềm không thể trùng lặp các chức năng với nhau đó là một phần
mềm tồi.
1.10. Kiểm tra được (Verifiable)

- Hãy kiểm tra mỗi yêu cầu để xem liệu bạn có thể nghĩ ra một số lượng
nhỏ các phép tests hoặc sử dụng một cách tiếp cận kiểm tra khác như thanh
tra (inspection) hoặc chứng minh (demonstration) để biết liệu yêu cầu đó đã
Phân tích yêu cầu phần mềm.

Page 7


IT4460

Nhóm 3

được cài đặt hợp lệ trong sản phẩm hay không. Nếu một yêu cầu không thể
kiểm tra thì xác định liệu nó có được cài đặt đúng đắn hay không sẽ trở
thành vấn đề gây tranh cãi. Các yêu cầu không nhất quán, không khả thi
hoặc nhập nhằng thì cũng không thể kiểm tra được.
- Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement

Specification (SRS) với đặc tính này để người làm dự án kiểm tra cài đặt yêu
đó đã hợp lí hay chưa, sai hoặc chưa tối ưu nhất. Một SRS kiểm tra được sẽ
nhanh phát hiện lỗi của mỗi yêu cầu trong quá trình triển khai dự án giúp
giảm chi phí về tiền bạc và nhân lực để sửa chữa.
II. Các Tips để viết đặc tả yêu cầu phần mềm
1. Đưa ra các đánh giá dựa trên góc nhìn của nhà phát triển.
Bất kể phía đối tác đưa ra yêu cầu nào, quan điểm nào, nên đứng trên
quan điểm của nhà phát triển để đánh giá yêu cầu đó. Bản thân phía đối
tác khi đưa ra yêu cầu phần mềm nào, đã mang góc nhìn và quan điểm
của họ. Thông thường, họ không phải là người trong ngành công nghệ
thông tin, và vì thế sẽ không hiểu hết rõ đặc thù của công việc phát triển
phần mềm cũng như những khả năng của máy tính. Do đó, luôn phải
đánh giá, nhận xét các yêu cầu phần mềm trên góc nhìn của nhà phát
triển.
1. Làm nổi bật các yêu cầu bằng cấu trúc phân cấp. Và cũng nên suy nghĩ,
đánh giá dựa theo cấu trúc phân cấp này. Bởi bản thân cấu trúc phân cấp
đã mang trong nó ít nhiều những thông tin về mối quan hệ logic giữa yêu
cầu: Yêu cầu lớn, yêu cầu nhỏ, yêu cầu cha – con, các yêu cầu cùng mức
phân cấp… Chính cấu trúc này giúp việc đánh giá trở nên chính xác, hợp
lý, và sát hơn. Đặc biệt đánh giá dựa trên hình ảnh trực quan bao giờ
cũng dễ dàng hơn là chỉ suy nghĩ vấn đề trong đầu mà không có hình ảnh
hỗ trợ. Và thực tế cũng chứng minh, hầu hết mọi người đối mặt với các
vấn đề phức tạp bằng cấu trúc phân cấp (nó phân rã vấn đề lớn thành các
vấn đề nhỏ - hiểu và có thể giải quyết được). Nếu không biểu diễn theo
cấu trúc phân cấp, khó có thể nhận ra mối quan hệ logic giữa các yêu
cầu/mục yêu cầu, khó nhận ra đâu là yêu cầu lớn, đâu là yêu cầu nhỏ, …
Phân tích yêu cầu phần mềm.

Page 8

IT4460

Nhóm 3

2. Cố gắng viết các câu và đoạn ngắn - đơn giản (write concisely):
o Tránh các đoạn văn nói dài. Bởi đôi khi một đoạn văn dài, với nhiều
ý, cuối cùng lại không chốt được yêu cầu mà nó nói tới chính xác là
cái gì!
o Dùng ngữ pháp, chính tả, và ngắt câu phù hợp (nên để người thông
thạo ngôn ngữ được sử dụng để viết SRS)
o Dùng từ vựng trong lĩnh vực kinh doanh
(đôi khi việc không sử dụng chính xác từ cũng làm thay đổi toàn bộ ý
nghĩa mà yêu cầu muốn diễn đạt)
Trong một đoạn nói về một yêu cầu phần mềm nào đó, có thể có rất
nhiều thông tin quan trọng, nhưng lại không chỉ rõ ra yêu cầu này cần
xây dựng cái gì! Thay vì đó, đừng để yêu cầu về một chức năng được viết
trong một đoạn quá dài, đưa các mô tả nền tảng (additional descriptive
background), context của chức năng ra ngoài, tách bạch với mô tả chức
năng.
Đừng yêu cầu người khác rà soát lại một tài liệu chưa được kiểm tra
ngữ pháp - chính tả.
Sẽ tốt hơn nếu có 1 ai đó giỏi ngôn ngữ rà soát lại SRS, tìm ra các vấn
đề về dùng từ và câu, để cho ra được 1 tài liệu tốt về mặt diễn đạt yêu cầu
phần mềm.
1. Phải có văn bản mô tả cho cả các hành vi được mong muốn lẫn các
ngoại lệ - Chúng ta mong đợi hệ thống hoạt động theo đúng những hành
vi mà ta mong muốn, tuy nhiên, 1 chương trình được viết cùng với rất
nhiều những đoạn mã để xử lý lỗi, ngoại lệ. Và nếu chúng ta không xác
định các lỗi, ngoại lệ cũng như cách xử lý chúng trong quá trình xây

dựng yêu cầu phần mềm, sẽ có 2 vân đề! 1 là developers sẽ chỉ ra ngoại
lệ đó và cố gắng thiết kế xử lý ngoại lệ đó theo 1 cách mà kém lý tưởng
hơn từ quan điểm của người dùng. 2 là sẽ không ai nghĩ về lỗi/ngoại lệ
đó. Và lần đầu tiên chương trình gặp lỗi, ngoại lệ đó, nó crash!
Công việc chỉ ra các ngoại lệ bị thiếu nên được thực hiện bởi tester,
bởi họ sẽ nghĩ về mọi điều tồi tệ có thể xảy ra với chương trình.
2. Tránh các ràng buộc thiết kế (design constraints) không cần thiết.
Tránh việc đưa vào SRS quá nhiều ý tưởng giải quyết (solution ideas).
Có nghĩa là đừng đưa quá nhiều ràng buộc thiết kế vào tài liệu SRS bằng
Phân tích yêu cầu phần mềm.

Page 9


IT4460

Nhóm 3

cách kết hợp quá nhiều ý tưởng giải pháp trong tài liệu hướng dẫn, trừ
khi có 1 lý do đặc biệt thỏa đáng.
3. Viết các yêu cầu ở mức chi tiết hợp lý
Khó để xác định xem tài liệu SRS cần được viết chi tiết đến mức nào,
một trong những hướng dẫn, đó là chia các yêu cầu phần mềm ra thành
các bộ phận mà có thể độc lập kiểm tra.
Các từ "and" và "or" xác định các yêu cầu phần mềm có được kết hợp
với nhau hay không. Ví dụ khi gặp 1 từ "and" trong yêu cầu phần mềm,
ta sẽ đặt ra câu hỏi, phải chăng 2 vế của từ "and" là của cùng 1 yêu cầu?
Hay chúng về mặt logic là 2 yêu cầu khác nhau và cần chia ra (split)?
4. Viết các yêu cầu một cách chính xác, cụ thể, không mơ hồ và gây nhầm
lẫn.

Một số lập trình viên đôi khi thích các yêu cầu phần mềm mơ hồ, gây
nhầm lẫn, để khi bắt tay vào xây dựng, họ có thể xây dựng cái gì mà họ
muốn ? Và thậm chí người dùng cũng thích các yêu cầu mơ hồ, gây nhầm
lẫn, bởi nó cho phép họ định nghĩa lại yêu cầu đó theo ý mà họ muốn tại
thời điểm cụ thể! Điều này không tốt một chút nào cho việc xây dựng
một phần mềm chất lượng tốt!
Có một số từ nên được sử dụng để viết yêu cầu, và một số từ nên
tránh. Nên sử dụng các từ "sẽ", "phải" thay vì nói "nên", "có lẽ", "có thể",
… (should, may, might, could, can, if possible, if you feel like, if you
have time, if you get around). Nên chọn 1 số thuật ngữ và sử dụng nó
một cách nhất quán từ đầu đến cuối SRS khi nói về các chức năng hệ
thống.
Một người bạn của tác giả gợi ý là thay thế từ should bằng cụm từ
"probably won't (có lẽ sẽ không)", và hỏi ý kiến người dùng có đồng ý
với yêu cầu (phần mềm) đó không, và thông thường, người dùng nói
không (tức là bản thân cụm từ probably won't cũng đã mơ hồ, không rõ
ràng).
Một số người viết yêu cầu phần mềm sử dụng should - nói đến chức
năng được yêu cầu trong hệ thống, might - chức năng được mong muốn
có trong hệ thống, và may - chức năng tùy chọn; điều này thực sự không
tốt, bởi chính bản thân những từ này trong giao tiếp hàng ngày đã ít nhiều
được sử dụng thay thế nhau. Chính điều đó sẽ khiến cho việc sử dụng
Phân tích yêu cầu phần mềm.

Page 10


IT4460

Nhóm 3

chúng làm văn bản trở nên thiếu tính nhất quán, các yêu cầu thiếu tính
đơn nghĩa! Như vậy cần tránh sử dụng các từ gây nhầm lẫn và mang tính
chủ quan.

Phân tích yêu cầu phần mềm.

Page 11


IT4460

Nhóm 3

1. Phân biệt Requirements Verification và Requirements Validation
1.1. Phân biệt
- Requirements Validation (Xác nhận yêu cầu)
Đây là việc kiểm tra rằng có phải một sản phẩm đúng đang được xây dựng hay
không. Cần chắc chắn rằng sản phẩm đang xây dựng (hay nâng cấp) sẽ làm thỏa
mãn các bên liên quan. Điều này được tiến hành bằng việc đối chiếu lại bản đặc tả
yêu cầu phần mềm với mục tiêu và yêu cầu của các bên liên quan.
- Requirement Verification (Kiểm chứng yêu cầu)
Đây là việc kiểm tra rằng có phải một sản phẩm đang được xây dựng đúng hay
không. Cần chắc chắn rằng mỗi bước được cho phép trong quá trình xây dựng
phần mềm đều mang lại lợi ích cho việc xây dựng sản phẩm đúng. Việc này được
tiến hành thông qua đối chiếu đối tượng được tạo ra theo bản đặc tả yêu cầu phần
mềm với bản đặc tả đó.
Sự khác nhau của hai công việc trên chính là ở vai trò của bản đặc tả yêu cầu
phần mềm. Với xác nhận yêu cầu, bản đặc tả yêu cầu phần mềm được kiểm tra
xem có phản ánh chính xác các yêu cầu của những bên liên quan hay không. Còn

với kiểm chứng yêu cầu, bản đặc tả yêu cầu được dùng làm mẫu để đánh giá phần
mềm đang xây dựng có phù hợp hay không.

Phân tích yêu cầu phần mềm.

Page 12


IT4460

Nhóm 3

Các so sánh cụ thể:
Xác nhận yêu cầu

Kiểm chứng yêu cầu

(Requirements Validation)

(Requirements Verification)

Xác nhận yêu cầu là các thủ tục kiểm
tra động (thay đổi theo diễn biến của
dự án, tùy vào các bên liên quan), có
tác dụng để sửa chữa đặc tả yêu cầu

Kiểm chứng yêu cầu là các thủ tục
kiểm tra tĩnh (có các quy tắc cho sẵn
để áp dụng), có tác dụng ngăn ngừa
sự sai khác của phần mềm với đặc tả

Là quá trình mang tính chủ quan của Là quá trình mang tính khách quan,
các bên liên quan, phụ thuộc rất các tiêu chuẩn kĩ thuật được áp dụng
nhiều vào đánh giá của người dùng
để so sánh sản phẩm với đặc tả
Khi phát hiện lỗi, cần sửa chữa đặc Khi phát hiện lỗi, việc sửa chữa tốn
tả (chi phí thấp nếu chưa tạo ra sản ít chi phí
phẩm), nếu sản phẩm đã được tạo ra
thì chi phí khắc phục rất cao
1.2. Ảnh hưởng của Xác nhận yêu cầu (Requirements Validation)
Xác nhận yêu cầu là công việc quan trọng trong quá trình phân tích và đặc tả
yêu cầu phần mềm.
- Những ảnh hưởng của Xác nhận yêu cầu:
+ Việc xác nhận yêu cầu giúp cho các yêu cầu được đặc tả luôn phản ánh đúng
nguyện vọng của các bên liên quan. Các khách hàng, người dùng được cung cấp
bản chạy được của phần mềm và được dùng thử để xem đã đáp ứng được đúng yêu
cầu của mình chưa. Nếu có bất cứ phát hiện nào, các lỗi đó sẽ được thông báo cho
người phát triển để chỉnh sửa. Việc này đảm bảo khi sản phẩm được tạo ra sẽ đáp
ứng đúng yêu cầu người dùng, và được chấp nhận.
+ Việc xác nhận yêu cầu tạo ra sự nhất trí, tin tưởng giữa các bên liên quan, tạo
định hướng thống nhất cho giai đoạn thiết kế, viết mã nguồn hệ thống.
+ Lỗi của quá trình Xác nhận yêu cầu phát hiện ra dẫn đến sự thay đổi của bản
đặc tả yêu cầu phần mềm, dẫn đến một loạt phản ứng dây chuyền, làm thay đổi từ
khâu phân tích thiết kế tới viết mã nguồn.
Phân tích yêu cầu phần mềm.

Page 13


IT4460

Nhóm 3

1.3. Ảnh hưởng của Kiểm chứng yêu cầu (Requirements Verification)
Kiểm chứng yêu cầu phần mềm được tiến hành thiết kế và lập trình sản phẩm
phần mềm
- Những ảnh hưởng của Kiểm chứng yêu cầu:
+ Kiểm chứng yêu cầu giúp phần mềm được tạo ra đúng với đặc tả của yêu cầu
phần mềm. Nếu phát hiện ra lỗi, những nhà phát triển phần mềm sẽ được thông
báo để sửa chữa, do đó đảm bảo rằng khi phần mềm được hoàn thành thì nó sẽ phù
hợp với các đặc tả yêu cầu.
+ Việc kiểm chứng yêu cầu giúp rà soát lỗi của những người thiết kế, lập trình,
qua đó nâng cao ý thức làm việc cẩn trọng, nghiêm túc của đội ngũ phát triển phần
mềm
+ Trong giai đoạn thiết kế, Kiểm chứng yêu cầu giúp điều chỉnh những bản
thiết kế hệ thống một cách chính xác, tối ưu. Các lỗi tạo ra được điều chỉnh trước
khi giao cho đội ngũ lập trình, làm giảm đáng kể chi phí sửa lỗi.
+ Trong giai đoạn cài đặt, Kiểm chứng yêu cầu giúp điều chỉnh những lỗi lập
trình ngay từ các mức thấp, làm giảm chi phí sửa lỗi bởi tránh được việc lan truyền
lỗi.
+ Các lỗi được phát hiện của Kiểm chứng yêu cầu thường không gây phản ứng
dây chuyền, chỉ dẫn đến việc sửa đổi một hoặc một số module của hệ thống.

Phân tích yêu cầu phần mềm.

Page 14


IT4460

Nhóm 3

2. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Simple Check
2.1. Quy trình thực hiện
• Người kiểm duyệt, kiểm soát yêu cầu phải có các kiến thức từ trước (các
phản hồi từ khách hàng )
• Quan sát xem có những cái gì sai lệch trong hệ thống hiện tại.
• Mô hình hóa : Mô tả và giải thích vấn đề
• Phân tích và kiểm tra các đặc tính của mô hình
2.2. Thời gian thực hiện
Kỹ thuật simple check là kỹ thuật kiểm tra sự khác nhau bằng cách truy xuất
nguồn gốc của yêu cầu vì vậy kỹ thuật simple check được thực hiện trong mọi giai
đoạn phát triển của phần mềm.
2.3. Tác nhân tham gia
• Lập trình viên
• Bộ phận kiểm thử
• Nhà quản lý dự án
3. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm prototyping

Kỹ thuật Prototyping là một kỹ thuật xây dựng một kiến trúc được cài đặt cụ thể
trước để các khách hàng, người dùng hoặc nhà phát triển có thể hiểu rõ thêm về
một vấn đề hay giải pháp của nó.
Các hướng tiếp cận của Prototyping:
• Bản mẫu trình diễn: Dùng để chứng minh các khái niệm, giải thích các đặc
tính thiết kế.
• Bản mẫu thăm dò : dùng để xác định vấn đề, thu thập nhu cầu, làm rõ mục
tiêu, so sánh các lựa chọn thiết kế
• Bản mẫu thử nghiệm : khai thác các đặc tính kỹ thuật, kiểm tra sự thích hợp
của một kỹ thuật
Phân tích yêu cầu phần mềm.

Page 15


IT4460

Nhóm 3

• Bản mẫu tiến triển : được phát triển khi thấy tiến trình tiếp diễn sẽ tương
thích với hệ thống.
3.1. Quy trình thực hiện
• Lựa chọn các nguyên mẫu để thử nghiệm
• Sau khi đã lựa chọn được các nguyên mẫu để thử nghiệm thì xây dựng các
kịch bản thử nghiệm.
• Cần phải có một kế hoạch cụ thể để xây dựng các kịch bản thử nghiệm sao
cho bao quát toàn bộ các yêu cầu phần mềm
3.2. Thời gian thực hiện
Kỹ thuật prototyping để trợ giúp cho việc xác định yêu cầu phần mềm nên được
thực hiện đồng thời với quá trình xác định yêu cầu phần mềm
3.3 Tác nhân tham gia
• Lập trình viên
• Bộ phần kiểm thử
• Nhà quản lý dự án

Phân tích yêu cầu phần mềm.

Page 16


IT4460

Nhóm 3

4. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Functional test design
4.1. Quy trình thực hiện.
 Xác định các chức năng mà phần mềm dự kiến sẽ thực hiện
 Tạo ra các dữ liệu đầu vào dựa trên thông số kỹ thuật của chức năng
 Xác định đầu ra dựa trên thông số kỹ thuật của chức năng
 Thực hiện các trường hợp thử nghiệm
 So sánh các kết quả đầu ra thực tế và dự kiến
 Kiểm tra xem các ứng dụng làm việc theo nhu cầu của khách hàng
4.2.

Thời gian thực hiện.

Functional test design là một cách tiếp cận kiểm tra, trong đó trường hợp thử
nghiệm, điều kiện và dữ liệu có nguồn gốc từ các yêu cầu. Nó bao gồm các
bài kiểm tra chức năng và cũng thuộc tính không có chức năng như hiệu
suất, độ tin cậy hoặc khả năng sử dụng.
Thử ngiệm chức năng (functional testing) còn gọi là thử nghiệm hộp đen
(black box testing) là sự thử nghiệm sử dụng các ca thử nghiệm được thiết
kế dựa trên đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát hiện ra
các khiếm khuyết. Thử nghiệm chức năng nhìn nhận mô đun được thử
nghiệm như là một hộp đen, và chỉ quan tâm đến chức năng (hành vi) của
mô đun, tức là kiểm tra xem có hoạt động đúng với đặc tả hay không. Các
ca kiểm thử bao gồm các trường hợp bình thường và không bình thường (dữ
liệu không hợp lệ...) của mô đun. Thông thường, không thể thử nghiệm với
mọi dữ liệu, chiến lược chung khi thiết kế dữ liệu thử nghiệm là phân hoạch
(dữ liệu) tương đương. Phân hoạch tương đương chia miền dữ liệu vào ra
thành các vùng, mà mỗi vùng chứa các dữ liệu có cùng hành vi. Do đó, đối

với mỗi vùng dữ liệu chỉ cần xây dựng một ca thử nghiệm. Thêm vào đó là
các ca sử dụng đối với biên giới của các vùng. Theo kinh nghiệm, các sai sót
về lập trình thường sảy ra đối với các dữ liệu biên.
Kiểm tra chức năng ở cấp độ hệ thống phải được phát triển sớm hay muộn ?
- Có thể (và nên) được bắt nguồn từ đặc tả yêu cầu - Mỗi (chức năng) yêu
cầu cần phải có một thử nghiệm liên quan
- Không chức năng (ví dụ, độ tin cậy) hoặc độc quyền (ví dụ, xác định
Phân tích yêu cầu phần mềm.

Page 17


IT4460

Nhóm 3

những gì nên không xảy ra) yêu cầu là khó khăn hơn để xác nhận với các
thử nghiệm
- Mỗi trường hợp yêu cầu kiểm tra phải được bắt nguồn từ yêu cầu của nó Phát minh ra các yêu cầu kiểm tra là một kỹ thuật xác nhận hiệu quả
Thiết kế các xét nghiệm này có thể phát hiện sai sót trong đặc điểm kỹ thuật
(ngay cả trước khi thiết kế và xây dựng hệ thống)!
- Thiếu thông tin hoặc không rõ ràng trong bản mô tả yêu cầu có thể làm
cho nó khó khăn để xây dựng các bài kiểm tra
• Một số quy trình phát triển phần mềm (ví dụ như phương pháp nhanh
nhẹn) bắt đầu với các bài kiểm thử trước khi trình phát triển phần mềm.(lập
trình).
4.3. Tác nhân tham gia.
 Khách hàng
 Bộ phận lập trình
 Bộ phận kiểm thử

 Người quản lí dự án.
Công cụ điển hình
 Dialog map
 Test case
 Ma trận theo dõi các trường hợp sử dụng

4.4.

Phân tích yêu cầu phần mềm.

Page 18


IT4460

Nhóm 3

5. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm User manual
Development.
5.1. Quy trình thực hiện
• Làm thế nào để cài đặt và bắt đầu với hệ thống
• Mô tả các chức năng và làm thế nào nó được thực hiện
• Làm thế nào để có được ra khỏi rắc rối
• Những bộ phận của hệ thống đã không được thực hiện
5.2. Thời gian thực hiện
• Giống như thiết kế thử nghiệm chức năng
• Có phải được thực hiện tại một số điểm
• Tiết lộ các vấn đề trước đó
• Buộc một cái nhìn chi tiết yêu cầu
• Đặc biệt hữu ích nếu các ứng dụng giàu giao diện người dùng / cho các yêu

cầu khả năng sử dụng
Phác thảo sổ tay người dùng ngay từ sớm trong quy trình phát triển yêu cầu và
dùng nó như là tài liệu đặc tả yêu cầu hoặc như một trợ giúp cho phân tích yêu cầu.
Một tài liệu sổ tay người dùng tốt sẽ mô tả tất cả các chức năng mà người dùng
thấy được (user – visible functionality) bằng một ngôn ngữ dễ hiểu. Các yêu cầu
khác như các thuộc tính chất lượng, yêu cầu hiệu suất, chức năng không thấy được
đối với người dùng (not visible to users) sẽ được tài liệu hoá trong SRS.
5.3.

Tác nhân tham gia
• Các PTV
• Các đại diện của NSD (Product champions)
• Tất cả các thành viên của công ty phần mềm sẽ tham gia vào quá trình
thực hiện phần mềm:LTV, các nhà kiểm thử, v.v

Công cụ điển hình
• Một số phần mềm soạn thảo văn bản
• Phần mềm đồ họa.
• Một số mẫu hướng dẫn sử dụng có sẵn.
5.4.

6. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Reviews and Inspections
Một nhóm các kỹ sư phần mềm, kỹ sư hệ thống và người có kinh nghiệm trong
Phân tích yêu cầu phần mềm.

Page 19


IT4460

Nhóm 3

lĩnh vực yêu cầu phần mềm sẽ cùng đọc và phân tích các yêu cầu, tìm ra các vấn đề
tiềm tàng để thảo luận, và thống nhất với nhau các công việc cần làm để giải quyết
những vấn đề đó.
Đây là một kỹ thuật kiểm chứng yêu cầu được sử dụng rộng rãi. Có rất nhiều bằng
chứng về tính hiệu quả của kỹ thuật này.
Kỹ thuật này có thể rất tốn kém:
•
•
•

Cần chuẩn bị và lên kế hoạch cẩn thận
Cần kiểm tra trước khi duyệt
Cần một danh sách kiểm duyệt phù hợp

Một số kỹ thuật kiểm duyệt và kiểm soát yêu cầu phần mềm:
Phân theo hình thức
1.
2.
3.
4.

5.
6.

6.1.

1.

Đọc văn bản yêu cầu phần mềm: Yêu cầu một người không là tác giả
của văn bản yêu cầu phần mềm đó đọc và kiểm duyệt.
Đọc và phê duyệt: Khuyến khích người kiểm duyệt đọc cẩn thận hơn
và có trách nhiệm hơn.
Đọc lướt: Đây là kỹ thuật không chính thức, ở mức tổng quát cao, đọc
để có cái nhìn tổng quát về văn bản yêu cầu. Kỹ thuật này có thể cần
phải được dẫn dắt bởi tác giả văn bản/chuyên gia.
Kỹ thuật kiểm duyệt chính thức (Formal Inspections): kiểm duyệt một
cách chi tiết, cụ thể và có cấu trúc. Xác định rõ ràng vai trò của những
người tham gia kiểm duyệt cũng như xác dịnh rõ điều kiện để kết thúc
việc kiểm duyệt.
Kiểm duyệt tập trung: Các chuyên viên kiểm duyệt có vai trò xác
định, mỗi chuyên viên chỉ tìm kiếm một số lỗi nhất định trong yêu cầu
phần mềm.
Kiểm duyệt tích cực: Tác giả văn bản sẽ hỏi trực tiếp các chuyên viên
kiểm duyệt các câu hỏi liên quan đến văn bản.

Quy trình thực hiện
Plan review.
Đội kiểm duyệt được lựa chọn, thời gian, địa điểm gặp mặt cũng được

Phân tích yêu cầu phần mềm.

Page 20


IT4460

Nhóm 3
ấn định.

2.

Phân phát tài liệu liên quan
Văn bản yêu cầu phần mềm được phân phát cho các thành viên đội
kiểm duyệt.

3.

Chuẩn bị cho việc kiểm duyệt các yêu cầu
Mỗi thành chuyên viên kiểm duyệt đọc các yêu cầu để tìm ra các xung
đột, thiếu sót, mâu thuẫn, lệch chuẩn và các vấn đề khác

4.

Tổ chức gặp mặt
Các vấn đề và nhận xét của mỗi cá nhân về văn bản yêu cầu phần mềm
sẽ được đưa ra thảo luận, và các việc cần làm để giải quyết các vấn đề
sẽ được đưa ra.

5.

Thực hiện các việc cần làm (kết quả của bước 4)
Giải quyết các vấn đề bằng cách tuân thủ thực hiện các hành động đã
thống nhất ở bước 4.

6.

Duyệt lại văn bản.
Văn bản yêu cầu phần mềm được duyệt lại để kiểm chứng sự hợp lý

của các hành động đã thống nhất. Kết quả của bước này, hoặc là văn
bản cuối cùng được chấp nhận, hoặc là cần được kiểm duyệt lại.

Đôi khi, để giảm thiểu chi phí của quá trình kiểm duyệt yêu cầu, cần phải thực hiện
bước "pre-review checking". Nghĩa là kiểm tra văn bản và tìm kiếm các vấn đề
trực tiếp, như là thiếu yêu cầu phần mềm, thiếu tuân thủ theo chuẩn, …

6.2.

Thời gian thực hiện

Có thể áp dụng khi mới xây dựng xong bước đầu các yêu cầu phần mềm từ các
biện pháp thu thập. Khi đó, các vấn đề vẫn còn tồn tại trong các yêu cầu phần
mềm. Và cần phải loại bỏ các vấn đề này trước khi đem văn bản yêu cầu đi
thương thảo.
Áp dụng khi cần xác minh rằng các yêu cầu mình viết ra sẽ thỏa mãn các bên
Phân tích yêu cầu phần mềm.

Page 21


IT4460

Nhóm 3

liên quan. Hay nói cách khác, tìm sự đồng thuận từ phía khác hàng.
6.3.

•
•

•

Tác nhân tham gia
Những người đến từ những lĩnh vực khác nhau sẽ mang đến những kỹ
năng và kiến thức khác nhau để kiểm duyệt các yêu cầu phần mềm
Họ sẽ cảm thấy được tham gia và có vai trò trong quá trình xây dựng yêu
cầu phần mềm, và họ sẽ hiểu hơn về nhu cầu/yêu cầu của các bên còn lại.
Nhóm kiểm duyệt luôn luôn có ít nhất một bên chuyên gia, một bên người
dùng.

Các vấn đề khi kiểm duyệt:
•
•
•
•
•

Tính rõ ràng của yêu cầu: Các yêu cầu được diễn tả một cách "tệ", khó
hiểu, hoặc có thể vô tình bỏ qua thông tin nào đó đã được thu thập trong
suốt quá trình xác định yêu cầu.
Thiếu thông tin: Một số thông tin trong văn bản yêu cầu phần mềm bị
thiếu.
Xung đột yêu cầu: Có xung đột nghiêm trọng giữa các yêu cầu (các yêu
cầu phủ định nhau). Các bên liên quan cần thương lượng để giải quyết
xung đột.
Các yêu cầu không thực tế: Các yêu cầu có vẻ như không thể thực hiện
được (unimplementable) với trình độ công nghệ hiện tại, hoặc với ràng
buộc nào đó trong hệ thống.
Các bên liên quan trong tình huống này cần bàn bạc để quyết định làm
cho yêu cầu đó trở nên thực tế hơn.

Phân tích yêu cầu phần mềm.

Page 22


IT4460

Nhóm 3

7. Kỹ thuật Fagan Inspection.
Fagan Inspection được đặc trưng bởi các quy định ai sẽ tham gia, bao nhiêu người
kiểm duyệt sẽ tham gia và mỗi người có vai trò gì trong kiểm duyệt.
Mỗi lần họp bàn không quá 2 tiếng. Chỉ cần khoảng đó thời gian các thành viên
tham gia kiểm duyệt tập trung vào công việc.
Cần 3 - 5 người kiểm duyệt.
Tác giả văn bản yêu cầu phần mềm sẽ đóng vai trò như người trình diễn văn bản.
Các số liệu được thu thập. Điều quan trọng là các số liệu này tác giả văn bản yêu
cầu phần mềm không được biết đến. Người đó chỉ như là một người giám sát suốt
quá trình kiểm duyệt.
Có một người chịu trách nhiệm điều tiết buổi họp bàn, bắt đầu việc kiểm duyệt,
dẫn dắt buổi gặp và đảm bảo các vấn đề được tìm thấy phải được sửa chữa.
Tất cả các người kiểm duyệt cần tự chuẩn bị trước bằng cách sử dụng danh sách
kiểm duyệt (checklists).
Các vấn đề được ghi lại theo khuôn dạng đặc biệt.
Fagan Inspection giống như "brain storming" trong phát hiện yêu cầu phần mềm.
Nó là một phiên động não để phát hiện các vấn đề trong yêu cầu phần mềm.
Cần kiểm duyệt lại nếu nhiều hơn 5% văn bản yêu cầu phải thay đổi. (bởi việc sửa
chữa 1 lỗi nào đó, lại phát sinh một lỗi mới. Sửa càng nhiều, càng dễ sinh ra lỗi
mới).

Phân tích yêu cầu phần mềm.

Page 23


IT4460

Phân tích yêu cầu phần mềm.

Nhóm 3

Page 24