Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Wikipedia needs your help
Previous Previous
 
Next Next
New Post 2/9/2012 9:54 PM
User is offline Engle
30 posts
9th Level Poster


Re: Wikipedia needs your help 

 Very interesting discussion indeed, seeing things from differing points of views.

1. The term ' requirement' is used so often and in so many different situations, that applying some context and segregation is helpful. Not merely for the sake of partitioning, but because they're valid thoughts to consider. If one can divide solution requirements into functional and non-functional with a fairly clear divisional understanding of each, then why not the same for business and stakeholder requirements ? The former is for the entire enterprise entity and the latter is for a sub-set of it, yet the first question that must be asked of a stakeholder requirement is ' what does this do for the business ? '. So, while there should be a requirement connection and flow from the top-down, it should be validated. 

2. The DFD technique is generally used by tech folks and theres no mention of it in the Enterprise Analysis Chapter in BABOK. What if other techniques were to be used, how would this fit in with the non-partitioning model ? 

Cheers all, 

 

 
New Post 2/10/2012 6:58 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Wikipedia needs your help 

Engle:

You ask:  If one can divide solution requirements into functional and non-functional with a fairly clear divisional understanding of each, then why not the same for business and stakeholder requirements ?

You also ask:  The DFD technique is generally used by tech folks and theres no mention of it in the Enterprise Analysis Chapter in BABOK. What if other techniques were to be used, how would this fit in with the non-partitioning model ? 

The answer to your first question is in part given by your second question.   The partioning of behavioral requirements unnecessarily into three types confuses BA's alot more than it helps them.  It has lead to the false pigeon holing of data flow diagrams as being largely a tool to model the behavior or requirements encompased within  an automation solution.  That flat out wrong:  The experts of the technique, such as Tom DeMarco make it clear that data flow diagrams are just as applicable for completely manual systems as they are for automated systems . 

The DFD data store symbols, for example, are NOT meant to be just  program or database files.  The ARE meant to be simply data at rest, whether the data is at rest within a computer, on a piece of paper in the inbox on someones desk, within your wallet, or wherever. Data flow diagrams are just as applicable for each of the BABOK's three requirements types: business requirements, stakeholder requirements, and solution requirements.  Such clearly illustrate s that there is no need for three types of requirements.

And by not knowing the real purpose  of data flow diagrams - or use cases, or BPMN for that matter - this whole career field degenerates into "Ya gotta have the right feel",  "Ya gotta just know via experience", and my favorite "Because the BABOK (or IBM) says so" rules when deciding which technique to use.  This is very immature.

Tony

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




Re: Wikipedia needs your help 
Modified By Adrian M.  on 2/20/2012 10:15:07 PM)

Hi Engle,

I like your example - it's exactly right in that the different BABOK classes are different types of requirements, not different levels or 'partitions' of a single requirement type.

For enterprise analysis, the first step is usually coming up with a list of "things" or business needs - then modeling them in various ways to show the relationships between them.  The "things" that are relevant at an enterprise level span a number of different categories, including services, events, capabilities, processes, information, products, etc.  There are different framework or taxonomy structures for organizing the 'list of things' such as Zachman Framework for Enterprise Architeture and National Institute of Standards and Technology (NIST).  From the list (regardless of how you document it), the type of diagram used to show relationships just depends on the perspective that you want to show or communicate.  The Open Group has released version 2 of their ArchiMate meta-model - the link below shows some example meta-model diagrams (using version 1, but still applicable), and there is a diagram on this page that shows how the enterprise business model can be decomposed down. 

http://iea.wikidot.com/meta-model

Other diagram types that show different perspectives are capability models and value-stream models.  Information flows (using DFD notation at the top 1-2 levels) show a limited but still very useful perspective - since information and information integration are very key to any business.  (And I use "limited" to mean targeted to a specific perspective, not to infer any criticism of the diagram because I do find them very useful).

For those readers who are wondering a business architect actually does, there's a good article on BATimes:

http://www.batimes.com/articles/the-bad-ass-ba-business-architect.html

 
New Post 2/10/2012 9:53 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Wikipedia needs your help 

Hey Sandy:

You say regarding the first web page you refer to:  "and there is a diagram on this page that shows how the enterprise business model can be decomposed down."  Specifically, which of the diagrams on that page are you referring to?

Tony

 
New Post 2/18/2012 5:43 AM
User is offline Robin Goldsmith
2 posts
www.gopromanagement.com
No Ranking


Re: Wikipedia needs your help 

Thank you for highlighting this need.  I have updated the Wikipedia article and hopefully have provided some of the information people commented on.  I tried to identify my additions but no doubt could have done better at it.  Please note that  I was not the original author of the article, was not the one who cited my book Discovering REAL Business Requirements for Software Project Success, had not looked at the article for several years, and to the best of my knowledge was not the author of any of the verbiage in the article prior to the additions/changes I just made. 

 
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