Have you ever been involved in a home or office building project? Did you end up with what you wanted? If so, it’s undoubtedly because you stayed involved and because, through the architect’s drawings, you had a way to communicate your requirements. The comparison of building a house to building a software system is one you’ve undoubtedly heard before. Nonetheless, the comparison is extremely useful, and it allows us to draw some crucial lessons.
Lesson one: You may have expressed your initial ideas in words, but the architect turned the words into drawings. Those drawings helped you ‘see’ what the finished product would be like.
Lesson two: The drawings you and the architect worked with were presented in your terms, not the electrician’s or the plumber’s. You could understand them.
Lesson three: You, the one paying the bills, had the opportunity to be involved and make changes throughout the life of the building effort.
Lesson four: The requirements, the original drawings that you and the architect worked through, drove the rest of the project. They produced electrical specs, plastering specs, and so forth. If the assumptions in those drawings changed, the changes rippled through.
Just as in building a house, a good requirements process must have a way to help the business owners extract, discover, and capture what they want in their own terms. A good software requirements process must have a way to communicate unambiguous requirements to the developers (the plumber, the electrician). And a good software requirements process must have a way to accommodate and even encourage change throughout the life of the project (you, the owner, are included in the process all along the way).
If your software requirements process doesn’t address these lessons, it won’t succeed.
Software Requirements Gathering Needs Both Words and Pictures
Most business sponsors are used to expressing themselves in words, and it is important to capture their initial goals and objectives in a medium they’re comfortable with. In addition, text statements are a good way to capture operational requirements such as the number of users that must be supported, or the necessary levels of security. But what about process (or functional) requirements? There are situations where it might take several pages to describe the process of, say, taking an order. In this case, a visual approach to understanding a business process flow seems preferable to a written one. The solution is to find a way to marry the benefits of text requirements and requirements management with visual models. Software requirements gathering needs to address visual and text requirements, and both kinds of requirements must be tracked and managed.
Software Requirements Must Be Gathered and Presented in Business Terms
For those software requirements that would benefit from a visual approach, you will need to find models that speaks in business terms, not IT terms. Many business owners are impatient with entity relationship models and even more so with class models. These models may provide the information IT needs, but may not be particularly understandable or useful to the business side of the house. As others have noticed, the real world of business and the technical world of computers are inhabited by two different kinds of people. Each has its own culture and language.
