Requirements Analysis and Documentation is the activities supporting the definition and docuentation of requirements information.
- Documemtaion is more than just writing requirements down. There are a number of frameworks for writing requirements including Unified Modelling Language and Business Process Modelling Notation. A popular technique is Use Case but there are many.
- 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.