Documenting and managing requirements as a business analyst

[responsivevoice_button voice=”UK English Female” buttontext=”Listen to Post”]

Solid documentation is an absolute necessity. It’s used throughout the lifecycle of the project. It’s what stakeholders sign-off on; it’s what the developers follow during the implementation phase; it’s what the testers use to validate that everything works as it should; it’s what the support teams use for post-deployment troubleshooting and it’s used to assess benefits realization at the end of a project.

Requirements documentation then has to be thorough and unambiguous. Typically, a requirements document should include the below sections.

  1. Introduction and background: the business drivers for the project; project objectives and scope.
  2. Business process models: to-be process models accompanied by detailed task descriptions.
  3. Function models: using context diagrams or use case diagrams to show the proposed functionality.
  4. Data models: using class diagrams and ERD’s to show relationships between data.
  5. Requirements catalogue, described in more detail below.
  6. Glossary.

So, the meat of the requirements document is going to be your requirements catalogue. An item in a requirements catalogue should include the following detail:

  • Requirements ID,
  • Date,
  • Version,
  • Status (in development, stalled etc…),
  • Requirement Name,
  • Business Area,
  • Source (who raised it),
  • Owner,
  • Priority (MOSCOW – Must, Should, Could, Want),
  • Type of requirement (business or solution),
  • Requirement Description,
  • Associated non-functional requirement (link to business requirements),
  • Acceptance criteria,
  • Justification,
  • Comments,
  • Related Documentation,
  • Related requirements,
  • Resolution (to be implemented; deferred; for later release).

When we look at categorizing our requirements, we can use the below table. Something can be either a business or a solution requirement. Within that, it can be one of the sub categories. To ensure that we’re hitting business objectives, we should always link functional and non-functional requirements back to business requirements.

All documentation should be subject to configuration management. This is the process of managing changes to the documents with versioning. This avoids the re-introduction of removed requirements & the development of outdated requirements.

Configuration items (CI’s) include the below. All of these items should be independently versioned:

  • Each requirement.
  • The requirements catalogue.
  • All diagrams and models.
  • The requirements document as a whole.
  • Prototypes*

Prototypes can change rapidly, especially in an agile environment. We therefore must baseline and control prototypes. You may wish to baseline every prototype before demonstration to stakeholders or you may wish to baseline daily. This will depend on the exposure your prototype has and the working practices in your team – for example, version controlled code.

To avoid confusion, we must implement formal change control for CI’s. After the requirements validation is completed, we baseline our requirements. Any changes must be presented to the configuration manager / stakeholders for approval.

 

Content based on study of the BCS Business Analysis course – Business Analysis 3rd Edition (Debra Paul, James Cadle and Donald Yeates).

Kieran Keene

view all posts

Join me on this career development project as I set out to develop the skills required to progress up the technology career ladder! Check out http://netshock.co.uk/about/ to find out more.