Building applications that meet the needs of the business is becoming increasingly challenging, with more-complex business processes and ever-increasing amounts of data to manage. On top of that, customers today expect instant results, which creates additional time pressure and leaves no room in the application development schedule for rework. So, what can IT organizations do to make sure they build applications right the first time?

One of the keys to eliminating rework in application development is defining the right requirements up front. Requirements need to be clear and succinct, but they also must incorporate feedback from multiple stakeholders. There is much to learn about improving the usability and value of requirements from agile development methods, where user stories (really just another term for requirements) are at the heart of the process.

Below are four tips based on lessons from agile methods that will help improve the requirements definition process—even for organizations that have not adopted other agile techniques.

1. Collaborate
Agile methods teach us to involve multiple stakeholders in defining requirements in order to get the requirements right the first time. Building better integration between the testing team and other members of the project team is a key value of application development. Improved integration drives improved productivity and yields improved software quality. For instance, focusing on the end-user viewpoint is important for understanding the business need and user experience. However, it is also necessary to get feedback from the development team to understand whether the requirement is feasible from a technical standpoint. Thus, collaboration between a business analyst, end-users, developers, and testers will lead to higher-quality requirements than if the business analyst works alone.

Sharing information across silos enables constructive negotiations to take place between stakeholders with opposing opinions—before any code is written. Working out these conflicts during the requirements phase helps to eliminate the rework that comes from discovering these differences during development, testing, or production phases.

2. Be Lean
More often than not, IT organizations will not know exactly what they want at the beginning of development, and their needs will probably change during the project. For these reasons, lean software development practices allow the software development process to start without having a long and detailed requirements document that will become obsolete after a couple of weeks.

Agile methods teach us that a 400-page document is not required in order for development to begin. In an agile environment, development can start with high-level user stories with perhaps one layer of detail added.

I recommend taking a lean approach to creating requirements definition assets. Being lean does not mean doing nothing. It means that before creating an asset, the team should evaluate the value that the asset will bring to the applications team and the larger organization. For example, if a requirement is for an enhancement that has been discussed at length and is well understood, there is little value in creating an excruciatingly detailed description.

This lean approach should be integrated with methods for obtaining customer feedback and with build tests performed at different stages of the development. This way of working eliminates waste and increases flexibility, because it shifts the focus (and effort) from creating a complete set of requirements to obtaining software that fulfills all the requirements, including the ones that were not clear at the beginning of the project.

The team should also evaluate how an asset will be reused. An asset will be of higher value if it can be used to drive both development efforts and the testing process. For instance, a requirement defined using a business process management (BPM) tool can be imported into certain test management systems to ensure that the application is tested against the criteria that matter to the business.

Taking a lean approach to requirements also includes eliminating waste. By carefully organizing requirements (by functionality or by how features will be built), it becomes easier to see which ones are needed and which can be eliminated.

I also recommend standardizing the content of requirements. By providing guidance and standard templates to business analysts, the process of creating well-defined requirements that are useful to the rest of the organization becomes easier.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.