Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Business Requirements vs Functional Requirements
Previous Previous
 
Next Next
New Post 8/25/2008 6:09 AM
User is offline Yuri Chernak
1 posts
No Ranking


Re: Business Requirements vs Functional Requirements 

Business requirements and functional requirements have different purposes and are used by different parties on a software project:

 

Business requirements have a purpose to capture end-user needs, i.e., they should be statements about WHAT an application should do for the end-user. Business requirements are first used by project management to plan the next release:

a)      agree with the end-users on the release scope;

b)      estimate the development effort;

 

After the release scope has been agreed, business requirements are used by BA (or developers) to specify solutions to the needs. These solutions (i.e. HOW TO details) are captured as software requirements (where functional requirements are a kind of software requirements). Functional requirements are used by developers and testers.

 

To summarize, business requirements should capture WHAT an application should do, whereas functional requirements should capture HOW the user needs can be implemented (from the end-user perspective).  

 

Hope, this could help. Yuri

 
New Post 8/26/2008 5:29 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Business Requirements vs Functional Requirements 
Modified By Modern Analyst  on 8/27/2008 1:33:49 PM)

Yuri:

I queried Yahoo for a definitions of a functional specification.   This is the very first one I reviewed from the results:

Functional Specification: 

A description of what a system (e.g. a piece of software) does or should do (but not how it should do it). The functional specification is one of the inputs to the design process

No need for me to go any further in researching.   The above is how the I and everyone that I have worked with views functional requirements.   Note: There are essential functional requirements (i.e., the unchanging "what")  and there are non-essential functional requirements (i.e., implementation specific functionality - the how.) 

Tony

 

 
New Post 8/26/2008 1:26 PM
User is offline Jim
15 posts
9th Level Poster


Re: Business Requirements vs Functional Requirements 

You can see why I have a problem distinguishing between the two...becauase everyone has a different opinion.  The terms do not seem to be consistently used anywhere.  Somewhere in every explanation is something about "the What" and "the How" but I have yet to find a good explanation with examples to back the it up.  That is why I was asking for examples in my first post.  Sometimes is sounds like BRs are higher-level features the system must support and the FRs are the details and other times it sounds like they are both refering to the same thing and other times the BRs are the overall business goals and the FR are the requriements.  I'm still unsure of the most effective way to use the two and if it makes sense to think of them as being the same or different.

 
New Post 8/27/2008 1:44 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Business Requirements vs Functional Requirements 

Jimbo:

Maybe this will help:  "Calculate Sales Tax" .     Is this a  goal, process, operation, function,  task, activity, or step?    

Answer:  Whichever you choose.  (Just be consistent.)

Is it a "What" or a "How"?     

Answer:  It depends if it is a goal, process, task,  or step.    If it is a high-level goal, it is a "What".   If is a low-level step required to achieve a high-level goal, then one may consider it a "How". 

Tony

 

 

 

 
New Post 3/9/2009 7:12 AM
User is offline ccory
1 posts
No Ranking


Re: Business Requirements vs Functional Requirements 
Modified By ccory  on 3/9/2009 9:30:22 AM)

I am swooping in a bit on Jimbo's topic because I have had recent discussions in my organization regarding my predisposition (as a Business Analyst) toward "writing too technically".  There has been a swing in expectations in my department recently (new kid in town with different perspective on "industry standard" is shaking things up).  Several of us are writing what they are calling "high-level" requirements (which is what I would consider "Calculate Sales Tax" and leaving the details to Development to work out with Business), and the rest of us are still eliciting this detail as Business Analysts and providing to the Developers in our Requirement documents.  I have been trying to put a "name" for years to my style of Requirement Writing, or to the level of detail I have been documenting.

In my mind, "Calculate Sales Tax" or even "The system shall calculate Sales Tax" is too vague.  It's a good starting point, but should prompt more questions...

I would expect to help the SME's to have an idea, or be assisted in determing:  What is the formula we should be using to calculate Sales Tax?  Does the Sales Tax need to be posted in a separate transaction?  Does it need to be displayed separately from the total amount and from other local taxes?  Is there a different taxable % based on the state the Sales Tax is applicable in?  Are there specific transactions were this tax is or is not applicable?  Will you need reporting on the Sales Tax?

I would not anticipate that our Business Sponsors/SME's/end users would be satisfied with the solutions development comes up with if they are not armed with these answers, as they do not really need to know our "business" in order to code for the needs.  Shouldn't I be eliciting and documenting these specifics?  Are they Business Requirements or are they Functional or System? 

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

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
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...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC