Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Agile Requirements and Upfront Roadmaps
Previous Previous
 
Next Next
New Post 11/12/2009 4:47 PM
User is offline Ken Anderson
1 posts
No Ranking


Agile Requirements and Upfront Roadmaps 

This is a continuation of a discussion that started in response to the article "A View to Agile Requirements".

Tony - you asked if I have worked on larger scale projects where formal requirements definition was done.  The answer is yes, and I found them extremely frustrating!   I'm starting to think that maybe we're actually saying the same thing in different ways.

I do agree with you that the approach to requirements gathering has to be tailored to the nature of the problem at hand, and I don't doubt that on a very large project in a complex organization dealing with problems that aren't well-defined, that it is possible that an initial roadmap might be completely changed.

When you say that nobody is smart enough to define such a roadmap up front, you are agreeing with the agile point of view that it is not possible to know all the requirements up front so it is therefore pointless to even try.

Also, I think there is a difference between developing commercial shrink-wrapped software and large enterrpise IT systems.  In the former, I think you not only can, but would have to have an upfront roadmap.  They might evolve, but it's unlikely they would completely change.  For example, I don't the Microsoft Word team would end up deciding to release a spreadsheet application the next time around.

If a project charter is something to the effect of, "Develop a new system that will completely revolutionize the way GM brings cars to market", well, yes than I would agree with you that it would be next to impossible to develop a feature roadmap with any degree of detail.  I think the point of Agile, though, is that you have to start somewhere, so even if you know your roadmap is going to totally change, take your best shot at it - don't spend months doing it, but come with with an initial backlog and set the process in motion.

I don't think we really have any fundamental disagreement here.

Ken

 
New Post 11/13/2009 7:28 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Agile Requirements and Upfront Roadmaps 

Ken:

To restate my orginal comment:   "The problem with, first thing, come up with a high-level - but adequate, "roadmap" of requirements: Nobody is smart enough.  If it were not the case, data flow diagrams would still rule the requirements engineering landscape."

But, if a first-thing, top-down approach is modified to be more pragmatic, it is amazing what can be done.   My approach to requirements elicitation on larger scale projects:  Proceed in as top-down a fashion as possible.    Key words:  as possible.    Basically, I start by creating some mid-level-of-abstraction data flow diagrams - not high-level, and not detail level - but somewheres inbetween.  This is an art, but, surprisingly, when you actually look at the system, is usually not all that difficult of a task.  This approach is much more feasible that trying to proceed starting from the high-level, and proceeding at too detail of a level results in the common "paralysis-by-analysis problems.   

What I focus most on is diagramming the  unchanging business essentials - not features.  (At the higher levesl, these business essentials are the goals and objectives.)  I may have some feature-related information to, for example,  help with readability, but it is all displayed within the context of a model that organized as much as possible on what must be done irregardless of any implementation considerations.   Deprioriting features as much as possible  is key.

I do not get carried away with the data flow diagrams.  Example:  Instead of creating a data dictionary, I just create some notes that expand upon the lables that I gave to the data flows.  I have always found that this is all the development staff realy needs to proceed and working this way is key to rapid analysis.

I then perform structured walkthroughs on the diagrams to verify them.   This usually requires at least a couple of iterations, but since they are not detail level, and since they are quickly created on pencil and paper, required time is minialized.

I next summarize these mid-level diagrams upwards into "the big picture".   Now the project has a big picture of that has gone through some rigorous analysis.   Now the rest of project can proceed in an Agile fashion, making changes  as necessary to the big-picuture.

Tony

 

 

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Agile Requirements and Upfront Roadmaps

Community Blog - Latest Posts

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC