Tìm hiểu,xác định yêu cầu

Khi một công ty muốn ký một hợp đồng cho một dự án phát triển một phần mềm, công ty sẽ phát biểu các yêu cầu ở mức trừu tượng để không bắt buộc định nghĩa trước các giải pháp. Các yêu cầu phải được viết sao cho các nhà phát triển phần mềm có thể đưa ra các giải pháp khác nhau. Sau khi đã trúng thầu và ký hợp đồng, yêu cầu phải được làm rõ hơn để khách hàng có thể hiểu và đánh giá được phần mềm. Cả hai tài liệu nói trên đều gọi là tài liệu yêu cầu người dùng.

Theo mức độ chi tiết có thể chia ra các loại tài liệu yêu cầu:

+ Xác định yêu cầu: đây là một khẳng định, bằng ngôn ngữ tự nhiên hơn là các sơ đồ, về các dịch vụ hệ thống cần cung cấp và các ràng buộc mà hệ thống phải tuân theo. Tài liệu này cung cấp cho các thành phần: người quản lý của bên khách hàng, người dùng cuối của hệ thống, kỹ sư của khách hàng, người quản lý ký kết hợp đồng, các kiến trúc sư hệ thống.

+ Đặc tả yêu cầu: là tài liệu được cấu trúc mô tả hệ thống các dịch vụ chi tiết hơn. Đôi khi tài liệu này được gọi là đặc tả chức năng. Đây có thể coi là hợp đồng ký kết giữa người mua và kẻ bán phần mềm. Tài liệu này cung cấp cho các thành phần: người dùng cuối của hệ thống, kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển phần mềm.

+ Đặc tả phần mềm: là mô tả trừu tượng hơn của phần mềm làm cơ sở cho thiết kế và triển khai. Tài liệu này cung cấp cho các thành phần: kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển phần mềm.

Xácđịnhyêucầu:là mô tả trừu tượng các dịch vụ mà hệ thống được mong đợi phải cung cấp và các ràng buộc mà hệ thống phải tuân thủ khi vận hành. Nó chỉ có các đặc tả phẩm hạnh bên ngoài của hệ thống mà không liên quan đến các đặc tính thiết kế. Nó phải được viết sao cho người ta có thể hiểu được mà không cần một kiến thức chuyên môn đặc biệt nào.

Các yêu cầu của phần mềm được chia thành hai loại:

1) Các yêu cầu hệ thống chức năng: các dịch vụ mà hệ thống phải cung cấp.

2) Các yêu cầu không chức năng: các ràng buộc mà hệ thống phải tuân theo.

Về nguyên tắc các yêu cầu của một hệ thống phải là vừa đầy đủ, vừa tráng kiện. Đầy đủ có nghĩa là mọi yêu cầu đều phải được đặc tả. Tráng kiện có nghĩa là các yêu cầu không gây ra mâu thuẫn. Thực tế đối với các hệ lớn và phức tạp thì thực là không thể đạt được tính đầy đủ và tính tráng kiện cho phiên bản đầu của tư liệu yêu cầu phần mềm. Vấn đề là khi duyệt lại hoặc trong các pha sau này của vòng đời phần mềm, người ta phát hiện ra các sự không thỏa mãn đó thì tư liệu yêu cầu phải được chỉnh lý lại.

Về bản chất, chúng ta phải hiểu và xác định rõ những yêu cầu của khách hàng. Tuy nhiên, thường bài toán được khách hàng phát biểu bằng ngôn ngữ tự nhiên cộng thêm với việc dùng các bảng các biểu đồ cho các người dùng dễ hiểu (xem là người dùng không biết các khái niệm chuyên môn công nghệ thông tin). Không may là ngôn ngữ được dùng này lại thường là không chính xác và mơ hồ, đôi khi có sự lầm lẫn giữa các biểu thị khái niệm và các biểu thị chi tiết làm cho việc mô tả chứa các thông tin hổ lốn được biểu diễn ở nhiều mức chi tiết khác nhau.

Ở đây, chúng ta cần chú ý rằng người đặt hàng có thể vì không hiểu biết gì về tin học nên họ không thể phát biểu chính xác và đầy đủ các yêu cầu của họ, đôi lúc thì những cái mà người sử dụng yêu cầu và những cái mà họ cần là không giống nhau. Thêm vào đó, chúng ta lại không hiểu biết đầy đủ về đối tượng, địa bàn cho nên không thể thu thập đầy đủ và chính xác các thông tin của đối tượng và đây chính là một trong những mâu thuẩn giữa khách hàng và chúng ta. Vì vậy, trong thực tế, đối với các hệ thống lớn và phức tạp, rất khó có thể đạt được tính đầy đủ và thống nhất của tài liệu yêu cầu.

