At ArgonDigital, when we talk about software requirements we talk a lot about visual models, going into detail about specific models, how to use visual models, and the mechanics of the particular model. But I thought I would take a step back and talk about why we use visual models at all.
When most people think of “requirements”, they usually think of long lists of text that spell out all the features and functions that they want the software to do. This text can take many forms, be it “system shall…” statements, user stories, or some other form of text.
Additionally, when people think of eliciting requirements, so often the image is a business analyst sitting down with a subject matter expert, and simply asking “What does the system need to do?” The business analyst writes down everything that the subject matter experts says, takes all of that information and puts it into a requirements document, and presto! Requirements are done and ready for review!
Have you reviewed one of those documents? Yup, it is difficult to do, which is why reviews rarely happen, or if they do, it’s in the context of a review meeting where each requirement is read through, one-by-one, until all have been covered. Those meetings are painful to sit through. And even if we get all of the requirements reviewed, we still don’t know if we have all of the requirements. There is no easy way, with text-heavy requirements, to verify or check.
The challenge in these types of requirements and elicitation techniques is really ensuring that all of the requirements have been found as well as ensuring that that the desired audience really understands what is needed. This is where models can help us out.
OK, before I go on, let me just state that models are not requirements. We use models to help us find and understand requirements.
So why models? Well, if you think about it, we all use models in our daily life. Do you have a GPS device in your car to help you find a place that you have never been to before? Or use the map feature on your smart phone? We could just use a list of directions; “turn right at the light, go three streets, turn left, drive for .3 miles, take a slight right, destination is on the left.” Is there anything wrong with that? No, not at all. However, a map with arrows is much easier to understand, gives you context to where you are and what the next step is.
Using models in requirements elicitation is the same thing. What we are attempting to do is give some visual structure to the information. We are also looking for requirements, to ensure that we do not miss anything. We are looking at the information from different perspectives.
So let me give you another example that is more requirements focused. I recently worked on a project for a financial company that involved loans to their customers. As the requirements were originally written, in text form with just a list of data elements that were desired, the implied relationship between a loan and a borrower was 1-1. In other words, each loan would have one only borrower and each borrower would have only one loan. When we took the words and made them into a picture, and showed it to the end user to ask if this is what they wanted, the answer was a resounding no.
In fact the relationship was more this, where a loan may have one or many borrowers and a borrow many have zero to many loans.
So why does this matter? If development had assumed that each borrow could only have one loan, then you get a product that is not only unacceptable to the business, but also unusable. Words alone do not find these sorts of requirements, but by using visual models, in this case a Business Data Diagram, we can see and find those requirements, and ensure that they are documented properly.
Visual models can also help us organize our requirements. I regularly organize my requirements by process flow, down to the step. This allows me to easily filter my requirements so I can quickly focus on a particular subset of requirements.
Finally, research has shown that most of the people in the world are visual learners. Again, let me use an example from our daily lives. Your nephew just got a new toy airplane, and you are going to help him put it together. Think about it: what sort of assembly instructions are best?
Ones with just pictures? Better…but still not ideal.
The best are usually the ones with words and pictures. The pictures give us a visual idea of what we are looking at, and the words help support the pictures with the additional information we need to know.
Software requirements are similar; just because we are now talking about software requirements instead of a toy does not mean that we learn any differently. So why would we treat our requirements differently?
