Part 1: The Golden Thread – A Requirements Meta-Model
I am currently mentoring a number of business analysts and this article is in response to a question one of then asked: What is the difference between a requirements document and the functional requirements document? The mentee had been asked (as part of a student project) to produce a requirements document and a separate functional requirements document — slightly confusing. Further investigation uncovered that what was meant by ‘requirements documents’ was in fact the business requirements.
This article intends to provide some definitions to the many different types of requirements and entities that relate to them and some of their possible sources. It also provides a meta-model that explains the relationships between the requirements and other entities and the traceable ‘golden thread’ from a strategic objective to lower-level requirements. This golden thread becomes particularly important to the business analyst as a tool to provide the business appropriate challenge around scope and benefit of requirements.
In part 1 of this article we will focus on the higher-level requirements, often referred to as the ‘Business Requirements,’ of Objectives, Benefits and Stakeholder/User Requirements and the relationships between them. Part 2 of this article will examine the lower-level requirements, sometimes referred to as the detailed, functional or system requirements (I prefer the term detailed requirements as I think functional and system requirements have connotations that can be misinterpreted).
Requirements Types
Objectives and Benefits
There are several types of objectives. These could be described within a company’s Mission, and broken down to be described as a Strategic Objectives and handed down to an Organizational unit’s objectives and be further broken down into a Programme’s objective and still further to a project’s objectives. There may also be strategic programmes or projects that are across organizational units. These are types of requirements. Each of these objectives should have an associated benefit (whether it is articulated or not).
Strategic Objective
Definition:
A Strategic Objective is something that a company focuses its efforts on to attain or realize a strategy that has an associated benefit to the company. Strategic objectives tend to be externally focused and take advantage of an opportunity or address an issue.
Example:
Improve customer service across the organization and increase the Net Promoter Score by 10 points.
Grow annual revenue by 10%.
Possible Source:
Possible sources could be a result of an Enterprise Analysis (such as SWOT and PESTLE analysis), examining a company’s vision and mission or part of a company’s strategy, as a result of market changes. Stakeholders will include the executive, board of directors and trustees.
Relationship to other requirements:
This really is the highest-level objective, and all objectives and requirements should tie back and support a strategic objective in some way.
Organizational Unit Objective
Definition:
This will be much more internally focused than the Strategic Objective. An Organization Unit Objective is something that a part of an organization focuses its efforts on to realize some sort of outcome and benefit, ultimately contributing to a Strategic Objective.
Example:
If the organizational unit is responsible for customer service, an Organizational Objective might be: Reduce our customer call handling times by 20%.
Possible source:
As part of a strategic objective, from the head of the Organizational Unit or a senior manager within the organizational unit itself.
Relationship with other requirements:
These should be linked to a strategic objective and in turn are likely to be linked to programme or project objectives and day-to-day business operations.
Programme Objective
Definition:
A Programme Objective is something that a programme of work is set up to achieve. These often take the form of some sort of change programme that focuses on improving an area within the business such as Customer Billing.
Example:
Merge the billing functions across the organization.
Possible source:
Possible sources could be derived from both strategic and organizational objectives. Stakeholders could include the programme sponsor and senior management associated with the programme, heads of the functions affected by the programme.
Relationship with other requirements:
These could be derived from both strategic and organizational objectives and are likely to be cascaded down to project objectives.
Project Objective
Definition:
A Project Objective is something that a project sets out to achieve with the resources it has. This also allows us to recognize whether the project has been a success or not.
Example:
Improve the resource management of the field force by reducing idle time by 10%.
Possible source:
Project sponsor, senior project stakeholders, programme objectives.
Relationship with other requirements:
Often, but not necessarily, Project Objectives are derived from Programme Objectives; they may also be directly related to a strategic objective.
Figure 1: Objective meta-model
Benefits
All objectives must have an associated benefit. If you are on a programme or project that does not have benefits identified, as a business analyst, you should question this and the value of doing the project in the first place.
Definition:
Something that is good for the business; this could be an improved bottom line as a result of selling more of a particular product, or avoided costs as a result of addressing some sort of regulatory requirement.
Example:
In utilizing our field resource more effectively, we will negate the need to bring in contractors, saving the company £1 million by Q4 2012.
Possible source:
Depending on the level of the objective the benefit is linked to will depend on what and who the possible sources are. For example, a project-level benefit source could be project sponsor, senior project stakeholders and from analyzing the project objectives (should the objective be defined before the benefit).
Relationship with other requirements:
Benefits are related to objectives at all levels; every objective should have at least one benefit.
Requirements and Related Entities
There are several different types of recognized requirements types such as user requirements, functional requirements, non-functional requirements. There are also other types of requirements that may be specific to the domain or the project that the requirements are for such as integration requirement or reporting requirements. This article does not seek to offer an exhaustive list of requirements and instead offers a meta-model of requirements and related entities, such as objectives and business rules, that the reader might find useful.
User Requirements or Stakeholder Requirements
Definition:
A user requirement (or stakeholder requirement) is a requirement that describes a need that a user has, something that has to provide the user with the ability to achieve something — a user capability.
Example:
The user shall be able to record a Sale Lead source.
Possible source:
Some possible sources of these requirements may be Subject Matter Experts, stakeholders on your project, potential users of the end system and previous sets of user requirements that have been used on similar projects.
Relationship with other requirements or entities:
User requirements must tie back to an objective, and in turn a benefit. User requirements also link to functional requirements, data requirements and business rules among others.
Conclusion
The objectives, benefits and user requirements described above are often referred to as the ‘Business Requirements’ and are sometimes featured in a ‘Business Requirements Document’ (BRD). I think the important point is that there should be a benefit related to what our objectives are and in turn what our requirements relate to. In business analyst terms, this is important for traceability and traceability is important as it allows the BA to provide the challenge to the business around their requirements and the value of those requirements being realized.
In Part 2…
In part 2 of this article, we go deeper into the Requirements Meta-model tracing the ‘Golden Thread’ from User Requirement to Functional Requirement, Data Requirement, Constraints and Business Rules.
Figure 2: A requirements meta-model
Don’t forget to leave your comments below.