Identifying requirements, the right way

Requirements Type

Requirements define the needs of the project to provide the best of its utility and benefits. Identifying requirements is crucial for a project’s success. If not done properly, it might lead to failure of the project no matter how good the concept and design is

A project comprises many functionalities and similarly, a requirement is composed of various types. This categorization of requirements makes the analysis process much simpler and clear for all the involved stakeholders. BABOK categorizes the requirements primarily as:

  • Business Requirements
  • Stakeholder Requirements
  • Solution Requirements — Functional and Non-Functional Requirements
  • Transition Requirements

Identifying so many types of requirements can lead to some confusion also. So, how to identify these requirements?

To start identifying requirements, a simple approach is to visualize the complete process and start step by step

To do that, let’s look at cooking for an example:

When you plan to cook a meal:

  • First, comes the question for whom you are cooking?. Is it for yourself or your family or the kids? These define your Business Requirements
  • Then, you decided on some extras as per each member. For instance, you sipping wine and non-spicy food for the kidsstakeholder’s requirements
  • Next, you get all your ingredients necessary for cooking the mealfunctional requirements. Also, take into consideration the time you require to prepare the meal and preparation required for serving the foodNon-functional requirements
  • Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leavestechnical requirements

Let’s understand each of these requirements with a technical example to Implement Log-in functionality

#1. Business Requirements

These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc


There shall be a Login screen through which Users will log into the system

Tip for identifying requirements: Words or phrases that describe what, such as “we need to be able to”, “we need to solve this” and “we need a way to

#2. Stakeholder Requirements

These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from a unique perspective. Therefore, you must understand every stakeholder’s needs. It also becomes important to ensure that all these requirements doesn’t conflict with each other


As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder — Customer)

As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder — Administrator)

Tip for identifying requirements: Similar to business requirements, but from the user’s perspective. Words or phrases that describe what, such as “we need to be able to, we need to solve this” and “we need a way to

#3. Solution Requirements

These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is a document to capture both functional and non-functional requirements

#3.1. Functional Requirements

These define specific behaviors, responses, information, rules for the solution primarily addressing the following:

  • Functional capabilities – The features the system will support
  • Business Rules – Data validation rules
  • Use cases – Interaction between different stakeholders within the system

These requirements include a complete description of ‘how’ to build the system


  • Registered users shall be able to login with valid username and password
  • On successful login, the user shall be redirected to a landing page in the system
  • On failure, for not registered username prompt “Username not registered” message and for invalid credentials prompt “Invalid credentials”
  • New users shall be able to register with the system by clicking on the “Sign-Up” link
  • Users shall be able to recover the password by clicking on “Forgot Password” link

#3.2. Non-functional Requirements (Quality-of-service)

These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity, or anything that would help the success of the system in the real-world


  • Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max)
  • Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click
  • Platform: The login functionality shall behave same on different platforms (Windows/Linux)

Tip for identifying requirements: Functional requirements are “verbs” and non-functional requirements are “adjectives” on these “verbs”

#4. Transition (Implementation) Requirements

These define conditions or capabilities only required to enable the transition of the solution from development to real-world business use. It describes what to do with the process, technology, education, training, enhancements before getting from the as-is into the to-be


Not valid in this example but for an explanatory purpose: The login system shall behave same once “Single-Sign-On” functionality is complete

Tip for identifying requirements: Look for temporary requirements such as “migrate from old system to new system”

There are many other types of requirements across diverse types of systems based on the scope. For instance:

#5. Technical Requirements

Once the solution requirements are clear, the best way to start with the development frequently involves technology. Technical engineers often write & maintain these requirements. It is a way to communicate between analysts and engineers (programmers, architects, designers). These requirements specify design and architecture for the solution components to be developed and implemented. They define how to program the solution, store data, and display it


  • Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera
  • Requires browser to have JavaScript enabled

Tip for identifying requirements: Technical jargon is used such as “password encryption algorithm” and “database schema” etc

#6. User Interface Requirements

These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links, etc. on the screen to allow the working of the functionality. Generally represented with wireframes


  • Textboxes for username and password shall be placed below the respective labels for Username and Password
  • Login and Cancel buttons shall be present in the center of the screen
  • A sign-Up link shall be present below the Login button
  • Forgot password link shall be present above the Login button

Requirement analysis is all about understanding, identifying, and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details

This article was originally published by me on

Surbhi Mahnot

Surbhi Mahnot

Surbhi Mahnot is the owner of this blog. She works as a Management Consultant with businesses to set up processes, and coordinate as Project Manager to help develop IT solutions. Travelling, reading, and shopping are her core interest besides work. Surbhi is available for consultant projects full-time, part-time, or remote work

Leave a Reply

Your email address will not be published. Required fields are marked *