Chương 4 Phân tích yêu cầu
4.1 Phân tích yêu cầu
Phân tích yêu cầu là nhiệm vụ của kĩ nghệ phần mềm nhằm đạt được mục tiêu quan trọng là bắc cầu qua lỗ hổng giữa việc phân bổ phần mềm mức hệ thống với thiết kế phần mềm (Hình 4.1).
Phân tích các yêu cầu cho một phần mềm giúp cho người thiết kế hệ thống có thể xác định được chức năng và hiệu suất phần mềm, chỉ ra giao diện của phần mềm với các phần tử hệ thống khác, và thiết lập những ràng buộc thiết kế mà phần mềm phải đáp ứng. Việc phân tích yêu cầu cho phép người kĩ sư phần mềm (thường được gọi là người phân tích trong vai trò này) tinh chế lại việc phân bổ phần mềm và xây dựng mô hình tiến trình, dữ liệu, và các lĩnh vực hành vi sẽ được phần mềm xử lí. Việc phân tích yêu cầu cung cấp cho người thiết kế hệ thống phần mềm một cách biểu diễn thông tin và chức năng có thể được dịch thành thiết kế dữ liệu, kiến trúc và thủ tục. Sản phẩm cuối của pha phân tích yêu cầu là các bản đặc tả yêu cầu. Các bản này cung cấp cho người phát triển và khách hàng các phương tiện để xác quyết về chất lượng một khi phần mềm đã được xây dựng.
Việc phân tích các yêu cầu phần mềm có thể được chia thành năm lĩnh vực đòi hỏi những tri thức, kinh nghiệm và nỗ lực của các phân tích viên hệ thống.
Đó là:
(1) nhận thức vấn đề, (2) đánh giá và tổng hợp, (3) mô hình hoá,
(4) đặc tả, và (5) kiểm điểm.
Tại bước đầu tiên, người phân tích nghiên cứu bản Đặc tả hệ thống (nếu có) và bản Kế hoạch dự án phần mềm. Điều quan trọng là hiểu phần mềm trong khung cảnh hệ thống và tìm hiểu phạm vi phần mềm được dùng để sinh ra các ước lượng lập kế hoạch. Tiếp đó, cần phải thiếp lập điều kiện và môi trường trao đổi cho phân tích viên để có thể đảm bảo rằng họ nhận thức đúng về vấn đề. Mục tiêu tại bước này là phân tích viên nhận thức chính xác và rõ ràng các phần tử cơ sở và các vấn đề cơ bản đúng như khách hàng/người dùng cảm nhận và kì vọng.
Việc đánh giá vấn đề và tổng hợp giải pháp là lĩnh vực chính tiếp theo của hoạt động phân tích. Phân tích viên phải định nghĩa mọi sự vật, dữ liệu quan sát được từ bên ngoài, đánh giá luồng và nội dung thông tin, xác định và soạn thảo, mô tả tường minh mọi chức năng phần mềm, hiểu hành vi phần mềm theo hoàn cảnh của các biến cố ảnh hưởng tới hệ thống, thiết lập các đặc trưng giao diện, và làm lộ ra những ràng buộc thiết kế phụ. Mỗi một trong các nhiệm vụ này đều phục vụ cho việc mô tả vấn đề sao cho có thể hình thành được cách tiếp cận hay giải pháp tổng thể.
Thí dụ
Kĩ nghệ hệ
thống Phân tích yêu cầu phần mềm
Thiết kế phần mềm
Hình 4.1 Phân tích yêu cầu là cầu nối giữa kĩ nghệ hệ thống và thiết kế phần mềm
lí kho. Người phân tích thấy rằng các vấn đề với hệ thống thủ công hiện tại bao gồm (1) không có khả năng lấy được thông tin về trạng thái của các phụ tùng một cách nhanh chóng; (2) phải mất đến hai hay ba ngày mới cập nhật được thẻ kho; (3) có nhiều tình huống đặt hàng lại với cùng một nhà cung cấp bởi vì không có cách nào liên kết nhà cung cấp với phụ tùng.
Một khi những vấn đề trên đã được làm rõ thì người phân tích sẽ xác định hệ thống mới cần phải tạo ra thông tin nào và dữ liệu nào cần được cung cấp cho hệ thống. Chẳng hạn, khách hàng muốn có báo cáo hàng ngày trong đó chỉ rõ phụ tùng nào đã đưa ra khỏi kho và bao nhiêu phụ tùng cùng loại hiện còn lại trong kho. Khách hàng yêu cầu rằng người coi kho sẽ vào sổ số hiệu của từng phụ tùng mỗi khi xuất chúng ra khỏi khu vực kho.
Một khi đánh giá được các vấn đề hiện tại và thông tin mong muốn (cái vào và cái ra), người phân tích bắt đầu tổng hợp một hay nhiều giải pháp. Một hệ thống trực tuyến với một thiết bị cuối đặt tại kho hàng sẽ có thể giải quyết được một loạt vấn đề. Nhưng liệu giải pháp này có trụ được trong phạm vi đã được vạch đại cương trong bản kế hoạch phần mềm hay không? Dường như hệ thống cần tới một hệ quản trị cơ sở dữ liệu. Nhưng khi đó ta có thể biện minh thế nào về mối liên hệ giữa cơ sở dữ liệu với nhu cầu của khách hàng? Tiến trình ước lượng và tổng hợp vẫn tiếp tục cho tới khi cả người phân tích lẫn khách hàng đều cảm thấy tin rằng phần mềm có thể được xác định thích hợp cho các bước phát triển kế tiếp.
Thông qua ước lượng và tổng hợp giải pháp, sự tập trung chủ yếu của người phân tích là vào “đó là cái gì?”, chứ không phải “làm nó ra sao?” Hệ thống tạo ra và sử dụng dữ liệu nào, hệ thống phải thực hiện chức năng nào, giao diện nào cần xác định, và hệ thống nằm trong các ràng buộc nào?
Trong hoạt động đánh giá và tổng hợp giải pháp, người phân tích tạo ra các mô hình hệ thống với một nỗ lực hiểu rõ hơn luồng dữ liệu và điều khiển, xử lí chức năng, thao tác hành vi và nội dung thông tin. Mô hình này được lấy làm nền tảng cho việc thiết kế phần mềm và là cơ sở cho việc tạo ra một bản đặc tả phần mềm.
Chúng ta đã lưu ý rằng không thể có ngay được đặc tả chi tiết tại giai đoạn đầu. Khách hàng có thể không chắc chắn chính xác là mình cần gì. Người phát triển có thể cũng không chắc rằng một cách tiếp cận cụ thể có thực hiện đúng chức năng và hiệu suất mong muốn hay không. Vì những lí do đó, và nhiều lí do khác nữa, có thể tiến hành một cách tiếp cận khác tới việc phân tích yêu cầu, còn gọi là làm bản mẫu.
Để thống nhất được các nhiệm vụ liên quan tới phân tích và đặc tả hệ thống nhóm phát triển thường cố gắng cung cấp một công cụ và phương thức biểu diễn hệ thống để cho khách hàng có thể duyệt xét và chấp thuận. Trong một thế giới lí tưởng, chúng ta hi vọng khách hàng sẽ xây dựng bản Đặc tả yêu cầu phần mềm một cách đầy đủ, chính xác và hoàn thiện. Nhưng trong thế giới thực thì điều này hiếm khi xảy ra. Thường thì bản đặc tả được xây dựng với nỗ lực liên kết giữa người phát triển và khách hàng.
Một khi đã mô tả được về thông tin, chức năng, hiệu suất, hành vi và giao diện cơ sở cho hệ thống thì cần xác định các tiêu chuẩn hợp lệ để biểu diễn tường minh và thống nhất cách hiểu thế nào là một phần mềm thành công, tức là phần mềm đáp ứng được các yêu cầu của khách hàng. Những tiêu chuẩn này sẽ được dùng làm cơ sở cho các pha kiểm định thử xuất hiện trong tiến trình phát triển phần mềm. Một đặc tả yêu cầu hình thức cần được viết ra để xác định các đặc trưng và thuộc tính của phần mềm. Bên cạnh đó, cũng có thể soạn nháp “Tài liệu sơ lược cho người dùng” cho trường hợp bản mẫu còn chưa được xây dựng xong.
Điều dường như kì lạ là tài liệu người dùng lại được xây dựng sớm thế trong tiến trình kĩ nghệ phần mềm trong khi chúng ta vẫn còn xa mới đi đến việc lập trình. Trong thực tế, bản thảo về tài liệu người dùng buộc phân tích viên (người phát triển) phải xét theo quan điểm của người dùng phần mềm (đặc biệt quan trọng trong hệ thống tương tác). Tài liệu này thúc đẩy người dùng/khách hàng duyệt lại hệ thống theo góc độ kĩ nghệ con người. Thật vậy, chúng ta thường được nghe các ý kiến đại loại như: “Ý đồ thì được, nhưng đấy không phải là điều chúng tôi kì vọng.” Việc bộc lộ những lời bình luận như vậy càng sớm trong tiến trình phần mềm thì càng có lợi cho nhóm thiết kế và phát triển phần mềm.
Các tài liệu phân tích yêu cầu (bản đặc tả và tài liệu người dùng) được dùng làm cơ sở cho việc kiểm điểm của cả khách hàng và người phát triển. Phiên họp kiểm điểm yêu cầu hầu như bao giờ cũng làm nảy sinh việc sửa đổi chức năng, hiệu suất, biểu diễn thông tin, ràng buộc hay tiêu chuẩn hợp lệ. Bên cạnh đó, bản Kế hoạch dự án phần mềm là việc tái xác nhận liệu các ước lượng ban đầu có còn hợp lệ không khi đã có thêm hiểu biết thu được từ phần phân tích.
K I Ể M Đ I Ể M
Phiên họp của những người liên quan rà soát và biểu quyết thông qua từng chi tiết của một sản phẩm.