Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  Wikipedia needs your help
Previous Previous
Next Next
New Post 2/1/2012 7:10 AM
User is offline Tony Markos
493 posts
5th Level Poster

Re: Wikipedia needs your help 


Below I attempt to answer your questions about needed requirements types and essential requirements by means of data flow diagrams.
Note: In the below, I am only referring to behavioral requirements, also called function or process requirements. I am not referring to performance requirements, data requirements, or timing requirements.
 Data flow diagrams are used to capture manual and/or automated system required behavior. Lets say that we are performing an enterprise analysis (the whole enterprise is considered as one big system) by creating a larger set of data flow diagrams. The topmost diagram will be a context diagram in which the diagram’s single process/function will be labeled with the highest level behavioral requirement – the highest level goal or object – of the enterprise. There is no higher level required behavior of the enterprise than this.
Now let’s say that we decompose the set of DFD’s many layers down. Within these layers, every requirement, whether that requirement is a higher level abstraction of lower level requirements or is a bottom-most level detailed requirement, and whether that requirement is implemented manually or is implemented by software will be captured by us in modeling the whole enterprise.
Guess what! We have created an all encompassing requirements document without having to break the requirements out into categories of business requirements, stakeholder requirements, and solution requirements. What do you call this single category of behavioral requirements.   Answer: Anything you want, just don’t muck things up by falsely partitioning the requirements into unnecessary additional categories
If additional categories are not needed, i.e, if the all the requirements can be captured using a single type of requirements, then any additional categories only unnecessarily complicate things.   And unnecessary complexity is real quick way to kill a business analysis project.
To necessarily complicate matters a little, while we only need one category of behavioral requirement (whatever we choose to call it), that category can consist of essential requirements and non-essential requirements.
What is an essential requirement?   Example: Lets say we have a business whose sole required behavior (sole goal) is to calculate the sales tax on beer sold in Texas (trying to keep it real simple here). Now let’s say that to make such calculation, a compute has requirements to r roles out the circular polarization, adjusts a servo modulator, and hemulates azel indicators.
In this example, the only essential behavior (i.e., unchanging business requirement) is to calculate the sales tax on the beer. The behavioral requirements of the computer will change as time passes and computer technology enhancements develop. That is the computer’s current behavioral requirements are non essential for the long term success of the business. The essential business behavioral requirements can be re-implemented by newer technology.
The finalized set of DFD’s will be heavily slanted towards essential requirements.


New Post 2/1/2012 12:18 PM
User is offline Jarett Hailes
155 posts
6th Level Poster

Re: Wikipedia needs your help 

Kimbo, I didn't mean to say that I would elicit solution requirements from non-technical stakeholders or take them at face value, only that it was a separate category of requirements. I also drill into any statements made by the business about solution requirements to get the underlying stakeholder requirements. 

Tony, thank you for your explanation. I think we're just using different terms for the same thing, except you have rolled what I would term stakeholder and business requirements into your essential requirement definition and calling non-essential requirements solution requirements. I've never encountered an organization with 'unchanging' business requirements though; competition forces them to adapt, government regulations change, etc. but I agree that solutions to meet business needs are more likely to change in the shorter term.

I have had to perform as-is analysis on entire organizations from scratch and have used the same approach you described, but my representation format has been multi-layered process diagrams using BPMN instead of DFDs. When I have done this the description of each process is considered a high-level requirement, and the details as each process is decomposed becomes the detailed requirements. When performing this work I do not try to classify requirements. 


New Post 2/1/2012 1:30 PM
User is offline Chris Adams
319 posts
5th Level Poster

Re: Wikipedia needs your help 

Jarett, Kimbo, Tony, (and Craig),

We are all very seasoned analyst as is apparent by the great dialog we've all participated in over the years on this community portal.  This truly is a great discussion since it takes what seems at first blush to be a fairly simple question and really questions what makes sense.

