Friday, March 19, 2010

   Quick Links:   Articles     MA Blog     Community Blog     Templates     Books     BA Humor     Events     Jobs     Interview Questions         RSS Feeds

Business Analyst Forums & Systems Analyst Forums

Community Highlights



AddThis Feed Button

AddThis Social Bookmark Button

Forums
 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  What Does "Just Good Enough" Requirements Look Like?
Previous Previous
 
Next Next
New Post 6/25/2009 2:45 PM
User is offline Irene
23 posts
9th Level Poster


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

Tony,

I like what you said about Agile: "not firm - but don't waste time". I don't think there is anything unwavering either.

Are "just good enough" requirements or essentials something we also call "high level" requirements, which just define a good functional scope for the project? My understanding is no matter what kind of documents you produce, (even no detail requirements or functional specs,) or what responsibles or tile you have, from the whole project perspective somebody still needs to get and define the details before releasing. My question is when? and who should do it?

Irene

 
New Post 6/25/2009 6:06 PM
User is offline kmajoos
127 posts
7th Level Poster


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

All,

Having worked extensively in the DFD focused world using waterfall SDLCs, the requirements delivery process was normally extreme and took a substantial amount of time. Add a fixed price contract to the mix and the level of detail (on paper) becomes horrendous. Yet, in my experience, almost 30-40% percent of requirements done this way never see the light of day.
 
So what level of requirement is right? Well, requirements should be defined at a sufficient level for developers to know what to design and for user to acknowledge that it is what they want. Therefore, borrowing from Buddha, the “middle ground” is sufficient. Buddha was wise – God bless his soul – Ooops!.
 
What is right also depends on the recipient’s “preference”. Many years ago I did research on “decision preference analysis”. Briefly, for decision making we either prefer (like) quantitative or qualitative information. For example,  the quantitative manager who would like to know how many defects had been fixed prefers the answer “18 out of 30 outstanding defects”.  The qualitative manager would be pleased with “just a little bit more than half the outstanding defects”.
 
So when people are to make decisions on requirements, the quantitative manager would want details and specifics and the qualitative manager would be satisfied with “close enough is near enough” answers. Therefore, what is “just right” depends on you – the readers – decision preference framework.
 
Just some thoughts!
 
Warm regards,
K
 
New Post 6/26/2009 10:20 AM
User is offline ajmarkos
249 posts
6th Level Poster


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

Irene:

There is a world of difference between essential requirements and "just good enough" requirements.  The former are specific and concrete, the latter are non-specific and vague.

The BA should stick to the essential (i.e., independent of implementation considerations).   Development staff should handle the implementation specific requirements.  Having said that, the majorirty of BA's actually are very implemntaion oriented.  So there is the way things should be, and the way things really are - two different things.

Tony

 

 

 

 

"

 
New Post 6/26/2009 10:41 AM
User is offline ajmarkos
249 posts
6th Level Poster


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

K:

The majority of times DFD are misused resulting in a big waste of time.   However, properly utilized, and especially for larger scale efforts, DFDing can be much more efficient and effective than the UML or BPMN.  I once worked on a large-scale federal government project that had spent over $150M in analysis - just analysis - and still lacked an adequate understanding of scope.  They were trying to use UML artifacts and because the UML is only for smallish efforts, they had no real idea of what the big picture was.   The Congressional Budget Office was going to kill the project unless someone could tell them what the extent of the project was.  I came late onto the project.  It took me only a couple of weeks to create and verify an adequate scope statement using DFDs.

What is essential in requirements specification?   As a process is defined by inputs and outputs, identification of inputs to a process and outputs from it is essential.  Essential - not "kind of a nice thing to do". 

Tony

 

 

 
New Post 8/25/2009 2:38 PM
User is offline craigwbrown
470 posts
www.betterprojects.net
5th Level Poster




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

Tony

 

Would you fancy doing a paper for this site on how to get to an essential DFD?

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





Subject Matter Experts

Modern Analyst Community Expert

Craig Brown
-General Analysis
-Project & Personnel Management
View Posts
View Expert's Biography

Guy Beauchamp
-Data Analysis & Modeling
-Structured Systems Analysis
View Posts
View Expert's Biography

Jarett Hailes
-Agile Methods
View Posts
View Expert's Biography

Kieran Creaton
-Requirements Gathering & Facilitation Techniques
View Posts
View Expert's Biography

Perry McLeod
-UML Modeling
-Project & Personnel Management
View Posts
View Expert's Biography

The Community Expert is just one way that Project Members volunteer their time to help the Modern Analyst Community. Want to become a Community Expert in one of the following areas? Submit yourself to be selected as a Project Member.

Available topics include:

  • General Analysis
  • Data Analysis & Modeling
  • Structured Systems Analysis
  • BPMN Modeling
  • UML Modeling
  • Rational Unified Process
  • Six Sigma
  • QA/Testing
  • Project & Personnel Management
  • User Interface Design
 


Privacy Statement  |  Terms Of Use
Copyright 2006-2010 by Modern Analyst Media LLC