Managing user requirements is a specialized area you should address for any project that focuses specifically on identifying, gathering, communicating, and documenting client requirements for an IT system.

Once identified, the user requirements effectively lay the foundation for developers, testers, and implementers to begin determining the functionality, responsiveness, and interoperability required of that system. Unfortunately, many people consider gathering user requirements as a waste of time. However, the strategy is crucial to a project’s success for developers and project managers to obtain accurate user requirements as well as increase the level of client and user involvement on a project.

Leading research indicates that poor requirements definition is a huge problem for many IT organizations. Unrealistic expectations that clients and users have regarding projects often arise because projects get started before the user requirements are determined. The biggest problems encountered on failed IT projects are:

Misunderstood requirements and scope creep, which often cause an over-allocation in resources, additional cost or overdue deliverables.

Incomplete requirements (data, reports), which result in incomplete information about the system.

Unstable requirements or new requirements being added during the development phase.

Ambiguity regarding the functionality and objectives of certain requirements.

Conflicting goals by different teams (e.g., the users may want one thing and the business requires another approach).

Too many “nice-to-have’s” that wouldn’t actually be used.

Companies do not always include the project manager during the first phases of a project (i.e., requirements gathering). Instead, many organizations simply hand off a “wish list” to the project or development manager at the development or deployment stage. But this strategy can cause major problems. Managers need to take a step back and review the user requirements thoroughly with the team.

A common result of poorly defined requirementsConsider this scenario: You want to develop a Web site selling high-tech gadgets. You proceed to tell the project manager and developers that you want a dynamic site with a large database, lots of graphics, a shopping cart, and a nice discussion forum. They begin developing your site based on these specs. Then you realize that you really wanted to have a scroll bar on your main index page and a full video archive for your consulting services, and you didn’t really need that big a database after all.

Reluctantly, the developer removes some code and adds a few more scripts, digs out more images from a photo stock catalog, and downloads some additional software, all of which adds weeks to the overall timeline and increases the cost of labor and materials.

This situation is the rule and not the exception in many IT projects. Looking back, you can see that the initial requirements established for the site were incomplete, ambiguous, and not measurable. Additionally, the requirements changed midway through the project, which led to the project schedule being extended as well as adding additional costs to the project. Requirement errors can cost 10 percent more to correct than other errors. At the maintenance stage, it could cost up to 20 percent more.

Obtaining the user requirementsGiven that the starting point of all requirements gathering is really a verbal interchange between the business analyst and client, good communication is crucial. Project managers must set the correct tone from the start of the project during the definition or exploratory phase. As a project manager, you must understand that user requirements must be captured correctly, and they have to be realistic and achievable.

One of the first things that must happen during this definition phase is the requirements-gathering meeting. This meeting usually includes representatives of all affected staff and could include the following members:

Project/development managerThe project/development manager should open up the meeting and act as the meeting facilitator. The relationship between the client and your team is formed during this meeting.

Client managersClient managers are the functional managers working in the specific area seeking the solution; they will have specific business needs of the system and would be best able to relay this information to the analyst.

UsersIdentified and knowledgeable users should attend this meeting to provide input about the project because they will be using the system regularly and will require different, more detailed functions from those at the management level.

IT departmentIt is crucial that members of the infrastructure, networking, security and technology groups also attend in order to help determine any system requirements that must be met and to ensure the necessary hardware is available and capable of running the solution.

Sales and marketing representativesDuring the initial requirements gathering meeting, it’s sometimes necessary to involve sales and marketing folks, since they understand the market and will be able to better articulate the client’s needs on matters such as presentation, format, and packaging.

This process may involve a series of meetings, where the project manager or analyst collects the requirements from the above-mentioned stakeholders. During the meeting(s), the analyst will:

Solicit common system requirements needed.

Resolve any conflicting requirements.

Establish and prioritize project goals.

Identify risks.

Determine critical success factors for the project.

The analyst continually ensures that each requirement is specific, measurable, and attainable. Based on this “wish list” verbalized by the client, the analyst sets about recording and refining these items, removing any unwanted or unrealistic requirements.

Once completed, this document forms the initial User Requirements Specification (URS) document, which defines the relevant business rules as well as user, system, and functional requirements. This URS is then reviewed with the client, and, upon their approval, forms a baseline from which work will begin.

Reaping the rewards of strong user requirementsOne of the biggest benefits of a proper user requirements specification is that you'll be able to plan and estimate your project correctly, decreasing the chance of cost and time overruns. I strongly believe that successful IT projects can only be produced through competent and careful requirements gathering, a strategy that gives you the opportunity to learn about the proposed IT project. It also gives the client the opportunity to look at the project blueprint on paper and begin thinking about how much of the “problem” they want you to solve.

Based upon the URS, the project/development manager will work with the client to translate these requirements into detailed project specifications (e.g., interface specification, billing specification, etc.). At this stage, the team resolves any conflicting views of the overall project goals, defines the interaction of the product with each member of the requirements team, and then establishes a cost and delivery schedule for the project.

After the initial requirements gathering exercise, you would be able to calculate an early estimate of the cost and delivery of the project. Additionally, all captured requirements should be stored within a common central database for use by the project team.

Prototyping is another option for developers/project managers to follow; it saves time and money because it's a fast and inexpensive way to conceptualize a working model based on a few initial requirements. Since prototypes can visualize the product's workings to the client, they allow you to deal with the misconceptions and disagreements that tend to appear as the product slowly starts taking form. As you progress, and the user requirements get resolved, you should then seek out the choices available for implementing that specific solution. It’s here that you have to decide which choice is best for the problem, such as what development platforms provide the efficient solution, tools, etc.

Reliable strategiesIn my experience, the time spent on the front end gathering detailed user requirements eliminates unnecessary delays, improves system quality, and greatly reduces scope creep and its associated cost overruns that may crop up later. Follow these best practices to make sure your user requirements are comprehensive:

Clarify any ambiguity.

Define the scope of the project carefully.

Don't allow developers to assume they know what users want.

Involve the users from the start.

Have all key stakeholders review the requirements once they are compiled.

Today, more and more companies are using the SEI CMM (Capability Maturity Model), ISO 9000, FDA or DoD standards, implying that there’s a greater emphasis being placed on gathering user requirements. Remember that effective requirements management is the first step to improving your software development process.