Options:

Corrine Thomas Albena Georgieva

NLP for Requirements Engineers, Part 1

How requirements engineers can benefit from applying the NLP communication techniques


Unquestionably, being a good communicator helps in achieving greater impact and efficiency in the requirements engineering line of work.

NLP comes from the study of how people get successful results when interacting with others. Through the systematic study of human communication and exploring the dynamics of mind (neuro), language (linguistic) and patterns of behaviour (programming) a set of easy to learn tools, techniques and ideas have been created which can be used by people to improve their communication skills.

This article explains six of these techniques which are particularly applicable to the daily practice of the requirements engineer. It is divided into two parts. Part 1 focuses on the first three techniques listed and part two on the rest:

  1. Senses
  2. Rapport
  3. Different Perspectives
  4. Meta Model
  5. Logical Levels
  6. Reframing


The first technique, the Senses, is about becoming aware of and enhancing the way we use our senses to observe and better understand ourselves and the outside world. We use our senses to experience and interpret what is going on around us. Everyone makes use of their senses in an individual way and has preferences on how the senses are used. NLP teaches us how to recognize preferences in ourselves and notice them in others.

Becoming aware of and becoming flexible with using the senses contributes to improved efficiency in requirements elicitation, communication and management. In addition, this technique can be used with stakeholders to explore and identify possible feasible solutions to a particular business problem during the strategic analysis phase.

Establishing Rapport is the second NLP technique; rapport is about creating harmonious, productive and trust based relationships with others and is something we all do naturally throughout the course of our day to day encounters with others. Through making use of techniques such as matching and mirroring, active listening and paying attention to the discussion partner, rapport can be much improved. This technique is invaluable in any stakeholder meeting or requirements elicitation workshop.

The third technique named Different Perspectives, teaches us how to use different perspectives in order to create a more complete picture of a given situation or problem. This exercise is particularly useful when preparing for a difficult requirements workshop or a business meeting, giving the requirements engineer a tool to anticipate the possible conflicts of interests among the stakeholders.

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 the International Institute of Business Analysis (IIBA).

The last three techniques: Meta Model, Logical Levels and Reframing are explained in the second part of this article.

What is NLP

Businesses today are facing more and more challenge, they are volatile, uncertain, complex and ambiguous, which means that the change projects are becoming increasingly difficult and stressful. To be able to handle this effectively requirements engineers need to have excellent communication skills, be able to adapt to the challenges they face and respond well to the different projects they are asked to work on. Good communication starts with an understanding of oneself. This is then built on to understand others and find ways of working together to achieve great results. Paying close attention to yourself does not come easily to many people; however it is all about noticing what patterns or programmes you run, ie. your default ways of thinking and behaving. By becoming aware of these patterns you can notice those times when they may not be useful to you and may stop you communicating well with others. Once you become aware of them, you have a choice to change the way you run the patterns. [7] (Chapter 4)

In this article we discuss some tools and techniques from neuro linguistic programming (NLP) which you can use to become more effective as a communicator and also apply to other aspects of your role of requirements engineer.

NLP originated in the 1970s through the work of Richard Bandler and John Grinder, it provides a series of techniques and tools which can be easily learned and applied both at work and personally to enhance motivation and productivity. When they began their work Bandler and Grinder and then others studied therapists at work to understand how they achieved the results they did with their clients. [4] Through this they worked out how to replicate the behaviour, attitude and approaches the therapists used. This has been documented and formed the start of the NLP techniques in use today. In day to day work it is possible to observe and model others in order to understand how they get excellent results and then work on learning this. It is even possible to model your own behaviour and learn where to make adjustments for gaining improvements.

NLP – Neuro Linguistic Programming is a rather complex name but as it is broken down into its component parts the relevance of each part of the name becomes clearer:

Neuro – relates to the neurological system and how we use our five senses both to experience the world around us and to create our internal world through remembering and imagining. The conscious and unconscious thought processes activate the nervous system which influences your physiology, how you feel, what you do and what you say. More detail on this is covered in the sections on the senses and building rapport.

Linguistic – is all about how we use language to make sense of our experiences, to talk to ourselves and to communicate with other people. The section on the meta model explores the use of language patterns.

Image 1: Lithograph “Self-Portrait in Spherical Mirror” by M. C. Escher, 1935

Programming – relates to the patterns of thinking and behaviour we run, like a computer program it is a set of steps designed to achieve a particular result. We learn steps to achieve things we want and then repeat those steps in the same way. Some of the patterns are very useful and serve us well, yet others can be frustrating and annoying.

Examples of patterns of behaviour are:

For example, if you are nervous before a workshop or meeting you may be telling yourself that it won't go well and your body will respond by 'doing' the physical response that it has learnt is nervousness, i.e sweaty palms, fast heartbeat, butterflies in the stomach.

NLP studies in a very precise way what humans think, say and do; it gives insights into the workings of the internal mind. One of the best ways to find out about NLP is to explore, experiment and have fun whilst finding out what NLP can do to support you and improve your role at work. At times it can feel awkward and difficult when you try something new especially when you are looking to change behaviours which you have done for a long time. It is worth trying new things little and often rather than overwhelming your brain with lots of new ideas all at once. Over time you will start to notice changes in the way you think and behave.

The senses

One of the key pillars of NLP is making use of the senses. We have five senses through which we experience the world around us. As we go about our day to day lives our senses are continually picking up millions of pieces of information about what is going on around us. We have the ability to filter that information to understand it otherwise we would be continually overwhelmed; our senses form a key part of our filtering process.

Through using the senses we receive information about what is happening externally and then build an internal representation of that within our mind again using the senses. In addition we also carry out an internal dialogue when creating this representation, this is the words we put to the representation we have created. Our five senses are:

The internal dialogue or self-talk is known as auditory digital. For example you may be going on holiday and step out of your car or aircraft in a new place you've never seen before. You look at it and see a wonderful view, an internal representation of this is created and becomes part of your memory and you might say to yourself 'This place is wonderful, just as I imagined it would be'.

Whilst we use all of the representational systems to some degree, many people have one or two senses that they prefer to use. Generally in Western culture within the working environment there are four main representational systems, these are:

VISUAL – this concerns external images, creating images and visualising within our mind.

AUDITORY – this involves external sounds, creating sounds in your mind and remembering sounds.

KINAESTHETIC – this concerns touch, internal sensations and emotions and awareness of the body.

AUDITORY DIGITAL – this is the internal self-talk, an assessment about a topic.

In the field of NLP it is generally thought that:

35 - 40% prefer visual system
20 - 25% prefer auditory or auditory visual
40% prefer kinaesthetic system [5] (chapter 6)

Here are some typical indicators of the preferred representational systems which can be useful in recognising what systems a person may be using. These may not be true for every single person but over time it is possible to see patterns in both your own and other people's communication.

Visual – prefer to think in pictures and diagrams

Auditory – prefer to think/communicate using words

Kinaesthetic – prefer to feel/experience things

Auditory digital – prefer to think in ideas and analyse

Each of us has a tendency to communicate in our own prefered system which may not match those we seek to communicate with. Within requirements engineering we communicate with many people from different areas of a business who could all have very different preferences. The more we become aware of our own preferences and practice at being flexible with how we communicate then the easier it will become to communicate effectively with a whole range of stakeholders.

Making use of the senses is applicable to many areas of the requirements engineer’s job, and is particularly useful in the following areas:

For example, when planning to interview a stakeholder to elicit requirements consider what you know about them and what you think their preferred senses are and then tailor your session with them to appeal to these senses. If they have a strong visual preference, then make use of lots of diagrams and models as you ask questions and explore ideas together. Alternatively, if they have a strong auditory preference, they may prefer just to talk to you whilst you ask questions and take notes. Someone with a strong kinesthetic preference may prefer you to visit them in their usual working environment, so that they can show you what they do and what they consider should be done to make things better.

