NLP for Requirements Engineers, Part 2

This article explains six of these techniques which are particularly applicable to the daily practice of the requirements engineer. It is divided in two parts, Part 1 focused on introducing NLP and the first three techniques:

1. Senses
2. Rapport
3. Different Perspectives
   
   
   This is the second part of the article which discusses the following three techniques in more detail:
   
   
4. Meta Model
5. Logical Levels
6. Reframing

The fourth technique, the Meta Model is essentially a set of questions that can be used to explore and understand the complete meaning of what someone else has said. During day to day conversation people often speak with language which can be rather vague and open to misinterpretation. This is because as we talk we filter out a lot of the detail that we hold in our minds in order to keep the flow of conversation and being concise.

The Meta Model questions focus on gaining a deep understanding of communication to gain clarity and common understanding. It can truly empower requirement engineers, who often need to gain a good understanding of what the stakeholders are telling them as well as having to write clear technical documentation, such as user manuals and functional specifications.

The fifth technique, known as Logical Levels, was created by NLP developer Robert Dilts and is based on the work of the anthropologist Gregory Bateson. This model proposes several different levels at which a change can take place and a hierarchy which indicates the relationships between the different levels.

The technique provides us with a structured way of understanding a given business problem or stakeholder’s interest and motivation. It teaches us to recognize the level at which a given problem is occurring and select the appropriate level at which to target the solution.

Requirements engineers can use this technique in the requirements elicitation process or when identifying the business need during strategic analysis, to systematically ask for information and verify the relevance of it.

The last technique discussed in this article is Reframing. It is based on the idea that all meaning depends on our point of view. To reframe something is to change its meaning by putting it in a different setting, context or frame. This technique is particularly useful when ideas need to be generated or solutions need to be found for a given business problem. To use reframing successfully it is essential to have good rapport with your stakeholders. More detail on rapport can be found in part 1 of this article.

Each of these NLP techniques is explained with practical examples to stimulate its immediate use. In the conclusion section, a mapping is provided between them and the requirements engineering areas of work where they are applicable. We have used the work area definitions from the two important authorities in the requirements engineering field: the International Requirements Engineering Board (IREB) and the Business Analysis Body of Knowledge (BABOK) issued by the International Institute of Business Analysis (IIBA).

Meta Model technique

The study of and use of language sits at the heart of NLP. We experience what goes on in the world around us through our senses and form representations of this inside our minds. As we store our experiences we filter what we remember through our sensory preferences and patterns learnt from our previous life experiences. We use language to communicate our thoughts and feelings and when we communicate both verbally and in writing we have applied filters to this. Through doing this it enables us to be concise and use a flow of language as we communicate.

The Meta Model technique is essentially a set of questions that can be used to explore and understand the complete meaning of what someone else has said. Through careful, respectful questioning and listening it is possible to explore the deep structure of an experience which someone has stored in their memory.

The questions are organized into three categories: deletions, generalizations and distortions.

Deletions

We all delete information when taking in an experience or recalling it in speaking to someone else. This is to prevent us from being bombarded by information that is not relevant at the moment of the experience.

The category of questions used to explore deletions are used with the intention of recovering missing information.

• Ask what, where and when questions to get the specifics of the requirement;
• Ask who exactly to recover missing actors;
• Ask how exactly to recover process flows, action sequences;
• Ask compared with what or who to elicit specific and measurable requirements;
• Ask who is making a given judgment and by what standard to define the real constraints of the system;

These questions are particularly applicable when formulating SMART business goals and requirements. See ^[2] (p. 113) for more details on SMART (Specific, Measurable, Achievable, Relevant, Time-bounded).

Some examples are given below to illustrate the use of this technique.

Stakeholder: A report is needed on the conversion rate of the site visitors.

In this requirement the actor is missing as well as the exact definition of the conversion rate.
The Requirements Engineer could ask:

• Who exactly needs to report and how is he going to use it?
• What is the definition of the conversion rate? What is the formula to calculate the conversion rate?

Stakeholder: The application is not secure enough.
This requirement is not measurable and specific. The judgement “not secure enough” needs to be quantified against a given standard. Furthermore, the real problem for which security measures are the solution is not identified.
The Requirements Engineer could retrieve the missing information by asking:

• Who is making this judgement and by what standard?
• What would happen if the application stays like this?
• How exactly the application needs to be secured?


The more specific the requirements are, the more impact the system will have in changing things for the better.

Generalizations

We generalize information when we take a particular experience and apply it generically to a multitude of other situations. By doing so, we are more efficient in dealing with new situations and are able to make decisions quickly. However, it can also lead to wrong assumptions and limitations we want to avoid.

When communicating requirements the requirements engineer can benefit from paying attention to generalizations. One type of generalization is the universal, this is disguised under the words: All, Every, Never, etc. When these words are heard challenge them to discover new possibilities, alternative and exceptional flows and constraints. Challenge them to decompose complex requirements and negotiate the priorities in an agile way as illustrated by the example below:

Stakeholder: Customers should be able to order online in all markets we are active in.
 To implement this requirement at once for all markets is a complex task.
To deal with it in a more agile way the Requirements Engineer could ask:

• All Markets? Could we start with the 3 most technology savvy markets? In parallel we will create a roll out plan for the rest including the lessons learned from the experience in the first 3 markets;

Another attention point for the requirement engineers are the generalizations made by the use of modal operators, such as shouldn't, can't, not possible, etc. Valuable information can be hidden there about the rules, constraints and the scope of the system at hand. These generalizations can also be a trigger to exploring new ways of doing business, as the example illustrates:

Stakeholder: People who are not guests of the hotel cannot reserve tables in the restaurant.
The Requirements Engineer detects the “cannot” modal operator and questions it:

• What would happen if they could?
  Stakeholder: Well, in that case we might not have enough free tables for the hotel guests.
  The Requirements Engineer could now use generalization to explore the conditions of this problem and perhaps come with new opportunities:
• Is this always the case?
  Stakeholder: No, actually in the low season, we could allow non-guests to reserve a table. I see, this is a new opportunity to boost our profit during the low season.

Distortions

In the third category there are questions dealing with the distortions. Distortion occurs when we give meaning to an action or situation which is not based on facts from the reality, but on an assumption we have made. Assumptions can point us in a wrong direction or unnecessarily limit our choices, which is why we want to discover and discuss them.

One way to find distortions is to look for nominalizations. Nominalization is a verb which is transformed into an abstract noun. For example:

Stakeholder: Failure of the system is unacceptable.
The abstract noun “Failure” is a nominalization. It limits the choice we have to 2 options: Success or Failure. The requirements engineer can turn this noun into a verb again, thereby creating space in the communication to analyse the whole process of failing and expanding the choices that the stakeholder has.
Requirements Engineer:

• When is the system failing?
• How is the system failing?

Nominalizations are static. In order to create choice and gather more information, this technique suggests to turn them into process and by doing so possibilities arise for alternative ways to achieve a given business goal. This technique gives us more control over the situation.

Another interesting distortion type is the presupposition. This is an assumption that is presented as a fact, however when challenged it can lead to the realisation that more is possible. For example:

Stakeholder: We don't want to insult the passengers by making them pay separately for the baggage.
Here the stakeholder is implicitly assuming that the passengers will be insulted when requested to pay for the baggage.
The Requirements Engineer can challenge this:

• What leads you to think they will be insulted if they need to pay for an extra baggage?

Stakeholder: Well, we have never asked them to do so before. The baggage was always included in the total flight price.
The Requirements Engineer can now work on generating some alternatives to “insulted” together with the stakeholder:

• What positive effects can come out of making the baggage price explicit to the passenger?
  Stakeholder:
• The passenger might become more aware of the environmental footprint each piece of baggage creates;
• We can offer cheaper tickets to passengers with no baggage;

It is good practice to challenge the stakeholders and make sure that their requirements are based on facts and the business value they add, instead of on subjective presuppositions and limiting nominalizations.

One way to remember the system of questions that disclose the deletions, generalizations and distortions we all make, is this handy illustration made by Anthony Robbins ^[3] (p. 222)

Practicing the Meta Model technique can truly empower requirement engineers in all work areas. It enables them to get more actionable insights quickly in any situation, and most of all when eliciting, detailing and prioritizing requirements and understanding the real problem the stakeholders want to see solved.

Logical Levels

The logical levels of change, also known as the neurological levels, is based on work done by Robert Dilts ^[5] (chapter 8) ^[7] (chapter 13) and the anthropologist Gregory Bateson ^[9]. It provides a structured way of gathering information and understanding what's going on in any system including individuals, a project, a team, a department, or even an organization. The model contains a number of different categories or levels at which change can take place and a hierarchy which indicates a relationship between the parts. In an organization or even personally, the changes made may be at one or more levels.

