Search This Blog


21 September 2007

Requirements Planning

The next edition of the Carnival of Business Analysts is themed around Requirements Planning.

It’s a challenging topic because it’s a relatively new for most people including many analysts. I look forward to reading people’s submissions (and of course supplementing them with my own search.)

Submit your blog post, article or white paper today.

Usually a business analyst will join the project at inception or shortly after the project’s scope is defined and then jump straight into requirements elicitation & definition. The IIBA and their BA Body of Knowledge recognises that Requirements Planning is a critical step in a quality requirements management process, and as a result it is listed as one of the main processes for Certified Business Analyst Professionals.

Requirements Planning is important because usually requirements management is a complex activity that takes more than interview or workshop to understand all the business requirements. In large organisations it is also common for several analysts to work on one project, and so co-ordinating the work of several people becomes an issue.

As a method of insuring quality and minimising errors and rework a planned approach is recommended. Essentially you are encouraged to treat the requirements management process as a sub-project of the project you are working on. The BABOK (v1.6) highlights the following areas as key to requirements management;
  • Identifying stakeholders and key roles
  • Selecting requirements activities,
  • Managing the requirements scope,
  • Communication of the requirements.

There are other industry bodies of knowledge that can help in requirements planning. You can look to these for ways to help plan your requirements management project.

The SWEBOK (Software Engineering Body of Knowledge 2004, available for download at has useful information for requirements planning. See chapter 2 in general and more specifically Chapter 2.7 for a list of practical considerations for people planning requirements.

These tips include facing up to the iterative nature of requirements definition, managing changes to requirements the importance of fleshing out requirements with background details through a description of their attributes, ensuring traceability, and lastly making sure requirements can be measured (and are presumably the right things to be measured.).

The other obvious source of planning advice is the PMBOK, cousin to the BABOK. The PMBOK has planning embedded into each major work activity and process. It also recognises planning as the second (after initiating) of five project management processes. The PMBOK takes an engineering approach to project management and so everything in this framework is process oriented, as it is in PRINCE2 and most other PM frameworks.

And there are several more frameworks. You can even develop your own. I'll point you to Josh Milne’s blog where he discusses the process of creating a customised project management (and planning) methodology as an example of how you can develop your own process.