Rapport technique

Having the ability to get along well with other people is essential for requirements engineers as they meet lots of very different stakeholders throughout the course of their day to day work and need to be able to develop good working relationships with many different people.

Rapport is at the core of all good communication, it is all about connecting with other people and finding a common understanding, this forms the basis of how relationships are built. When people are relating well they trust, respect and understand each other. Rapport is the ideal foundation for discussion, negotiation and decision making. Strong rapport is built over time through ongoing relationship building. When two people are in rapport they are on each other's wavelength and are able to see each other's point of view. Each of us builds rapport naturally with others and it is usually only when we have issues building rapport that we notice the differences between ourselves and other people.

Rapport building is such an unconscious and natural thing to do that you probably don't even think about it. When you meet someone for the first time you will start a process of making a connection with them. This is done initially through looking for things you have in common through conversation such as discussing where you live, what you do for work, what your interests are and how you like to spend our leisure time. Alongside the conversation between two people there are many other things happening unconsciously which also form part of building rapport. As rapport is built we will start to match and mirror the body language of the person we are chatting with. [6] (chapter 6)

When you are next in a meeting, in a pub or restaurant take a few moments to observe people who are deep in conversation and you will probably notice that the positions of their bodies are often matching each other and they use similar gestures. If you were to get closer you would find that the pace of their speech is similar and the words they use are aligned. In the section on senses language was mentioned and people who are in rapport will often use a similar representational system to discuss something.

Building rapport is one of the most important skills a requirements engineer can have. When rapport happens naturally at work, progress happens; ideas are shared, concerns discussed and then a conclusion reached. It is possible to create rapport with people with whom you don't have anything obvious in common and who seem very different to you. In these situations you can consciously choose to do the same things that you normally do unconsciously to build rapport.

There are some key principles underpinning rapport:

There are four main ways to create and build rapport, these are:

1. Using good listening and observation skills to pay close attention to:

2. Match and mirror body posture and movement to:

3. Pacing by:

4. Leading by:

When looking at rapport it is often a good idea to start with creating a map of those people or groups of people you interact with. This could be within your work environment or include all areas of your life. This can be done using a mind map or something similar:

Figure 1: The example given here shows relationships from both the business and personal environments as taking a holistic view often provides more insights into how you build rapport with individuals.

Once you have the map, look at it and notice which groups or individuals you interact with easily and which are more challenging. Identify those people you would like to build greater rapport with and then when opportunity arises for you to observe any of these people develop your skills by noticing the following about how they communicate:

VOICE:

BREATHING:

MOVEMENT AND ENERGY LEVELS:

BODY LANGUAGE

It is often the subtle changes that give the most clues to a person’s thought processes. Choose one or two of the characteristics and either match or mirror what they are doing. Be careful here not to copy every detail of someone's voice, gestures as matching and mirroring is not the same as copying which can be seen as mimicking and does not build rapport. Matching and mirroring is done with respect for the other person; the intention is to communicate to the other person’s unconscious mind that you are on the same wavelength as them.

Once you are able to match someone else, sometimes known as meeting them in their map of the world in NLP, then you can lead them in the direction you would like to go in order to have your message delivered and understood.

Building rapport with a group is more complex than building rapport with individuals, yet it is very useful in meetings and workshops where you want the group to engage and work with you.

Some ideas of how to achieve rapport with groups are:

Good relationships are essential to many aspects of the requirements engineer's role and so rapport is relevant to all areas where you are engaging with other people.


Different perspectives

When trying to understand a given business problem, it often helps to look at it from several different perspectives. There is no ¨right¨ perspective, instead each perspective adds to the creation of a more complete picture of the situation.

