How to Build Great Software - Requirement Gathering

by Ifenna Ozoekwe-Awagu

At Mobnia we pride ourselves in building digital products that help you succeed. But how do you build a software product that is reliable and robust? This is the fourth in a series of posts that address this question.

Requirement gathering is an important part of your project. It's the first link in the chain so it's the first place your project can go off the rails.

Requirements Defined

Requirements are the features your application should provide. They're gathered at the start of the project from your customers and used throughout development to ensure the right thing is being built. At the end of the project, they're used to verify the finished product is what the customer asked for. Large projects require a number of requirements that are formally spelt out and greatly detailed. The following are properties requirements should have:

Clear

Requirements need to be clear, concise and easy to understand. There's no room for jargon. Technical terms and abbreviations are allowed if they're common knowledge in the project's domain.

Each requirement must state in concrete terms exactly what it requires. They can't be vague or ill-defined.

Unambiguous

If the requirement isn't worded to tell you exactly what it requires, you can't build a system to satisfy it. If a requirement says your program will "find the best route from point A to point B", what exactly is meant by "best" route? The shortest in distance? The shortest in time? A requirement should communicate the same thing to all the people that read it.

Consistent

A project's requirements must be consistent with one another. Not only should they not contradict one another, but they shouldn't provide so many constraints that the project becomes unsolvable.

Generally, your application will have to find the balance between development speed, development quality and cost. You can have two of them but never all three.

Prioritized

Features have priorities in a project. Some are more like nice-to-haves rather than application-critical and can be pushed back to a later release (especially when they are high-cost). You need to be aware of how important a feature is so that when scheduling the project, you can know what you can cut out and what you shouldn't.

Verifiable

You need the ability to know whether or not you've met a requirement. They therefore need to be verifiable, ie: they must be limited and precisely defined.

“Process at least 100 work orders per hour on average during a typical work day”

is better than

“Process more work orders per hour than are currently being processed.”

Words to Avoid

  • comparatives: "faster", "more". How much more/faster? These need to be quantified.
  • imprecise adjectives: "robust", "fast", "user-friendly". They're still comparisons and too imprecise for requirements.
  • vague commands: "maximise", "optimise". These aren't concrete goals. Provide numbers or some other criteria to make the requirement verifiable.

Requirement Categories

These categories can be used as a checklist to ensure you've created requirements for the most important parts of the project. There are four ways:

Audience-oriented Requirements

These focus on the different audiences and their various points of view. Requirements are classified according to the people who care the most about them. Here are the more common ones:

Business Requirements

These lay out the project's high-level goals and explain what the customer hopes to achieve with the project. Customers may define vague goals that really can't be met with software alone ("Improve staff morale by 25%"). Sometimes they are unavoidable in business requirements, but if possible they should be pushed into the business case (a more marketing-style document that tries to justify the project).

User Requirements

These describe how the project will be used by the eventual end users. They usually include stuff like sketches of forms, prototypes, etc. They may be very detailed and specify exactly what the application must do in different scenarios or they may just specify what the user needs to accomplish but not how the application must accomplish it. These requirements should be kept as flexible as possible, specifying the project's needs without mandating a specific approach.

Photo by rawpixel on Unsplash

Functional Requirements

These are detailed statements of the project's desired capabilities. Basically the things the application should do. In this, they are similar to the user requirements, but may also include stuff the users won't be able to see directly, eg: processing workflows.

Non-functional Requirements

They are statements about the quality of the application's behavior or constraints on how it produces a particular result. They specify stuff like the application's performance, reliability and security characteristics.

Implementation Requirements

Temporary features needed to transition to the new system, but will later be discarded. Eg: copying pending invoices from the database of an old tracking system to that of the new one. The method is an implementation requirement.

FURPS

An acronym for functionality, usability, reliability, performance and scalability. These are this system's requirement categories.

  • Functionality: What the application should do. General features like what it does, interface with other systems, etc

  • Usability: What it should look like. They describe features like general appearance, ease of use, responsiveness, etc

  • Reliability: How reliable the system should be. Stuff like when it is available (for use), how often it is allowed to fail, how accurate it is, etc

  • Performance: How efficient the system should be. Things like its speed, memory usage, database capacity, etc

  • Supportability: How easy it is to support the application. How easy it is to maintain it, to test the code, how flexible it is, etc

FURPS+

FURPS was extended to FURPS+ to add requirement categories engineers felt were missing. They are:

  • Design constraints: Constraints on the design based on factors like the hardware, software, network or database.

  • Implementation requirements: Constraints on the way the software is built. (You may need to meet certain standards).

  • Interface requirements: Constraints on the interfaces with other systems. What data will they exchange with your system? What kind of interactions will take place? When?

  • Physical requirements: Constraints on the hardware and physical devices the system will use. Minimum amount of processing power, portability, environmental features, etc.

Common Requirements

These are some specific requirements that arise in many applications:

  • Screens: What screens are needed?

  • Menus: What menus will the screens have?

  • Navigation: How will the users navigate through the different parts of the system?

  • Work flow: How does data move through the system?

  • Login: How is login info stored and validated? What are password formats and rules?

  • User types: Are there different kinds of users? Do they need different privileges?

  • Audit tracking and history: Does the system need to keep track of who made changes to the data?

  • Archiving: Does the system need to archive older data to free up space? Should data be copied out to a warehouse for analysis?

  • Configuration: Should the application provide configuration screens to let administrators change the way the system works?

Gathering Requirements

Listen to Customers (and Users)

Start by listening to customers and learning as much as you can about the problem they want to address. Focus on the problem and not suggested solutions so you can keep the requirements flexible. Take lots of notes, if a request seems odd, dig deeper to find out what's behind it. The customer knows more about their business than you do and may have reasons that they think is too obvious to explain.

