Issue 21

The root of all evil in software development

Cluj Business Analysts
Mădălina Crișan, Business Analyst Monica Petraru, Product Manager Cătălin Anghel, Business Analyst


Supposedly the answer is bad requirements. It is risky to take a radical stand and to isolate the determining cause to a single factor, but poorly conducted elicitation is surely one of them. From my experience, during elicitation, even with the best interest at heart, there is neither discrimination nor consideration for the terms requirements / solution design. This results in a cumbersome bundle of mixed information that doesn"t add up into a cohesive, unitary whole.

There"s incontestable value and need for design, but in early rounds of elicitation, focus ought to be paid to underlying cause for the requirement to help us to generate the suitable options for our stakeholders.

The risks of not doing this segregation between the two terms are multiple, ranging from:

  • implementing a specific solution for a general problem that we were unable to express,
  • loss of stakeholder interest, involvement and trust,
  • "false positive" endorsements or the worse,
  • further re-work and costs and eventually project failure.

Below, there are arguments from a business analyst"s perspective to support this view point.

We"ll start with the magical definition of elicitation, then we"ll be diving into its purpose and object, exploring how it relates to the interpersonal relationships and concluding with a heavenly match between interview and interface analysis.

A magical definition

BABOK (Business Analysis Body of Knowledge) defines eliciting as: to draw forth or bring out (something latent or potential); to call forth or draw out (as information or a response). According to IREB (International Requirements Engineering Board), elicitation techniques fulfill the purpose of finding out the conscious, unconscious and subconscious requirements of stakeholders. Words like "latent", "potential", "unconscious", "subconscious" link back into the Latin definition of the word, which is to "draw out by trickery and magic" (www.thefreedictionary.com). There"s something to the magical character of elicitation.

In my opinion, it thighs back to the fact that clients don"t have a rigorous or formal view of domain. Hence, it cannot be expected of them to completely be aware of domain- problem relationship. We, as business analysts, model the business, that is, we create an abstract and simplified view of the world, with all the advantages and perils that come along with. It is none the less true or valuable that modelling:

  • guides elicitation - and helps formulate questions, helps uncover problems, highlighting inconsistencies, conflicting requirements, disagreement between stakeholders.

If you consider a poorly expressed problem, stripped of details, pushed forward into solution analysis - you may have found some justification for the difficulties caused in projects by poor requirements.

The object of elicitation

It is both stakeholder requirements, and the solution requirements.

Requirements definition according to BABOK is: "(1) A condition or capability needed by a stakeholder to solve a problem or achieve an objective; (…)".There are many more definitions, but words like "problem", "opportunity", or "constraint" appear recurrently.

Design on the other hand is a collection of decisions about how to implement a set of requirements.

Surfacing what is of value to us is easier said than done, because as it turns out we are terrible at estimating what is of value to us, and to what extent. Moreover, we are wired to think in terms of solutions rather than problems simply because of visualization ease. This is why there are difficulties in finding the fine boundary between problem statements, problem definition on the one hand, respectively solution definition on the other hand.

Building upon the previous argument, requirements are statements which translate or express a need and its associated constraints and conditions, such that we can now differentiate between stakeholder requirements and solution requirements. The Business Analysis Core Concept Model makes a clear definition of change, need, solution, value, stakeholder, and context, and maps these values as follows:

  • Requirements: Need, Value, Stakeholder;
  • Design: Solution, Need, And Context;

There"s no fine grain line between the two, as they share the need. What is certain though, is that when we set out for elicitation, it should be clear to us what the object of the elicitation is. It is in the engagement phase of a project that one should lay down the rules regarding the granularity that constitutes design details, upon which the stakeholder is happy to have no steering or decision authority.

Empty window frame

A trivial example whereby I choose to disjoint myself from the triviality and how this situation is handled in almost every case, an example I am going to use as a hyperbola to make a point. Consider an empty window frame. You"d be tempted to say, we"ll buy insulating glass window and the issue is solved. Your problems could be:

  • esthetics, comfort or health - wind and rain get into your home ruining furniture and your floors, or
  • safety related - you are exposed to burglars.

Let"s think about the context. What if your broken glass pertains to a mental health facility, or to a country side field? Is the solution we inferred still suitable?

In the first alternative, you would certainly be interested in the safety aspect and also the privacy aspect. So you may need reinforced, insulated, mirrored glass. For the broken window in the field, you may only be interested to have a cover for rain - in which case a thick foil of plastic could do the job just fine.

Human Characteristics in Elicitation

You can leverage many human tendencies to your gain during elicitation, but not if you have impaired expectations, desire for self- expression or exploit the interviewee"s performance anxiety. Feelings like desire to be recognized, appreciated predisposition to curiosity, gossip, the instinct to complain, and last but not least - occupational hazards: advising, teaching, correcting challenging are all very important levers to use during elicitation.

You can try one of the obvious - as conversation starter: expression of mutual interest, simple flattery, quid pro quo exploit, or, with the necessary caveat - for the experienced or daring: oblique references (comments made indirectly, in either a positive or negative light, which generate either defense or criticism; useful to cross check understanding). Also without the partner noticing, the business analyst can insinuate during his speech - provocative statement or taking an opposing stand which will result in knowledgeable people wanting to instruct, correct.

