Metaphors in Requirements

This week I was asked to review job descriptions for analyst roles within our IT function. The roles were “Analyst, Business Systems”, and “Senior Analyst, Business Systems”.

The person who asked me was looking for my opinion because I am strongly opinionated, blunt, and have experiencing hiring and leading business analysts and requirements engineers. She wanted to understand the difference between an analyst and a senior analyst.

Other than the expression of leadership within a project or team context that I would expect of any senior contributor, my answer had to do with metaphors.

Metaphors are the solid business abstractions that software is designed around. Metaphors are the unambiguously defined concepts that ground the business process. Metaphors are the litmus test to see if requirements are cohesive and complete. If your metaphors suck, so do your requirements.

Back in the ’90s when I was learning object oriented application design (OOAD) we were taught that each application or major feature had a “central object” that was the focus of it’s existence. Microsoft word has a “document”. Every e-mail client has a post or a message. This central object is the metaphor around which the application is designed, we just didn’t call them metaphors back then.

When designing an application all of your actions are performed on metaphors, all of your business rules contemplate metaphors, and your data model expresses your knowledge of your metaphors. Your metaphors are the essence of your understanding and modeling of the REAL BUSINESS stuff that your users and customers have to deal with in the REAL WORLD as part of their job. The more your metaphors align with reality, and the more you can eliminate ambiguity among and between metaphors in your requirements, the easier it will be for software designers, architects, and developers to model and fashion a system around them.

That’s my story and I am sticking to it. The senior analyst gets this, and carefully and thoughtfully identifies, defines, and clarifies essential metaphors within business requirements, and knows the the requirements aren’t complete until all of the metaphors defined hold together with the business rules and actions required.

Metaphors work most effectively when you can get your user community to communicate (to you, and to each other) in terms of metaphors that you helped define. When you have defined useful metaphors that clarify the business process, your users will adopt your terminology because it helps them understand what is important. Then in that context your software (being true to those metaphors) will be intuitive.

An analyst can capture and document the business process. The senior analyst (one with mastery) can change the conversation casting metaphors that help the business community define its value proposition and supporting processes more effectively.

No Comments

Leave a Reply