FANDOM


Requirements Analysis and Documentation is the activities supporting the definition and docuentation of requirements information.

  • Requirements should be written in precise and accurate language. The uses of words such as "must," "shall," "will" and others have particular importance in this area.
  • There is a capability maturity model called RMM - Requirements Maturity Model which describes five levels of maturity when dealing with requirements. THe lowest is no formal management or documentation, the highest provides for a highly capacble and reuseable set of requirements documentation and management systems.
  • Requirements should be written without inappropriate constraints, or with the imposition of a aparticular solution approach. By defining solution approaches (eg using a particular development approach, a particular computer system and so on) means that a solution designer is constrained unneccessarily. This has been identified as a common cause of delivery probelms for projects by reports such as the infamous Standish Groups CHAOS report.
  • Requirements managed and documented by a BA should add value to the project, not simply be a reprt of what project stakehodlers have asked for. A key reason for the business analysts participation in the project is to ensure requirements are valuable and contribute to the project's success as defined in the business case.


This article is a stub. You know the drill. We'd love you to expand it.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.