Yêu cầu (kỹ thuật)

So sánh giữa yêu cầu sản phẩm và yêu cầu quy trình

Các dự án là đối tượng của ba loại yêu cầu: các Yêu cầu Doanh nghiệp dùng các thuật ngữ doanh nghiệp để mô tả những gì cần được hoàn thành hoặc tạo ra để đem lại giá trị; các Yêu cầu sản phẩm mô tả hệ thống hay sản phẩm mà là một trong vài cách thực hiện các yêu cầu doanh nghiệp. các Yêu cầu quy trình mô tả các quy trình mà tổ chức phát triển hệ thống phải làm theo và các ràng buộc mà họ phải tuân theo.
Các Yêu cầu Sản phẩm và Quy trình có mối quan hệ chặt chẽ. Các yêu cầu quy trình thường được áp đặt với mục đích đạt được yêu cầu sản phẩm ở bậc cao. Ví dụ, một yêu cầu về cận trên của chi phí phát triển (yêu cầu quy trình) có thể được áp đặt để tạo điều kiện cho một yêu cầu về cận trên của giá bán sản phẩm (yêu cầu sản phẩm); một yêu cầu rằng sản phẩm phải bảo trì được (yêu cầu sản phẩm) thường dẫn đến các yêu cầu phải tuân theo các phong cách phát triển cụ thể nào đó (ví dụ, lập trình hướng đối tượng, các hướng dẫn phong cách lập trình, hay một quy trình review/inspection (các yêu cầu quy trình)). Cả hai loại yêu cầu này đều có tính sống còn đối với mọi hệ thống cần phát triển (Surafel)

Một số nhân tố trong phát triển yêu cầu

Việc trình bày các yêu cầu ở một cách lý tưởng là rất khó. Người dùng khó hình dung được hết những thông tin nào là cần thiết cho các nhà phát triển, và hai bên có thể không thực sự hiểu các cách diễn đạt của nhau. Thông thường, người ta thuê người dùng chuyên gia (expert user) làm cầu nối giữa người dùng và các nhà phát triển. Những người dùng chuyên gia này có thể biểu đạt các yêu cầu chức năng sao cho chúng có thể dễ chuyển thành một tính năng thiết kế của hệ thống, trong khi người dùng cuối (end user) vẫn hiểu được.

Khả năng kiểm thử

Hầu hết các yêu cầu cần có khả năng kiểm thử được. Nếu không, phải sử dụng một phương pháp kiểm định khác (ví dụ phân tích, duyệt lại thiết kế). Các yêu cầu kiểm thử được là một thành phần quan trọng của việc kiểm định (validation).
Một số yêu cầu không thể kiểm thử được do chính cấu trúc của nó. Trong đó có các yêu cầu nói rằng hệ thống cần luôn luôn hay không bao giờ thể hiện một tính chất nào đó. Việc kiểm thử thích đáng cho các yêu cầu này sẽ cần đến một chu trình kiểm thử vô hạn. Những yêu cầu như vậy cần được viết lại để nói về một khoảng thời gian có tính thực tế hơn.
Các yêu cầu phi chức năng không kiểm thử được có thể vẫn được giữ để làm tài liệu về chủ ý của khách hàng; tuy nhiên, chúng thường dẫn đến các yêu cầu quy trình mà chúng được xác định là một phương pháp thực tiễn cho việc thỏa mãn yêu cầu ban đầu. Ví dụ, một yêu cầu phi chức năng rằng không được có các backdoor có thể được thỏa mãn bằng cách thay nó bằng một yêu cầu quy trình rằng cần sử dụng phương pháp lập trình đôi (pair programming).

Viết yêu cầu

Các yêu cầu thường được viết sao cho chúng hướng dẫn sự tạo ra/sửa đổi một hệ thống theo các quy tắc doanh nghiệp (business rules) phù hợp với miền ứng dụng của hệ thống. Hình thức tổng quát của một yêu cầu có dạng "ai cần làm gì". Ví dụ: "người ký hợp đồng cần giao sản phẩm không muộn hơn ngày xyz".

Các thay đổi đối với các yêu cầu

Theo thời gian, các yêu cầu có thể thay đổi. Trong trường hợp này, một khi đã được xác định và thông qua, các yêu cầu cần được đưa vào quy trình kiểm soát thay đổi (change control). Với nhiều dự án, một số yêu cầu được thay đổi trước khi hệ thống được hoàn thiện. Đặc tính này của các yêu cầu đã dẫn đến các nghiên cứu và thực hành về quản lý yêu cầu (requirements management).

Các tranh cãi về tính cần thiết của sự chính xác trong các yêu cầu phần mềm

Một số phương pháp luận kỹ nghệ phần mềm hiện đại, chẳng hạn như lập trình cực đoan, đã nghi ngờ sự cần thiết của các yêu cầu phần mềm được mô tả chính xác - cái mà các phương pháp luận này coi là một các đích di động. Thay vào đó, họ mô tả các yêu cầu một cách phi hình thức bằng các "câu chuyện người dùng" (các tóm tắt ngắn vừa vặn trọng một cái thẻ nhỏ với nội dung giải thích một khía cạnh của những gì mà hệ thống cần làm), và tạo một chuỗi các trường hợp kiểm thử chấp nhận (acceptance test case) cho câu chuyện người dùng này.