Checklist Of Do's and Don'ts

This checklist addresses process and content specific issues of business requirements management and analysis. A checklist must always be specific for an organization, and this list gives you a head-start.

Project Process Specific Do's and Don'ts

Process specific issues address points that in the course of the project should be solved.

A project qualifies for business requirements management, when one or more of the following conditions apply:

  • Complexity in functionalities;
  • Complexity in dependencies of other business projects;
  • Complexity of dependencies with other departments;
  • In order to resolve the business priorities in relation to complexity issues make sure that you let requirements mark in the categories 'must have', 'should have', and 'nice to have'. Start with 'must have'.
  • Budget over k€100 (k$ 150).

Project Content Specific Do's and Don'ts

Content specific issues deal with the quality of the resulting specifications.

  1. Specify your business requirements with the help of goal-based verbs:

    • Business requirements should always be specified using verbs in the active form.
    • Business requirements should be associated with an end-to-end system goal.
  2. Use definitive language and avoid fuzzy language:
    • Be explicit.
    • Language must be definitive and unambiguous.
  3. Use a structured narrative, keep the context visible, and keep the value to the user clear.
    • Do not use flat paragraphs that just give a listing of separate issues, with no real connectedness.
    • Alternatively, the structured narrative shows the individual steps that make up the deliverable.
  4. Express objectives SMART, and in non-technical language. Make sure that they are in the specific language of the business domain.
  5. Get specific on detail:
    • Specify detail, and avoid late scoping surprises.
    • Specify the business requirements in detail as far as it is possible.
  6. Avoid implementation details, and avoid a lock-in with the architecture:
    • Technical details belong in the architecture, and design documentation.
    • Always specify in terms of what the system offers.
  7. Specify alternative scenario's and flows.
  8. Avoid premature design and capturing design in structured business requirements:
    • Each business requirement yields a tangible observable value to an actor.
    • Do not over-abstract business requirements.

back to top