Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  What Does "Just Good Enough" Requirements Look Like?
Previous Previous
 
Next Next
New Post 8/28/2009 10:19 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: What Does "Just Good Enough" Requirements Look Like? 

Craig:

There is, of course, the classic book "Essential Data Flow Diagramming" by Menamin and Palmer.

The basic idea is to assume a world of perfect technology.  For example, a business has a requirement to, for example, calculate sales tax on a purchase.   In a world of perfect technology, a majical button would suddenly appear to the user.  And the user would simply press the majical button and the sales tax would be instantly calculated: No programming to implement sofware, no database links, no servers - nothing but majic.  (Of course, one can argue that in a world of perfect technology, the button would not even be necessary, just telapathic though, but I wont go there.)

The requirement to calculate sales tax is essential - it is technology independent and is a requirement even if the business has no computers.   All the implementation requirements are non-essential - they exist only because of imperfect technolgoy (i.e., the lack of a majic).  What the BA needs to do is come up with a comprehensive, integrated understanding of the essential functions and, especially, how they all interrelate.  This then gives the logical framework into which all implementatiion considerations are properly pigeonholed.

Craig, the difficulty in understanding the concept of "essential functions" is that the BA needs to be really counter cultural.   The BABOK , for example, teaches things like there are system requirements - which occur within a software system, and there are business requirements.  Not true: Some essential requirements (i.e., business requirements) are implemented by computer, and some are not.   This confustion results in questions like "What is the difference between a business requirements spec and a functional requirements spec?"

Tony

 

 

 

 
New Post 8/28/2009 3:25 PM
User is offline Kimbo
449 posts
5th Level Poster


Re: What Does "Just Good Enough" Requirements Look Like? 

Tony,

I find myself in agreement with you for the first time ever :-)  I think the way you describe Essential requirements is the key to what we do. So much of the output I see from BA's is not about business requirements, its just poor screen design with a mishmash of rules, requirements and lots of solution. Its a constant battle

Kimbo

 
New Post 9/24/2009 7:13 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: What Does "Just Good Enough" Requirements Look Like? 

Tony

 

I don't find any of the Structured ANalysis techniques to actually be in conflict with agile approaches to work.  I think an initial context diagram is essential also.  Maybe even a layer or two down as well.  It can provide a context to the requirements as you move forward.

I do think that in the context of an iterative development you can park the 'keep the solution out of the requirements' concept, as requirements can evolve and respond to the system as it emerges.

For example; your dev team deliver a particular style of search for looking up ice cream shops online.  Why not leverage that search tool when specifying a search for gelato vendors?

 
New Post 9/25/2009 10:07 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: What Does "Just Good Enough" Requirements Look Like? 

Kimbo:

And just look at all the needless confusion that results when BAs think otherwise than in terms of  essential functional requirementsand non-essential functional requirements:  Like the common notition that there are Business Requirements and seperately Functional  Requirements.   On the Requirements Engineering list serv someone recently asked what is the difference is between a Business Requirement and a Functional Requirement.    WEEKS LATER, the "people in the know" were still debating this.   And they all made valid points.  Unfortunately they all made contradicting valid points!

Enterprise Requirements, Business Requirements, Functional Requirements, System Requirements, Business Functional Requirements, System Functional Requirements - this is all a political partitioning - not a logical partitioning of what a BA needs to do in functional modeling.

Tony

 

 
New Post 9/25/2009 10:18 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: What Does "Just Good Enough" Requirements Look Like? 

Craig:

The problem is is that the Agile folks largely espouse the UML techniques - not DFSs (including Context Diagrams).   This is a tremedous roadblock to focusing on the essential - as the topmost essential in functional modeling is identification of inputs and outputs and there ain't no UML technique that seriously addresses inputs and outputs.  

No one gets it:  the Agile modeling battle cry of  "model just enough" is just a cutesy sound bite that upon any critical evaluation holds no water at all.

Tony

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  What Does "Just Good Enough" Requirements Look Like?

Community Blog - Latest Posts

Gen1us2k
Gen1us2k
Most of the IT projects imply constant cooperation between the team members and customers. Although it might be often overlooked, the role and the importance of the client within the project is very crucial. Thus, it is in your interest to build a strong relationship based on trust. However, gaining trust on a single occasion is not a dealmaker &md...
0 Responses
emorphistechno
emorphistechno
Introduction In today's world, most enterprises work aggressively to achieve a higher level of business growth, which is made possible by leveraging one of the best automation technologies. One such technology is Robotic Process Automation (RPA) that plays a vital role in streamlining the customer experience in the most profitable manner.&nb...
0 Responses
Nick Stowers
Nick Stowers
Introduction   When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points clear...
0 Responses






Latest Articles

From an Intermediate to a Strategic Senior Business Analyst
Aug 09, 2020
0 Comments
It is strange how something that is supposed to be simple is actually so complex.  Something that is supposed to be a matter of linear career pro...
Copyright 2006-2020 by Modern Analyst Media LLC