Yêu cầu xác định những gì một sản phẩm phải thực hiện — kỳ vọng được ghi lại về kết quả của việc thực hiện một dự án. Tài liệu này ghi nhận kỳ vọng của khách hàng cũng như của người phát triển đối với chương trình, các chức năng của nó, và toàn bộ dự án. Yêu cầu bao gồm các đặc tính, chi phí, tiến độ và rủi ro. Như vậy, yêu cầu là một phát biểu về những gì cần phát triển, hay một mô tả định lượng chính xác về những gì mong muốn đạt được sau khi thực hiện dự án. Việc xác định yêu cầu kém là nguyên nhân chính gây ra các vấn đề trong quá trình thực hiện dự án.
Yêu cầu quy định phải làm gì, làm tốt đến mức nào, và trong những ràng buộc nào. Nếu yêu cầu sai, dự án và sản phẩm sẽ có sai sót. Yêu cầu, ràng buộc và giả định phân chia vấn đề thành các phần. Điều này quyết định sự thành công tổng thể của dự án.
Các loại yêu cầu:
- Yêu cầu chức năng xác định một phần tử hệ thống cho trước phải làm gì.
- Yêu cầu hiệu năng xác định các tham số định lượng của các chức năng tương ứng do hệ thống thực hiện.
- Yêu cầu ràng buộc phát sinh từ các hạn chế về chế độ vận hành, điều kiện môi trường, các cân nhắc về an toàn, hoặc sự tuân thủ quy định.
- Yêu cầu kiểm chứng mang lại sự tin tưởng rằng hệ thống có các đặc tính đã quy định trong môi trường vận hành thực tế của nó.
- Yêu cầu giao diện xác định các chức năng, đặc tính, dung sai và ràng buộc của tất cả các giao diện.
- Yêu cầu vận hành quy định mức độ sẵn sàng vận hành của hệ thống, tập trung vào hiệu năng của hệ thống, đồng thời xác định cách hệ thống tương tác với người dùng.
Trong tài liệu tiếng Anh, từ viết tắt SMART được dùng để ghi nhớ các đặc điểm của một yêu cầu tốt.
- Specific (Cụ thể) — yêu cầu chỉ được đề cập đến một tính năng của dự án hoặc một đặc tính của hệ thống. Chúng phải được diễn đạt theo hướng phải làm gì và làm tốt đến mức nào, chứ không bao giờ theo hướng một giải pháp khả dĩ — làm điều đó như thế nào.
- Measurable (Đo lường được) — một tham số đo lường được phải được diễn đạt một cách khách quan và định lượng.
- Achievable (Khả thi) — một yêu cầu phải khả thi về mặt kỹ thuật với chi phí hợp lý.
- Relevant (Phù hợp) — một yêu cầu phải tương ứng với cấp độ hệ thống đã chọn.
- Traceable (Có thể truy xuất) — các yêu cầu ở cấp thấp hơn phải được suy ra rõ ràng từ và/hoặc được hỗ trợ bởi các yêu cầu ở cấp cao hơn. Các yêu cầu không có yêu cầu “gốc” được coi là “mồ côi” và cần được đánh giá về tính cần thiết của việc thực hiện chúng.
Tính cần thiết. Nếu có nghi ngờ về việc liệu một yêu cầu có cần thiết hay không, chỉ cần tự hỏi: “Hệ thống sẽ gặp tác hại gì nếu yêu cầu này không được đưa vào danh sách?” Nếu không có câu trả lời, thì có lẽ yêu cầu đó là không cần thiết.
Tính kiểm chứng được. Ngay khi một yêu cầu được đặt ra, cần xác định cách thức kiểm chứng nó. Để làm điều này, phải chọn một tiêu chí tuân thủ phù hợp.
Tính khả thi. Để khả thi, một yêu cầu phải có thể thực hiện được về mặt kỹ thuật trong tiến độ và ngân sách đã cho, với các ràng buộc bổ sung. Nếu còn tính bất định về khả năng thực hiện kỹ thuật của một yêu cầu, cần tiến hành một nghiên cứu phù hợp hoặc điều tra sâu hơn. Nếu tính bất định vẫn còn sau đó, nên phát biểu một mục tiêu thay vì một yêu cầu. Rõ ràng là dù một yêu cầu khả thi về mặt kỹ thuật, nó vẫn có thể không đạt được do chi phí, tiến độ, hoặc các ràng buộc khác như trọng lượng. Việc đặt ra một yêu cầu cho điều không thể thực hiện được là vô nghĩa; cần phải thực tế.
Tính rõ ràng. Mỗi yêu cầu phải diễn đạt một ý duy nhất và phải ngắn gọn, đơn giản. Điều quan trọng là yêu cầu phải rõ ràng và không mập mờ. Các yêu cầu tốt thường không cần gì hơn những câu đơn giản.
Một yêu cầu nên được phát biểu theo cách khẳng định và không bao giờ nên bắt đầu bằng phủ định. Nó phải đúng ngữ pháp, không có lỗi đánh máy và thiếu sót. Cần sử dụng thuật ngữ nhất quán ở mọi cấp độ của hệ thống.