Requirements capture is based on the communication of basic needs. It is a crucial analytical process that sets the tone for the entire software development project.
Any needs not identified during the requirements capture stage will result in scope creep. According to Suzie DeBusk, President of DragonPoint, the most effective way to minimize scope creep is to allocate 30% of the time spent on a project to requirements capture, design, and review. How does requirements capture reduce scope creep?
A thorough requirements capture process minimizes false assumptions, therefore reducing the overall cost and length of a project. The International Journal of Technology Management cited that, “companies with intense front-end activities actually spent 40% less time developing their products than companies with few front-end activities.”(1999)
The requirements capture stage is similar to the planning phase of a construction project. If the client and architect do not communicate effectively, the blueprints will not meet the client’s needs. And, depending on the size and scope of the discrepancies, this error in communication can result in costly rework as the project evolves. Suppose a client approves a set of plans for a building, the general contractor breaks ground, and a week later, the client visits the job site and sees that the slab was poured, but the basement was not excavated. The client panics since he requires a basement for storage of critical equipment that needs to be on site. Since his old building had a basement, the client assumed that his new building also would have a basement.
Due to a critical disconnect during the requirements capture stage of the project, a basement now can’t be added without incurring major expenses and significantly delaying the completion date.
Working with a consultant to develop a software system for your business can be much like a construction project. There are, however, some cues to watch for and steps to take to ensure a smooth requirements capture process, resulting in a project that falls within the constraints of time and budget.
- Be prepared for the initial consultation. Now that you’ve hired someone for software development, don’t lose track of your needs. What are the business goals that prompted you to call in a consultant? Take time to delineate your needs before you meet with your consultant.
- Remember your current system while creating your wish list. It is tempting to focus on what is missing and overlook the importance of what already works well. Regardless of how basic, do not assume anything. Tell your consultant what aspects of your current system work for you.
- Communicate. A conscientious software developer will send two consultants to the initial requirements capture meeting. By having an extra set of ears present, the consultants return to their office with a clearer concept of what you need. Ask your consultant to restate your requirements, and keep restating until you clarify any misunderstanding.
- Look for listening. A good consultant listens. Beware of a consultant who, after 15 minutes, takes over the meeting and tells you that she fully understands your needs. You did not build your company overnight, and your consultant will not understand your needs in 15 minutes.
- Listen for insightful questions that demonstrate you and your consultant share common goals. You will know how well the consultant has been listening by the type of questions he asks. Is the consultant intuitive enough to know what he doesn’t know and smart enough to ask the right questions?
In our next article, “Requirements Capture: Keys 6-10 for a Successful Software Development Project”, we’ll discuss steps 6 through 10.
Food for Thought
While researching the topic for this issue of the newsletter, I thought about describing a process.
Years ago, I found myself teaching Freshman Composition at the University of New Orleans, where I had an amazing group of students who thought they were excellent communicators. I tried to tell them that I wasn’t a mind reader, but, they continued writing essays that I could not follow or understand. One afternoon, I decided to prove my point. I walked into class with a grocery bag and unpacked all the necessary ingredients to make a tasty peanut butter and jelly sandwich. I told them that I just flew in from Mars, where I’d lived all my life and I had no idea how to make a peanut butter and jelly sandwich. So, they laughed and began to tell me what to do.
“First get two slices of bread,” I heard. So, I picked up the bag and tore it open, sending sliced bread flying over my students’ heads. Seeing the mess I’d made, they said something about a twisty tie. But, it was too late to fix that problem since the bag was already destroyed. One student, who was starting to get the idea of good communication, carefully told me how to twist off the lid from the jar of peanut butter. She told me to hold the middle of the jar with my left hand while I turned the lid in a counter clockwise motion with my right hand. Finally, one step worked!
Next, I was told to take the knife and spread the peanut butter on the bread. Not knowing any better, I first put the wrong end of the knife into the jar of peanut butter. Then I took the artistic approach and buttered the outside edges of the bread. The students said I had to start over. “But, what about all my hard work thus far?” I argued.
“Sorry, but you should have known what we meant. You don’t put the peanut butter on the edges.” “But, I did exactly what you told me to do,” I retorted.
They screamed in horror when I opened the grape jelly by smashing the jar on the floor. They got exasperated explaining how to clean up the sticky mess. And they became very frustrated when, after I was told to cut the sandwich, I cut it into a dozen tiny pieces. A simple process that should have taken less than two minutes to complete was dragged out to a 25-minute ordeal and was accompanied by much aggravation. Most of the students finally got the message that I could not read their minds.
Consultants can’t read minds either, and they have no way of knowing about your specific requirements unless you tell them. –Rosary Alvarez
