1 - Mục tiêu và yêu cầu của phần mềm:
Yêu cầu của phần mềm là tất cả các yêu cầu về phần mềm do người dùng nêu ra bao gồm các chức năng của phần mềm, hiệu năng của phần mềm, giao diện của phần mềm và một số các yêu cầu khác
Thông thường các yêu cầu phần mềm được phân loại dựa trên 4 thành phần của phần mềm như sau:
Mục tiêu quan trọng nhất đối với chất lượng phần mềm là phần mềm phải thỏa mãn được các yêu cầu và mong muốn của người dùng. Người dùng thường chỉ đưa ra những ý tưởng, nhiều khi rất mơ hồ về phần mềm mà họ mong muốn xây dựng. Và việc của các kỹ sư phát triển phần mềm đó là phải giúp họ đưa những ý tưởng mơ hồ đó thành hiện thực và xây dựng được một phần mềm có đầy đủ các tính năng cần thiết thỏa mãn yêu cầu của người dùng. Hơn thế nữa, ý tưởng của người dùng thường xuyên thay đổi và việc của nhà phát triển là phải nắm bắt và đáp ứng được các yêu cầu thay đổi đó một cách hợp lý.
2 - Những khó khăn trong việc phân tích, nắm bắt yêu cầu:
2.1 - Những vấn đề từ phía người dùng:
2.2 - Những vấn đề từ phía nhà phát triển:
2.3 - Những vấn đề khác:
3 - Các giai đoạn trong phân tích yêu cầu:
Mục đích của giai đoạn phân tích là xác định rõ các yêu cầu của phần mềm cần phát triển. Tài liệu mô tả yêu cầu phải vừa dễ hiểu với người dùng vừa chặt chẽ để làm cơ sở cho việc lập kế hoạch. Do đó yêu cầu thường được mô tả ở nhiều mức chi tiết khác nhau, nhiều giai đoạn khác nhau. Cụ thể như sau:
3.1 - Tìm hiểu các yêu cầu của phần mềm:
Các phương pháp để tìm hiểu các yêu cầu của phần mềm bao gồm:
3.2 - Phân tích yêu cầu và thương lượng:
Sau khi tìm hiểu được các yêu cầu của phần mềm, chúng ta cần:
3.3 - Mô hình hóa yêu cầu:
Một số phương pháp hay dùng để mô hình hóa yêu cầu đó là:
a - Biểu đồ luồng dữ liệu Biểu đồ luồng dữ liệu (Data Flow Diagram - DFD) là một kỹ thuật để biểu diễn luồng thông tin vào ra của một chức năng trong hệ thống
Các thành phần biểu đồ luồng dữ liệu bao gồm:
Biểu đồ luồng dữ liệu có thể được dùng để biểu diễn cho một hệ thống hay phần mềm ở bất kì mức nào, từ tổng quát cho đến chi tiết. Trong thực tế, DFD có thể được phân chia thành nhiều mức biểu diễn. Sau đây là minh họa một DFD cho hệ thống bán vé tầu.
b - Biểu đồ thực thể quan hệ
Mô hình quan hệ - thực thể ER (Entity Relationship Model) được sử dụng để thiết kế cơ sở dữ liệu ở mức khái niệm. Mô hình này được sử dụng như một công cụ để trao đổi ý tưởng giữa nhà thiết kế và người dùng cuối trong giai đoạn phân tích
Mô hình quan hệ - thực thể bao gồm ba phần tử cơ bản:
Sau đây là một ví dụ cho mô hình quan hệ - thực thể
3.4 - Đặc tả yêu cầu:
a - Phân loại yêu cầu: Yêu cầu được chia thành nhiều loại:
b - Đặc tả yêu cầu: Nếu như tài liệu xác định yêu cầu được viết bởi ngôn ngữ tự nhiên của khách hàng thì tài liệu đặc tả yêu cầu phải rất rõ ràng và được xây dựng theo hướng của người phát triển, tránh gây hiểu nhầm giữa khách hàng và người phát triển.
Có các phương pháp đặc tả như sau:
Chất lượng cả bản đặc tả yêu cầu được đánh giá qua các tiêu chí sau:
c - Thẩm định yêu cầu: Sau khi các yêu cầu được xây dựng thì chúng cần được thẩm định xem đã thỏa mãn nhu cầu của khách hàng hay chưa. Nếu việc thẩm định không được thực hiện một cách nghiêm túc, chặt chẽ thì các sai sót sẽ có thể gây ra những hậu quả lớn cho các giai đoạn về sau.
Mục tiêu của việc thẩm định là xác định xem yêu cầu có thỏa mãn 4 yếu tố sau không:
d - Xây dựng bản mẫu:
Đối với các hệ thống phức tạp, nhiều khi chúng ta không nắm chắc được yêu cầu của khách hàng, chúng ta cũng khó đánh giá được tính khả thi cũng như hiệu quả của hệ thống. Một giải pháp được đưa ra là xây dựng bản mẫu. Bản mẫu vừa được dùng để phân tích yêu cầu vừa có thể tiến hóa thành sản phẩm cuối cùng. Bản mẫu phần mềm không phải nhằm vào việc thẩm định thiết kế (thiết kế của nó thường là hoàn toàn khác với hệ thống được phát triển cuối cùng), mà là để thẩm định yêu cầu của người sử dụng.
3.5 - Định dạng đặc tả yêu cầu:
Kết quả của bước phân tích là tạo ra bản đặc tả yêu cầu phần mềm (Software Requirement Specification - SRS). Đặc tả yêu cầu phải chỉ rõ được phạm vi của sản phẩm, các chức năng cần có, đối tượng người sử dụng và các ràng buộc khi vận hành sản phẩm. Có nhiều chuẩn khác nhau trong xây dựng tài liệu, dưới đây là một định dạng RSR thông dụng (theo chuẩn IEEE 830-1984).
Trên đây là khái quát về bước phân tích và đặc tả yêu cầu trong quá trình phát triển phần mềm. Kết quả của việc phân tích là tạo ra bản đặc tả các yêu cầu phần mềm. Đặc tả cần được xét duyệt để đảm bảo rằng người phát triển và khách hàng có cùng nhận biết về hệ thống cần phát triển. Trong các bài viết sau, tôi sẽ mô tả chi tiết hơn về các phương pháp để mô hình hóa yêu cầu