The Different Perspectives technique is built around these three perspectives [3] (chapter 3: Learning):

  1. Your own perspective, also called the first position. This is based on your own views of the situation using your knowledge about yourself and the given situation plus your values.

  2. The second perspective or position, is the viewpoint of another person and the ways he or she thinks, feels and behaves.

  3. The third perspective is the neutral or detached one. This perspective enables you to consider the situation as an independent observer who is not directly involved. In this position you observe the situation as if you were situated some way from it looking down at what is happening.

The technique suggests taking each of these three positions and from each position systematically analysing a given situation or a business problem.

We will illustrate the application of this technique with an example.

Imagine you are a requirements engineer who wants to prepare for a difficult requirements elicitation workshop.

First you mentally consider the workshop from your own perspective. You define the outcome you want of the workshop, as well as how you will know you have achieved it.
In addition, you think of how to structure the workshop and finally you define your fall back position or what you will do when your outcome could not be achieved.

Now you move to the second position. Use your imagination to consider the workshop from the perspective of each of your stakeholders. For each stakeholder define what they will be thinking and feeling about the workshop. How are they likely to behave during the workshop? What are their objectives and motivation?

Check if there could be conflicting interests and what strategies you have for dealing with them. A typical example of conflicting needs in a complex IT-enabled business environment are those of the development and research department eager to innovate and experiment, against the operations department that is looking for stability.

Image 2: Lithograph “Convex and Concave” by M. C. Escher, 1955

Finally, use your knowledge and imagination to consider the workshop from the third position, the neutral and detached one. To get into this perspective, you need to forget for a moment that it is about you and your goals and outcomes. You need to step back mentally to observe the situation objectively. For example, you could imagine you are one of the company directors and you are concerned with its general wellbeing. From this perspective, you analyse your needs and those of your stakeholders in search for common ground. Look for ways to get the stakeholders to understand each other and move the conversation towards the realization of the common goals.

This mental exercise of visiting the three different perspectives has given you a more complete picture of the workshop and how it might run. These insights will allow you to prepare for and anticipate the possible conflicts of interests among your stakeholders. You are now in better position to create a workshop that enables negotiation of requirements that benefit all parties.

Each position has its own benefits and drawbacks. Taking the first position in a given situation, such as a requirements workshop, can be very powerful in making our goals clear, yet we can come across as opinionated. Some people are very good in using their imagination to understand the feelings and thoughts of other people. By nature they take the second perspective, showing empathy, but should watch out for neglecting their own interests. Third position enables us to judge the situation objectively, however we could appear distant and uninterested.

This example from the Requirements Negotiation work area is certainly not the only application of the Different Perspectives technique. Requirements Elicitation and Strategy Analysis are other areas where this technique can be used to structure and accelerate the discovery and envisioning of possible solutions that create greater value for stakeholders.

Conclusion

This is the first part of the article in which we have presented the first 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 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:

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.

A short description is follows 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.

Part two of this article will focus on another 3 useful techniques, namely: The Meta Model, Logical Levels and Reframing.

References and Literature



Corrine Thomas

Corrine Thomas is an experienced leader and Business Analyst with over 25 years of working across a range of industry sectors including Local Government, Healthcare, Telecommunications and Financial services. She has a proven track record of creating and transforming capability of business analysis practices through good people management, training and coaching. She also has many years’ experience of delivering business analysis on large scale change programmes. She is a qualified NLP trainer, coach, an inspiring conference speaker and published author.

Albena Georgieva

Albena Georgieva is a senior requirements engineer with experience in the e-commerce and public domain. During her technology consultancy career at Capgemini she has successfully conducted and coordinated business analysis efforts as well as advised customers on the improvement of the requirements management process in complex corporate environments. Her most recent clients are KLM, Unilever and the Dutch Ministry of Foreign Affairs.
She is currently working on several e-commerce and digital marketing initiatives at KLM mainly in the roles of information analyst and product owner.