Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

Reaping the Benefits of Good User Requirements

From User Requirements to System Design

~ By Duncan Haughey

Hands holding paper cards with requirements concept words

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

Three questions to asked 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 resources, 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.¹

Providing a Firm Foundation

Good requirements gathering provides a firm foundation from which to work. Customers must know what you are developing and that it 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 important 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. Like all business meetings, there should be an agenda. Cover these 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. Next steps

Ideally, a business analyst should lead an open meeting where all ideas are encouraged to draw out the customer requirements. Customers are not always used to articulating their needs, so it is important to play back your understanding of their needs to ensure clarity. Additional meetings may be necessary to gather all the requirements.

The requirements are written up by the business analyst in the Business Requirements Specification and shared 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 by email.

Including Use Cases in the Business Requirements Specification can be very useful for documenting business process and identifying roles in the process. Customers often find the diagrams easier to understand than just 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, as well as 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 in a logical way
  • To arrange someone else's thoughts and ideas in a logical way
  • To understand what a software package must do before making a selection
  • To decide whether to buy or build a solution
  • As a point of reference throughout the project
  • To provide a basis for testing

Common Problems

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

  • No time because of tight deadlines
  • Customer not available to meet and discuss requirements
  • Requirements gathering seen as a waste of time
  • Assuming we know what the customer requires without asking them
  • No way of efficiently recording requirements
  • A dislike of requirements writing

Prototyping

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

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

System Design

Once you have established and agreed on a clear 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 useful at this stage and help the team create a clear and unambiguous software design document.

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

Summary

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


References

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


Comments

Be the first to comment on this article.

Add a comment



(never displayed)



 
1500
Enter the word hand backwards.
Notify me of new comments via email.
Remember my form inputs on this computer.

Is Your Project Proposal READY?

Businessman saying: Are you ready in retro style pop art

The mnemonic READY is useful when creating a project proposal. It will help you produce a project proposal that's difficult to ignore.

Work Breakdown Structure Made Easy

Work Breakdown Structure

The Work Breakdown Structure is a deliverable-oriented, hierarchical decomposition of the work to be completed by a project team.

How to Avoid Project Burnout

Exhausted businessman resting on a pile of paperwork with tongue hanging out from overwork

Resources on projects can be susceptible to burning out before the project finishes. Here are a few ideas to prevent burnout in project teams.

Learning from Project Failures

Success and failure directional signs

Some of the most important lessons we learn come from failures. Kenneth Darter explains a simple four step process to make sure the same failures aren't repeated.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Duncan commented on…
10 Rules of Highly Successful Project Management
- Mon 26 September 7:50am

John Corbett commented on…
10 Rules of Highly Successful Project Management
- Mon 19 September 1:36pm

London Management Centre commented on…
Get Maximum Benefits of Merging Top-down and Bottom-up Project Management
- Mon 19 September 11:29am

Latest tweets

General Project Management • Best Certification For Me? https://t.co/KZdv5lIiKy #pm #projectsmart about 9 hours ago

General Project Management • Re: Course Recommendation! https://t.co/R001FDPE3A #pm #projectsmart about 19 hours ago

General Project Management • Re: Need help with technological terms https://t.co/JlHbxg6tks #pm #projectsmart about 19 hours ago