Đăng ký Đăng nhập
Trang chủ 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...

Tài liệu 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

.PDF
7
539
91

Mô tả:

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
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 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.............. 3 1.1. Tính đúng đắn (correct) .......................................................................... 3 1.2. Tính hoàn chỉnh (complete) .................................................................... 3 1.3. Tính nhất quán (consistent)..................................................................... 4 1.4. Tính khả thi (Feasible) ............................................................................ 4 1.5. Tính có thể thay đổi (Modifiable) ........................................................... 5 1.6. Tính cần thiết (Necessary) ...................................................................... 5 1.7. Có độ ưu tiên (Prioritized) ...................................................................... 6 1.8. Có thể truy vết (Traceable) ..................................................................... 6 1.9. Không nhập nhằng (Unambiguous). ....................................................... 7 1.10. Kiểm tra được (Verifiable) ..................................................................... 7 II. Các Tips để viết đặc tả yêu cầu phần mềm, sử dụng tiếng Việt. ..................... 8 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. - 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ả Phân tích yêu cầu phần mềm. Page 3 IT4460 Nhóm 3 đầ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 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 Phân tích yêu cầu phần mềm. Page 4 IT4460 Nhóm 3 đề 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 đó. 1.6. 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ự Phân tích yêu cầu phần mềm. Page 5 IT4460 Nhóm 3 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ử 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 Phân tích yêu cầu phần mềm. Page 6 IT4460 Nhóm 3 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ôngphả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 đó đã đượ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ở Phân tích yêu cầu phần mềm. Page 7
- Xem thêm -

Tài liệu liên quan