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
User is offline Adrian M.
755 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.

Tony

 

 
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!

 

Regard,

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

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC