There’s little argument that investigating and identifying business needs (i.e. requirements) is a critical task of business analysis. However it’s of little use correctly identifying business needs if we can’t then effectively document them – to the clients who will be paying for the solution and to the developers who will be building it. In today’s time poor world we need to address both audiences in a single document.
This paper – based on IRM’s Writing Better Requirements workshop – takes a top down view of the requirements life-cycle. The paper looks at where business requirements come from and what analysts can do to turn them into solution requirements that developers can work with. Understanding the end-to-end process is a first step in producing well written, clear and specific requirements documentation.
The source of requirements
As we know, every organisation has (or should have!) a business strategy which describes how it will achieve its objectives, its goals. For business units within the organisation to achieve these objectives, opportunities need to be seized or problems overcome.
Equally, every organisation has a framework in which it operates. The framework ranges across many areas – customer needs, market forces, regulatory, how it’s organised and structured, etc. Of particular relevance to the business analyst is the enterprise architecture, the blueprint of the organisations processes and systems.
The business strategy, together with the enterprise architecture, give business units a framework to achieve their business objectives.
To seize opportunities, to solve problems, we need to make things happen and this is done through projects.
Without wishing to upset anyone who might favour one project methodology over another, it’s fair to say that in some shape or form every project has a business case and a terms of reference. These may be written down or in someone’s head, they may be set in stone or fluid and changing. Either way, the business case should be telling us what we’re trying to achieve and the terms of reference should tell us (or at least give us a framework) of how it will be done.
What we’re trying to achieve – be it removing a supply chain roadblock or launching a new product – is the essence of business requirements.
The terms of reference together with the business case, enterprise architecture and organisational strategy, give us our high level source documents for the project.
One of the golden rules of business analysis is to keep an open mind. As such new information (e.g. extra functionality, performance constraints) is often identified by stakeholders during the investigation and analysis phase. If approved, these additional requirements need to be added to the overall scope of the project.
The high level source documents drive business requirements and these business requirements, together with stakeholder requirements, can collectively be called user based requirements. Each one is documented in a template and forms part of our overall single document along with references to the high level source documents.
Although stakeholder requirements translate into business and/or solution requirements, it’s important not to lose track of their individual needs. The needs of stakeholders should be easily identifiable, after all they hold a stake in the project and can make or break it.
Read the full paper here: Writing Better Requirements
If you enjoyed this paper, you may also like:
From Mission Statement to Business Process
