6 | The Quest for Good Requirements
300 Brickstone Square • Suite 201 • Andover, MA 01810 USA • 1.800.288.7246 • +1.978.649.8200 • info@corpedgroup.com
of facilitated requirements workshops.
• Shadow users as they perform job tasks and use the results of the observations to identify needs
and to understand business processes. Document these insights in flow charts or UML activity
diagrams.
• Hold feedback sessions during which users can provide feedback on issues or problems with
the current system. The results can be used to formulate requirements on how to enhance the
system. Looking at problem reports from the help desk can be particularly insightful.
• Build a prototype that demonstrates the requirements and provides realistic feedback to the
users.
• Identify, document, and address any risks that might have a negative impact on the project; i.e.,
that might cause a delay in delivery, an increase in budget, or a reduction in scope.
• Validate the requirements through walkthroughs and other formal or informal meetings with
stakeholder to ensure that the right requirements have been discovered.
Requirements Analysis
As soon as requirements have been identified, they must
be analyzed to ensure that they are correct, not in conflict
with each other, and that they are precisely understood by
all stakeholders. During analysis, the requirements must be
decomposed into sufficient detail so that the project team can
accurately estimate effort for implementation and assure that
the requirements are indeed feasible.
Analysis Artifacts
During analysis, the analyst constructs a number of textual, digital, and visual artifacts, including:
• Context diagrams
• Use case model
• Conceptual data models and data dictionary
• User interface model
• Business process models
• Prioritized requirements catalog
• Business rule catalog
• Prototypes (horizontal discovery as well as vertical feasibility prototypes)
Requirements Documentation
To communicate the requirements to the stakeholders for validation and to provide the development
team with a thorough understanding of what must be done, the analyst must write a requirements
specification. This is simply called the requirements package, as there are no industry standards for
the format of that specification. Every organization has adopted a different document template. It is
important, however, that an organization has a standard document template. The template must be
flexible, as no single structure will fit all projects.