Observe target"s visual response and first and foremost, minimize the ego threat. Nobody likes to be pointed fingers under the spot spotlight, so for a higher return on the long run, act more like an "accomplice" who understands the challenges of having to know the right answers and avoid the "go fetch" attitude.

A match made in heaven: interview - interface analysis

One of the techniques made available by BABOK is the interview, which is defined as a conversation that compels people to voluntarily tell you things without you asking. Even though it is a planned conversation, and it sounds like it is straight forward, the fact that you need to be building on what you learn during the interview and human tendencies makes it harder than it meets the eye.

People say "fail to plan = plan to fail", and this is why it is recommended to start by formulating the relevant questions (open, hypothetical) and consider your relationship with the target namely the attitude info sharing. Having done this, during the interview, you can and should re-word questions to motivate sharing and validate your understanding.

There are key words that can be used to keep our eye on the ball, and prevent important knowledge slipping through your finger: WHY - leads to deeper motivations; WHAT - leads to facts; HOW - leads to a discussion about process, not structure; COULD - encourages maximum flexibility. Other helpful questions are: What, precisely, is the problem to be solved? When does the problem occur? What generates the problem? What situations, are they new or old? How is the problem handled now? Why does the problem exist?

The so called "putative" questions go one step further by asking about a situation in a way that tests your model view of the domain. In my opinion, this would equate to replacing variables in a formula, with numbers.

The most important activity you do in elicitation is not talk, but listen, or else you run the risk of unintentionally leading the interviewee. When asking questions, first and foremost, we need to remember the opportunities to be addressed problems to be solved, the problems to be solved and the constraints that we need to comply with.

Like most people, you may be under the impression that this is more or less just a smoke screen, and that it doesn"t help write code, so consider you have successfully put into words the problem to be solved, opportunity to be addressed, constraint to comply with. You have also drawn a context diagram (and you now know whether you"re filling in a window frame on the country side field or in a mental health institution).

Next in terms of steps and something that fleshes out the details required for development: Interfaces. Interface analysis serves the purpose of identifying connections between solutions and/or solution components and defines how they will interact: interfaces to external applications; interfaces to external hardware devices.

For defining interfaces it is important to specify the type of interface, and the purpose. Then we state the inputs and outputs; define validation rules that govern inputs and outputs; Identify events that trigger interactions.

There is a heated debate on the definition of requirements that helps get some closure on this topic. This debate goes round in circles only to come to the conclusion that the WHAT for one group, can be the HOW for the next group, as we move from business executives to executants.

There"s no single recipe for preventing chaos regarding requirement but some helpful ideas are:

  • placing the due importance on problem statement,
  • envisioning and declaring the objective and object of your elicitation activity
  • iving a couple rounds of gathering the requirements,
  • gradually diving deeper and deeper into solution design,

All this, once we"ve understood the problem/opportunity you want to solve, your options to address it... and the "business layer" your work is aimed at.

Requirements Elicitation - Best practices

Dear colleagues, as you have already found out the process of requirements elicitation is concerned with collecting information and specifications from different stakeholders. Before the requirements are formally entered into a requirements list, the analyst or requirements engineer needs to lean and issue them to careful inquiry in order to ensure that they are well formed, this being the basis for any further elicitation action.

Secondly, it is of extreme significance that you, as business analysts, possess a toolkit of techniques with the purpose of fitting your method when gathering requirements.

Moreover, we, as business analysts want to deliver in the end a business analysis approach of valuable quality. This means, which better designed processes, will result in a better customer experience, if they do not, the question may be asked, why using them? The possible upgraded customer satisfaction will be difficult to assess, however, unless there is evidence, which suggests specific customer dissatisfaction

With things as they are now. The question that should be emphasized: how can we obtain a satisfied customer in the end? As most of you can remark, a possible and feasible answer is quite simple: by applying a wide variety of best practices known in the area of business analysis.

The success or failure of a system development effort depends on the quality of the requirements. The quality of the requirements is greatly influenced by techniques employed during requirements elicitation because elicitation is all about learning the needs of users, and communicating those needs to system builders.

  1. Collaborative sessions - standard or default approach to eliciting requirements
  2. Best practice :
    • Essential when a large, diverse, and autonomous set of stakeholders exists.
    • Emphasizes creativity to aid envisioning innovative systems
    • The use of technology facilitates conducting the group session with stakeholders distributed over a wide geographical area.

Models (data flow diagrams, state charts, UML)

Historically used as the elicitation technique - Currently a means to:

  • Facilitate communication
  • Uncover missing information
  • Organize information gathered from other elicitation techniques and
  • Uncover inconsistencies.

Best practice

  • Time-ordered sequences of events to capture a typical interaction between the system and the systems or people it interfaces with
  • Create the DFD on a white board as the result of collaboration because the purpose for any model is to help the thought process, not serve as final customer documentation.
  • Build DFDs bottom up based on events as defined by essential systems analysis
  • The use of data dictionaries whenever there are multiple, diverse, and autonomous stakeholders.

