Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  Requirements Doc vs Functional Requirements
Previous Previous
Next Next
New Post 11/5/2009 2:09 AM
User is offline bernard
18 posts
9th Level Poster

Requirements Doc vs Functional Requirements 

Hi all

The company I'm in is in the early stages of establishing a full project framework. We're meeting to discuss processes, documentation etc.

I've been asked to produce a template requirements spec and a template functional requirements doc.

In the past, I've always said that this was the same document. The requirements for the business are captured then the actual functional requirements are catalogued along with the non-functional, technical and general requirements.

Am I missing something here? Are they totally different?

New Post 11/5/2009 12:14 PM
Online now... Adrian M.
764 posts
3rd Level Poster

Re: Requirements Doc vs Functional Requirements 

Hi Bernard,

It all depends on a miriad of factors.  They are different if you have reasons to make them different.

I've generally seen all requirements document in the same Business Requirements Document (BRD).  However - at times there are business reasons why there are different.  In the case when the business requirement comem from the line of business and need to be baselined - it is a good idea to have those as a separate document.  In some organizations, functional requirements tend to be document by the technical design team (systems analysts) perhaps using use cases and those tend to lend themselves well to be in separate documents.

If you have a small team, working on small projects, a combined document may work.

One of the advantages of having multiple documents is the ability of different team members working on different documents/areas at the same time. 

Before you create the template(s), you need to gather the requirements for "why" you need this template.  Of course - you're in trouble because you don't have a template to capture your requirements. Oops! 

Seriously - you need to understand why you're doing this and how these artifacts will be used.   Are there any requirements rearding traceability in which case you might want to use a spreadsheet to track requirements or, better yet, an off the shelf requirements management tool.  If the goal is to have requirements be signed-off by the business - is there a need to present them in a form other than text (such as UI Prototypes)? 

etc.  You need to apply business analysis techniques in order to arrive at the answer yourself since there is no off-the-shelf one-size-fits-all solution.

Hope this makes sense!

- Adrian

Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
New Post 11/5/2009 2:00 PM
User is offline Tony Markos
493 posts
5th Level Poster

Re: Requirements Doc vs Functional Requirements 

Bernard stated:

"The requirements for the business are captured and then the acutal functional requirements are catalogued......."

Tony Markos responds: 

A little ways back, on the Requirements Engineering listserv, someone asked the seemlingly simple question: "What is the difference between Business Requirements and Functional Requirements?".   TWO WEEKS LATER the debate was still going on!   Now the respondents were all top-notch analysts, and the answers they gave all made perfect sense.  Unfortunately, all their answers were largely in conflict - and no concensus was reached.

I mean - depending upon who you ask - a given requirement can alternatively  be called a business requirement, functional requirement, business functional requirement, system requirement, business system requirement, functional system requirement, etc., etc., etc., etc.  And each can either can be contained in a document or a spec.

I suggest standardizing on whatever terms are typical for your organ, and realize that in other companies, definitions will differ.



New Post 11/7/2009 12:34 AM
User is offline kr_BA
34 posts
9th Level Poster

Re: Requirements Doc vs Functional Requirements 

Hi All,

   The same confusion was with me once, but I am convinced with what is stated above that my thinking was perhaps correct. I can explain it in few sentences as;

    A requirement doc is something, which is a collection of statement that demand of something (process, system or change), that often highlights some needs or some way to accomplish certain task/goal. To a layman it will appear as a plain English statement of business writing asking for solution. These statements are often high level functional requirement as stated by client which will be further broken down into functional requirements according to the solution perceived. For example a requirement statement can been seen in "Use Case Goal" heading while creating use case specification doc which is a methodology of writing functional spec doc while putting requirement statements in BRD's (Business requirement Specification).

Hope this also help in above context...............Any modification in this concept will be welcomed!



Kumar Rohit


New Post 9/28/2010 2:09 AM
User is offline anonymous
0 posts
No Ranking

Re: Requirements Doc vs Functional Requirements 

HI Kumar

Are you saying that the below set of requirements willalso be considered as high level functional requirements

  • should have login feature
  • forgot password feature
  • ability for the user to logout at any time during whilst in the application

I consider the above as high level functional requirements. which later go into details that result in functional requirements.

Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Requirements Doc vs Functional Requirements

Community Blog - Latest Posts

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - The AI Business Analyst I recently had an engaging discussion with Maria Becerra, a passionate advocate for AI and an accomplished business analyst, on the AI Business Analyst. Maria is a respected name in strategy, business analysis and AI. Her path from Colombia to Canada ...
Hosted by Deirdre Caren in Agora Insights' Blueprints for Success I'm thrilled to have Susan Moore join us for episode 9 in our Blueprints for Success. In this session, Susan shares her rich tapestry of experiences that have shaped her career. Her journey into business analysis (ba) is a compelling narrative of exploration and disco...
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...



Copyright 2006-2024 by Modern Analyst Media LLC