Requirement Engineers are often involved in projects that include changes of the ways people do or organize their life and work. Knowledge on how to lead and facilitate people through change is thus crucial for them. A new perspective on what gets in the way of change can be found by making use of the logical levels model.

The model can be used to recognise how the various levels interact and how they are related. And it provides a means of

• Asking for, and verifying the relevance of, information
• Keeping track, in a highly structured manner, of the huge amount of information that is often available when discussing a business problem or opportunity
• Recognising at which level a problem is occurring
• Recognising the most appropriate level at which to target the solution.

The different levels of thinking and perception considered by the model are summarised in the diagram below:

Environment

This is all about the situation and surroundings: the people and places etc. that you are interacting with, and responding to. To gather information about what is happening at the environment level, typical questions asked are:
Where?
When?
With Whom?

Behaviour

This is all about what people and organizations actually do within the environment and is an outward expression of skills, beliefs, values, identity and purpose. It is the actions taken and what is done on a daily basis, for example, what an observer would see or hear or feel when the individual or organisation are engaged in a particular activity. It is not unusual to find that behaviours are not aligned with beliefs, values, identity and purpose.

Capabilities & Skills

This relates to how things get done, including the skills, abilities and knowledge that organizations require and which individuals have. It answers the question how things get done?

Values & Beliefs

Values and beliefs are the ‘whys’ about what is done.

This encompasses those things that are true and important to individuals and an organization within a situation. Beliefs are convictions we hold to be true and these shape our behaviours.

Identity

This is all about what the individual or organization identifies with. For individuals it concerns people's sense of self or their role. It answers the question - Who?

Mission/purpose

This connects to something bigger gives the purpose for the organization or change. For an organization it is often expressed as the mission statement.

Each of the levels is a higher abstraction than the previous one; everything within a system works well when the different levels are aligned. In general, the higher levels have a greater influence and power than the lower levels; it is normally harder to change the higher levels. For example an organization/department can move to a new office location but it will take longer for the people in the organisation to take on and believe in a new set of organizational values. However, if changes are made at the higher levels, than the levels below will also follow and change.

When organizations or individuals make changes, they are less likely to succeed if they don’t make those changes at the most appropriate level. When requirement engineers work on scoping and defining of the context and the boundaries of a given system, it is therefore important that they gather information from all levels and work out where the change work needs to be targeted. ^{[5] [6] [7]}

The systematic approach of the logical levels technique is particularly useful for requirements engineers when working in the early stages of a change programme to set the direction, goals and outcomes for the change. Through making use of the levels to ask questions and gather information about the change initiative, it is possible to assess where changes need to be targeted for a change programme to be a success.

Questions that can be asked to the stakeholders are:

1. What is the purpose of this Change/Transformation programme?
   Who is impacted by this?

2. Who will we be as an organization when this transformation completes?
   How will our customers and employees see the organization following the transformation?
   Is this aligned with the purpose?

3. What does the organization value? Does this transformation align with those values?
   What is important about this transformation?
   Does it align with the organization’s values?
   What is important to how the organization will interact with its customers?

4. What skills are important to achieve the goals set out in this transformation programme?
   To what extent are these skills present at the moment?

5. What does the organization do? Which behaviours will help the organisation through this transformation?

6. What aspects of the environment support this transformation and which aspects hinder it?

The level based questions above can be applied not only to big transformation programs, but also to smaller initiatives and projects.

Next to using this technique for exploring the context and setting the boundaries of the system to be changed or build, it can be helpful to use it during requirements negotiation, especially when conflict analysis is needed.
As IREB defines, one of the major tasks of the requirements engineer is to negotiate requirements in order to establish a common understanding of the requirements for the system to be developed among all relevant stakeholders ^[1]. If conflicts occur, the requirements engineer can apply the logical levels model to analyse at which level the conflict is present.
Is it the environment, for example the stakeholders have different needs considering when they need something or where? Or is it more on the level of values, meaning that the stakeholders have divergent values and preferences?
Or is it maybe a conflict on the identity level, also called relationship conflict, where emotional problems in personal relationships between stakeholders are present?
Figuring out on which level the conflict exists will help the requirements engineer to choose suitable conflict resolution technique.

Reframing technique