Tony, while I appreciate your view on the BABOK keep in mind that it's created by other very seasoned analysts and incorporates feedback from BAs who have been doing this for a very long time and are considered leaders in our industry.  I believe that the amount of time and discussion that has gone into each line of the BABOk makes it quite valuable (even if I don't agree with 100% of its content). 

To all...With that said, the BABOKs classification of requirements I found to be confusing when I first read it.  So I studied it closely and reworked it trying to stay true to what I believe the IIBA meant.  You can read this version/definition of requirement categorization here.

Let me know what you all think.  In addition, I hinted at a topic within this description that is not usually discussed.  That is the idea of conflicting requirements, and I don't me the type of conflicts that come out of poor requirements.  I mean legitimately conflicting but VALID requirements.  I see this happening when the direction of the overall Enterprise is stated, but to best accomplish the overall enterprise goal two different stakeholder groups have requirements which end up in conflict.

Eventually, these conflicts need to be resolved.  This may mean creating processes or solutions which are not optimal for either stakeholder group, but strikes the best balance for the overall enterprise.

I also think its worth talking about requirements of the Enterprise versus requirements of the Customer.  You may ask, shouldn't they be inline, well....not always.  The main goal of the Enterprise is typically to make money for its shareholder/investors. That is NOT the main goal of the Customer. So once again, the requirements that each group might have can be in conflict and must strike an optimal balance. Of course, if an enterprise has goals which are too far out of line with its customer it will not be sustainable!


Chris Adams
Core Member –
LinkedIn Profile
New Post 2/2/2012 8:53 AM
User is offline Tony Markos
493 posts
5th Level Poster

Re: Wikipedia needs your help 


Regarding your article:  You believe that more than one type of behavioral requirement is not needed in, for example, an all encompassing enterprise analysis.   Data flow diagrams prove that false.


New Post 2/2/2012 8:54 AM
User is offline Sandy
74 posts
8th Level Poster

Re: Wikipedia needs your help 

It's really interesting to see the different perspectives being offered here, and I found it helpful to go back and re-read the BABOK definitions within the context of this discussion.  The posting from Chris was very helpful as well.  I think a key point made in BABOK (and in the article from Chris) is that "Business Requirements" are defined through enterprise analysis, while "Stakeholder" and "Solution" requirements are defined through requirements analysis.  Evaluating the classification aginst fit to a single requirements analysis technique such as DFD's or evaluating the different BABOK classifications from the single perspective of "behavioral requirements" unfortunately misses the actual intent of the classification scheme.  It's a bit like criticizing apples because they're not oranges.

The different classes of requirements are not simply different levels of abstraction - they have different attributes, different terminology for describing and defining them, and serve quite different purposes.  When preparing a business case or similar type of project initiation document for example, "stakeholder requirements" (I've also had them called "features", "capabilities", and "stakeholder requests") are a distinct and necessary classification for describing the scope of the 'solution' (independent of manual or technical realizations) being proposed.  They are typically described in a different manner than would be used to describe the high-level behavioral requirements and subsequent decomposition into the detailed essential requirements. 

The important thing to note - and the beauty of the BABOK - is that no single tool fits all purposes and all situations.  The value of a stakeholder requirements classification in activities such as business case development does not negate the value of solution requirements when describing a solution in full detail.  The need to decompose behavioral requirements into detailed or 'essential' requirements does not negate the need to define a separate class of requirements in other situations.  The BABOK offers a comprehensive set of tools and techniques, so that we as Business Analysts can apply the most appropriate one(s) in any given project or situation.  The intent is not for every tool to be used in every situation. 

I like oranges (one of my favorite fruits), but they're not all that useful when I need to bake an apple pie.  I think we grow professionally not by doing the same thing over and over, but by adding new skills and new techniques into our repertoire.  Being able to learn from the many different perspectives and experiences posted on these forum discussions is fantastic - so thanks everyone for sharing your thoughts! 

Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Wikipedia needs your help

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...


Upcoming Live Webinars


Copyright 2006-2021 by Modern Analyst Media LLC