Báo cáo bài tập tuần 3 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 tuần 3

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