Do you know that many software development projects fail due to incomplete, unclear, or incorrect requirements?
Here’s how it happens: a product owner sends a list of unclear, unprioritized, or incomplete requirements to their software development team who doesn’t bother to look at them thoroughly. (Probably because they don’t have a software requirements elicitation process, which we’ll talk about a bit later.)
Since everybody is interested in getting the app out the door as quickly as possible, they start the project as soon as the coffee brews. And then it begins: the errors and rework, the missed deadlines, the unforeseen risks, the additional expenses.
But this nightmare could have been avoided altogether if only the requirements were clear and complete!
Why does making a clear list of requirements feel like solving a difficult math problem? Let’s first consider what requirements are.
What are requirements, exactly?
Software requirements are descriptions of a software system’s functionalities. But when describing these functionalities, a lot of product owners mix up solutionideas with requirements. Let me show you some examples of what solution ideas look like:
1. Then I select the state where I want to send the package to from a drop-down list.
The phrase “a drop-down list” describes a specific user interface. This is not a requirement, but rather an idea about how the interface might be designed. Is a drop-down list really the best solution here?
2. The app has to allow a user to swipe left and right to navigate between the screens.
The phrase “swipe left and right ” offers an idea for navigation design. But does using swipe guarantee the best user experience for the given app?
While the ideas above suggest how this or that feature should work or what the feature should look like, they don’t provide a clear understanding of the required functionality for the development team. They also limit the possibilities for the designer who might otherwise have come up with better UX solutions.
Sometimes a simple question – “What does a user expect from this feature?” – can help us separate our solutions from problems. Question like this should be asked during the requirements elicitation process.
What is the requirements elicitation process?
Every project that we work on at Yalantis goes through a requirements elicitation stage (or requirement engineering process) where our requirements analyst helps the team elicit, analyze, and document requirements that need to be defined before we can successfully start the app development process.
Requirements elicitation isn’t about transcribing what you say. It’s a collaborative and analytical process that includes collection, discovery, extraction, and definition of business, user, functional, and nonfunctional requirements.
Requirements are gathered from uncategorized product-related information including product descriptions, features, types of users, sketches of screens, design references, links to competitor’s apps, and other documents that have been piling up on your desk for the past few months.
All this information needs to be sorted through.
The requirements elicitation phase requires your full involvement, because every tiny detail can mean a lot for your project. Sometimes we can’t move on until we get your feedback or approve a suggested solution.
It’s hard to describe how the requirements elicitation process happens using abstract definitions. So why don’t we look at a real project?
How we elicit requirements
Let’s imagine you want to develop a job search app where people can find jobs and companies can find candidates. You’ve been lucky to secure the funds, and now you’re going to develop the first version of your app.
You reach out to Yalantis, and we sign a contract for the planning stage. Time to have your requirements elicited! Below are requirements elicitation techniques that we use at Yalantis:
1. Asking questions
According to your app development requirements, app users should be able to perform the following actions in the app:
search for vacancies
apply for jobs
receive push notifications
make in-app purchases (to post vacancies, for example)
bookmark job listings
At first glance, everything seems clear. This information is enough to start project planning, isn’t it? Far from it!
Our requirements analyst will prepare a list of questions to get more details about your app. We typically use a Google doc for questions because we can share it with all team members. Here are a few possible questions that our requirements analyst would ask:
What sign-up options do you want to offer (email, FB, Google+, etc.)?
What fields does a user need to fill in when creating a profile? Which of these fields are required and which are optional? How are we going to validate these fields?
Do we need any background checks for employees to guarantee their qualifications?
Can a user create both an employee and a recruiter account with the same email?
2. Drawing use case diagrams and mindmaps
We aren’t really into writing tons of text to record your requirements. (And if we were, then you would have you read all of it to confirm the plan.) We prefer creating use case diagrams, or mindmaps that illustrate the app’s functionality. Use case diagrams and mindmaps allow us to confirm the scope with you very quickly – during a Skype call, for example.
Let’s assume you’ve answered our questions listed above. Here’s how we can show the functionality in a use case diagram using our software requirements example:
After negotiations and clarifications, you may get a more detailed mind map:
As you can see, eliciting requirements helped us define a high level scope of requirements for the app. Our next step is to go deeper into the details of every feature so our developers can provide you with a precise estimate.
How we document requirements
The next step in requirements analysis is creating documentation. We will talk about why documentation is so important a bit later. Now we’ll go on discussing how to gather requirements and how to document them properly.
1. Write detailed user stories
We rely on user stories to get more details about each feature. A user story has the following structure:
As a <role>, I want <goal/desire> so that <benefit>
We follow the INVEST principle when we write user stories. This principle guarantees that a user story will be:
But even user stories aren’t enough for developers to work with. We want to avoid developers guessing the details for a given feature during implementation. That’s why for each user story we also write scenarios, acceptance criteria, limitations, and constraints.
Let’s take a look at a couple of examples:
User Story 1.As a registered job seeker I want to view job details so that I can get more information about the vacancy I’m interested in and apply for it.
1. User taps on a job listing preview to open details
2. User sees detailed information about a chosen vacancy
1a. User isn’t logged into the app
1a.1 User sees a prompt to log in
1b. User’s profile is unverified
1b.1 User sees an alert to go through the account verification process
Check that the following sections of a job listing are shown:
- short company description
- requirements/ necessary qualifications
- job benefits
- additional information
- contact information
A guest user cannot access job listing details
A link to the company’s profile is available and tappable
“Report the job” option is available and tappable
“Apply for the job” option is available and tappable
User should be logged into the app
User should have a verified profile
User Story 2.As a registered company representative I want to search for a candidate by position title so that I can find an employee who fits a vacancy at my company.
1. User opens a search menu
2. User types a position title and confirms their search
3. User receives search results matching their search criteria
3a. Search results aren’t found
3a.1 User receives an alert
Start typing a position title and make sure that autosuggestions are shown
Make sure you can scroll through autosuggestions to choose the one you want
Type the name of an existing position title in the job listings and check if you get relevant search results
Type the name of a non-existing position title in the job listings and make sure nothing is found
Autosuggestions should be shown after at least 3 symbols (without spaces) have been entered
As you can see, a user story becomes more understandable when it’s specified in such a way.
2. Creating a state diagram
To improve the team’s understanding of the functionality documented in user stories, our requirements analyst next creates a state diagram. For example, here is a state diagram that illustrates an event-driven status change to a candidate’s application:
3. Creating a class diagram
Back-end developers, in turn, might not fully understand the relationships between main classes in the app. In this case, our requirements analyst creates a class diagram:
4. Creating an activity diagram
When you start discussing a candidate’s application process with your team, there might be some differences in the way each team player sees it. That’s why our requirements analyst creates an activity diagram to help your team reach a common understanding:
As you can see, graphically representing requirements can be quite handy during the elicitation process. It makes the requirements much clearer.
We follow Agile principles in our approach to software development, and the process of requirements elicitation is no exception.
Requirements can change as the process of app development goes on. When they do, our requirements analyst will go all the way back to the elicitation activities we’ve described, and the process of requirements engineering will start all over again.
Why do we bother documenting requirements?
Well-documented and easy-to-work-with requirements provide a firm foundation for app development. They give you (and us) a full picture of your project. With clear requirements, you know what should be done to successfully complete your project – and you can trust that your team is on the same page.
With documented requirements, developers know what to develop and testers know what to test. Each team player has everything they need to perform their job.
We encourage our clients to actively collaborate with us on the requirements documentation. We want your feedback and we want you to be part of our team.
Both sides can benefit from this collaboration: you can be sure that your team is on the right path to satisfy your needs and that nothing important is missed, and we can gain a better understanding of what should be developed and how we should develop it.
Your project should never fail due to incomplete, unclear, or incorrect requirements!