Keep Dreaming

Hey, wake up!  Stop dreaming…it will never happen.  But you could come close.  If you want your next project you to be more successful than the last project, use these hints and the user-requirements explanation at the end of this article to motivate your users to be intimately involved during this stage of the project.

Instead of bemoaning the fact that gathering requirements is as much fun as exploratory surgery, start with the best in mind and see how close you can get.  If you could dream up the ideal scenario for gathering requirements, it might go something like this.

Dream Scenario:
Joe used to be a user in the group for which your team is designing a new application.  He was then promoted to manager before finally coming on board your team.  Joe is intimately familiar with what the users need, what management needs from the application and how the system can deliver it.  He can design it and then code it to specifications with no help from anyone.  

Next Best Thing:
Well, if you can’t hire Joe away from the user group and teach him to develop, what about getting your designers and developers to shadow users while they work?  I clearly remember using new applications and immediately realizing that the developer never sat with the users.  Users cannot possibly articulate each step and function, option and result of their jobs while sitting in a conference room, yet that is the level of detail you need for your project to be a true success.

Reality:
For most of the projects I manage, our user groups are one or two time zones away from the developers, and we must expect users to relay their processes and requirements over the phone and via e-mail.  If your reality is like mine, we can stop dreaming but still hope to improve the quality of our requirements documentation.

Set Expectations, Give Explanations
It is critical to set customer expectations in the project-request phase by explaining, “Yes, we can create a site or application that will meet your needs, but it will be a team effort.  We will need an estimated two hours per week from your team members for requirements meetings, and you will all have homework.”   

When creating our communications plan, I encourage good user representation by saying, “The users might not see the application until user acceptance testing, and when they do, they frequently have very valuable input for improvements, but by then the application is already built, and changes would delay delivery sometimes by several weeks.  Sometimes users even point out a missing function that makes the application unusable, so I recommend having a user or team lead you trust involved in requirements.”  

After you have set expectations for your clients and gotten a commitment for their involvement, be sure they provide you with their processes--a process flow diagram they create for you, in addition to any training or quality control documents they might have.  I typically ask them to define their current process as well as the process they envision using the new application.  This isn’t quite as detailed as a use case, but it helps the users and your development team envision what-if scenarios and identify interactions with other groups that might have implications for your project.

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 by essentially shadowing themselves.  Use the following description to help your user-group management explain the necessary commitment to the folks selected to help define requirements.

Why Is Requirements-Gathering So Much Work?
If someone asked you, “How long would it take you to write a book?” you might have a few questions of your own.

• What subject?      
• Fiction or non-fiction, novel or textbook?      
• What is the intended readers’ understanding level…expert or novice?      
• Hardback or paperback?      
• Workbook or picture book?      
• How many chapters?      
• What font should I use? Do any readers need large print?

As you can imagine, developing a web-based application or web site is even more detailed.  User requirements must answer dozens of questions.

• What must the user do first, next and last for each function of the job?      
• Is there a need for the user to 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: field-length, alpha or alphanumeric, required or not, any validation required?

These user requirements must then be translated into system requirements and ultimately into code as the developer creates your site or application.  

Describing the work you do in exact detail and in the proper sequence is difficult or impossible.  If your design team can shadow users of the new application as they do their work, they will get a much more accurate picture of what the new application must accomplish.

If you must supply requirements without developers available to watch your every move, do the next best thing.  Take notes to define requirements as you 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 requirements-gathering will take some time, the end result is time saved with accurately defined needs, and a user-friendly application that meets your business needs and streamlines your job.