Artifact Driven Elicitation — Explained in less than 9 minutes
Did you know that when the brain becomes confused, it receives a hit of dopamine, resulting in bewilderment that forces the brain to pay close attention? Confused right? No problem, confusion is good for learning!
Now that you are here to learn about Artifact Driven Elicitation, we must first understand the term elicitation. To put it simply an elicitation is the process of collecting information.
In requirements engineering, requirements elicitation is a process of gathering the requirements of an intended software system from stakeholders. It is also known as requirement gathering.
Requirements can be gathered, not just alone by communicating with the clients and end-users, but also through some other practices. There are many such practices out of which some common ones are listed below:
- Stakeholder Analysis
- Research
- Brainstorming
- Interviews
- Questionnaires/ Surveys
- Observation
- Document Analysis/Review
- Prototypes
- Use cases
- Role-playing etc.,
The requirements elicitation phase is followed by requirement analysis and specification phases generally. The techniques of requirement elicitation are mainly of two types. They are:
- Artifact driven elicitation and
- Stakeholder-driven elicitation
The combination of these techniques helps us to achieve a balance of efficiency and effectiveness in our result. In this article, we will be focussing on the Artifact driven elicitation techniques alone.
Artifact driven elicitation
What is an artifact? This term indeed has a broader meaning. The artifacts in software development are different from ancient artifacts(Just in case if you are thinking of them!). An Artifact is one of many kinds of tangible by-products produced during the development of software(Source: Wikipedia). It is a physical part of a system that exists at the level of the implementation platform. It might include any existing information about the system gathered from various sources. These can be things like system prototypes, past documents about the current system, data samples, questionnaires, conceptional grids, data models, reusable knowledge — the list goes on.
Artifact driven elicitation is a method of gathering information of the system-that-was and the system-to-be. It follows existing documentation to understand the system as it was.
Artifact-driven elicitation techniques are listed and briefed below:
Background study or content analysis
One of the first things we need to do is to start elicitation is by collecting, reading, and integrating the relevant documentation(if available) about the:
- Organization: Look at the organizational charts, business plans, financial reports, meeting minutes, policy manuals, job descriptions etc.,
- Domain: Go through some books, surveys, published articles, regulations, reports on similar systems in the same domain. Examine and try to understand the overall domain.
- System-as-is: Examine the documented workflows, procedures, business rules, defect/complaint reports, change requests, exchanged documents, user manuals etc.
This process of conducting the background study is sometimes known as content analysis. It supplies information that we can use later.
Gathering artifacts — Questionnaires
Questionnaires are a relatively easy and effective way of obtaining subjective data. This method is quick yet inexpensive. One more advantage is that we can collect data remotely from a lot of people.
Questionnaires can be qualitative or quantitative based on the type of questions. The most common types of questions asked are:
- Open-ended: These are questions that allow responders to give a free-form response based on their feelings, knowledge and thoughts. They provide rich qualitative data as the answers are detailed. e.g. What happened at the meeting?
- Close-ended: These are questions that usually have a fixed number of options to chose from(such as multiple-choice). We will get a single word or short answers using this method. e.g. Is the meeting good?
Questionnaires help us prepare better-focussed interviews. Interviews act as powerful methods to gather information. The drawbacks of this method include low response rate, inaccurate results etc.,
Repertory grids and card sorts/concept laddering
Using the repertory grid technique(RGT or RepGrid) helps us identify how people interpret experiences. We ask stakeholders to characterize target concepts through value ranges and attributes.
Card sorts are for concept characterization. We ask stakeholders to partition a set of cards. Each card represents a concept graphically or textually. We then group these cards into subsets based on the stakeholder’s view.
In concept laddering, we delve deeper into individual requirements we discover and arrange the concepts into taxonomic trees.
These techniques are simple, cheap, and easy to use. However, they may not always produce accurate and relevant results.
Storyboards and scenarios for concrete exploration
Scenarios and storyboards help us to obtain information from concrete examples through narratives on how things are running in the system-as-is and how things should be running in the system-to-be.
Storyboards are nothing but sequences of snapshots that narrate a story. Snapshots might be a sentence, sketch, slide, picture, etc.,
Scenarios illustrate a typical sequence of interactions. They are a structured form of storyboards.
Prototypes and mock-ups
Prototypes and mock-ups are another way of expressing your ideas other than storyboarding or scenarios. They help us understand the meaning of some of the requirements and turn inadequate ones into adequate ones. They can be in myriad forms.
A function prototype focuses on specific functional requirements. UI prototypes or user interface prototypes focus on usability by showing dynamic aspects of user software interaction. These are used in agile and spiral model settings often.
Mock-ups or throwaway prototypes generate and validate requirements.
Knowledge reuse
The last technique of artifact driven elicitation is knowledge reuse. The purpose of knowledge reuse is to quicken the elicitation by reusing knowledge from experience with similar and related systems. The knowledge requirements can be domain-independent or domain-specific. Quality will increase efforts will reduce using this technique.
General reuse process:
1. RETRIEVE relevant knowledge from other systems
2. TRANSPOSE it to the target system
3. VALIDATE the result, ADAPT it if necessary & INTEGRATE it with the system knowledge already obtained.
Quick Recap:
- Artifact driven elicitation is a method of gathering information of the system-that-was and the system-to-be.
- The goal of this process is to gather background knowledge and to get a better understanding. So that you can ask better questions later.
Artifact-driven elicitation techniques:
- Conducting a background study,
- Artifact gathering through questionnaires.
- Use of repertory grids and card sorts/concept laddering for concept characterization.
- Use of storyboards and scenarios for concrete exploration.
- Prototypes and mock-ups.
- Reuse of relevant knowledge.
I hope this guide has helped you understand Artifact Driven Elicitation a little more. If it does, please let me know in the comments so that I could get to know.
References:
