Kiểm điểm đặc tả

Một phần của tài liệu Kiến trúc và thiết kế phần mềm (Trang 95 - 98)

Chương 4 Phân tích yêu cầu

4.8 Kiểm điểm đặc tả

Việc kiểm điểm bản Đặc tả yêu cầu phần mềm (và/hoặc bản mẫu) do cả hai bên, người phát triển phần mềm và khách hàng cùng tiến hành. Bởi vì đặc tả

phiên kiểm điểm.

Việc kiểm điểm trước hết được tiến hành ở mức vĩ mô. Tại mức này, người kiểm điểm cố gắng đảm bảo rằng bản đặc tả được đầy đủ, nhất quán và chính xác. Cần đề cập tới các câu hỏi sau:

- Các mục tiêu và mục đích đã được thiết lập cho phần mềm có nhất quán với mục tiêu và mục đích của hệ thống hay không?

- Những giao diện quan trọng với mọi phần tử hệ thống đã được mô tả chưa?

- Luồng và cấu trúc thông tin đã được mô tả thích hợp cho lĩnh vực vấn đề chưa?

- Các biểu đồ có rõ ràng không? Liệu mỗi biểu đồ có thể đứng riêng không đòi hỏi giải thích thêm không?

- Các chức năng chính có còn được giới hạn trong phạm vi và đã được mô tả thích hợp chưa?

- Liệu hành vi của phần mềm có nhất quán với thông tin nó phải xử lí và chức năng nó phải thực hiện hay không?

- Các ràng buộc thiết kế có hiện thực không?

- Rủi ro công nghệ phát triển là gì?

- Các yêu cầu phần mềm khác đã được xem xét đến chưa?

- Các tiêu chuẩn hợp lệ đã được phát biểu chi tiết chưa? Chúng có thích hợp để mô tả một hệ thống thành công không?

- Liệu có sự không nhất quán, bỏ sót hay dư thừa nào không?

- Việc tiếp xúc với khách hàng có đầy đủ không?

- Người dùng đã kiểm điểm bản Tài liệu sơ bộ của người dùng hay bản mẫu chưa?

- Các ước lượng về Kế hoạch dự án phần mềm bị ảnh hưởng thế nào?

Để đưa ra câu trả lời cho nhiều câu hỏi trên, việc kiểm điểm có thể tập trung vào mức chi tiết. Tại đây, mối quan tâm của chúng ta tập trung vào từ ngữ của bản đặc tả. Chúng ta cố gắng làm lộ ra vấn đề có thể ẩn náu bên trong nội dung đặc tả. Những hướng dẫn sau đây là gợi ý về việc kiểm điểm chi tiết bản đặc tả:

Phải quan sát các mối nối có sức thuyết phục (như “chắc chắn”, “do đó”, “rõ ràng”, “hiển nhiên”, “từ đó suy ra rằng”…) và hỏi “Tại sao chúng lại được sử dụng?”

Cẩn trọng với những thuật ngữ mông lung (như “một số,” “đôi khi,”

“thường,” “thông thường,” “bình thường,” “phần lớn,” “đa số”…) ; yêu cầu làm sáng tỏ ngữ nghĩa của các thuật ngữ này.

Khi đã nêu danh sách, nhưng không đầy đủ, thì phải đảm bảo mọi khoản mục đều được hiểu rõ. Chú ý vào các từ như “vân vân,” “cứ như thế,” “cứ tiếp tục như thế”, “sao cho”, …

Phải chắc chắn rằng phát biểu phạm vi không chứa những giả thiết không được nói rõ (như “mã hợp lệ trong khoảng 10 tới 100.” Đó là số nguyên, số thực hay số hệ 16?)

Phải nhận biết về các động từ mơ hồ như “xử lí”, “loại bỏ”, “nhảy qua”,

"bỏ qua", “xoá bỏ”…. Những từ này thường gợi ra nhiều cách hiểu.

Phải nhận biết các đại từ “vu vơ” (như “module vào/ra liên lạc với module kiểm tra tính hợp lệ dữ liệu và đặt cờ báo kiểm soát của nó.” Cờ kiểm soát của ai?).

Tìm các câu có chứa sự chắc chắn (như “bao giờ”, “mọi”, “tất cả”,

“không một”, “không bao giờ”) rồi yêu cầu bằng chứng.

Khi một thuật ngữ được định nghĩa tường minh tại một chỗ thì hãy thử thay thế định nghĩa này vào chỗ xuất hiện của nó.

Khi một cấu trúc được mô tả theo lời thì hãy vẽ ra bức tranh để có thể hiểu được nó.

Khi một tính toán được xác định thì hãy thử với ít nhất hai thí dụ.

Một khi việc kiểm điểm đã hoàn tất thì bản bản Đặc tả yêu cầu phần mềm sẽ được cả khách hàng lẫn người phát triển kí xác nhận. Bản đặc tả trở thành một

“hợp đồng” cho việc phát triển phần mềm. Những thay đổi trong yêu cầu được nêu ra sau khi bản đặc tả đã hoàn thành sẽ không bị huỷ bỏ. Nhưng khách hàng phải lưu ý rằng từng thay đổi sau khi kí đều là một mở rộng của phạm vi phần mềm và do đó có thể làm tăng thêm chi phí và / hoặc kéo dài lịch biểu.

Ngay cả với những thủ tục kiểm điểm tại chỗ tốt nhất thì một số vấn đề đặc tả thông thường vẫn còn lại. Bản đặc tả rất khó “kiểm thử” theo mọi phương cách thông thường, và do đó sự không nhất quán hay bỏ sót có thể bị bỏ qua, không để ý tới. Trong khi kiểm điểm, người ta có thể khuyến cáo những thay đổi cho bản đặc tả. Có thể sẽ cực kì khó khăn để lượng định tác động toàn cục của

yêu cầu cho chức năng khác? Người ta đã phát triển các công cụ đặc tả tự động hoá để giúp giải quyết vấn đề này.

Một phần của tài liệu Kiến trúc và thiết kế phần mềm (Trang 95 - 98)

Tải bản đầy đủ (PDF)

(221 trang)