A condition or capability needed by a user to solve a problem or achieve an objective, or something that must be met or possessed by a system or system component to satisfy a contract, standard, etc. This is also a documented representation of a condition or capability as in the above.
This is also an approximation as to what we want.
In a Software Sense
Requirements contain both the user’s view of the external system behaviour and the dev’s view of some internal characteristics. They include the behaviour of the system under specific conditions and those props that make the system suitable.
There are different types of requirements
- Business requirements: A high level business objective at a product level
- Business rules: A policy that defines or constrains some aspect of the business (not software related)
- Constraints: A restriction that is imposed on the choices available to the dev for the design and construction of a product
- External interface requirements: A description of a connection between a software system and a user / client
- Features: One or more logically related system capabilities that provide value to the user against a set of functional requirements
- Functional Requirements: A description of behaviour that a system will exhibit under a specific condition (what the system is supposed to do)
- Non-Functional Requirements: A description of a property or characteristic that a system must exhibit or a constraint that it must respect (what the system is supposed to be)
- Quality attributes: Requirements that describes a service or performance characteristic
- System requirements: A top-level requirements for a product that contains multiple sub systems which could be software or hardware
- User requirements: A goal or task that users must be able to perform with a system
Often times, stakeholders have different definitions of requirements and different definitions of the correct problem to be solved which makes defining requirements difficult.
Why Software Fails
- Unrealistic or unarticulated project goals
- Inaccurate estimates of needed resources
- Badly defined system requirements
- Poor reporting of the project’s status
- Unmanaged risks
- Poor communication among customers, developers, and users
- Use of immature technology
- Inability to handle the project’s complexity
- Sloppy development practices
- Poor project management
- Stakeholder politics
- Commercial pressures
We use Requirements Engineering to find our problems and design our requirements.