Reaping the Benefits of Good User Requirements

From User Requirements to System Design

Requirements Management | By Duncan Haughey | Read time minutes

A critical part of any software development project is the requirements gathering. Good user requirements lead to better estimates, improved customer satisfaction, reduced cost and shorter project duration. If you are unclear about what you are delivering, how will you know when you have delivered it?

Three questions to ask before the start of any software development project are:

1. Why are we building the system?
2. What do we need it to do?
3. What benefits are we expecting to get from it?

A failure to gather business requirements or to assume we know what is required can lead to a poor outcome, a need for extra people, increased cost and longer duration.

As Frederick Brooks, American computer architect, software engineer, and computer scientist, noted, The hardest single part of building a software system is deciding what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. ^[1]

Providing a Firm Foundation

Good requirements gathering provides a firm foundation from which to work. Customers must know what you are developing will satisfy their needs. Developers need to know what to develop and testers what to test. A high-quality requirements document can provide all of these things.

When creating a requirements document, it is essential to get everybody involved, including the customer, project manager, customer account manager, developers, testers and anyone else with a stake in the project. Requirements gathering is a joint activity, not solely the domain of business analysts and project managers.

A good set of requirements enables the project manager to plan and estimate the project well.

Running Requirements Meetings

The requirements gathering meeting is the time to get all the team members, customers and stakeholders, together to define the requirements for the system. Create the agenda as you would for any business meeting. Cover these six agenda points during the meeting:

1. Introduction to the attendees.
2. The objective of the meeting.
3. The purpose of the project.
4. The customer's requirements.
5. The expected benefits.
6. Any risks and issues.
7. Next steps.

Ideally, a business analyst should lead an open meeting where all ideas are encouraged to satisfy customer requirements. Customers are not always comfortable articulating their needs, so it is essential to draw out their needs to ensure clarity. Additional meetings may be necessary to gather all the requirements in detail.

The business analyst writes the requirements into the requirements document and shares them with the customer. The document must be clear, concise and thorough. The customer should review and agree on the contents of the document. Depending on the relationship, you may wish to obtain a formal sign off either physically or via email.

Including use cases in the requirements specification document can be very useful for documenting the business process and identifying roles in the process. Customers often find these diagrams articulate the requirements better than plain text.

Here are some of the rules for writing requirements documents:

• Write requirements in the language of the user.
• Avoid technical jargon.
• Confirm what the system will not do and what it will do.
• Keep it clear, concise and thorough.
• Include a section for non-functional requirements.

Why Gather Customer Requirements?

Here are some of the reasons for gathering requirements:

• To arrange your thoughts and ideas logically.
• To put someone else's thoughts and ideas logically.
• To decide whether to buy or build a solution.
• To understand what a purchased software package must do before making a selection.
• As a point of reference throughout the project.
• To provide a basis for testing.

Common Excuses for Not Gathering Requirements

Here are some of the reasons often given for not carrying out requirements gathering:

• We have no time because of tight deadlines.
• Our customer is not available to meet and discuss requirements.
• Requirements gathering is a waste of time.
• We know what the customer wants without asking them.
• We have no way of efficiently recording requirements.
• We don't like writing requirements.

Using a Non-Functional Prototype

When your customer finds it difficult to articulate their requirements, non-functional prototyping provides a low-cost way to help them visualise a potential solution. Often customers are not entirely sure of their needs (particularly in software development projects), and a non-functional prototype can help tease out their requirements.

Creating a Proof of Concept

A proof of concept may be required if the technology is innovative or the project team are unfamiliar with it. A proof of concept confirms the IT department's capability to deliver the required solution.

The System Design

Once you have established and agreed on a firm set of requirements, the next step is to model the software solution. Using a recognised notation such as the Unified Modeling Language (UML) can be helpful at this stage and help the team create a clear and unambiguous software design document.

Another helpful approach is Behaviour Driven Development (BDD), a practical and recommended agile software development methodology. It documents and designs an application around the behaviour a user expects to experience when interacting with it. It has the added benefit of keeping developers on track and avoiding the tendency to gold plate or future proof applications. Watch this video to get a full rundown of BDD.

What is Behaviour Driven Development?

Before building the solution, check the software design against the requirements to ensure that what you build meets the customer's needs. Revisit the requirements regularly to make sure you are staying on track.

Final Thought

Requirements gathering is an essential part of project management and software development. Make your aim to create a clear, concise and agreed set of requirements that allow you to provide what the customer wants. You can design and deliver a robust and credible software solution from these requirements. After all, the most complex single part of building a software system is deciding what to build.

References

^[1] No Silver Bullet: Essence and Accidents of Software Engineering, Frederick P Brooks (1987). Addison Wesley.

Recommended read: Requirements Hurried…Project Buried, by G Chandrashekar.