Category: Requirements

John Dewey on Starting with a 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.

Read More

“Requirements as Inventory” Metaphor

Think of requirements as inventory or as component materials in a storage bin with a shelf life and a carrying cost. Inventory isn’t free. You have to pay someone to produce (model and document) requirements. You need a supply of good, current (fresh) requirements to produce a quality product.

Read More

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.

Read More

Don’t Forget the Constraints!

In addition to eliciting and specifying the requirements, an important part of the analyst’s value-add lies in helping business stakeholders and delivery teams identify and understand the constraints that will apply for the solution.

Read More

Begin with what you HAVE to do

The simple fact is, you can’t know all the details upfront. You can and should, however, be able to work with your stakeholders to identify the broader range of necessary capabilities and constraints, or “placeholders for conversations”.

Read More
Loading