IT:AD:Requirements

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.

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

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.