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 3: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 1:14 PM
User is offline Adrian M.
762 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 3: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 1: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 3: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

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...



Copyright 2006-2023 by Modern Analyst Media LLC