Requirements are funny things in that everyone that I know in the business has a slightly different idea as to what makes a good requirement and a lot more ideas as to what makes a bad one. Top of that list is normally one that has been written by someone else. In this post I would like to suggest a slightly different approach borrowed from the world of agile where a requirement is split into two constituent parts. The requirement and the acceptance criteria for that requirement.
We used to talk a lot as business analysts about SMART requirements. This typically stood for specific, measurable, attainable, relevant and time-based.
All of these things are useful but it is really exhausting to write detailed requirements that fulfil all of them. This is where acceptance criteria come in. These are a relatively new concept from the agile world that are used to determine when a user story has been completed.
There are also those amongst us who believe in behavioural based design that like to write these as tests that can be applied to the system to determine if they have been met in the format of given…. When.. then.. The problem with this approach is that it is a bit like drawing a box by colouring in everything around it that isn’t in the box. Much easier to just draw four lines and then colour in the rest. It is also much easier to define the functionality in detail before defining how to test that functionality.
What acceptance criteria really do for us though is allow us to separate a high-level requirement that has a business benefit and sponsor from the description of behaviour that proves that it has been implemented.
So if we examine our SMART acronym then the acceptance criteria handle the specific, measurable and attainable while the business case associated with the user story determines the relevance and the drop dead date covers off any time sensitive user stories.
Requirements
The typical agile approach is to develop a catalogue of requirements (called a backlog) written in the form of a narrative (as a … I want to … so that…) which is enough to allow the project team to assign a points score for each of these user stories and to determine the overall scope of delivery for a minimum viable product. This can then be supported by a problem statement to further elaborate the requirement if there is any ambiguity as to what is required. However the key purpose of the requirement is to clearly describe the intent without the specifics and also to state the rationale to support that requirement. It is also vitally important that a requirement has an owner. This is the stakeholder who is accountable for the user story and delivery of the value that they have assigned to the user story.
Acceptance Criteria
Acceptance criteria are the required changes to system behaviour that are needed to support the requirement described in the narrative and further elaborated in the problem statement.
When determining the acceptance criteria for a user story each component of the application needs to be considered to determine if it is impacted by the change. For instance which pages need to be changed or do we need a new email or report. How are we going to calculate a value etc..
When determining what the acceptance criteria are for a requirement then all of the above need to be considered as well as non-functional acceptance criteria that are not directly related to the functionality of the requirement but do relate to how that requirement is achieved. Once you have completed this impact assessment and defined the new system functionality then it is much easier to write the test cases to determine if these changes have been made correctly. These can be written in the format of Given…when…then..