Agile Modeling

One of the challenges I encounter with producing customer requirements for consumption by a development team is overcoming the barrier of understanding. My company does not have dedicated business analysts, so the role of translating customer needs to development needs and architecture is typically handled by our developers. What if they don’t see the big picture of what the user wants, but instead only see a large collection of unrelated detail?

Organizing requirments in categories can help to provide a mental framework, but navigation becomes difficult past 2-3 levels. It’s becoming apparent to me that in order to bridge the gap, some diagramming and coalescing of requirements into pictoral form must be provided. The question is, of the tens of possible types of models, which types are most effective and therefore worth the time?

I’ve found a site that details numerous types of models and diagrams, and provides handwritten examples of each. The silver-bullet takeway from this site is the following:

“know a wide variety of modeling techniques … apply the right artifact(s) for the situation at hand.”

My current problem is that I’ve been away from my brief studies in UML during my Master’s program for six years, and I don’t have command of that wide variety of modeling techniques. I have, therefore, just shared with you the newest item on my personal to-do list…

Advertisements

~ by John Peltier on October 25, 2008.

3 Responses to “Agile Modeling”

  1. […] to draw a complete picture.  So even though one might have the language challenge under control, various types of models (both graphical and verbose) can help to provide views into the system’s requirements from […]

  2. […] of the things I’m trying to convince my team about is the advantage of delivering multiple types of models to provide several views of the requirements.  To me, it makes the requirements more consumable […]

  3. Interesting that you don’t have business analysts.

    At the end of the day the people who need to understand the objective are those cutting the code. Whatever is the most ‘agile’ way to get to this understanding is right. This is a very individual thing, but there are lots of fantastic tools and ideas out there.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: