Báo cáo bài tập tuần 3: Phân tích yêu cầu phần mềm

Báo cáo bài tập tuần 3: Phân tí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 tính chất lượng của một bản đặc tả 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. Mời các bạn cùng tham khảo.
Nội dung trích xuất từ tài liệu:
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 tich yêu câu phân mêm ́ ̀ ̀ ̀ Giảng viên: PGS.TS. Huynh Quyêt Thăng ̀ ́ ́ Danh sách sinh viên: (nhóm 3 ) ́ 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 Hà Nội – 4/2014 M ụ c lụ cPhân tích yêu cầu phần mềm. Page 2 I. Mười đăc tinh chât lượng cua môt ban đă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 tinh nay để đam bao 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. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để đam bao mỗi yêu cầu đã được mô ̣ ́ ̀ ̉ ̉Phân tích yêu cầu phần mềm. Page 3 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 tinh nay để đam bao 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ó tinh 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ề tai chinh, về tai ̣ ̀ ̀ ́ ̀ nguyên phân cứng, phân mêm, hoăc về độ phức tap tinh toan). ̀ ̀ ̀ ̣ ̣ ́ ́ - Để 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 ban hang 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 ...