IT:AD:Requirements
- See also:
Summary
Software development is launched from Requirements, when there is very little deep understanding or consensus in the industry on how to classify, rank or even develop Requirements.
Considering the financial impact of poor Requirements on solution development, it behooves us to invest in understanding how what are the elements of valuable requirements, and what constitute poor requirements.
Classifications
A classic structure (highly outdated, IMHO):
- Business Specifications:
- Functional Specifications:
- User Functional Specifications
- Infrastructure Functional Specifications
- Quality Constraints:
- Design
- Operational
- Environmental
- System Design Specifications
Notes
Management
In the time of Consensus based Requirements, I'm still looking for the right tool. * Trello
- Custom Fields are almost there – but can't be used to Filter or Search or be copied between boards. Basically…useless.
- Tags are not fit for purpose of Categories, Qualities
* Ragic
- Great table embed functionality. Nearly there. But can't be filtered…
* Dokuwiki
- Too excentric
- Too slow
- No json output
- Not open data enough
What is a Requirement?
Two leading bodies in the industry are the IEEE and the IIBA. Both have different but similar definitions of what a requirement is.
Why bother getting them right
Requirements are the basis of getting quality results:
Use non-ambiguous terms
The Use of WILL, SHALL and WONT in RFP requirements is contentious.
Remove ambiguity by using IT:AD:RFC 2119
Requirement Classification
To put it bluntly, too many in the business of commissioning and delivering software think there are only two kinds of requirements – Functional Requirements and Business Requirements.
Understanding what a requirement is expected to capture starts by knowing what classification it belongs to.