Requirements, as traditionally used, are a separation tool. To separate the "thinkers" from the "doers". In software this is a HUGE mistake!
This conjecture is a fallacy.
The purpose of requirements elicitation, use, and implementation of the requirement that result in outcomes is to ensure that an organization and, all its participants, have a shared understanding of the needs and expectations of those work outcomes in the form of business, technical, and operational Capabilities. The requirements documents (in whatever form) are the basis of the process to verify these needed capabilities with customers and internal or external stakeholders and validates these requirement meet to need strategic intent of the work. [2]
The requirements process begins with the analysis and elicitation of the objectives and constraints of the organization needed to meet the strategic goals in the form of Capabilities. [1] This is the foundation of Capabilities Based Planning, The Capabilities must be defines before the Requirements are elicited. If the fallacy above, intentionally ignoring this process would be needed to seperate the doers from the thinkers. This process of Capabilities then Requirements is the foundation of Systems Engineering, which in turn the foundation of good business systems development.
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO 2007).
System requirements are all of the requirements at the system level that describe the functions which the system as a whole should fulfill to satisfy the stakeholder needs and requirements, and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary.
System requirements play major roles in Systems Engineering, as they:
- Form the basis of system architecture and design activities.
- Form the basis of system integration and verification activities.
- Act as the reference for validation and stakeholder acceptance.
- Provide a means of communication between the various technical staff and the business stakeholder that interact throughout the project.
Source of the Fallacy
Pardon him, Theodotus: he is a barbarian and thinks that the customs of his tribe and island are the laws of nature.
— George Bernard Shaw, Caesar and Cleopatra
[1] Software Engineering Body of Knowledge, http://sebokwiki.org/wiki/System_Requirements
[2] "Aligning IT to Organizational Strategy,"
[3] Capability-Based Planning, Chapter 32 TOGAF 9.1, Part III
