By Donna Boyette
How would you like to hear this from a customer?
“We want the application as quickly as possible, but I know we’ll have to invest some serious time in the requirements stage before we’ll know how much time your team will need to develop it. Don’t worry about how long it takes to get a complete set of requirements. We’re ready to work with you.”
While such a rosy scenario will never happen, you could come close. If you want your next project to be more successful than the last, motivate your client to have users intimately involved in identifying requirements during this stage of the project. By explaining the benefits of user input into the project requirements, you can help your client become more willing to spend the necessary time up front to create a finished product that is user-friendly and that meets the needs of the entire business.
Getting users involved
At the beginning of the project-request phase, encourage good user representation by having a user or team leader involved in requirements gathering. Users will often point out omissions or details that will make an application unusable if not included. Most of the time, unfortunately, this step is not taken and users don’t see the application until user acceptance testing. By that time, the application is already built and changes would delay delivery.
After getting a commitment from the client for user involvement, be sure they provide you with their processes (request a process flow diagram), in addition to any training or quality-control documents they might have.
You should also request the process they envision for using the new application. While it won’t be as detailed as a use case, the proposed process will help the users and your development team to envision “what-if” scenarios and identify interactions with other groups that might have implications for your project.
Why is requirements gathering so much work?
The next best thing to being there is to inspire the customers so that they are willing to be your eyes and ears as they define user requirements. Here’s a good comparison to help your user-group management explain the commitment to the folks selected to help define requirements: If someone asked, “How long would it take you to write a book?” you might ask them:
- What subject?
- Fiction or nonfiction, novel or textbook?
- What is the readers’ understanding level…expert or novice?
- Hardback or paperback?
Developing a Web-based application or Web site is even more detailed. In such a case, user requirements must answer dozens of questions:
- What must the user do first, next, and last for each function of the job?
- Do users enter comments after the function is completed?
- Does the application need to interface with another application?
- What are your user security requirements?
- Will you have a system administrator and department administrators, or will users self-register?
- Is there a need for system-stamped time and date and last-updated-by details?
- Will you need reporting of the system usage or work results?
- Is every piece of data in the report tied back to the field source in the application? What are the computations?
- What are the business rules attached to each field on each page of the site?
- When you select Enter, do you go right to a new function or to a list of pending items?
- Define field attributes: Length? Alpha or alphanumeric? Any validation required?
That’s not even an exhaustive list. Keep in mind that all these user requirements must be translated into system requirements and ultimately into code as the developer creates your site or application.
Have users write out the details
Describing someone’s workflow in exact detail and in the proper sequence is difficult or impossible. One strategy for helping the design team is to have them shadow users of the new application as they do their work, gaining a much more accurate picture of what the new application must accomplish.
If you must supply requirements without having developers available to watch the users’ every move, do the next best thing. Have the users take notes to define requirements as they work. Provide this detail to the development team and be willing to answer as many questions as they can throw at you.
Success in this stage can mean a successful rollout, and though user requirements-gathering will take some time, the end result is time saved, accurately defined needs, and a user-friendly application that meets your client’s business needs and streamlines the users’ jobs.
This article was originally published on gantthead on March 26, 2001.