Requirements capture is based on communication with your custom software development services partner. It is a crucial analytical process that sets the tone for the entire software development project.
The initial requirements definition creates the blueprint for the project. During each phase or sprint of development, detailed requirements are documented for the tasks included in the deliverable.
Any needs not identified during the requirements capture stage of a sprint may result in scope creep. 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 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. For example, George approves a set of plans for a building. Fred, the general contractor, breaks ground. George visits the job site and sees that the slab was poured and there’s no basement. George is furious because he requires a basement. Why didn’t George communicate this to Fred? George’s old building had a basement. He assumed Fred knew a basement was required in the new building. At this point, adding a basement would incur major expenses and delay the project.
How do you avoid a similar software development project false assumption? There are some cues to watch for and steps to take to ensure a smooth requirements capture process, resulting in a project that is on time and in budget.
- Don’t be like George! Do not assume anything. Tell your software development partner what works in your current system. It is tempting to focus on what is missing and overlook the importance of what already works well.
- Be prepared for the initial consultation. Now that you’ve hired someone for custom software development services, clearly communicate. What are your business goals? Take time to think through and list your needs before you meet with your software partner.
- Communicate. Ask your software partner to restate your requirements. Have her keep restating until you clarify any misunderstanding.
- Look for listening. Beware of someone who listens for a few minutes and then tells you they know how your business works. You did not build your company overnight. Your software partner will not understand your needs in 15 minutes.
- Listen for insightful questions that demonstrate your partner understands your goals. You will know how well someone has been listening by the type of questions he asks. Is your software partner asking the right questions?
In our next article, “Requirements Capture: Keys 6-10 for a Successful Software Development Project”, we’ll discuss tips 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