Photo by NeONBRAND on Unsplash

Use the Five Ws (and One H)

Sometime customers have trouble articulating their needs. These help:

Who

Get to know about who will be using the software. Are users and the customers the same? Learn as much about the users as possible.

What

Find out what the customers need the product to do. Focus on the goals as much as possible. Keep your options open with regard to solutions.

When

Find out when the application will be needed, if it will rolled out in phases and if so, what features will be needed and when. When you have a good idea of the requirements, you can scheduling techniques to find out how much time is actually needed. Compare this with the customer's timeline and if they don't match, you need to talk with the customer.

Where

In what kind of environments will the application be used?

Why

Why do the customers need the application? Clarify the customer's needs and see if they're real. Do they really need to be implemented? Is that really the problem?

How

You shouldn't completely ignore the customer's ideas. If customers are doing something in a certain way for example, you may reduce training time by making your application follow a similar approach.

Study Users

Customers (and users) may not tell you everything they do/need to do. They may take some details for granted. By studying the users as they work, you can learn about what they need to do and how they currently do it. Then you can, with your engineering perspective, look for solutions that may not occur to said users.

Refining Requirements

When you've gotten the requirements, you need to develop ideas for solving the user's problems by distilling the goals into approaches. The goals you've collected have to be broken down into forms, navigation techniques and other features the application must provide to let users do their jobs. The following sections describe three approaches for doing this:

Copy Existing Systems

If your system replaces an existing one or a manual process, you can use behaviors from the existing setup as requirements for the new one. This makes things more straightforward for you and increases the possibility of the requirement actually being satisfied. It also provides an unambiguous example of what we need to do.

It does have its disadvantages. It may be difficult to unify the changes you plan to make and the components from the old system. They may be impossible to reconcile. Users may also be unwilling to allow the existing system to be streamlined if you're basically upgrading it. They may want to hang on to features you've determined are useless.

Utilize Experience

When the people writing the requirements understand the customer's needs and have previous experience, they more easily understand what the application needs to do. They can bring up requirements comprising everything needed for a successful project. This applies across the project team, but more importantly to the team lead. A project's chances for success are greatly improved if the project lead has experience with similar projects.

Brainstorm

The above techniques share the common disadvantage of being unlikely to lead one to new innovative solutions better than the old ones. You need to brainstorm to find creative solutions.

Photo by Headway on Unsplash

One approach is the Osborne method. Here, as many ideas are gathered as possible, without care for practicality and quality. When a large list is assembled, you examine them more closely to see what deserves further work. Participation should be thrown to as large a group as possible (users, customers, architects, developers, etc) to increase the diversity of ideas. The method follows four rules:

  • focus on quantity
  • withhold criticism
  • encourage unusual ideas
  • combine and improve ideas

Other techniques include:

  • Popcorn: People speak out as ideas occur to them. Ideal for small groups.

  • Subgroups: Break the group into smaller groups and have each one brainstorm. They then come together and present the best ideas. Ideal for larger groups.

  • Sticky notes: Participants write down ideas on something. Said ideas are gathered, read out and the best ones voted for.

  • Idea passing: Participants sit in a circle. Everyone writes down an idea and passes to the next person until each person gets their original idea back. By this time each idea would've been examined by the group.

  • Circulation list: Similar to idea passing, but the passing is done outside of a single meeting.

  • Rule breaking: List the rules that govern the way a task/goal is achieved. Everyone then thinks of ways the break said rules while achieving the goal.

  • Individual: Individuals perform their own solitary brainstorming sessions.

Brainstorming is generally useful for finding creative solutions to complex problems.

Recording Requirements

The requirements need to be documented. Sometimes just writing them down in plain English works (if you're very careful). Other ways are:

UML

The Unified Modelling Language (UML) lets you specify how system parts should work. It uses several kinds of diagrams to achieve this. Some diagrams represent classes, others represent behaviours, etc. Unfortunately, it's complicated and so, only useful if everyone involved understands UML, which is generally not the case.

User Stories

This is a short story explaining how the system will let the user do something. The scope of each story should be limited so that they don't take too long to implement. Stories should come with testing procedures for verification purposes. They are easy to understand, expressive and flexible. They can, however, be confusing, ambiguous, inconsistent and unverifiable if poorly written (although this applies to all other techniques).

Use Cases

A description of a series of interactions between actors (users or parts of an application). They often have a larger scope than a user story. They usually follow a template as well, which may look something like:

  • Title: The name of the goal. Usually includes an action and the main actor. Eg: "User Examines Data".
  • Main success scenario: A numbered sequence of steps describing a normal case scenario.
  • Extensions: Sequences of steps showing other variations of the scenario (like when the user enters invalid data).

Prototypes

These are mockups of some or all of the parts of the application. The customers are given a feel for what the finished product will look like and how it will behave. In a nonfunctional prototype, the controls don't actually do anything. A functional prototype looks and acts much like the finished product will, but hacks are allowed. It may even use hard-coded fake data.

The prototype can be used to define and refine requirements based on customer feedback. After this, you could leave the prototype as is and simply use it for reference (throwaway prototype) or you could replace it's code and data with production quality stuff until it evolves into the finished application (evolutionary prototype).

Requirements Specification

How you formally write up your requirements depends on the project. Large projects require more formal documentation.

Validation and Verification

requirements need to be validated and verified. Validation is basically making sure your requirements say the right things.That they describe everything the application should do. Verification involves ensuring that the finished application actually satisfies the requirements.

Changing Requirements

In many projects, requirements evolve over time. Tasks turn out to be harder or more difficult and customers add new features. Changes can be accommodated as long as they don't get out of hand. You can monitor this with a change control board. Customers can submit change requests to this board for approval. The board then decides whether the change should be implemented or pushed to a later release.