The Parallax Effect on Requirements Analysis

Have you ever gazed at the stars and found it difficult to focus on a particular one? It’s initially a bit disconcerting. If you look away a small amount, the star seems to become visible. Look straight at it and the star begins to dim and even disappear. Scientists call this the “parallax effect.” I just call it frustrating (I’m an impatient star-gazer).

Many times a problem we’re trying to solve or something we are analyzing is like that.

• How often do you forget the name of something when you try to recall it, only to remember it later while walking outside, or when you are in the shower?
• Or, the solution to a nagging problem suddenly pops into your head when you are working on something else?

These mental phenomena are very similar to the parallax effect. I’m sure there is a scientific name for it, but my psychology classes are only distant memories. I’ve noticed this same experience in business analysis countless times and informally call this the “parallax effect on requirements.”

The main way I’ve observed the parallax effect on projects is by focusing on too few methods to elicit and analyze requirements. For countless reasons, overworked business analysts may rely on one main method for eliciting requirements – such as interviews or requirements workshops. Then, to keep on schedule, BAs will use one primary method to analyze and document the discovered requirements. Swim lane diagrams and use case models come to mind here.

That is when the parallax effect strikes. Bam! You get stuck on a thorny issue like resolving an alternate path of a use case. You may resort to more interviews to solve it, but both struggling with the use case and re-interviewing are like staring at that star. The solution starts fading and disappearing.

So, what is the equivalent to diverting your gaze from the star so you can see it? How can you keep the problem in focus without over-focusing on it? The most practical way I’ve learned is to use a coordinated set of models to view the problem from multiple angles. You don’t need to use 27 models to do this – four categories will do. All software applications have the following four types of functional requirements in varying degrees:

1. Business Process – current and future states of the business processes affected by the solution being built. Business Process models set the context for and are the foundation for every other type of requirement.
2. Interaction – show how users will interact with a new system, and include scenarios, use cases and user stories as primary methods.
3. User Interface – an extension of the interaction requirements, these requirements uncover additional data that is input to or output from a system. Prototypes are excellent ways of drawing out user interface requirements.
4. Data – the data needed to support a business process and/or is input or output during the interaction with a system, and/ or appears on user interfaces. Data models, such as Entity-Relationship Diagrams and Class models are typical types of models that help here.

Concurrent Requirements Modeling is what we call the use of complementary modeling techniques to quickly and completely analyze functional requirements. Using these four categories of models provides a complete, well-rounded set of functional requirements. That’s a huge benefit in and of itself, and it also saves time and frustration by combating the parallax effect.

Let me give you a quick example. During a workshop a student team was working on a use case and got stuck on what happened during an error situation. Their first reaction was to ask the “customer” (me, during a role-play) what they wanted. When that didn’t work, they sketched out an activity diagram of the process and a rough prototype. The team got out of their use case rut, and were able to ask pointed questions about the business process and interface. They got most of what they needed to complete their use case alternate path. The data model would have supplied a few more missing pieces. But, by moving their analysis to other models, the team looked away from the “star” and were able to “see” the problem and solution more clearly.

So, the next time you stare too long at a problem and lose sight of it, maybe the parallax effect is at work. Try looking away by utilizing complementary techniques, and the problem may well come into focus.