A few years ago I started organizing the requirements in my projects in a very specific way and that approach has greatly simplified my discussions with project stakeholders. My definitions roughly align with IIBA’s definitions in their Business Analysis Body of Knowledge (BABOK), but are more constrained.
Under BABOK 3.0 there are 4 main groupings for requirements:
- Business requirements (I use a more constraining definition)
- Stakeholder requirements (I use a more constraining definition)
- Solution requirements (I don’t use these very often anymore)
- Transition requirements (I don’t use)
I’ve added two other groupings:
From BABOK, Business requirements are statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.
I use a much more constrained definition than BABOK when modelling Business Requirements.
For me, Business Requirements are functional requirements “imposed” on the business by some external organization. Typically they are imposed through legislative, regulatory, policy instrument (policy, directive, standards etc.), or contractual obligations. They indicate something that the Organization MUST do and are typically realized by Business Products and Business Services (I’m using the Archimate definitions for both).
I model goals, objectives, and outcomes as goals, objectives, and outcomes NOT as requirements. I typically use the OMG’s Business Motivational Model when modelling these concepts, and have looked at Archimate’s Motivation Elements. At the moment though, I, and the Open Group that publishes Archimate, suggest the BMM for more detailed modelling.
The following is an example of a Business Requirement using my definition, taken from a project that will implement a set of Business Services that will allow the owners and operators of Cement Manufacturing Plants to report information to Environment and Climate Change Canada (ECCC). The Business Requirement describes why ECCC as an organization is responsible for delivering the service.
Notice that I use terminology (influencer, assessment, goal, strategy, tactic) from the OMG’s Business Motivational Model to summarize where the origin and rational for the Business Requirement. For more complex projects I’d model each of motivational elements separately, but for this project the narrative was adequate.
On behalf of the Government of Canada (GoC), the Department of the Environment and Climate Change Canada (ECCC) MUST regulate the Air Pollutants from industrial sectors located in Canada
The business requirement to regulate the Air Pollutants from industrial sectors located in Canada traces from:
- GoC’s identification as Air Pollutants as a potential influencer on both the environment and human health
- GoC’s assessment of Air Pollutants and the determination that some are harmful to both the environment and human health.
- GoC’s goal: Protect the environment and human health
- GoC’s strategy to support to this goal: reduce Air Pollutants emitted by equipment and facilities operated within Canada that are known to be harmful to the environment and human health.
- GoC’s tactic to implement this strategy: the creation of Regulations to impose limits on the emission of Air Pollutants emitted by equipment and facilities operated within Canada
- GoC’s has issued a directive to ECCC to create and enforce these Regulations.
To address this directive:
- ECCC’s assessed the industries and their facilities and equipment that produce these emissions to identify those that produce the largest volume of emissions.
- ECCC’s competing goals: protecting the environment and human health vs. minimizing regulatory burden on industry.
- ECCC’s strategies to support these goals: define reasonable exemptions, specify achievable emission limits for the facilities and equipment, define the Responsible Person(s) under the regulations (the Responsible Person is an individual, corporation, or another entity that owns and/or operates the regulated facility and/or equipment), require the Responsible Person(s) to provide information about themselves, their regulated facilities, their regulated equipment, and the results of tests on the emissions from those facilities and equipment.
ECCC has decided on the following tactics to implement this strategy:
- Create the Multi-Sector Air Pollutants Regulations (MSAPR) that will initially focus on Stationary Spark-ignition Engines, Boilers and Heaters, and Cement Manufacturing Facilities.
- Reduce burden on industry by only requiring information necessary to assess compliance to emission limits.
- To regulate these Facilities, ECCC will establish reporting requirements, and require that the Responsible Persons for these Facilities submit to ECCC information about themselves, the Additional Responsible Persons for each facility, their Authorized Official, their Contact Person (if different from the Authorized Official), the location of each Regulated Facility that they own or operate, and information about each each Kiln at the facility.
- To determine the effectiveness of the regulations, and each Responsible Person’s compliance with the regulations, ECCC will require that the Responsible Persons for these Facilities submit to ECCC, on an annual basis the amount of emissions and clinker produced in the preceding year.
From BABOK, Stakeholder requirements are describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as abridge between business and solution requirements.
Similar to my approach to Business Requirements, I limit Stakeholder Requirements to requirements imposed on a Stakeholder by the Organization and write them so they describe something that a Stakeholder functionally MUST, CONDITIONALLY MUST, or MAY do.
- As the Responsible Person for a Regulated Cement Manufacturing Facility I must provide to ECCC a Compliance Report for each Facility I am Responsible for. (MUST)
- As the Responsible Person for a Regulated Cement Manufacturing Facility, IF I cease being the Responsible Person I must notify ECCC within 30 days (Conditional MUST) (not actually a requirement under the regulation, provided as an example)
- As the Regulator I must provide a service that allows the Responsible Person to submit a Compliance Report to ECCC.
- As the Regulator I must provide a service that allows the Responsible Person to inform ECCC they are no longer the Responsible Person
The Responsible Person has a stakeholder requirement directly imposed on them under the regulations. Under the regulation the responsible person must be an owner and/or operator of the facility. If there are multiple owners and/or operators they choose amongst themselves who will be “the” Responsible Person, the rest are identified as Additional Responsible Person. They are all legal responsible for ensuring the submission happens.
From BABOK, Solution requirements describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories:
- functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage, and
- non-functional requirements or quality of service requirements: do not relate directly to the behaviour of functionality of the solution,but rather describe conditions under which a solution must remain effective or qualities that a solution must have.
I actually don’t use these very often anymore, I’m more likely to work with the development team to directly trace the system use cases and mock-ups they provide as realizations from business activities, business tasks and/or sub-tasks I’ve modelled in BMPN. With the notes of these business elements written as user stories that describe in general how an IM/IT solution might help a business worker complete the activity/task. The system use case is written by the IM/IT solution provider so they can explain in detail how the person will interact with the IM/IT solution to complete all or part of the activity/task.
From BABOK, Transition requirements describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.
I don’t use transitional requirements as a category, for me these are more of an attribute of the the other types of requirements. E.g. a transitional business requirement, a transitional stakeholder requirement.
Solution constraints identify specific technologies and standards that must be used by the Solution or even impose a specific solution, and may force otherwise viable options to be discarded. They trace from some from legislative, regulatory, policy instrument (policy, directive, standards etc.), or contractual obligations.
In many projects the individuals who will be using a solution have preferences on what solution or technology to use, the workflow within the tool, the colours, fonts etc. The preferences typically indicate one of many possible options for addressing a requirement. I capture these preferences, but also make it clear that they are preferences and are not the same as a true requirement or constraint.