It’s all about requirements

After working for 34 years, I have reached the conclusion that the common denominator in any project is Requirements.

For the business, the objective of the project is to take ideas and turn them into working products. It starts with a business idea which then turns into to business requirements to stakeholder requirements to functional requirements, to technical design, to technical specifications, to construction, to testing, and then to delivery. This transformation is the most valuable part of any project, yet is there a single person in charge of requirements? Is there a Requirements Manager or a Requirements Engineer? Unfortunately, the function of requirements engineering is distributed among everyone on the team, including the project manager and the business analyst. This results in a novice-level management of requirements resulting in requirements malpractice, which is one of the biggest headaches for projects.

A professional-level management of requirements includes a disciplined methodology to elicit, organize, and document requirements, followed by generating alternatives, identifying business rules, dependencies, assumptions, and constraints, then going thru a formal validation and approval process. Once official, requirements continue to evolve by adding specifications, modeling, and creating visuals. A requirements traceability matrix provides the linkage from business requirement all the way to test cases, and helps analyze impacts of changing requirements. Lastly, requirements are placed in an enterprise-level repository for reuse. All this transformational activity is facilitated by a Requirements Management Tool. In summary, companies and project management methodologies and practitioners need to greatly improve their requirements engineering maturity level. Once key step in that direction is learning the requirements management methodology developed by PMI called the PMI-PBA.