Intranet Journal
The online resource for intranet professionals

Gathering Requirements: The Crux of the Matter

8/11/03

Perhaps the most important piece of any application development project is requirements gathering. After all, if you're not clear on where you're going, how will you know when you get there? So why do most intranet teams spend so little time focusing on developing the skills necessary to do this piece well?

Critical Success Factors for Successful Requirements Gathering

Choose the Right Member of Your Team
Some people are great technicians; others are good with people and have exceptional communication skills. A select few excel at both. Ideally, you want the team member with the best people and communication skills you can find handling your requirements gathering. He or she needs to be able to meet with the customer and communicate effectively with a non-technical audience. In addition, he or she needs to be able to also convey this information verbally and in writing to the technical audience known as the rest of the development team.

Meet with the Customer Early and Often
Since the business customer drives the project, it is imperative that they are involved from the inception of the project. Literally meeting with the customer in person and on the phone is a very important piece of the process. While e-mail is great for confirming and verifying details, getting a big picture view of the functional requirements and the associated details is best accomplished the old fashioned way — with human contact.

Ask Questions
Interviewing and conversational techniques can be the difference between success and failure when it comes to extracting information and requirements from your customer. Knowing how and when to use powerful questions to get the customer to think in depth about the current and proposed process will not only help your mission but can also improve the business process. Once you get clear on what functionality needs to be included, use clarifying questions to flesh out the details of how it needs to happen.

Clarify What the System Will Not Do
As important as clarifying what the system will do is being clear on what it will not do. In addition, it is essential that you clarify what the users will do versus what the system itself will do. A good practice is to clearly indicate in your scope and requirements documentation not only what functionality will be provided but also what will be excluded. Use cases and flowcharts can also be very helpful to illustrate and document process flow while differentiating roles.

Share this documentation with your customer not only for the purpose of discussion but also to obtain their buy in and approval.

No Technical Jargon Allowed
One of the primary reasons for not putting your team's resident geek in charge of requirements gathering is the fact that technical jargon and technical issues have no place at the functional requirements gathering table. While the technical team will need to define and detail technical requirements, nothing will derail the purpose of obtaining clear business requirements faster than someone talking techno-speak to a customer. It simply shuts down the lines of communication and intimidates them.

Functional requirement meetings should focus solely on the business processes the system is meant to replace or enhance. The technology platform that will be used to accomplish this task is irrelevant. Save that discussion for the roundtable of technical folks who will spearhead the design phase of the project.

Document and Reconfirm
Companies tend to vary in terms of their actual documentation requirements. However, regardless of what is required, clear, concise, and thorough functional requirements documentation is a key to success, not just a luxury. This documentation should be the bible from which all team members operate and be the standard to which all testing is performed. As a side benefit, this documentation will ease all future transitions in personnel as well as facilitate system maintenance.

Revisit the Requirements Often
A project's requirements are the building blocks for the remaining phases of the system development life cycle. From requirements, all other things flow (design, construction, test plans, acceptance testing, etc.).

Requirements are also the yardstick by which project success or failure is measured. Therefore, as a development team, revisit them often.

After all, if the system doesn't do what the customer needed it to do, what's the point? You cannot realize any ROI if you build the wrong or inadequately functioning system.