Xem mẫu
- ̀ ̣ ̀
Bai tâp tuân 3
̉ ̀ ́ ́
Giang viên: PGS.TS. Huynh Quyêt Thăng
Danh sách sinh viên:
Lê Trung Hiêú 20111568 CNTT-TT 2.3 K56
̀
Đam Văn Hoai ̀ 20111600 CNTT-TT 2.3 K56
Nguyên Đức Cương
̃ 20111203 CNTT-TT 2.3 K56
̀
Đoan Văn Đat ̣ 20111370 CNTT-TT 2.3 K56
1
- 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. Tính đúng đắn (correct) 6. Tính cần thiết (Necessary)
2. Tính hoàn chỉnh (complete) 7. Có độ ưu tiên (Prioritized)
3. Tính nhất quán (consistent) 8. Có thể truy viết (Traceable)
4. Tính khả thi (feasible) 9. Không nhập nhằng
(Unambiguous)
5. Tính có thể thay đổi
(Modifiable) 10. Kiểm tra được (Verifiable)
2
- 1. Tính đúng đắn (correct)
Mỗi yêu cầu cần mô tả chính xác chức năng được xây
dựng.
Tham chiếu đến nguồn của yêu cầu.
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 tinh nay để đam bao phần mềm đáp ứng đầy đủ các
̣ ́ ̀ ̉ ̉
đặc tả yêu cầu phần mềm.
3
- 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ếu yêu cầu phần mềm nào đó còn chưa rõ ràng sẽ
được đánh dấu là “TBD - To Be Determined”
Phải xác định được kết quả của các dữ liệu đầu vào.
Phải có đầy đủ nhãn và tài liệu tham khảo.
Đăc tinh nay để đam bao mỗi yêu cầu đã được mô tả
̣ ́ ̀ ̉ ̉
đầy đủ.
4
- 3. Tính nhất quán
(consistent)
Các yêu cầu phần mềm không xung đột nhau và xung đột
với yêu cầu mức cao hơn.
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.
Đăc tinh nay để đam bao đã giải quyết hết các xung đột
̣ ́ ̀ ̉ ̉
của các yêu cầu trước quá trình phát triển phần mềm.
5
- 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 của hệ thống
Cần phải đánh giá tính khả thi của một yêu cầu phần
mềm.
Đăc tinh nay để đam bao cac yêu câu được đưa ra có thể
̣ ́ ̀ ̉ ̉ ́ ̀
thực hiên được trong thực tế.
̣
6
- 5. Tính có thể thay đổi
(Modifiable)
Mỗi khi có sự thay đổi yêu cầu cần được thực hiên môt
̣ ̣
́ ́ ́ ́
cach nhanh chong, chinh xac.
Cần viết các yêu cầu thật rõ ràng, mạch lạc , gán nhãn
khác nhau cho mỗi yêu cầu.
Đăc tinh chât lượng nay để có thể tiêt kiêm thời gian, chi
̣ ́ ́ ̀ ́ ̣
phí cho quá trinh đam phan và quan lý yêu câu phân mêm.
̀ ̀ ́ ̉ ̀ ̀ ̀
7
- 6. Tính cần thiết (Necessary)
Mỗi yêu cầu đưa ra phải là thật sự cần thiết đối với
khách hàng hoặc các hệ thống liên quan.
Đăc tinh chât lượng nay để đam bao moi yêu câu được
̣ ́ ́ ̀ ̉ ̉ ̣ ̀
đưa ra trong SRS đêu cân thiêt cho dự an phân mêm.
̀ ̀ ́ ́ ̀ ̀
8
- 7. Có độ ưu tiên (Prioritized)
Mỗi yêu cầu cần gán một thứ tự ưu tiên.
Xác định đúng mức đầu tư cho mỗi yêu cầu.
Đăc tinh nay để đam bao 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 ->
đá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.
9
- 8. Có thể truy vết (Traceable)
Mỗi yêu cầu phần mềm cần được liên kết đến nguồn
phát sinh của nó, đến các phần tử thiết kế, mã nguồn.
Đăc tinh nay để 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 đó.
10
- 9. Không nhập nhằng
(Unambiguous)
Cần viết một yêu cầu rõ ràng, cụ thể, đơn nghĩa .
Để loại bỏ nhập nhằng mô tả yêu cầu bằng các ngôn
ngữ hình thức như use-case.
Đăc tinh nay để giúp cho SRS trình bày rõ ràng nhất,
̣ ́ ̀
tường minh nhất.
11
- 10. Kiểm tra được (Verifiable)
Cần phải kiểm tra được mỗi yêu cầu có được cài đặt
hợp lệ trong sản phẩm hay không.
Một yêu cầu không thể kiểm tra được sẽ trở thành vấn
đề gây tranh cãi.
Đăc tinh nay để 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.
12
- 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.
2. Làm nổi bật các yêu cầu bằng cấu trúc phân cấp.
3. Cố gắng viết các câu và đoạn ngắn - đơn giản (write concisely)
4. 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ệ
13
- II. Các Tips để viết đặc tả yêu
cầu phần mềm (tiếp)
5. Tránh các ràng buộc thiết kế (design constraints) không
cần thiết.
6. Viết các yêu cầu ở mức chi tiết hợp lý.
7. Viết các yêu cầu 1 cách chính xác, cụ thể, không mơ hồ
và gây nhầm lẫn.
14
- Cam ơn thây và cac ban
̉ ̀ ́ ̣
đã lăng nghe
́
15
nguon tai.lieu . vn