Các yêu cầu được tìm hiểu còn chứa các mâu thuẩn:

 Thiếu rõ ràng: Rất khó sử dụng ngôn ngữ tự nhiên mô tả chính xác không nhầm lẫn mà không làm khó khăn cho người đọc.

 Nhầm lẫn yêu cầu: Các yêu cầu chức năng, các ràng buộc, mục đích của hệ thống và các thông tin thiết kế không được phân biệt rõ ràng.

 Trộn lẫn yêu cầu: Một số các yêu cầu khác nhau có thể được thể hiện như là một yêu cầu đơn.

Giải quyết mâu thuẩn này, chúng ta phải: trên cơ sở nghiên cứu kỹ lĩnh vực ứng dụng và thảo luận với người sử dụng để định nghĩa chính xác các yêu cầu của bài toán. Xác định rõ và đầy đủ bài toán là yếu tố quan trọng góp phần đảm bảo thành công của dự án. Nhiệm vụ của giai đoạn này là xây dựng được các hồ sơ mô tả chi tiết về các yêu cầu, nhiệm vụ, chức năng của hệ thống dự kiến.

Đánh giá các yêu cầu phần mềm liên quan với việc cho biết các yêu cầu thực sự định nghĩa hệ thống đáp ứng đòi hỏi của khách hàng. Nếu việc đánh giá này không chính xác, các lỗi trong phần yêu cầu sẽ truyền tới thiết kế hệ thống và triển khai hệ thống. Chi phí sửa chữa lỗi sẽ rất lớn. Sự thay đổi về yêu cầu ngụ ý rằng việc thiết kế và triển khai cũng phải thay đổi theo. Một số khía cạnh của yêu cầu cần phải kiểm chứng:

 Giá trị: người dùng có thể nghĩ rằng hệ thống cần một số chức năng, tuy nhiên sau một số phân tích, có thể xác định các chức năng khác cần được đưa vào. Do hệ thống có nhiều loại người sử dụng nên có các yêu cầu khác nhau và không thể tránh khỏi sự thỏa hiệp các nhu cầu đó.

 Chắc chắn: mọi yêu cầu không được mâu thuẫn với các yêu cầu khác

 Hoàn chỉnh: định nghĩa cần phải bao gồm mọi chức năng và các ràng buộc

 Hiện thực: không có các yêu cầu đặc biệt đến mức phi hiện thực. Có thể dự đoán trước các phát triển phần cứng, tuy nhiên phát triển phần mềm thì khó dự đoán hơn.

 Mẫu: là một mô hình chạy được của hệ thống được trình bày với người sử dụng. Đây là một kỹ thuật đánh giá yêu cầu hiệu quả. Nó cho phép người dùng thử nghiệm với hệ thống. Việc đánh giá lại yêu cầu không nên được coi là công việc tiếp theo của tư liệu hóa yêu cầu sau khi đã hoàn thành. Các xem xét về yêu cầu định kỳ liên quan với người dùng và kỹ sư phần mềm luôn cần thiết.

Các xem xét yêu cầu có thể là hình thức hoặc phi hình thức. Xem xét phi hình thức liên quan việc các người ký hợp đồng thảo luận các yêu cầu với khách hàng. Nhiều vấn đề có thể được giải quyết dễ dàng bất ngờ khi tham khảo trực tiếp với khách hàng. Đối với yêu cầu xem xét chính thức, đội phát triển phải dẫn dắt khách hàng thông qua các yêu cầu hệ thống, giải thích các triển khai của mỗi yêu cầu. Nhóm rà soát phải kiểm tra mỗi yêu cầu về độ thống nhất, hoàn chỉnh cho toàn bộ tài liệu. Họ có thể phải kiểm tra:

 Có khả năng kiểm tra: tài liệu có thể kiểm tra thực tế được không?

 Khả năng hiểu biết: tài liệu có được khách hàng hiểu biết thấu đáo hay không?

 Lưu vết: nguồn gốc của tài liệu có được xác định rõ ràng hay không? Rất có thể phải quay lại nguồn gốc ban đầu để đánh giá ảnh hưởng của sự thay đổi.

 Tính thích hợp: các yêu cầu đã phù hợp hay chưa? Có thể thay đổi các yêu cầu mà không làm ảnh hưởng lớn đến toàn bộ hệ thống không.