defining requirements

People often talk about identifying business needs, defining requirements to create products. In your career as an IT professional, you must have heard terms such as requirement analysis, business requirements, software requirements, technical requirements, etc

So, what are these requirements?

Ours is a world where people don’t know what they want and are willing to go through hell to get it

— Don Marquis

Well, to most people, this can be a simple question. But, this is the most complex question for the person who is responsible to gather the requirements, primarily a Business Analyst. It takes endless efforts to ask and understand the requirements

Different people have different ideas about requirements. For a product owner, it is the ability to use/sell the product that helps with the business and revenues. To deliver a quality solution matching the expectations is project manager’s requirement. For a team lead, requirements are on the technical side, for example, a maintainable architecture. For a developer, requirements are to develop the assigned feature or make changes as requested

Requirements are a set of prioritized needs from all the involved stakeholders that form the base for the functionalities or features to be included as a part of the solution

Per BABOK guide, official definition of requirement is:

  1. “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.” In simpler words, a decision-making process to derive requirements from needs
  2. “A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.” It is a step where business requirements are drafted as solutions requirements to get started with developing the solution
  3. “A documented representation of a condition or capability as in 1 or 2.” The documentation is itself a requirement as it helps all the stakeholders and consumers in understanding the requirements for the solution

Where do these requirements come from?

All the requirements arise from a need. We need to understand those business needs or business problem statements. Unless there is a problem, we can’t think of providing a solution. It requires a lot of analysis & research to understand the problem itself. For instance, feasibility study, knowing business terms and concepts, cost/benefit analysis, business strategy, etc

A Business Analyst (BA), firstly starts with a very broad and general description of the business needs. The next step involves working with the key stakeholders to define the project scope (inclusions and exclusions), high-level business requirements, risk areas, assumptions, and constraints

Talking about stakeholders, it’s important to know about their role and how critical is their involvement in the project

Who are stakeholders?

A stakeholder is a generic term for a person or group of people who participate in the project directly or indirectly. They also have a say in the decision-making process of the project. They can be:

  • Executive Sponsor — mostly concerned about the funding of the project and high-level information
  • Product Manager — makes important decisions for the project and review & approve the identified requirements
  • Project Manager — prepares the project plan, manages the execution of the project, resources and works very closely with the BA (Business Analyst)
  • Subject Matter Experts — assists in defining project scope, works with the BA to define business rules, processes and user interface

Other roles such as Technical Personnel, Technical Writers, Quality Assurance Personnel, Database Administrators can also act as stakeholders in a project if needed

How stakeholders help to define requirements?

Since each stakeholder plays a different role in the project, they have different requirements too. Each of them has their perspective, priority and at times they clash with others. This becomes a big challenge for a BA

Identifying stakeholders is important for clear and detailed requirements. When everyone speaks, it becomes really hard to reach to any conclusion. With multiple stakeholders involved, it becomes necessary to precisely state their roles & say in the project. For instance, RACI matrix is one such technique to clearly define responsibilities

How to identify requirements?

The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want

— Steve McConnell

The process to identify requirements from the needs or conditions is termed as Requirements Analysis. A detailed analysis is critical to the solution’s success or failure. It involves the tasks as analyzing, documenting, defining, validating, and managing the changing requirements. Every organization have their own standards for requirement analysis though, the primary steps are:

  • Identify stakeholders
  • Requirements elicitation — capture stakeholder requirements through various techniques such as interviews, questionnaire, joint group discussions, prototypes or use cases
  • Identify requirement categories — categorize all the gathered requirements into functional, non-functional, business, technical or transitional requirements
  • Analyze requirements — analyze the requirements whether they are clear, complete, unambiguous, consistent and testable
  • Requirements documentation — there are various types of documentation such as Business Requirements Document (BRD) to describe business requirements, Software Requirements Specification (SRS) to describe functional and non-functional requirements, Use cases and User stories (in agile context)

All the involved stakeholders work collaboratively on these recorded requirements documents to receive feedback. It is important to take sign-off to freeze the scope of work and avoid frequent scope creeps at later stages

Why are the requirements important?

Per new research,

  • Success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start
  • Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their project
  • Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization

Defining requirements properly serve as the basis for the project. If they are incomplete or unreliable, the entire project will suffer at the end. Next time, when defining requirements, do remember:

Excellent requirements leave no room for interpretation, confusion, or omission of critical 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 *