Requirements

Requirement types, best practices, pitfalls, and other reference.

John Dewey on Starting with a Problem to be Solved

A problem well-stated is a problem half solved

“A problem well stated is a problem half solved.” – John Dewey

One of the more valuable lessons I’ve learned is that good solutions begin with a clear understanding of the problem to be solved. By starting with the problem, following up with objectives that articulate the definition of  success, and then ensuring that requirements and subsequent solution artifacts and trace cleanly to, and support the original problem, we can avoid the confusion and wasted resources associated with deviating from or adding scope to the solution’s original problem and intent.

Benjamin L. Kovitz on Requirements

Slide8

“Without requirements, there is no way to validate a program design; that is, no way to logically connect the program to the customer’s desires.” 

— Benjamin L. Kovitz

If human communication and human memory were perfect, we may not need deliberation and documentation of requirements. Alas, neither is close to true. It is the iterative exercise of modeling requirements, and then documenting them that enables shared understanding to be affirmed, and then shared with those who use requirements to guide design, construction and quality assurance. Requirements are the link between concept and product, and an important standard for measuring solution success. 

A Requirements Model (Graphic)

There is no perfect, fits-all template or set of documents which will be effective across all companies or even for all of a given company’s projects. The business analyst should work with internal and external stakeholders to determine which communicative tools will best serve for each project effort and model requirements accordingly.