Any initial project request is likely to be brief. This is actually ideal, since lengthy, restrictive documents on the front end of a project invariably serve to eliminate flexibility and innovation on the back end. The request may make perfect sense to the users, many of whom are likely to have been discussing it for weeks or months ahead of time. Nevertheless, the IT department is likely to view it as vague. Therefore, the first priority of the development team is to acquire a complete understanding of what is being requested and why.

Performing sufficient comprehensive analysis is quite often a terribly ignored action item, and insufficient analysis is a common reason why so many software projects are doomed from the moment the request is made. Users and developers rarely speak the same lingo. Developers' tenure with the company or experience in an industry may provide a level of empathy, but their primary task is software development and all of the trappings that go with it. That is their world, and those are the elements they are mostly exposed to. It requires additional effort and a systematic approach to reach beyond this limited sphere of influence and connect with the users at a level that removes all of the barriers to identifying the problem.

A good first step is to isolate the people or areas impacted by the system. Do not assume that the two or three managers who gathered in the conference room have done proper due diligence. They have a need or desire, but that aspiration will have either a direct or an indirect influence on other areas. These impact points could be both internal and external. Any change made to a system could potentially cause a ripple effect that touches your company's customer base. System development should be client-driven. Before the first Visio diagram is created, you must spend sufficient time determining who is affected and how.

How do you identify who these stakeholders are? You will need to start talking to people. Speak with project sponsors, managers, users, and anyone whose involvement may be needed. And do not hesitate to ask them to help you identify other impacted resources as well. As you compile a list of these people and areas, determine the level of impact and whether the effect is minimal or critical. Eventually, you will have put together a solid list of people who must be involved with the development process.

Why did the user make the request? Is there a perceived business need for new functionality, or have your customers--internal or external--uncovered flaws that impact the bottom line? How will the business be impacted by the change or implementation requested? Uncovering the underlying reasons for the project request is imperative to building a solution. Root cause analysis is critical if you are going to develop a system that actually provides benefits. This process could involve long meetings, numerous people, and tedious code reviews, but it is time well spent. Ask as many questions as you need to in as many ways as you must to reach understanding.

Some approaches suggest that you identify the root cause before determining who the stakeholders are. The two steps actually go hand in hand. Part of your root cause analysis will uncover forgotten resources impacted by the project. Likewise, the discovery process of isolating the stakeholders will provide a glimpse into the intricacies of the system that will enhance your understanding of direct and indirect impact points and how they relate.

No system is boundless, and no development is limitless. Your ability to define and refine your system will be hindered by certain constraints. These could include financial considerations, available programmer tools, and schedule. The constraints frequently will be known up front, but other times you may have to dig to find them. You may not like them, but they are a fact of a programmer's work life. There is an upside, however. One element that continues to inspire many programmers is "the challenge." The system development effort may be handcuffed by business realities, but that does not mean the effort is doomed. These are the kinds of problems that programmers thrive on, so you should perceive constraints as an opportunity to develop or learn new techniques--not as an excuse to build inferior software.

Constraints, in and of themselves, also become the first basic requirements that must be documented. Any timing issue, hardware constraint, or other environmental constraints become part of the world in which the new system will exist. In this case, constraints are positive factors because they help define the system.

Requirements Gathering Techniques

You have identified the stakeholders and isolated the root cause and constraints surrounding the system project request. Where do you go from here? Now, it is time to begin gathering the requirements from which you will design the system solution. For larger development efforts, some shops require a standalone functional requirements document to serve as a clear, documented understanding between users and IT. This is an excellent idea for most projects, as it protects both sides should the system fall short of what is needed. The document should be presented to at least the project requestor and business sponsors on one side and the IT project manager and lead development staff on the other to collect physical signatures. The artifact should then be made available for all to view on a shared network drive for future reference.

How do you build the document?

One method of gathering requirements--and the easiest to facilitate--is to simply interview the users. Find out what their needs and expectations are. Be alert for the hidden agenda in their answers as this will lead to more probing questions, the answers to which will likely be included in the documented requirements. The IT resources used for this technique should avoid going into the situation completely cold. Remember that when you're interviewing a user in this fashion, the goal is to reach a solution. Be prepared. Use a predefined list of questions if you feel that it will help keep the interview on course.