Reframing is a very powerful NLP technique, that is based on the thought that the events and situations we deal with do not have inherent meaning. It is us who give meaning to them. It is our past experiences that provide us with context to interpret the new events and situations. The meaning we given to them, depends on us, on the frame we put around them.

Reframing is the mental exercise ^[4] (chapter 15) of changing the meaning of a certain experience or situation by choosing a different ¨frame¨ around it. Changing the way we look at things, will also impact our state and behaviour. Reframing helps us turn problems into opportunities and create better choices for ourselves, the organisation and the society as a whole.

There are two common and interrelated ways to practice reframing:

• Context reframe;
• Meaning (content) reframe;

Context reframe

Changing the context in which a given situation occurs is done by imagining the same situation in detail, but in a different context. Usually the new context is one for which the current situation can add value.

For example, imagine you have a person in your team that is very precise and likes to think of every detail before he acts. So, every time you organize a brainstorming session about the future features of your product, he cannot resist and goes into too much detail, pointing out all the possible problems instead of supporting the ideas generation process. Now, you could think of a different activity where these characteristics of your colleague come handy. And you come up with asking him to pick up on the testing and quality assurance. And then you discover what a brilliant colleague he is, who is so thorough and secure, that no bug can escape his test cases. The quality of your product increases significantly. So, instead of getting frustrated by this person, you have created a new context where this person can add value.

Another inspiring example from the software industry on the power of reframing is the rise of the employability of autistic people ^[8]. While autism condition has historically hindered jobseekers, several global IT companies have thought of (reframed) the undesired condition into a desired skill set. They have found a new context in which people with autism add value, namely they tend to be really good at identifying mistakes and sensing patterns, which are crucial skills for software testing. Autistic people can add unique value, therefore training them in to testers has become normal nowadays.

Reframing is not new. Many fables and fairy tales include behaviors change their meaning when the frames change. One of the most knows fables teaching us about the power of reframing is Andersen's ¨the ugly duckling¨. The young swan, not knowing he is a swan, is raised up by a duck family. When comparing himself to the ducks he feels very ugly, but once he meets the likes of him (change of context), he realizes how beautiful swan he is.

Meaning reframe

The second way to reframe a given experience is to give it a different meaning. Search for meanings which energize you, give you new perspectives and transform your weaknesses into strengths.

Here is an example of a situation, where meaning reframe has been used to motivate you and change your behaviour.
Imagine, you are given the task to assist a junior colleague with complicated work he needs to learn doing. You are very busy and slightly irritated because you certainly do not have time to
waste on teaching, while your important work is staying behind.
However, if you reframe the ¨wasting¨ into ¨investing¨ time in a person who will, once he has learned enough, support you in achieving more in the future, will help you starts feeling differently.
You start feeling your time is wisely spent and the irritation disappears.

Reframing is especially suitable technique for situations where out of the box thinking and brainstorming needs to be facilitated. In the role of Requirements Engineer often we are facilitating strategy analysis discussions where solutions are being generated for a given enterprise need or problem. Here it is important to realise that each question you ask, contains a frame in itself.

For example, consider these two questions:

• Can unidentified customers rate the flight?
• Who can rate the flight?

The first question has only one right answer, yes or no. The second question has an infinite number of solutions, including identified and unidentified customers, employees and crew members. These two questions that try to clarify the business need, differ only in the way they are framed. And as you can see, by changing the frame, you dramatically change the range of possible solutions. 


Being able to guide the audience to reframe their problems, will create space for designing innovative solutions.
The requirements engineers are often working on projects dealing with change in the organisation. And change comes together with resistance. The reframing technique is exceptionally powerful tool in dealing with resistance. You can use it to transform your stakeholder’s objections into benefits and possibilities, thereby gaining their commitment and support for the necessary change.

Conclusion

This is the second and last part of the article in which we have presented the second three NLP techniques that we think are particularly applicable in the core work areas of the requirements engineers.

In this section we have plotted each of these techniques to the RE work areas, as described by the two important authorities in the requirements engineering field: IREB and IIBA.
The matrices show the applicability and the usefulness of each technique for the given RE work area.

A short description follows on each requirements engineer area of work, as specified in the IREB Certified Professional for Requirements Engineering Syllabus ^[1].

System and System Context

This work area is about determining the context and the boundaries of the planned system. All possible context aspects, such as people, systems, processes, events, documents are considered, in order to determine which aspects will be covered by the planned system and which aspects are part of this system’s environment. The context boundary identifies the part of the environment that has a connection to the system to be developed.

