Among the most important questions for a BA when eliciting requirements are, “how do I know when I have finished?” Or, in other words, “at what stage can I tell that I know all there is to know about this requirement?”
By: Peter Aveyard, Capita Customer Management, peter.aveyard@capita.co.uk and Michael Sylvain, Capita Customer Management, michael.sylvain@capita.co.uk
This article was previously published here.
Peter Aveyard is a serving Business Analysis Manager at Capita Customer Management. He has over 15 years’ experience in Software engineering and Business Analysis, having worked in various industries that include, Finance, Utilities, Transport and Manufacturing. He is also a lecturer in Business Analysis at Bradford IT College and has been instrumental in organising the colleges Business Analysis Apprenticeship scheme.
Michael Sylvain is a Senior Business Analyst at Capita Customer Management (CCM), with experience of analysis, change management, bidding and engagement. As well as working in business process outsourcing, he has over 15 years’ experience in investments and finance. Michael has been involved in the design and implementation of CCM’s analysis framework and internal training Academy programme and has worked with Bradford IT College to assist in their Business Analysis Apprenticeship scheme.
RIF
In the next few articles we’ll be taking a look at how we elaborate on a simple user story and break it down to a point where we can say it is done.
Why use user stories?
Whatever methodology you are used to working with, user stories are a great starting place. That’s because, as structured sentences, they must contain the beginning of a completed set of requirements.
Let’s take a look at an example:
As a customer I need to book a train ticket so that I can travel to my intended destination.
User stories always contain two clauses: the first is a statement that tells you about what needs to be done – as a customer I need to book a train ticket; the second tells you the reason why it has to happen – so that I can travel to my intended destination.
For the purpose of decomposing the user story, we’re just going to concentrate on the first clause because it’s the part that gives us the requirements.
User stories always contain two clauses: the first is a statement that tells you about what needs to be done – as a customer I need to book a train ticket; the second tells you the reason why it has to happen – so that I can travel to my intended destination.
For the purpose of decomposing the user story, we’re just going to concentrate on the first clause because it’s the part that gives us the requirements
Understanding the Format: RIF
Our next step is to make sure we have prepared the user story so that it is in the right format so that we can begin analysis. For this, we can use the acronym RIF, which stands for Role – Information – Function.
Role – the role here is the customer.
Information – the information (or data object) here is a train ticket
Function – the function here is to book
Remember, this is just a start. If you are thinking that there might be more information or customers hidden somewhere in customer and book and ticket, that’s exactly what we’ll be moving on to in the next stage; there are also sometimes more than one of each in a user story, too. For now, we’re simply trying to ensure that our user story has all the relevant parts so that we can begin the real analysis.
Here’s another example:
As a sales agent I need to take payments from customers.
Using RIF we can identify sales agent and customer as roles, payments as the information object and to take as the function.
You can also use RIF to identify where you don’t have enough detail to begin analysis. Here’s an example (from real life) of a badly-written user-story:
As a customer I need information
Using RIF we can see it has a role and – even though we don’t know enough about what information – it mentions information. The main problem is that there is no verb in the sentence that tells us what action is being carried out, or, in other words, the function that we’re doing for the customer with the information.
Summary
RIF is a quick tool to help us check that a user story is correctly formatted – and to identify its high level components – so that we can begin our analysis work. By starting with RIF, this will allow us to start to decompose our user stories – a process that will lead to us knowing that our analysis of the requirements is done.
TYPES OF
If our user story has a role, information (object) and a function we can begin analysis. So what comes next?
Types Of…
We start to extract all the requirements by taking each of the terms in the user story and asking what Types Of them there are. Let’s look at our example user story:
As a customer I need to book a train ticket.
The first term we identified was a Role; in this case the role is the customer. So we need to interrogate this term and flush out all the assumed knowledge and scenarios by asking what Types Of customer are there. In this instance we might discover that there are:
- Regular travellers
- Off peak travellers
- Peak-time travellers
This means we now understand that the role customer contains at least three different variations that may have unique or shared requirements.
We can then ask the same question of Information and Function – the other two terms identified in RIF. What Types Of book are there and what Types Of (train) ticket are there? By examining the Types of customer and ticket, for example, it is impossible to miss whether there are two or more classes of ticket available to customers, or to discuss if off peak is a type of customer or a type of ticket.
Note: In this case, a train ticket is already a type of ticket. If any of your terms already have an adjective or qualifier in them, this tells you there are other Types Of them that will either have different requirements, or need to be excluded from the user story.
It’s very easy to do this analysis on a whiteboard with a client while discussing their user story. It also very quickly generates a large amount of detail – as well as highlighting relationships between types and attributes of some of these types. Below, we’ve used Sparx Enterprise Architect to capture this information about types and relationships – it’s worth noting that developers in user story decomposition meetings can also use this information about types to make the beginning of an information model or class diagram.
Looking at this simple diagram, we’ve determined that there are 3 roles, 3 functions and 3 information objects.
3 roles x 3 functions x 3 information (objects) = 27 possible user stories
There are 27 combinations of these terms and this covers all the possible variations of the original user story. Each of these 27 possible variations is described in terms of testable outcomes which makes it easy to check if they apply with the client.
But we’re not finished: in the next section we will be looking at how we get to the final stage of decomposing a user story.
Summary
User stories can be decomposed into more atomic elements by asking What Types Of terms there are. This flushes out all the possible categories and variations that are assumed in the user story in a clear, logical way that quickly generates specific, testable detail.
UNIVERSAL QUANTIFIERS
So far, we’ve used RIF to transform our user story into the correct format to begin analysis and then used Types Of to uncover the main variations for each user story.
These techniques have already produced a great deal of detail, but how do we know there aren’t still some more types of actors or information left undiscovered in our analysis of the user story? To answer that, we use the concept of universal quantifiers.
Universal Quantifiers
In ordinary speech, we use quantifiers like No, Some, Most or All in order to give information about how many of something there are. For instance, if we were describing apples, we might say “some apples are red” or “most apples are green”. But the terms No and All are different because they are universal quantifiers – they apply to every member of the set they describe. For example, “no apples are blue” tells us something testable and true about every statement about the colour of the object apples.
This is important to us because, as analysts, we’re trying to ensure we always do two things:
- that we’ve captured all the types of things we need to know about
- that the truth of all the information we have captured is testable
Because all our user stories refer to roles and objects, therefore we should be able to quantify all of these terms. By quantifying them, we will then be able to ensure no types of things have been missed, or are hiding additional roles or functions. We will also ensure that all our scenarios are testable.
Example 1: Types of Traveller
In order to explain how we do this, let’s look at one of our earlier scenarios:
As a regular traveller I need to book a season ticket online
Currently this user story only refers to one instance of a regular traveller. As analysts, we need to be sure that what an SME calls a “regular traveller” doesn’t contain some more, hidden types of traveller that behave differently and have different requirements.
One way to test our knowledge is to prefix each term in turn with a universal quantifier in order to make the statement clear and testable in absolute terms. As a result, our subject matter experts can reliably affirm or deny it. Our user story might now look like this:
All regular travellers need to book season tickets online
If our SME confirms that all regular travellers need to do this, then it means that all regular travellers behave the same way – which means they are all the same type of traveller, and that our analysis of user types is complete. But if the SME tells us this is false – that only some regular travellers do this – it means there must be another type of regular traveller or functionality that we have not yet captured.
For example, it could be the case that there is only an online facility for corporate regular travellers. This means that there are further types of regular traveller which have different requirements that we have yet to capture. We can now formulate our user stories appropriately:
All corporate regular travellers need to book season tickets onlineNo domestic regular travellers need to book season tickets online
Example 2: Types of Ticket
While we now understand more about our types of travellers, the next step is to apply this technique to each subsequent term in our user story. After all, when we look at the term season tickets, do we mean No, Some, Most or All season tickets? This time we ask our SME to validate this statement:
All corporate regular travellers need to book all season tickets online
They reply that only some corporate regular travellers can book season tickets online, which also directly encourages them to explain what the reason is for this difference. It might be because there are different types of season ticket or different types of the function to book online, for example. As with all of these techniques, it’s easy do with a whiteboard adding and changing terms as we go, each statement leading to the next question.
In this example, a regular traveller can renew their season ticket online, but they cannot buy their first season ticket online. This tells us there are more types of “book” or “season ticket” than we had previously understood, and one way we could capture this is:
All corporate regular travellers need to book renewed season tickets onlineAll corporate regular travellers need to book first-time season tickets in person at a ticket office
We can then repeat the process for each of the elements uncovered by RIF in the sentence, going back to incorporate extra types of traveller or season ticket into earlier user stories, where necessary. As we proceed logically through the user story, we can be confident we are identifying and testing all the types of roles or information.
Summary
In this section we looked at including universal quantifiers to flush out all the types of elements in our user story.
Whenever we encounter actions described using the quantifiers Some or Most, we know that we need to uncover additional types of roles or information objects in order to understand the requirements fully.
All and No are universal quantifiers. They indicate that the requirement applies to every member of a group identified by the term. When all the terms in a story can be described with universal quantifiers, we know we have completed the analysis of the roles and objects.
The last part is to look at how universal quantifiers apply to the functions in our user story. This is the last part of decomposing our User Story into requirements and is covered in the next section, Functions.
FUNCTIONS
In the previous section we built on our analysis of user stories by using universal quantifiers to ensure we had identified and tested all its component roles and information objects.
While we can use this approach for roles and information objects, we need to consider one additional element when it comes to analysing the main function.
Quantity vs. Frequency
Let’s look again at one of our example user stories:
All corporate regular travellers need to book renewed season tickets online
By now, we’re familiar with how to use types of and universal quantifiers to analyse the function to book and to test what other types of booking there are. The need “to book …online” is, for example, only one type of booking, and we might already have identified other types that include “in-person booking” or “telephone booking”.
In this sense, booking is like our roles or objects which are described and quantified into types using adjectives. However, as the function in a user story is always a doing activity, it’s important we remember to analyse it further. While objects can always be quantified usingNo, Some, Most and All, the frequency of functions can always be analysed using Never, Sometimes, Mostly, Always.
Example
Quantifying the frequency of a function with an SME can be done in much the same way as we quantified roles and objects. Looking at our earlier example, we can add always or never to the function and ask our SME:
Can all corporate regular travellers always book renewed season tickets online?
If the answer is yes, then we know that there are no time restrictions, and that the requirement for this function is that it must be available 24/7 – 365 days of the year. Our lowest-level user story for this scenario then becomes:
All corporate regular travellers need to always book renewed season tickets online
If the SME replies that corporate regular customers can only sometimes book this type of ticket online, it indicates we don’t yet have a complete picture of the requirement. Perhaps there are undiscovered types of an object that we have still not identified – for example off-peak and peak tickets? Or perhaps the time a certain function needs to be available to a type of customer is limited to a set time period? After confirming with our SME, our user story might look like this:
All corporate regular travellers need to always book renewed season tickets by telephone between 0600 and 1800.
Note: In this example, always means that this function is available at all times during the time range specified.
This level of detail means that both the what and when of the function are both clearly testable and have been fully validated against the roles and information involved in performing it.
Finally, once we have defined whether a function is available always, never, or between certain hours, we can then repeat this process for all the other types of customer, ticket and booking to complete our requirements. This gives us a fully decomposed matrix of testable, specific requirements covering all the possible scenarios in each user story.
It’s Not Only Non-Functional
While frequency might be thought of as a non-functional requirement, asking questions about when each function can be done also helps us to ensure we have captured all of the information we need to say our requirement gathering is complete.
As with the quantifiers some and most, when a function is only available sometimes or mostly, this means we have not finished analysing the requirement, and that we need more information to complete it.
Decomposing User Stories: Final Summary
By starting with RIF and types of and then using universal quantifiers and frequency, we can quickly, logically and easily move from:
As a customer I need to book a train ticket
To:
All corporate travellers can book single tickets onlineAll peak time travellers can book return tickets online.
And finally to:
All peak time travellers can always book all types tickets at the ticket office between the hours of 06:00 – 21:00
In the process, a fully testable and complete set of requirements will have been produced from every single high-level user story. This allows you to be confident your analysis is done and that all the scenarios have been captured and validated.
All articles are © 2015 by the authors.
The views and opinions expressed by our authors are those of our authors and do not necessarily reflect the official policy or position of IRM UK.
This article was featured in IRM UK’s Monthly E-newsletter. To subscribe please visit http://www.irmuk.co.uk/usefulinfo/enewsletter.cfm. Please note we are always on the look-out for new contributors so if you have an article you would like published please forward it to jeremy.hall@irmuk.co.uk for consideration.
IRM UK Strategic IT Training Ltd. 2nd Floor, Monument House, 215 Marsh Road, Pinner, Middlesex, HA5 5NE, Tel: +44 (0)20 8866 8366 E-Mail: customerservice@irmuk.co.uk Web: http://www.irmuk.co.uk