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


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



- Để 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í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ó.

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


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

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