The Community Blog for Business Analysts

Surbhi Mahnot
Surbhi Mahnot

Defining Requirements

All professionals talk about identifying business needs, identifying requirements to create tools so that they can help businesses take better decisions. In your career as an IT professional, I am sure at some point you must have heard terms such as “Requirements”, “Business Requirements”, “Software Requirements”, “Project Requirements”, “Technical Requirements” and the list goes on.

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 of the people, this appears to be a simple question. But, this is the most complex question to answer (for the professional responsible to gather requirements, primarily a Business Analyst) as it takes forever to ask and understand “What are the requirements”.

Different people have different ideas of requirements. For a product owner, requirement is as simple as the ability to use/sell the product that helps with the business and revenues. For a project manager working on that solution, requirements are to get the solution developed with best quality that meets all the expectations of the client and minimize resource allocation to bring most benefits to the company. For a team lead, requirements are to identify the technical challenges, build a maintainable architecture and get the solution developed smoothly. For a developer, requirements are to develop the assigned feature or make changes in the software as requested.

Requirements, at first glance are really needs (end objective), wants, suggestions or ideas. Derived from those needs, we set an objective and take a decision about what things should be done or not to be done to achieve that objective.

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 the Business Problem Statement. Unless there is a problem, we can’t think of providing a solution. A lot of analysis and research is carried on before requirement analysis to understand the problem. These involve feasibility study, knowing business terms and concepts, cost/benefit analysis, business strategy etc.

A Business Analyst (BA) starts with a broad and general description of what needs to be done and then starts working with key stakeholders to define the project scope (inclusions and exclusions), high-level business requirements, solution requirements, technical requirements and transition requirements primarily.

Talking about stakeholders, it’s important to know about who they are 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 are involved with the project (directly or indirectly) and have a say in decision making process of the project. They can be:

  • Executive Sponsor — Mostly concerned about funding of the project and high-level information
  • Product Manager — Make important decisions for the project and review & approve requirements
  • Project Manager — Prepares project plan, resource allocation plan, manages the execution of the project 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

There is a whole set of other roles such as Technical Personnel, Technical Writers, Quality Assurance Personnel, Database Administrators and others who can be important stakeholders in a project, depending upon the needs.

How stakeholders help with requirements?

Since each stakeholder plays a different role in the project, they have different requirements too. Sometimes, what emerges as the biggest challenge for a BA is to extract useful information from all these stakeholders that matches the preferences best with the client’s business. This is because each of them view the project from their own perspective!

To create best requirements for a project, identifying responsible stakeholders is important. There are many techniques available such as RACI matrix. Not all stakeholders are important for every project. It is primary task to identify the right stakeholders and their say in the decisions to keep things smooth in long run. (When all speak, it becomes real hard to reach to any conclusion).

How are requirements identified?

“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 solution’s success or failure. It involves the tasks as analyzing, documenting, defining, validating, documenting and managing the changing requirements. There are different standards set in different organizations for the requirement analysis though the primary steps could be identified as:

  • 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 — requirements are documented in various forms 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)

These recorded requirements documents are then collaborated upon to receive feedback from all involved stakeholders. Once the requirements match the needs for the project, it is important to take sign-off to freeze the scope of work and avoid frequent scope creeps at later stages.

Why are 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

Requirements serve as the basis for the project plan and if there are inadequate or incorrect requirements, entire project will suffer at the end.

  • They are used as inputs into the design stages of product development
  • They are important input for verification process for the product developed
  • They represent what functionalities are necessary for the product
Excellent requirements leave no room for interpretation, confusion or omission of critical details and is easily understandable by everyone involved in the project.

Next time when you start with your project, make sure you have all your #requirements…clear and loud!

Stay tuned for more with requirement types, characteristics and more coming up!

This article was originally published by me on LinkedIn

This entry was published on Mar 16, 2017 / Surbhi Mahnot. Posted in Requirements Analysis (BABOK KA) , Requirements Management and Communication (BABOK KA). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  2 members liked this article

COMMENTS

yan senjani posted on Sunday, April 9, 2017 10:34 PM
Nice sharing Surbhi Mahnot,

can we gather our requirement get in one methode?
for example we use design sprint in 5 days or do you have suggestion that common in industries use to gather requirement in simply ways.
any tools to help requirement gathering process.

Thanks

YAN SENJANI
Surbhi Mahnot posted on Monday, April 10, 2017 2:23 AM
I am glad that you liked the article, YAN.

In Agile/SCRUM, the focus is on delivering a working model at the end of every sprint. Hence, the requirements are gathered relevant to the sprint only.

A good practice when working with sprints is, your requirements gathering sprint should be 1 week ahead of the actual work sprint. That way, you can be sure that when you have to start, say design sprint, you already have the requirements. Meanwhile, when the team is working on the sprint tasks, the person gathering requirements should start work for next sprint.

Discussions, Brainstorming, Questionnaire, Gap analysis, Market research, prototyping, use cases are common ways to gather requirements and make sure they match the expectations.

Some tools that I use to track my requirements are: JIRA, MS Office suite, Trello, StoryOnBoard and Mind maps.

Thanks
Surbhi Mahnot
Ken posted on Monday, August 7, 2017 9:57 PM
Surbhi,
I'm the requirements lead for a very large software acquisition. My question is, if we intend on purchasing a COTS product, how useful is documenting the requirements using BPMN? And, if we do use BPMN, is there any utility in transferring that information into a tool like ProcessMaker? I'm just not sure of the return on investment to use these tools.

Vr
Ken
Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
11 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC