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 5: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.


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

Re: Agile Requirements and Upfront Roadmaps 


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.





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

Community Blog - Latest Posts

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...



Copyright 2006-2023 by Modern Analyst Media LLC