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.

Requirements Success Factors

Last January my role was redefined, and since then I have been managing two teams covering diverse aspects of two software programs. The first team is responsible for requirements, functional design, quality assurance, and the second team is responsible for support.

In this role, I have been focused on analysis and have been interviewing more business analyst type resources than I have before. I don’t call them business analysts, although my company has a job description for “senior analyst, business process”. The reason is because their job is not to analyze business process, their job is to elicit, understand, organize and document requirements for software products. I prefer to use the term “Requirements engineers”, and I like to talk about requirements engineering because requirements are not simply a description of the current or desired business practice, or a wish list. Requirements are a high cohesion document, describing capabilities that are required to deliver specific business value through software automation.

In a recent interview of a candidate for a contract “requirements engineer”, I asked a question that I usually ask candidates of any skillset – “What the top three critical success factors for practitioners of ?”

My friend Johanna Rothman would say that this is not a very good behavior description question, because it does not give the interviewee an opportunity to tell how he has done this. I believe that it is a very good question, because it asks two things at once? Does this candidate see him or herself as a practitioner of a discipline, or as someone doing a job. It also forces them to describe how they practice this skill set. If this answer rolls off of their tongue, then they have spent some time thinking about how to do a better job. If they struggle with it, it is likely that they don’t think about it much, they just do it.

Then there is the answer it self – this tells me what they think is important. I usually ask this question towards the end of the interview, after I have already asked the behavior description questions. I look for answers that are cohesive with the earlier responses, to see if they are spitting out what they think I want to hear, or they practice what they preach.

This candidate did pretty well – after he answered, he asked me what I thought the three critical success factors were.

My answer:

Semantic Clarity or Disambiguation – terms, and concepts, especially metaphors must be precisely defined.

Cohesion – the document must add up with mathematical precision.

Organization, especially abstraction or generalization – the basis of software is abstraction, and this must begin with requirements, classes of problems, value propositions must be clearly identified and categorized.

His answer:

He had cohesion and disambiguation or something close to it, but substituted scope management for organization.

I don’t think he is wrong, but in my organization, scope is fixed after requirements, not before. This is because premature scope management inhibits value delivery, IMO.

I think I’ll hire him…

— Correction —

My candidate did not have cohesion, he said communication, and he talked about making sure that each person walks away from a conversation with the same understanding of the topics discussed. I agree that this is a success factor for gathering requirements. Certainly anyone who goes into a business to understand what is required, in order to add some specific value to the business must have ample communication skills, and most importantly, establish appropriate feedback mechanisms to ensure that the understandings are shared. This for me is a component of semantic clarity and disambiguation, call it a sub-factor.