Trong các ngành kỹ thuật, một yêu cầu (requirement) là một đòi hỏi được tài liệu hóa về các chức năng và đặc điểm của một sản phẩm hoặc dịch vụ. Thuật ngữ này thường được dùng trong các ngành kỹ nghệ hệ thống và kỹ nghệ phần mềm.
Trong cách tiếp cận truyền thống lịch sử của ngành kỹ nghệ, những tập yêu cầu được dùng làm đầu vào cho những quy trình tiến độ thiết kết trong quy trình tăng trưởng mẫu sản phẩm .
Pha phát triển các yêu cầu có thể được thực hiện sau một nghiên cứu tiền khả thi (feasibility study), hoặc một pha phân tích khái niệm của dự án.. Pha yêu cầu có thể được chia thành các phần: thu thập yêu cầu (từ những người có vai trò quan trọng đối với sản phẩm/dịch vụ), phân tích yêu cầu (kiểm tra tính nhất quán và hoàn chỉnh), định nghĩa yêu cầu (viết các yêu cầu mang tính mô tả dành cho các nhà phát triển), và đặc tả (tạo cầu nối đầu tiên giữa các yêu cầu và thiết kế).
Yêu cầu trong kỹ nghệ mạng lưới hệ thống và kỹ nghệ ứng dụng[sửa|sửa mã nguồn]
Có ba loại yêu cầu: yêu cầu chức năng, yêu cầu phi chức năng (hay yêu cầu hiệu năng 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 mô tả xem hệ thống phải làm gì, nghĩa là hệ thống phải có khả năng thực hiện những công việc gì. Ví dụ: “Hệ thống cần lưu trữ tất cả chi tiết về đơn đặt hàng của khách hàng.”
- Yêu cầu phi chức năng là các ràng buộc về các loại giải pháp thỏa mãn các yêu cầu chức năng. Các yêu cầu này mô tả về chính hệ thống, và về việc nó cần thực hiện các chức năng của mình tốt đến mức độ nào, chẳng hạn yêu cầu loại này là yêu cầu về tính sẵn có, khả năng kiểm thử, khả năng bảo trì, và tính dễ sử dụng. Có thể chia các yêu cầu phi chức năng thành hai loại:
- Ràng buộc về hiệu năng: chẳng hạn “hệ thống cần phục vụ liên tục từ 5 giờ sáng đến 9 giờ tối.”, “mỗi đơn đặt hàng cần được lưu trữ trong tối thiểu 7 năm”.
- Ràng buộc về quá trình phát triển hệ thống: thời gian, tài nguyên, chất lượng. Ví dụ: khi nào hệ thống cần hoàn thành (thời gian); tổng chi phí cho phát triển hệ thống (tài nguyên); cần áp dụng các tiêu chuẩn nào cho quá trình phát triển hệ thống, trong đó có 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 hướng dẫn cho việc lựa chọn giải pháp. Có nhiều tính năng quan trọng đối với một hệ thống, nhưng nhiều trường hợp không thể có giải pháp đạt được mọi tính năng ở mức tối ưu. Do đó cần có một thứ tự ưu tiên, tính năng nào cần được ưu tiên hơn tính năng nào. Nếu khách hàng không mô tả thứ tự ưu tiên, nhà phát triển phần mềm sẽ tự chọn thứ tự và thứ tự này có thể không phải cái mà khách hàng mong muốn.
Một tập hợp các yêu cầu định nghĩa các tính chất hay tính năng của hệ thống cần xây dựng. Một danh sách yêu cầu ‘tốt’ thường tránh nói đến chuyện hệ thống cần thi hành các yêu cầu bằng cách nào, mà để các quyết định dạng này cho người thiết kế hệ thống. Việc mô tả cách cài đặt 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 loại sản phẩm và yêu cầu tiến trình[sửa|sửa mã nguồn]
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ệ ngặt nghèo. Các yêu cầu quy trình tiến độ thường được áp đặt với mục tiêu đạt được yêu cầu mẫu sản phẩm ở bậc cao. Ví dụ, một yêu cầu về cận trên của ngân sách tăng trưởng ( yêu cầu quy trình tiến độ ) hoàn toàn có thể được áp đặt để tạo điều kiện kèm theo cho một yêu cầu về cận trên của giá cả mẫu sản phẩm ( yêu cầu mẫu sản phẩm ) ; một yêu cầu rằng loại sản phẩm phải bảo dưỡng được ( yêu cầu mẫu sản phẩm ) thường dẫn đến những yêu cầu phải tuân theo những phong thái tăng trưởng đơn cử nào đó ( ví dụ, lập trình hướng đối tượng người dùng, những hướng dẫn phong thái lập trình, hay một quy trình tiến độ review / inspection ( những yêu cầu quy trình tiến độ ) ). Cả hai loại yêu cầu này đều có tính sống còn so với mọi mạng lưới hệ thống cần tăng trưởng ( Surafel )
Một số tác nhân trong tăng trưởng yêu cầu[sửa|sửa mã nguồn]
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.
Các yêu cầu tốt[sửa|sửa mã nguồn]
Theo triết lý, những yêu cầu tốt nên có những đặc thù sau :
- Cần thiết – Cái cần phải nhắc đến nếu không hệ thống sẽ thiếu một phần tử quan trọng mà không một thành phần nào khác của hệ thống có thể bù lại được.
- Không mù mờ đa nghĩa – Chỉ có một cách hiểu
- Ngắn gọn súc tích – Được diễn đạt bằng ngôn ngữ mô tả ngắn gọn và dễ hiểu, trong khi vẫn truyền đạt được nội dung cốt yếu của yêu cầu
- Nhất quán – Không mâu thuẫn với một yêu cầu khác; các yêu cầu sử dụng cùng hệ thống ngôn ngữ và thuật ngữ 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ỗ để người đọc không phải xem thêm tài liệu khác để có thể hiểu được nội dung của yêu cầu.
- Đạt được – Một khối lượng thực tiễn có thể được thực hiện trong lượng tiền/tài nguyên/thời gian có được
- Kiểm thử được – Phải có khả năng xác định xem yêu cầu đã được thỏa mãn hay chưa bằng một trong 4 phương pháp duyệt (inspection), phân tích, trình diễn, hoặc kiểm thử (test).
Khả năng kiểm thử[sửa|sửa mã nguồn]
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).
Phân tích yêu cầu[sửa|sửa mã nguồn]
Các yêu cầu rất dễ có các vấn đề về mù mờ đa nghĩa, không hoàn chỉnh, và không nhất quán. Các kĩ thuật chẳng hạn như thẩm tra chính xác (rigorous inspection) đã cho thấy ích lợi trong khi giải quyết các vấn đề này. Các rắc rối về mù mờ đa nghĩa, không hoàn chỉnh, và không nhất quán nếu có thể giải quyết được ngay tại pha yêu cầu thường gây chi phí nhỏ hơn nhiều so với khi chính các rắc rối này chỉ được phát hiện tại các giai đoạn sau của quá trình phát triển sản phẩm. Việc phân tích yêu cầu là để giải quyết các vấn đề này.
Có một sự trả giá cần xem xét giữa những yêu cầu quá lờ mờ và những yêu cầu chi tiết cụ thể đến mức chúng
- tốn nhiều thời gian để tạo ra
- bắt đầu hạn chế các lựa chọn có thể đối với việc tạo sản phẩm
- tốn chi phí cao để tạo ra
Viết yêu cầu[sửa|sửa mã nguồn]
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 biến hóa so với những yêu cầu[sửa|sửa mã nguồn]
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 thiết yếu của sự đúng chuẩn trong những yêu cầu ứng dụng[sửa|sửa mã nguồn]
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.
