Four Agile Tips to Eliminate Rework in Application Development: Page 2 of 2

[article]

3. Iterate
Rather than spending several months cranking out a comprehensive requirements document, agile methods teach us that it is better to approach the creation of requirements as an iterative process. Creating requirements this way helps generate feedback, promotes collaboration, and enables teams to identify potential defects earlier in the software development lifecycle.

I recommend that the business analyst start by defining the high-level business requirement, describing who needs the functionality for what purpose and why. Then, rather than working in isolation, the analyst should go back to the major stakeholders to get feedback. Does the high-level requirement adequately describe the business need? Is there enough information to get developersstarted? If not, drill down to add an appropriate level of detail and check in again with the stakeholders. Repeat until there is agreement that there is enough information, and then let the developers get going.

Remember that different requirements will require different levels of detail. Reduce complexity by providing just enough elaboration without overdoing it. This will save time for both the business analysts who define the requirements and the application team members who consume them.

4. Visualize
Requirements do not have to be written in paragraph form or as lines of code. Sometimes, a picture really is worth a thousand words. Agile methods teach us that visualization can increase understanding of both the requirements and the dependencies between requirements. Visualization can make it easier to identify potential problems, such as missing use cases. Pictures can also be easier to read and navigate than text-based requirements.

Even with these benefits, it does not make sense to visualize all requirements. The following criteria should be considered when deciding whether to use visualization:

  • Will requirements visualization speed up requirements definition, or will it add more time to the development process?
  • If a requirement is very complex and has too many sub-requirements, will creating a picture turn into a "spider's web" diagram that may overcomplicate the definition of the requirement?
  • Does it make sense to visualize the high-level requirement only and define functional requirements associated with it as text, or is it appropriate to visualize all requirements?
  • Should high-priority or high-risk requirements be the only candidates for visualization? 

There are many methods to use for visualization of requirements. For example, when showing how a user will move through an application to make a purchase, using a tool such as Microsoft Visio to define process flows would be appropriate. However, mockups and more rich-content visualizations will be more suitable when describing how a new user interface should look.

Requirements visualization is not a panacea for business and IT communication, but it can act as a facilitator of better understanding between business analysts and the rest of the applications team.

Summary
Building applications right the first time is more important than ever. These applications not only need to meet the needs of the business, but they have to overcome extremely complex processes. To add to the challenge, customers are accustomed to accessing information when they want it, meaning the applications need to always be available, in an instant. 

In order to overcome these complexities, organizations should leverage these practices to properly define application requirements. This will allow application teams to execute more efficiently, lower costs, and eliminate rework—all while meeting the needs of the business and providing instant results to customers.

User Comments

5 comments
Jonathan Kupersmith's picture
Jonathan Kupersmith

So is this Agile or just sound practice. I agree with your 4 tips completely and all of these should be part of how we run projects. But to me this is not new with the popularity of Agile. Teams need to do things in smaller manageable chunks. Teams need to collaborate. The days of 400 page docs should be past us. Teams have been running projects like this for years. And if they are not they should.

Thanks for sharing.

June 7, 2011 - 9:04am
Renee Seltzer's picture
Renee Seltzer

I completely agree. I especially think it's important for companies to connect more with their end-users. Analytics tells you what happened, but not why it happened. It's important to figure out the why and apply this to your next set of designs/prototypes/IU's, etc.

I totally agree with this and wish more organizations engaged their customer and earlier in the process. "For instance, focusing on the end-user viewpoint is important for understanding the business need and user experience."

June 7, 2011 - 11:01am
Charanya Aswath's picture
Charanya Aswath

Nice article. Clear explanations. I think the biggest challenge is with documenting the requirements and documenting just enough. It is challenging to have a general guideline for documentation especially for consulting companies that deal with projects in all verticals and all scales.

June 9, 2011 - 5:23pm
Gerard Miller's picture
Gerard Miller

Hi Filip,

1. Collaborate

2. Be Lean

3. Iterate

4. Visualize

sound like Good Things To Do to me.

A comment on Visualize - In the example you gave a diagram was a better way to convey the information than text. Your point to use more tools than text is a good one. There may be other tools available for example audio, moving visual (i.e. a mini-movie) or interactive.

The key is to use these tools but keep in mind the goal: inform the user. I've seen Wired magazine table of contents that had so much color, so many different sized fonts and other wicked cool features that obscured organization of the table of contents.

Mick

June 6, 2011 - 8:17am
Chris Gangai's picture
Chris Gangai

Hello Filip,

Excellent article and agile tips! Wondering if in separate article here or else where you could describe how one could employ these tips using the HP ALM tool, specifically the requirements management functionality?

Thanks,

Chris

July 7, 2011 - 12:59pm

About the author

Filip Szymanski's picture Filip Szymanski

Filip Szymanski is director of products at HP Software and responsible for the HP Application Lifecycle Management (ALM) product line. He leads the team responsible for current and future ALM releases, including requirements, test, and defect management. Before joining HP via the Mercury Interactive acquisition, he was in technical sales, where he enabled the sales organization to sell higher revenue products and services. He holds a B.S. degree in computer engineering from Santa Clara University.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 24
Oct 12
Oct 15
Nov 09