“Do question, even the basics!
You will be a fool for once!
If you don’t, you will be, for a lifetime.” – Himmilicious
Okay, here’s a little challenge for all of you BAs out there. Find someone who would have no idea what requirements are and explain the subject to them in as simple terms as possible. It’s not that easy, is it? And yet, this is something that we’d be expected to communicate on a daily basis to customers who might potentially know what a requirement is, but not be especially clear how to express them unambiguously or accurately. Moreover, there are plenty of business analysts who are starting out (and a surprising number of more experienced BAs) who can’t confidently answer the question “What are requirements, and what have they got to do with me?” If you’re in that boat, fear not – this post is for you! Call it ‘Requirements 101’, if you will.
Brace yourselves, this is going to be a long one.
As business analysts, we will be expected to carry out many tasks and objectives during an assignment, but the one task that is common across any industry, organisation or business function is the identification, capture and management of requirements. This is a fundamental part of the role, and is a key deliverable for any BA. As this is a vast and complex subject, I can’t cover everything, so I’ll be aiming to give an overview of the basics in this article, and will drill down on more detailed aspects of requirements in future posts.
At its most simple, a requirement is a tool used to clearly, accurately and unambiguously describe something that the client or customer – which may be an organisation, a function, an individual or even a system – wants or needs in order to evaluate and / or effect a desired change. Referring to the Business Analysis Book of Knowledge (BABOK), requirements can be defined as:
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).
This ‘10,000ft view’ forms the basis for how a business analyst needs to approach defining the “ask” from the client, and the mechanics of capturing the requirements rely on well defined and established methods that we’ll look at shortly. However, it’s important to note that there are several different types of requirement that could possibly be captured, depending on the scenario and the business or client needs. These are broadly broken into the following types:
People, Process & Procedural (PPP) Requirements: Understanding the changes or improvements that a client – be it a function, area, organisation or individual – wishes to implement as part of their ongoing operational development, and defining the steps needed to accomplish their aims. These may be driven by market forces (for example, a competitor develops a new market leading product which the client wants to develop their own version of), mandatory changes driven by governments or regulatory bodies, or changes in the ways of working the client is looking to employ, such as outsourcing existing processes to deliver cost savings. Of course, this is a non-exhaustive list, and the reasons for change may vary significantly.
System or Product Requirements: Defining and modelling the properties of a platform, system or application, or identifying criteria required to implement a new system, or make changes to an existing system. These may incorporate technical, Functional requirements which outline the what and why of the ask and sit within a clearly defined scope, as well as Non-Functional Requirements (NFRs), which focus on the when, where and how of delivering the solution – which we’ll look at in further detail later.
Speaking of solutions, you would do well to remember this (and I’ll write it in all caps AND in bold, so you know that I’m actually making a point here);
REQUIREMENTS ARE SUPPOSED TO BE PLATFORM AGNOSTIC.
Got it? Good. I’ll explain why a little further on.
Getting back to the basics, requirements generally can be assessed as falling into one of the following categories, as defined in the classification scheme by the IIBA (www.iiba.org) in the BABOK:
These describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.
These 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.
These describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.
Also referred to as Quality of Service requirements, these 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.
Speaking of solutions, I mentioned earlier the need for requirements to remain platform/solution agnostic, so let’s make something very clear; your requirements should drive the evaluation and selection of an application, product or solution, not the other way round. Too often, BAs are often pressurised into writing requirements based on a very specific product or application, which reduces or removes altogether the organisation’s ability to objectively review a set of options independent of influence. Of course, this may be case of ‘JFDI’ and you will have little choice but to produce requirements in such a way, but we should be clear that this is absolutely NOT best practice, or even, in some cases, ethical.
Requirements can be gathered using a variety of different techniques, such as workshops, interviews or reviewing documentation, and can be captured in variety of ways, such as cataloguing individual requirement instances, use cases or user stories – you may even use several different techniques in combination in order to refine the way requirements are captured. Regardless of the tools used, requirements identification and capture – referred to from here on in as the Requirements Elicitation phase – will generally follow an established set of steps, which may vary slightly dependent on the delivery methodology used in your project, be it Agile, Waterfall or a combination thereof.
The DADA model (Discovery – Analysis – Definition – Agreement), which forms an key part of The Way of the BA method, is used to guide the requirements journey from start to end. Let’s take a look at each of these components within the model.
This stage relies on the Business Analyst to carry out fact finding , formally termed Requirements Elicitation, in order to understand what the nature of the perceived problem is, and what the client or customer is asking for. During this stage, BAs should expect to gather requirements from a number of sources, including;
- Subject Matter Experts (SMEs) within an organisation who understand or operate systems or processes impacted by proposed changes, or who have key insights into how the solution should be implemented from a technical and operational perspective;
- External customers who sit outside of the client organisation (particularly useful when modelling customer experiences with the client or identifying opportunities to disrupt a specific market);
- Solution and/or Enterprise architects, who wish to apply changes to an existing technical infrastructure or implement new platforms and applications, and provide strategic guidance on how a solution may integrate with the organisation, and the technical design considerations and constraints that will need to be taken into account in the solution design;
- Senior stakeholders and sponsors, where requirements needed to be understood to help shape the strategic direction for an organisation;
- Regulatory entities, who may mandate changes which must be implemented by a client.
There are a number of methods that business analysts can use to carry out this step, from running workshops to document, system & process reviews. Business analysts should work through the mechanics of how they are looking to work through Discovery and ensure that they agree and document the approach with key project resource, including other BAs engaged in the project or programme, your Programme and / or Portfolio Manager or equivalent, and most importantly, the Project Manager. Best practice would see the Business Analysis Approach document being formally reviewed by peers and a Lead BA or BA Practice Lead, and securing approval of the approach document by having it signed off by the aforementioned resources – especially by the project manager. The approach needs to align with the project plan, both in terms of projected resource requirements and also in terms of the deliverables outlined at each phase. Having the document formally documented will help you to communicate clearly to the project team and stakeholder what you expect to deliver, when the deliverables are expected to be due, and the effort you think will be needed. More importantly, it helps protects you as a business analyst from scope creep and seeing more work added to your pile without your agreement.
When it comes to capturing requirements the best tool for the job is dependent on a number of factors, including the methodology employed by the project, the budget and time available to complete the phase of the project – which will be driven primarily by the Project Manager and the plan – and the availability and willingness of resource you’ll need to engage with in order to define the requirements. This last point is often overlooked by BAs at the Discovery stage of the project, and it can sometimes be a battle to get the information needed in order to clearly articulate and capture the requirements in full. This can result in the overall design either missing key aspects that the client would want to see, or worse yet, can lead to BAs “filling in the gap” with assumptions because the business resource needed to provide the requirements weren’t onboard with the project or were unwilling to share information. It goes without saying that stakeholder management is a key requisite for the business analyst to carry out any part of requirements elicitation and management successfully.
Other tools useful for requirements elicitation at the Discovery stage include producing user stories (especially for Agile deliveries), and use cases. As your requirements at this stage will usually be captured at the scoping stage, the detail won’t usually require a significant level of granularity, and should therefore be defined at a relatively high level, capturing the outline of the design without too much of the detail. If you’re not sure about just how much detail is required at this stage, you can use this as a general rule; if you can’t fit it all onto a single PowerPoint slide, you’ve probably got too much.
Once you’ve captured everything at high-level, make sure that you walk the requirement through with the stakeholders who have contributed to, or have an designated interest in the requirements. You should have already carried out stakeholder analysis at this stage, which should result in the successful production of a RACI (Responsible / Accountable / Consulted / Informed) model artefact that you can use to identify who needs to be engaged, at what stage and the best approach used for them on an individual basis. At the end of the walkthrough, everyone should agree that what’s been documented is accurate and complete, and you should ensure that the requirements are signed off by all of the appropriate parties and set to baseline status. This is a great way to make sure that everyone is (as close to being) on the same page and avoid additional asks being slipped in under the radar! This leads me to the second key point I’m going to make (again, I’ll say it louder for y’all in the back so you know how important this is!):
REQUIREMENTS ARE NOT WISH LISTS.
If you can get everyone onboard with that idea, you will find life as a BA is a good deal more straightforward.
Key Outputs: Business Analysis Approach, Stakeholder Model (RACI), High-Level Requirements Document, User Story, Use Case
Where the Discovery phase is concerned with putting the framework of the design in place, Analysis is the stage where the detail is fleshed out. At this point, you should be looking to take the baseline high-level requirements captured previously and expand them out into more detailed sub-requirements with the view of modelling a solution to the needs identified in the Discovery phase. As an example, if I have a high-level requirement to “Make a cup of tea.”, my sub-requirements might be identified as needing to include:
• The user will require a cup to hold the tea
• The user will require a working electric kettle to boil the water
• The user will require 0.3L of boiling water per tea drinker to steep the teabag in
• The user will require a minimum of one English Breakfast teabag per tea drinker, etc…
And so we can see that the initial high-level requirement is developed into a more granular set of requirements, building out the detail of the solution. In order to get to this level of detail, further requirements elicitation will need to be carried out by the business analyst. This is likely to require spending time with the Subject Matter Experts (both product/process, and implementation SMEs), architects, process owners, stakeholders and product owners. It’s worth mentioning that your existing high-level requirements will need to undergo review again, and this may result in some of the requirements being changed or even removed from the project scope.
NOTE: In this case, any changes to existing requirements set to baseline status will need to undergo formal change control via Change Request, and may need to have approval secured at the appropriate level (e.g. Programme / Portfolio Manager, Project Sponsor, Executive Sponsor, etc.) in order to be re-baselined.
Details requirements may take a variety of forms, but should at least contain the following attributes:
Requirement ID Each individual requirement should be given a unique identifier which enables it to be tracked and managed throughout the definition and implementation of the solution. The ID should be brief, but meaningful (e.g. “REQ_RPT_01” for a series of reporting requirements) and be indexed in descending order (REQ_RPT_01, REQ_RPT_02, REQ_RPT_03… etc.). It is also possible to ‘nest’ or ‘stack’ requirements and sub-requirements to aid clarity (e.g. (REQ_RPT_01, REQ_RPT_01.1, REQ_RPT_01.1.1… etc.), although this may depend on the rules around managing requirements for the specific organisation.
Requirement Type This may vary between projects and organisation in terms of exactly how this is defined, but should generally describe whether the requirement captured is Business, Functional, Non-Functional, Solution, etc.
Requirement Narrative/Description The most important bit! Here is where the individual requirement describes what is actually being defined. Good practice might see the narrative start off with “The solution will/must…”. Remember that the requirement narrative must describe a single clause or statement; conjoined statements incorporating multiple requirements in a single narrative is not seen as being good practice.
Source Where the requirement originated from, be it an individual, a workshop, a function or even external documents or historic requirements from another project or programme.
Owner The individual or business function who will assume ownership of the requirement and maintain accountability for its delivery unless removed from scope.
Priority Determines whether the requirement is seen as being high, medium or low priority for delivery. This must be agreed by the project with all relevant stakeholders, although there is flexibility for the priority to change according to the business needs and project scope. Several methods can be used to prioritise the requirement, the most common of which is the MoSCoW (Must/Should/Could/Won’t) method. However, the preferred method will be dependant on the organisation / client’s chosen approach.
While there are other attributes that can be used to facilitate the capture of requirements, these are the most common and generally the most useful. Client organisations will usually have a preferred framework for requirements that they wish for BAs to use, and you should work around this in order to deliver the expected output. Let’s pause for a moment and go over the characteristics which constitute good requirements. Any requirement you capture and document should meet all of the following criteria:
Accuracy The requirement is captured in full without any information missing.
Consistency The requirement is fully aligned with in scope reference materials and does not contradict any other requirement documented.
Clarity The requirement should be expressed in an unambiguous way, and documented without using jargon or acronyms (unless they are also documented in a glossary or requirements context) and easily understood by all stakeholders.
Atomicity The requirement is singular in what it is describing and does not conjoin multiple statements e.g. the requirement “The car must have air conditioning and a sunroof.”, should be expressed as two individual requirements; 1) “The car must have air conditioning”, and 2) in “The car must have a sunroof”.
Relevancy The requirement must be up to date and reflect the current or desired future state of change outlined by the client or stakeholders e.g. the requirement “The software must be compatible with Windows 3.1” is irrelevant if Windows 3.1 has been decommissioned and is no longer used within the client organisation at the time of writing.
Traceability It must be possible to meet all or at least part of the business need stated by the client or stakeholders through the documented requirement, and the requirement must be testable.
If the captured requirement fails to meet all of the criteria, then you should consider whether the requirement needs to be changed to meet the standards outlined in the table, or whether it should be in the suite of requirements at all.
You should expect that the analysis and production of detailed requirements can often feel like a series of iterative cycles, as captured requirements are reviewed, discussed and dissected by a number of interested parties. It can be disheartening at times to spend a lot of time and effort in drafting a set of requirements in great detail, only to seemingly have them ripped apart by reviewers and peers during a review! It’s important to remember that requirements should be open to critique and we need to remove our ego out of the process if we are to get to the best output possible. We should remember that the requirements are for the customer not for our own personal glory! Options available to business analysts in order to drive out further detail and analysis include further workshops, 1:1 interviews, and review of existing and new processes, business or technical designs and other related materials.
These techniques are usually targeted towards specialist resource (e.g. process SMEs, Product Owners, developers and technical experts), key business members (e.g. customer experience analysts, heads of department and operational leads) or policy & procedure owners (think Financial Crime and Data Governance functions) as they will usually have the detail needed within the organisation that will enable you to get the information you require to drive out the necessary level of granularity. Externally, you may have to work with product developers and vendors who can provide the insight and understanding of an application the client may be considering, or a third party organisation which may provide an additional service of some sort that the client is looking to engage in. Conversely, requirements can also be used to define the type of service or vendor a client will be looking to go to market for, and the requirements captured will be used as criteria to assess vendor suitability as part of the Request for Information / Request for Proposal (RFI / RFP) activity. Best practice may, dependent on time and complexity, also see you assessing the impact of the requirements proposed against the existing business model or infrastructure, which will also aid you in helping the business to make informed decisions around the solution approach. You can bake this into the requirements catalogue and assign a impact rating or weighting on a line by line basis, or you can roll it up into a summary Impact Assessment document which will need to be reviewed and agreed as a project artefact by the relevant stakeholders.
Whatever the situation, ensuring that the requirements have,
a) the right level of accuracy,
b) the right level of appropriateness, and
c) the right level of detail,
is crucial to ensuring the ongoing success of any project or programme delivery. As business analysts, we should not underestimate the importance of the analysis that needs to go into producing decent requirements at this stage, not should we underestimate our importance to the client and the project. You and the work that you do are extremely valuable!
Key Outputs: Detailed Requirements Document, Requirement Catalogue / Index, Impact Assessment, Change Request
DefinitionThis is a relatively straightforward section to explain, but in practice probably has the most actual work in terms of document output. Following the capture of baseline requirements in the Discovery and Analysis phases, Definition is where the business analyst will model the solution via documents such as Business System/Solution Design (BSD), prototypes & wireframe mock ups (particularly useful for modelling UX when building out systems-based solutions). In addition, the requirements catalogue will be further refined and expanded out to ensure that all of the requirements documented are still fit for purpose, align with the agreed design and have been given defined owners to see through to completion and implementation. It may be that the needs of the project necessitate the requirements catalogue to provide a subset of the captured requirements for a given delivery, particularly if there is a separate work stream (e.g. your wider portfolio of work has a specific section which is highly sensitive, or under Non-Disclosure Agreement). In this instance, it may be appropriate to split out the necessary requirements into a separate document, and limit the access to those who have an approved business case to view it.
I’m adding this amendment on the recommendation of a friend of mine, Des Blackburn, who also happens to be an excellent business analyst (thanks Des!). If you’ve produced a set of use cases as part of the Analysis phase, there’s a great argument to also produce further definition around how data is modelled as part of the solution. This clearly applies to software / application-derived solution or functional requirements. Producing output for data modelling is a useful tool to help you cross reference your use cases and requirements against business constraints that might not immediately be apparent to you. For example, your use case may specify access to a set of finance data in an application, but there are additional constraints around role based access controls (RBAC) being in place to ensure that only specific users should be able to access it. You would capture this in your data modelling output, and ensure that the requirement to control access by role is formally documented and approved by your stakeholders.
Regardless of the approach, you will find that most business users (I.e. your customer) will have little desire to trawl through possibly hundreds of individual requirement line items (especially if you’ve captured them in a spreadsheet!). Here’s where, as a BA, you can really add some value by tailoring the requirements into a more business focused document which provides a detailed description around the key requirements, the impacts they have across business areas and users, how they are driven by the project aims and objectives and call out risk, issues and dependencies in a business friendly language. I generally use a Requirements Context document to achieve this, but you may also look to use the Business Solution Design (BSD) document or equivalent used by the client to achieve this aim. Baseline requirements will need to be managed through the design, build, test and implementation implementation phases of a project delivery, and you will likely need produce a requirements traceability matrix of document to:
1. Identify which requirements have remained in scope for build and test
2. Ensure that all requirements that have been built and test have been done so according to the agreed solution design, or provide a rationale / justification if not.
3. Ensure that each requirement owner is held accountable for the delivery of the requirement through the build, test and implementation phases.
Requirements traceability can be baked into the existing detailed requirements catalogue, or can have a new dedicated document specifically created for that purpose. This is dependent on the methodology in use, and the business analysis approach agreed. Note that ownership of requirement traceability may sit with a Test Lead / Test Manager, with the BA providing guidance and support to ensure completion of the activity and continuity of requirements management.
Once again, you should be looking to have any documentation you produce agreed and approved by relevant stakeholders once you’ve walked the documents through with them.
Key Outputs: Detailed Requirements Document, Business Solution Design, Requirements Context Document, Requirements Traceability Matrix
AgreementThe final step isn’t really a step at all, but is an ongoing activity that the business analyst will manage throughout the process. Every requirement captured, and every artefact produced will need to be reviewed by key stakeholders and project resource, and the approval logged and retained as a historic artefact for the project or programme. I’ve mentioned throughout this article several times how this can be approached, and you may find that you have the most success by sitting everyone you need down in a room, and walking them through the requirements, taking feedback and comments into account until everyone is satisfied (or as close to everyone as possible). Believe me when I say that this is much easier said than done, and you will find that it may take all of your powers of communication, negotiation and persuasion (and possibly bribing people with tea and cakes) to get everyone’s signature against your artefacts.
Once you’ve managed to overcome that hurdle and baseline the requirements, make sure that you store the final version of the documents in a shared location specifically designated for your project (e.g. a network drive or collaborative repository such as SharePoint) and write out to your stakeholders formally, informing them of the location of the baseline documents and that the exercise to produce the artefacts has now been completed. You should also state that changes to baseline artefacts should only be carried out under a controlled change methodology. This is important to prevent scope creep, and other stakeholders attempting to sneak in last minute changes which could blow up the delivery of the solution at a late juncture. If you have written approvals from your stakeholders (pro tip: you definitely should), the emails should also be stored online as project artefacts, and can be used as evidence of the stakeholders signing up to what you’ve captured throughout the requirements elicitation process.
And that’s it! Once you’ve completed the identification, capture and documentation of your requirements, you’ll need to manage them throughout the lifecycle of the project, and possibly beyond.
I’ve had to gloss over a lot of the detail here, and I think I could – quite literally – write a book on the subject of requirements. You can be certain that I’ll be writing further articles on requirements, and a post on requirements management will be coming soon. I’ll also be updating the Resources section with a couple of templates for you to use for free (as I’m nice like that)
Drop any comments or questions in the Comments section below, and for those of you going on your requirements journey, good luck!