Yêu cầu kỹ thuật

Trong lĩnh vực kỹ thuật, một yêu cầu (requirement) là một điều kiện được ghi chép rõ ràng về các chức năng và đặc điểm cần có của một sản phẩm hoặc dịch vụ. Thuật ngữ này thường xuất hiện trong ngành kỹ thuật hệ thống và phần mềm.

Trong phương pháp truyền thống của ngành kỹ nghệ, các tài liệu yêu cầu được sử dụng làm cơ sở cho các giai đoạn thiết kế trong quá trình phát triển sản phẩm.

Giai đoạn phát triển yêu cầu có thể được thực hiện sau khi hoàn thành nghiên cứu khả thi (feasibility study) hoặc phân tích khái niệm của dự án. Giai đoạn yêu cầu thường được chia thành các bước: thu thập yêu cầu (từ các bên liên quan), phân tích yêu cầu (kiểm tra tính nhất quán và đầy đủ), định nghĩa yêu cầu (viết yêu cầu chi tiết cho các nhà phát triển), và đặc tả (tạo sự kết nối giữa yêu cầu và thiết kế).

Các yêu cầu trong kỹ thuật hệ thống và phần mềm

Có ba loại yêu cầu chính: yêu cầu chức năng, yêu cầu phi chức năng (còn gọi là yêu cầu hiệu suất hoặc yêu cầu chất lượng dịch vụ), và mục tiêu thiết kế.

• Yêu cầu chức năng chỉ rõ các chức năng mà hệ thống cần thực hiện, tức là những công việc mà hệ thống cần làm. Ví dụ: 'Hệ thống phải có khả năng lưu trữ toàn bộ thông tin về các đơn hàng của khách hàng.'
• Yêu cầu phi chức năng bao gồm các ràng buộc liên quan đến cách mà hệ thống thực hiện các chức năng của mình. Những yêu cầu này mô tả về hệ thống và mức độ chất lượng mà nó cần đạt được, chẳng hạn như yêu cầu về độ sẵn sàng, khả năng kiểm thử, khả năng bảo trì, và sự dễ sử dụng. Yêu cầu phi chức năng có thể được chia thành hai loại:
  • Ràng buộc hiệu suất: ví dụ như 'hệ thống cần hoạt động liên tục từ 5 giờ sáng đến 9 giờ tối', 'mỗi đơn hàng phải được lưu trữ ít nhất 7 năm.'
  • Ràng buộc phát triển hệ thống: bao gồm thời gian, tài nguyên, và chất lượng. Ví dụ: thời điểm hoàn thành hệ thống (thời gian); tổng chi phí phát triển hệ thống (tài nguyên); tiêu chuẩn áp dụng trong quá trình phát triển hệ thống, bao gồm các phương pháp quản lý dự án và phát triển hệ thống (chất lượng).
• Mục tiêu thiết kế: các chỉ dẫn cho việc lựa chọn giải pháp. Dù một hệ thống có nhiều tính năng quan trọng, nhưng không phải lúc nào cũng có giải pháp tối ưu cho tất cả các tính năng. Do đó, cần xác định mức độ ưu tiên cho các tính năng. Nếu khách hàng không chỉ định thứ tự ưu tiên, nhà phát triển sẽ tự quyết định và thứ tự này có thể không phù hợp với mong muốn của khách hàng.

Một tập hợp yêu cầu mô tả các đặc điểm hoặc tính năng cần có của hệ thống. Danh sách yêu cầu tốt thường không chỉ ra cách hệ thống cần thực hiện các yêu cầu bằng cách nào, mà để lại việc này cho các nhà thiết kế. Việc chỉ định cách thức thực hiện hệ thống được gọi là thiên kiến cài đặt (implementation bias).

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

Dự án thường liên quan đến ba loại yêu cầu: các Yêu cầu Doanh nghiệp sử dụng các thuật ngữ doanh nghiệp để mô tả những gì cần hoàn thành hoặc tạo ra để mang lại giá trị; các Yêu cầu sản phẩm mô tả hệ thống hoặc sản phẩm như là một trong những cách thực hiện các yêu cầu doanh nghiệp; và các

Yêu cầu sản phẩm và yêu cầu quy trình có sự liên hệ mật thiết. Yêu cầu quy trình thường được thiết lập để đảm bảo đạt được yêu cầu sản phẩm ở cấp độ cao. Ví dụ, một yêu cầu về giới hạn chi phí phát triển (yêu cầu quy trình) có thể được thiết lập để hỗ trợ yêu cầu về mức giá tối đa của 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 dễ bảo trì (yêu cầu sản phẩm) thường dẫn đến việc phải tuân thủ các phương pháp phát triển cụ thể (như lập trình hướng đối tượng, hướng dẫn lập trình, hoặc quy trình kiểm tra) (yêu cầu quy trình). Cả hai loại yêu cầu này đều rất quan trọng đối với mọi hệ thống đang được phát triển (Surafel).