Dear colleagues, software projects actually require pragmatic approaches for applying the corresponding technique or method that are doable in real - life situations and constraints. We, as analysts, need a practical guidance in applying best practices in the phase of requirements elicitation process.

Requirements Elicitation - Challenges and Future Steps

Requirements elicitation is a complex process involving many activities with a variety of available techniques, approaches, and tools for performing them. The relative strengths and weaknesses of these determine when each is appropriate depending on the context and situation.

Which techniques and approaches should be used for a given requirement elicitation activity?

As a relevant example, the use of more requirements elicitation technique in high specifications volatility projects can be possible and applicable. Interviews, prototyping techniques or workshops are combined in order to collect the wishes from those projects as they are extremely complicated and involve randomly varying requirements. If we deal with, geographically distributed software development process, groupware techniques (video conferences, use cases, brainstorming) besides efficient requirements management are recommended/

We should not forget that elicitation techniques have their strengths and weaknesses. What"s more, to reason for differences, a strong requirements elicitation process should use more than one technique and method.

The beauty relies on choosing the right approach and this step requires an understanding of the audience and the pro and cons of each possibility that we have at our disposal.

Other important argument: the choice of techniques to be employed is dependent on the specific context of the project and it is often a critical success of the elicitation process.

Strong arguments:

  • The selected technique is recommended by the approached methodology.
  • The selected technique is the analyst"s favorite.
  • The choice of the technique is governed by the intuition of the analyst to be the best approach in a given situation

Clearly requirements elicitation is best performed using a variety of techniques. In most of the projects several methods are employed during and at different stages in the software development life-cycle, often in cooperation when complementarily.


Over time, a number of important challenges and trends have occurred within the field of requirements elicitation process.

One of the most important challenges is the development of ways to reduce the gap between research and practice in terms of awareness, acceptance and adaptation. This can only be achieved by setting the results into practice and making the approach more attractive, thereby providing the relevant proof and motivation for business analysts to use them.

Other challenges that the business analyst may encounter during the elicitation process include:

  • Conflicting requirements from different stakeholders
  • Unspoken or assumed requirements
  • The stakeholders" unwillingness to change or help design a new product.
  • Not enough time allocated to meet with all the important stakeholders.
  • Knowing when and which techniques, approaches and tools to use combined with the knowledge of how → improve the chances of customer satisfaction and project success;
  • Limited access to project stakeholders;
  • Geographically dispersed project stakeholders;
  • Stakeholders change their minds;
  • Conflicting priorities;
  • Too many stakeholders are willing to participate;
  • Stakeholders - overly focused on one type of requirement;
  • Stakeholders - afraid to be pinned down;


  • Developers do not understand the requirement.
  • Developers do not understand the domain knowledge.

The key to overcoming these challenges as you elicit requirements is to continually motivate your users, developers and customers to communicate and cooperate with each other. You can do this by selecting the right elicitation techniques.

Future of elicitation techniques

Despite obtaining a suite of successes and progresses in the area of requirements elicitation, there are still some issues which are waiting to be taken appropriately into consideration.

Below some of the potential requirements elicitation research areas that are recommended to be taken into consideration are listed:

  • Reducing the gap between the theory and practice, and experts and novices;
  • Increasing the awareness and education of analysts and stakeholders in industry;
  • Developing guidelines for technique selection and managing the impact of factors on the process;
  • Investigating ways of collecting and reusing knowledge about requirements elicitation;
  • Integration and use of new technologies including web and agent based architectures into the support tools;
  • Exploring how requirements elicitation activities relates to new and developing fields of SE (AGILE development methodologies, web systems)


The process of requirements elicitation, including the selection of which techniques, approach, or tool to use when eliciting requirements, is dependent on a large number of factors including the type of software project being developed, the stage of the project, and the application domain to name only a few.

Most of the approaches require a significant level of skill and expertise from the business analyst to use effectively.

However, from the range of existing techniques, variations of interviews, group workshops, observation, goals, and scenarios are still the most widely used and successful in practice.

In the end, the choice of the corresponding elicitation techniques for the respective project is made by the REQUIREMENTS ENGINEER based on the given cultural, organizational, and domain specific constraints.


  1. A Guide to the Business Analysis Body of Knowledge(r) (Babok(r) Guide), by IIBA (Author), Kevin Brennan (Editor)
  2. Requirements Engineering, by Elizabeth Hull, Ken Jackson, Jeremy Dick
  3. Mastering the Requirements Process: Getting Requirements Right (3rd Edition), Suzanne Robertson, James Robertson
  4. Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB compliant (Rocky Nook Computing), by Klaus Pohl , Chris Rupp
  5. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series),by Dean Leffingwell
  6. The Business Analyst"s Handbook, by Howard Podeswa
  7. Discovering Requirements: How to Specify Products and Services, by Ian Alexander, Ljerka Beus-Dukic
  8. OCEB Certification Guide: Business Process Management - Fundamental Level, by Tim Weilkiens , Christian Weiss , Andrea Grass
  9. Requirements by Collaboration: Workshops for Defining Needs, by Ellen Gottesdiener




  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects