Business Analyst Community & Resources | Modern Analyst

The Community Blog for Business Analysts

Neetu

Requirement vs specification

As a business analyst, we capture client requirements in different documents like BRD (business requirement document), FSD (functional specification document) and SRS (software requirement specification). If we are capturing the requirements in these documents, then why the document nomenclature is different? The answer is Yes. We are capturing the requirement but from different perspective. That’s why the document nomenclature is different.

Requirement refers the business need from the perspective from business user whereas the specification defines those requirements from system perspective. Requirements document what is needed whereas specifications document how to achieve the requirements.

The requirement represents the problem or need whereas the specification provides the solution to that problem/ need.

The requirement is gathered from business user/ stakeholders whereas the specification is provided by technical team keeping requirements in mind.

The input for requirement is the business users whereas the input for specification is requirement document, business users and technical team.

The output for requirement is requirement document like BRD, concept note whereas the output for specification is specification document is SRS, FSD.

The combination of complete, clear and concise requirement as well as specification is the recipe of fulfilling business user's need and to retain clients.

This entry was published on Mar 07, 2020 / Neetu. Posted in Functional Specifications, Business Analysis. Bookmark the Permalink or E-mail it to a friend.

15 members liked this article

COMMENTS

Dan Tasker posted on Wednesday, March 25, 2020 2:02 PM

Neetu

It's nice that you are writing to help resolve the requirements problem. Those document types you mentioned are an example of how requirements have different levels. I'm happy with the three conceptual levels that the BABOK talks about - Business Requirements, Stakeholder Requirements, and Solution Requirements (although I prefer the older terms Goals, High-Level Requirements, and Detailed Requirements. I discuss these in my Requirements in Context series on this web site, and in the Trips-R-You case study, also published on this web site. I'd be interested in your opinion of what I've presented.

Kind Regards
Dan Tasker

Neetu posted on Thursday, March 26, 2020 4:49 AM

Dan,

Thank you for reading my article. I will definitely read your article and share my opinion.

Regards,
Neetu Gaur

Only registered users may post comments.

Modern Analyst Blog Latests

Jarett Hailes

Three Audacious Goals for Business Analysts in 2013

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

Howard Podeswa

Hey IIBA, What’s Up With That?

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

Adrian M.

BA ABCs: “C” is for Class Diagram

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