Các yếu 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à khá khó khăn. Người dùng thường gặp khó khăn trong việc hình dung tất cả các thông tin cần thiết cho các nhà phát triển, và sự hiểu biết giữa hai bên có thể không hoàn toàn khớp nhau. Thường thì người ta sẽ thuê những 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ể diễn đạt các yêu cầu chức năng một cách dễ hiểu để chuyển thành các tính năng thiết kế của hệ thống, trong khi người dùng cuối (end user) vẫn có thể hiểu rõ.

Các yêu cầu chất lượng

Theo lý thuyết, các yêu cầu chất lượng nên có các đặc điểm sau:

• Cần thiết – Một yếu tố không thể thiếu, nếu không hệ thống sẽ thiếu một thành phần quan trọng mà không thể được thay thế bởi bất kỳ phần nào khác của hệ thống.
• Rõ ràng và đơn nghĩa – Chỉ có một cách hiểu duy nhất
• Ngắn gọn và rõ ràng – Diễn đạt bằng ngôn ngữ đơn giản, dễ hiểu, trong khi vẫn truyền tải đầy đủ nội dung chính của yêu cầu
• Nhất quán – Không mâu thuẫn với các yêu cầu khác; các yêu cầu sử dụng hệ thống ngôn ngữ và thuật ngữ đồng nhất cho các khái niệm.
• Hoàn chỉnh – Các nội dung được trình bày đầy đủ tại chỗ, giúp người đọc không phải tham khảo thêm tài liệu khác để hiểu yêu cầu.
• Đạt được – Có thể thực hiện trong phạm vi ngân sách/tài nguyên/thời gian hiện có
• Kiểm thử được – Có khả năng xác định xem yêu cầu đã được đáp ứng hay chưa thông qua một trong các phương pháp như duyệt, phân tích, trình diễn, hoặc kiểm thử.

Hầu hết các yêu cầu cần phải có khả năng kiểm thử. Nếu không, cần sử dụng các phương pháp khác như phân tích hoặc duyệt thiết kế. Khả năng kiểm thử là một yếu tố quan trọng trong việc xác thực yêu cầu.

Một số yêu cầu không thể kiểm thử được do bản chất của chúng, chẳng hạn như yêu cầu hệ thống phải luôn luôn hoặc không bao giờ thể hiện một đặc tính cụ thể. Kiểm thử cho những yêu cầu này sẽ yêu cầu một chu trình kiểm thử vô hạn. Các yêu cầu này nên được điều chỉnh để nói về khoảng thời gian thực tế hơn.

Các yêu cầu phi chức năng không thể kiểm thử vẫn có thể được lưu giữ như tài liệu về ý định 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à có thể xác định phương pháp thực tiễn để đáp ứng yêu cầu ban đầu. Ví dụ, yêu cầu phi chức năng về việc không có backdoor có thể được thay thế bằng yêu cầu quy trình yêu cầu sử dụng phương pháp lập trình đôi (pair programming).

Các yêu cầu thường gặp vấn đề về sự mơ hồ, thiếu sót và không đồng nhất. Các phương pháp như thẩm tra chính xác (rigorous inspection) đã chứng minh hiệu quả trong việc giải quyết những vấn đề này. Nếu các vấn đề về sự mơ hồ, thiếu sót và không đồng nhất được giải quyết ngay trong giai đoạn yêu cầu, chi phí sẽ thấp hơn nhiều so với khi phát hiện chúng ở các giai đoạn phát triển sản phẩm sau đó. Phân tích yêu cầu giúp khắc phục những vấn đề này.

Cần cân nhắc giữa yêu cầu quá mơ hồ và yêu cầu quá chi tiết, vì chúng có thể

1. tốn nhiều thời gian để phát triển
2. giới hạn các lựa chọn trong quá trình tạo sản phẩm
3. có chi phí cao để thực hiện

Viết yêu cầu

Các yêu cầu thường được soạn thảo để hướng dẫn việc tạo ra hoặc chỉnh sửa hệ thống theo các quy tắc doanh nghiệp (business rules) phù hợp với lĩnh vực ứng dụng của hệ thống. Cấu trúc cơ bản của một yêu cầu là 'ai cần thực hiện điều gì'. Ví dụ: 'người ký hợp đồng phải giao hàng trước ngày xyz'.

Thay đổi các yêu cầu

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

Tranh cãi về mức độ chính xác cần thiết trong các yêu cầu phần mềm

Một số phương pháp kỹ thuật phần mềm hiện đại, như lập trình cực đoan, đặt nghi vấn về sự cần thiết của các yêu cầu phần mềm được mô tả chính xác – mà các phương pháp này coi là một mục tiêu thay đổi. Thay vào đó, các yêu cầu thường được mô tả phi chính thức bằng các 'câu chuyện người dùng' (các mô tả ngắn gọn trên thẻ nhỏ giải thích một khía cạnh của những gì hệ thống cần làm), và xây dựng 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.

• Phân tích yêu cầu
• Tình huống sử dụng (Use case)
• Quản lý yêu cầu (Requirements management)