it:ad:requirements:home

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.

A classic structure (highly outdated, IMHO):

  • Business Specifications:
  • Functional Specifications:
    • User Functional Specifications
    • Infrastructure Functional Specifications
  • Quality Constraints:
    • Design
    • Operational
    • Environmental
  • System Design Specifications

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

Two leading bodies in the industry are the IEEE and the IIBA. Both have different but similar definitions of what a requirement is.

Requirements are the basis of getting quality results:

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.

  • /home/skysigal/public_html/data/pages/it/ad/requirements/home.txt
  • Last modified: 2023/11/04 03:30
  • by 127.0.0.1