Cluj Business Analysts 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:
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.
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:
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.
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:
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.
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:
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.
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.
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:
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.
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.
Historically used as the elicitation technique - Currently a means to:
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 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.
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:
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:
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.
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:
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.
by Ovidiu Mățan
