Requirements Engineering at Yalantis

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:

  • create profiles

  • post jobs

  • search for vacancies

  • send messages

  • 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:

  • independent

  • negotiable

  • valuable

  • estimatable

  • small

  • testable

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

Acceptance criteria:

  • Check that the following sections of a job listing are shown:

- position

- short company description  

- responsibilities

- 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

Acceptance criteria:

  • 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.


5. Iterating

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!

4.1/ 5.0
Article rating
Remember those Facebook reactions? Well, we aren't Facebook but we love reactions too. They can give us valuable insights on how to improve what we're doing. Would you tell us how you feel about this article?

We use cookies to personalize our service and to improve your experience on the website and its subdomains. We also use this information for analytics.

More info