Requirements Elicitation

This is one of the core RE work areas. It consists of identifying requirements sources, dealing and involving the stakeholders and applying different elicitation techniques with purpose of finding out the conscious, unconscious and subconscious requirements of the stakeholders.

Requirements Documentation

This work area is about documenting important information about the requirements in different forms, such as the description in prose, diagrams with formal semantics, rules specification up to glossary. Documentation plays a supporting function in communication and therefore needs to be unambiguous, consistent, clearly structured, modifiable, complete and traceable.

Documentation of Requirements using Natural Language

Requirements engineers make great use of the natural language in communicating with the stakeholders and documenting the requirements. This work area describes how requirements engineers can pay attention to the potentially ambiguous and interpretable elements of the language during the processes of eliciting and documenting requirements.

Model-based Documentation of Requirements

Requirements engineers use models as abstractions of an existing reality in order to make it easier to understand information. Models help to process information selectively about the facts and their connections, to record them more quickly and document them unambiguously. Goal models, use case models and entity-relationship models are just some of the models this work area describes in greater detail.

Requirements validation and negotiation

In this work area the focus lies on two specific activities:

• validation of requirements against the defined quality criteria,
• negotiation of requirements in order to establish a common understanding and buy in from all the stakeholders.
  Dealing with conflicts is a crucial part of this working area.

Requirements management

The requirements engineers need to manage the requirements over the whole lifecycle of the system. This work area consists of mastering several techniques such as defining attribute schemas, dealing with requirements prioritisation and traceability, versioning and handling the process of change requests.

Tool support

This work area is focusing on the selection and the usage of requirements management tools which support the RE procedures and techniques being used by a given project or organisation.

The requirements engineering work areas according to BABOK 3.0 ^[2] are listed below.

In the continuation a short description is given of each work area.

Business Analysis Planning and Monitoring is the work area that covers the organization and the coordination of the efforts of business analysts and stakeholders. It includes tasks such as planning the business analysis approach, governance, information management and stakeholder engagement.

Elicitation and Collaboration is a crucial part of the requirements engineer’s work where he or she performs tasks to obtain information from stakeholders and confirm the results. It also describes the communication with stakeholders once the business analysis information is assembled.

Requirements Life Cycle Management knowledge area describes the tasks
that requirements engineers perform in order to manage and maintain requirements
and design information from inception to retirement.

Strategy Analysis is the knowledge area focusing on the most effective way to apply the capabilities of an enterprise in order to reach a desired set of goals and objectives. Strategies may exist for the entire enterprise, for a division, department or region, and for a product, project,
or iteration.

Requirements Analysis and Design Definition is the knowledge area about the structure and the organization of the requirements discovered during elicitation activities. It is about specifying and modeling requirements and designs, validating and verifying information, identifying solution options that meet business needs, and estimating the potential value that could be realized for each solution option.

Solution evaluation is the knowledge area that deals with the assessment of the performance of and value delivered by a solution in use by the enterprise, and to recommend removal of barriers or constraints that prevent the full realization of the value.

Practicing these NLP techniques will help requirements engineers become better communicators. Better communication in turn, will not only increase their professional efficiency and productivity, but also their satisfaction, confidence and resilience in general.

References

• [1] International Requirements Engineering Board (IREB), Certified Professional for Requirements Engineering Syllabus, Version 2.2, 2015, available at: https://www.ireb.org/en/downloads
• [2] International Institute of Business Analysis (IIBA), Business Analysis Body of Knowledge (BABOK), version 3, 2015
• [3] Robbins, A, Unlimited Power: The New Science Of Personal Achievement, Simon & Schuster, 1989
• [4] O'Connor J, NLP Workbook: A practical guide to achieving the results you want, HarperCollins Publishers, 2001
• [5] Lazarus, J, NLP for Business Success, Career Press, 2014
• [6] Cooper, L, Business NLP for Dummies, Publisher For Dummies, 2009
• [7] Knight, S, NLP at Work, 3rd edition, Nicholas Brealey Publishing, 2009
• [8] Hodson, H, Rise of the autistic workplace, New Scientist, issue 2919, 1 June 2013, available at: www.newscientist.com
• [9] Bateson, G, Steps to an Ecology of Mind, University of Chicago Press, 2000