Welcome back to the Greyloud University where we will help you refine your idea or vision for a software application.
Hopefully, you’ve read the first in this series of Greyloud University papers (‘How to Ensure Software Project Success’) and you understand the context of a software development framework (‘SDLC’) and process; you know about the concept of iteration. In this second article of our course, I am going to cover the gathering of the Business Requirements.
This step will usually require you to work with people known as Business Analysts. You might already have them in your company already, or your development partner will have them in their team. This is a skilled area – these professionals will know how to dig behind your ideas and uncover other possibilities that you hadn’t considered. They can add real value to the final business requirements.
Where do business requirements come from – just from you, or are there other people or organizations you need to involve (the stakeholders)? Who are they, those people/organizations with a vested interest in the final product? How do you gather the Requirements, how do you sort the wheat from the chaff? And then, what’s the next step?
Who are the interested parties: Leverage the stakeholders
Who are the Stakeholders - you will need to identify them? They are key to the process of gathering the Business Requirements. Think about the vision you have of the finished software. Who will use it? Who will interact with it (even remotely, such as a smartphone user sharing a screenshot with a third party)? Who will maintain it – for example, change any configuration data either locally or at a central server – or both? Sad to say it, but even the Revenue Authorities might be a stakeholder in that you could have to provide data for them.
So, you need to compile a list of all the Stakeholders. They need not be named individuals, they could just be roles (e.g. corporate customer, personal customer) – but you will have to choose someone to represent those roles and to provide requirements from that perspective. For commercial viability and to protect your idea (your intellectual property – ‘IPR’) you may choose people within your firm to take on the role of external stakeholders. For example, your Sales Director might take on the role of Corporate Customer at this stage. Someone else might take the role of Remote Personal User. And the Revenue authorities – don’t worry, your finance manager should have that role. Get the idea?
Start building the business model: Gather the business requirements
What does a business requirement look like? Try this out:
Requirement # 1. ‘The sales manager will be required to respond to customer billing inquiries by checking the accuracy of a particular invoice on the accounting system’. Priority: Must Have.
Notice the ‘priority level’. You can use terms such as ‘Must Have’, Should Have’ and ‘Desirable’. This helps to identify what is really important and what, if there is a budget constraint, can be scheduled for a later version. Give your stakeholders something to think about – start with the vision and some suggestions. They will find it easier to build on that rather than start with a blank screen.
A small hole can sink a ship, so this is where some rigor is advisable. I recommend strict control of the Requirements. I prefer to number them and give each one an owner (usually the originator). Capture everything, don’t lose anything – there may be real nuggets buried in there.
And then there are your own requirements if you are an entrepreneur. Is it a killer app you plan? You may need to keep some requirements under wraps from all the stakeholders in the initial stages – and have watertight non-disclosure agreements in place.
You can carry out requirements gathering by email, but I would recommend Requirements Workshops, organized broadly by functional grouping – depending of course on the size of the project and the complexity of the solution. If you can’t run them in the same room then they can be done virtually using Skype or other software. Workshops save a huge amount of time as they will save time and focus the debate. Let people think freely and interact, and remember to capture everything – you don’t want to miss that one killer nugget.
There may well be cross-functional interaction which will define additional Business Requirements – e.g. ‘Requirement #27 Confirm successful transaction by linking to our billing system and return after transaction processing successful or canceled. Priority: Must Have.’
Then, don’t forget to check the competition. What they have (and don’t have) can provide you with useful input to both the Business and Technical requirements – and give you an edge. Hang on, Technical Requirements - what are they?
Nuts and bolts: Identify the technical requirements
Besides the business requirements, there will be a parallel set known as the technical requirements. These will also need to be gathered in order to help identify the technology to be used and manage the operation of the system. Many of these technical requirements will be generated from the Business Requirements. A good software partner will help you flesh these out, along with input from your technical staff. Of course, your business requirement might be to ‘provide a technical solution to screen-scraping a smartphone screen’. The technical analysts will help you clarify these requirements. These also need prioritization as they will have risk, cost and resource implications.
An example might be ‘Must be deployable to both Android and iPhone platforms’. I certainly would not consider a release to both Apple and Android platforms at the same time, so I would prioritize one or other for the first release although they are both ‘Must Have’.
Give people a picture: Produce the user stories organized by functional modules
What are User Stories? It’s simple, these are a visualization (and/or description) which describe what the end user or user of a system does or needs to do as part of his or her job function. You need to produce these for each user role you identified (remember the stakeholders, although might not have user roles within the system)?
A good software partner will help with this step. It’s very important because this helps the business analysts and development teams (in-house or external) to establish a common understanding of the how the system will work for the users.
I once worked on a retail banking project (when banks were still on the High Street) and we filmed the bank tellers at work so that we could figure out the most efficient way for them to process counter transactions with minimum hand/finger movement. This was then factored into the user stories. Of course, if you plan to change the behavior of users then you need to consider this very carefully, as there could be serious implications – as happened when Microsoft released Windows 8. The changes to the Windows user experience (‘UX’) were significant and users were unprepared – and very unhappy.
Typically, these user stories may be prepared and presented as a spreadsheet. They will be organized by functional area – ‘module’ and in timeframes - ‘epochs’.
Check you are all on the same page: Confirm understanding across stakeholders
The user stories are confirmed with the stakeholders usually at ‘walkthrough sessions’ which can be done virtually. Expect changes - re-working is a good thing at this time as it’s better to capture issues early on and save cost and time.
For the record, keep a set of minutes and ensure all stakeholders confirm them.
Closing words: The fog starts to clear
By the completion of this stage, you (and the stakeholders) should have a pretty good feel for the solution that will be built. But do remember that it is an iterative process and some revisiting may be necessary. So:
- Identify all the Stakeholders
- Use the Stakeholders to gather and prioritize the Business Requirements
- Compile the Technical Requirements with the technical team
- Produce the User Stories
- Confirm the User Stories with the Stakeholders
My next article will help you understand how to Firm up the Software Requirements Specification as the final vision starts to crystallize.