Every user is different. Many will happily provide input, and most will be thrilled that IT has taken the time to actually consider their needs in the development process. There will always be some users, though, who either feel they have enough knowledge to dictate how the system will be built or prefer to keep their knowledge close to the vest and expect you to know the business already. Prevent yourself from biasing the users or their responses. Even the most difficult users will have valuable input if you place them in a situation that makes them comfortable enough to talk freely without feeling as if their time is being wasted. This makes the interviews more productive and makes it easier for you to get your head around what the needs and goals are for the system.

A second and extremely useful technique for gathering requirements is brainstorming. This can be intimidating if not done correctly. The object of a brainstorming session is to generate ideas, not judge them. Many of the ideas produced in this fashion will be far-fetched, but sprinkled in between will be valid system concepts such as features, scope, and system audit trails. A standard brainstorming session is conducted by a facilitator and consists of anyone who could provide a valuable contribution to the eventual system design.

Any brainstorming effort must include the understanding that no idea will be criticized or thrown out. All contributions are valid for this exercise, and nothing is too extreme. You look for quantity without filters or prejudice. Refinement will come after all options are on the table. Only then will you take the ideas and sort through them. The best way to record the ideas is on index cards or Post-it notes. This method is easy, and it provides anonymity for those who may have something to offer but tend to be shy in a "group think" situation such as this.

A third method is use-case scenarios. Developing use-case scenarios is a requirements gathering technique that works well when you need to illustrate system functionality. A full discussion of use cases is beyond the scope of this article, but they are worth mentioning here as an introduction. (To learn more about use cases, see "Java Journal: UML (Unified Modeling Language)" and "UML: Modeling in the OO System"). In this model, different use cases are developed for the "actors" of a system, diagramming how they would interface with the system and how the system reacts to their actions. An actor is not necessarily a person. An actor in this sense could also be an independent system that interacts with the proposed solution being designed.

A fourth method of eliciting requirements is to build prototypes. While it may seem illogical to begin building a model system without first obtaining all the requirements, prototyping does provide a way to illustrate the feasibility of a system and to provide a hands-on demonstration of impact points that may otherwise elude the developers and users. The responsibility for building the prototype does not necessarily fall with the developer. Users can develop a prototype as a way of providing developers a visual representation of their needs.

Prototypes are good for getting the audience to play devil's advocate. It is good to have them asking questions. What is wrong with the prototype? What are the flaws? Does it meet all of the needs? Will it function within the system architecture? Why or why not? Like brainstorming, prototypes should be considered an open-ended activity. The idea behind a prototype is not to sell it as a panacea but rather to put a tangible image of the possibilities in the minds of the project team as a catalyst.

Putting It All Together

All of the work done thus far should lead to one thing: a specification of functional requirements. Notes, diagrams, and feature lists should be collected and transformed into a readable document. That document's only purpose is to define the behavior of the system, not how the developers will design or code the solution to produce that behavior. After the functional specifications are approved, then you can begin adapting those requirements into appropriate designs.

For larger project efforts, you may opt to produce a high-level design that describes the entire system and--without much detail--the various components that make up that larger picture. For large and small efforts alike, each module will have a detailed design rooted in the requirement information collected. Testing efforts should also use the requirements as the basis for building test scripts. Each action item of the test should be aimed at proving that requirements have been met. This is why it is so crucial to involve the users during the testing phase--not only to help with the testing scenarios but also to perform user acceptance testing behind your own systems test.

Some people confuse the aim of a project charter with the discovery process described here. The purpose of a charter is to justify assigning resources to the project effort. Requirements gathering helps you enumerate necessary features and functionality. That is all you are aiming for from this stage. Keep those activities separate, and you should have an easier time clarifying what you need. In the end, always present your documentation to the user to ensure universal understanding. If you have properly used the users' knowledge and experience up front, you will avoid the headaches in the end.

And your users may think you knew what you were doing all along.

Steve McGuire is an author and midrange applications developer in North Carolina. Steve can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it.