Name of Skill

Elicitation of Requirements

Classification of Skill

Requirements elicitation is a skill that requires both, strong technical skills in addition to strong non-technical (soft skills). Bridging between business problems and its technological solution involves both, a lot of interaction with the stakeholders and strength in understanding the technology (software). Therefore, the requirement analyst should have sufficient software knowledge to be able to gather the technical constraints in addition to being a great communicator.

To clarify more the important skills for a good requirement analyst who can elicit requirements:

• Fundamentals skills: One must possess communication skills, management skills, problems solving skills, as well as research skills.
• Business Analysis skills: Comprehension and documentations skills are paramount to this role especially when coupled with creativity.
• Technical skills: Knowledge of software and IT skills in addition to experience in creating test cases and running acceptance testing with stakeholders.

Prerequisites for Skill

A requirement analyst is needed to conduct elicitation. Experience in understanding the problem domains of different software project and identifying the critical system stakeholders are important traits. Prerequisites for this skill include excellent communication skills to interact with the stakeholders for interviews, run background studies for the system-to-be, and gather useful data through questionnaires, flowcharts and surveys. A good requirement analyst also must have a strong eye for scope to help the stakeholders narrow down requirements toward a set of important requirements that can be implemented.

Related Software Engineering Area(s)

Requirements elicitation activities are related to Software Requirement Engineering as a whole. Moreover, Requirement Engineering is related closely to Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Quality in addition to other areas.

Rationale for Skill

Requirements elicitation is a skill that has a big role in determining the level of success of a certain project, therefore it plays a big role in a project's fate. With the endless and changing requests of stakeholders, the requirement analyst working in the elicitation plays an important part in this role. This skill was chosen because it extracts useful requirements and helps software engineers select the correct elicitation techniques for identifying the right stakeholders and paves the way towards the right interaction. Organizational and technical constraints for the system-to-be is also clarified in the elicitation phase.

With all of this in place, the elicitation done helps to minimize errors or missing requirements, after the project's delivery, that is usually costing hundred times more to fix. Since there will be continuous discussions with the stakeholders, alternative feasible solutions are always suggested to satisfy the completion of the project within the given timeframe meeting the delivery deadline. For example, a requirement engineer would explain what is meant by a “wicked problem”, by providing examples of such problems (in one of the meetings with stakeholders) to avoid having any.

Roles for Skill

The Requirement Engineer and Technical requirement analyst play an essential role in requirement engineering and specifically in requirements elicitation. They are responsible in eliciting the needed requirements from main users and other stakeholders. Since the RE/BA are responsible in capturing the intial details from the customer/stakeholders, they have a responsibility to minimze the cognitive distance with the software PM/development team.

Work Related to Skill

After gathering several requirements through various elicitation techniques (and possibly selecting the most optimal approaches), requirement modeling is produced once all the requirements are elicited. The requirement modeling can be modeled using UML (Unified Modeling Language), while it is provided to the clients/stakeholders in the business language. Use case diagrams and activity diagrams would also accomplish this.

Click on the link (on the right) for an example of a Use Case diagram: UC diagram example

Real-World Example

Selecting One artifact-driven elicitation technique that could be used would be Card sorts and Repository grids. A hypothetical example would be having an open dialogue to discuss a project similar to a streaming website, such as "YouTube". The scenario provided is based on the Brainstorming and User Story technique. In this scenario, "the card" was used to note down these requirements.

The round of discussions for gathering requirements would be as follows (written down on the Cards):

1. Point 1: "A Website for streaming Videos created by Users."
2. Point 2: "Different types of users exist. Some are contributors, and some are only watchers (users streaming videos only) "
3. Point 3: "The contributors would be called creators. And as a creator, they can upload videos 24/7."

At this point, there can be a conversation or an open dialogue discussion on the points written down on the cards:
4. Discussion 1: "Finding a video/video category: there should be a search bar based on keywords."
5. Discussion 2: "How to upload: There should be an upload button that creates a one-shot upload from the local machine of a user to the website"
6. Discussion 3: "User files sizes: Video files should be restricted to 100 MB and a length of 5 minutes"
7. Discussion 4: "User file format: Standard video files as .mp4 and .mpg"

Role of Academia or Industry in Cultivating the Skill

Research papers and academic books nurture the idea of elicitation. Currently, there is a focus on the types of interviews being done, and whether they are structured interviews or unstructured, to check which collects more information compared to the other. Different research papers are conducting surveys and evaluating some techniques for eliciting requirements of computer-based systems, paying particular attention to how they deal with social issues.

Tools Supporting the Skill

Elicitation techniques have complementary strengths and limitations. There are artifact-driven and stakeholder-driven elicitation techniques. Elicitation is being practiced on small and large complex projects.

The following provides a list of techniques used for elicitation:

1. Brainstorming and User Story
2. Document Analysis
3. Focus Group
4. Interviews
5. Interface Analysis
6. Observation
7. Prototyping
8. Survey/Questionnaire

A 7 minute video explaining what is Artifcat-Driven elicitiation:

To compare the various elicitation techniques and showing the strengths and weaknesses of each, please refer to the below table:

Name of technique	Strengths	Weaknesses
Brainstorming and User Story	Speed of idea collection	Sometimes, participants are not creative and prepared
Document Analysis	Reuse of existing material	Finding information could be difficult
Focus Group	Saves time and cost by eliciting many requirements	Shortage of solid/numerical data
Interviews	Direct way of questioning the stakeholders	The interviewer must be well-prepared and experienced in software projects to get the needed answers
Observation	Captures and elicits information not found in the documentation	Due to the limited period, abnormal observations may be missed
Prototyping	Minimizes the adherence distance	Limited to a certain scale due to cost andn budget factors
Survey/Questionnaire	Yields a large set of results that could be quantitative	Could open the door to some unanswered questions due to missing information

Skill Self-Assessment

6/10

The best way to assess and self-evaluate is to measure what one knows versus what one does not know. My knowledge in this area is limited to the readings I have done, in addition to eliciting requirements for projects done in Academia, however not in practical real world projects. This is the main reason why I would give myself this rating, as I feel I am lacking adequate industry experience, and as a result, I may have missed touching some corners. In addition to that, I cannot judge how useful a Group Brainstorming session with multiple stakeholder is, compared with a one-on-one interview with a stakeholder, and which is more effective in terms of communication channel and productivity. This rating is based on my understanding, after acknowledging and realizing how important it is to elicite. The input it provides is massive to steer a project in the right path. In addition to that, I think there could be some issues in recalling all of the points being discussed after every successive interview/meeting. Also, there should be equal attention on all details being discussed (so there is nothing missed). Elicitation requirements sheds the light and emphasizes how important communication and agreement are for the success of a project.

References

Please find below the list of references used in writing this web page:

• Wikipedia. Requirements_elicitation. https://en.wikipedia.org/wiki/Requirements_elicitation
• Pierre Bourque, Richard E. Fairley (2014). Swebok V3.0. Guide to the Software Engineering Body of Knowledge
• Axel van Lamsweerde (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications
• Pankaj Kamthan. On Distances in Software Engineering. https://users.encs.concordia.ca/~kamthan/courses/soen-6011/se_distances.pdf
• JosephA.Goguen, CharlotteLinde. Techniques for Requirements Elicitation. https://pdfs.semanticscholar.org/dfa9/c873a3039c27fef9901bad0341f47c8275e2.
  pdf?_ga=2.103306437.497009371.1596861978-1104115924.1596861978