Slide Báo cáo bài tập tuần 3: Phân tích yêu cầu phần mềm

Chia sẻ: Cau Be | Ngày: | Loại File: PPT | Số trang:15

Thêm vào BST

Báo xấu

163
lượt xem 24
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Slide Báo cáo bài tập tuần 3: Phân tích yêu cầu phần mềm có kết cấu nội dung giới thiệu đến các bạn một số nội dung chính về mười đặc tính chất lượng của một bản đặc tả yêu cầu phần mềm tốt, các Tips để viết đặc tả yêu cầu phần mềm, sử dụng tiếng Việt được trình bày dưới dạng slide giúp các bạn dễ dàng nằm bắt nội dung.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Slide Báo cáo bài tập tuần 3: Phân tích yêu cầu phần mềm

̀ ̣ ̀ 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êú 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à có 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 có 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 để có thể tiêt kiêm thời gian, chi ̣ ́ ́ ̀ ́ ̣ phí cho quá trinh đam phan và quan lý 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 và cac ban ̉ ̀ ́ ̣ đã lăng nghe ́ 15