Knowing What You Need: Gathering the Business Requirements

By now, you’ve read the first in this series of Visichain University papers How to Ensure Software Project Success and you understand the context of a software development framework (SDLC) and process.

Additionally, you understand the importance of iteration throughout the process of software development.

Now we will take a deep dive into prioritizing features via a structured collection of the business requirements.

Gathering Business Requirements

In this second article of our course, we are 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 have them working in your company already, or your development partner will have them in their team.

The job of the Business Analyst is a highly skilled role – these professionals will know how to dig behind your ideas and uncover non-trivial gothchas and, even better, unimagined opportunities that you hadn’t considered. A sharp Business Analyst will save you both time and money, adding tangible value to the final business requirements.

Questions to Consider at this Phase in the Process:

  1. Where do business requirements come from – just from you, or are there other people or organizations you need to involve (the stakeholders)?
  2. Who are they, those people/organizations with a vested interest in the final product?
  3. How do you gather the Requirements, how do you sort the wheat from the chaff?
  4. And then, what’s the next step?

Who Are the Interested Parties: Leverage Your 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?

Graphic depicting stakeholders you need to consult when gathering business requirements for your software development project

Start Building Your 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 rigor is advisable.

Visichain recommends strict control of the Requirements. We prefer to number them and give each requirement 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 we 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 get all the stakeholders in the same room then a Requirements Workshop 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.’

Example of Documenting Software Specification at a Workshop

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 requirements also need prioritization because they will have risk, cost, and resource implications.

An example might be: ‘Must be deployable to both Android and iPhone platforms’.

We certainly would not consider a release to both Apple and Android platforms at the same time, so we would prioritize one or other for the first release although they are both ‘Must Have’.

How to communicate technical specificaiton in supply chain software development

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.

How to communicate a user story to your development team

A good software partner will help with this step. A user story is important because this helps the business analysts and development teams, whether in-house or external, to establish a common understanding of the how the system will work for the users.

We once worked on a retail banking project. Our team filmed the bank tellers at work so that we could engineer the most efficient way for the tellers to process counter transactions with minimum movement of their hands and fingers.

This was then factored into the user stories.

When you plan to change the behavior of users, then you need to consider 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 immensely unhappy, to say the least.

Typically, user stories may be prepared and presented on a spreadsheet. They will be organized by functional area – ‘module’ and in time frames – ‘epochs’. Here’s an example in the screenshot below.

Example of how to document a user story for software development

Check You are All on the Same Page: Confirm Understanding Across Stakeholders

The user stories are confirmed with the stakeholders at Walkthrough Sessions, which can be done virtually.

Expect changes: re-working is a good thing because it’s better to capture issues early on to 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 will have a clear feel for the solution that will be built. But, being an iterative process, revisiting will be necessary.

The main points:

  • 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

Our next article will help you understand how to Firm up the Software Requirements Specification as the final vision of the software starts to crystallize.