EXERCISE #1 SOFTWARE REQUIREMENT ELICITATION

Requirement Elicitation Through User Stories and Scenarios

By Sandino Vargas-Pérez

This exercise will introduce you to the software requirement elicitation process in Software Development. You will engage in requirement gathering, user story development, and scenario modeling to design a system based on a real-world user request. The focus is on translating user needs into structured requirements that guide the development process.

Exercise Description:

You will assume the role of software developers tasked with building an Art Catalog System for a professional artist. The artist wants to display high-resolution images of their paintings and photographs with relevant metadata, such as titles, descriptions, dimensions, and pricing for potential buyers.

Through this exercise, you will simulate the software requirement gathering process by conducting user interviews, defining user stories, and creating usage scenarios. By the end of the activity, you will develop a document, which will serve as a blueprint for developing a structured Software Requirement Specification (SRS) document for Exercise #2.

Learning Outcomes:

By the end of this exercise, your team should:

• Understand the importance of software requirement elicitation in software development.
• Develop some awareness on how to conduct user interviews to gather and refine software requirements.
• Develop clear and actionable user stories to guide the development process.
• Create structured usage scenarios that illustrate system functionality.
• Improve their analytical and problem-solving skills by considering user needs, usability, and system limitations.

---

Stage 0: The Stakeholder's Request

The following is a fictional request by a client who has commissioned your team with the development of a software system to facilitate their work as an artist and creator. After another team has reviewed the client's request through interviews and email communication, they have come up with a distilled version of what the client wants for the system and organized these "wants" as features with some descriptions about their use or need:

As you can read, the client has a general idea of what they want and your team has been provided with a series of features which are located in the first column ("Art Display", "User Accounts", etc.) and in the second column there is a reasoning for the use and need of that feature.

To Do:

Become familiar with the features requested by the client: you can look up websites with an image uploading feature, for example, to understand how the requirements for the "Art Display" feature are approached by a web developer. Take into account what Sommerville (pp. 112-113) says about system requirements from the stakeholder's perspective:

Stakeholders often don't know what they want from a computer system except in the most general terms; they may find it difficult to articulate what they want the system to do; they may make unrealistic demands because they don't know what is and isn't feasible. [...] Stakeholders in a system naturally express requirements in their own terms and with implicit knowledge of their own work. Requirements engineers, without experience in the customer's domain, may not understand these requirements.

Outcomes:

This activity will help your team get familiar with the client's request and choose a feature to develop further in Stage 1. Take notes that might be important to your team about these features and how software developers have implemented them in their products.

---

Stage 1: Choose a Feature

From the features that the client envisioned for the system, choose one to start your work. Identify 3 tasks that a user can perform based on the description of the client's needs for that feature. For example, if you chose the "Artwork Display" feature, you can identify the following tasks based on the client's needs:

• Upload an image.
• Display an image.
• Edit an image.

You can add or identify tasks that might not be obvious from the client's feature descriptions or that you think are important to have for the successful implementation of such feature.

To Do:

Next, your team will have to discuss with the "client" some of the characteristics of the tasks you've identified. From Sommerville (p. 55):

Requirements elicitation and analysis is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development of one or more system models and prototypes. These help you understand the system to be specified.

Using the feature and tasks you selected and identified, open a ChatGPT prompt and use the chat to role-play with the generative A.I. by simulating a conversation between the client (Nube from Digital Art Collective) and you (a member of a software developing team). You will need to create an account with OpenAI in order to use ChatGPT.

Prepare a set of 5 to 10 questions that your team wants to ask the "client". These questions should be based on the tasks you identified from the feature and should help you visualize how tyhe client intends to perform these tasks.

Here are some example questions that can help you with the conversation and gather as many details as possible (you will, of course, create your own questions and/or use some of the ones below):

Once you are ready to chat, issue the following prompt to ChatGPT:

Substitute [FEATURE] with the name of the feature your team selected. This prompt will help the generative A.I. understand what you need from the "client".

Outcomes:

This activity will help your team derive the requirements needed to implements the features the client has requested and help you create a useful way to develop those requirements in Stage 2. Sommerville (p. 115) states:

Formal or informal interviews with system stakeholders are part of most requirements engineering processes. In these interviews, the requirements engineering team puts questions to stakeholders about the system that they currently use [or have used in the past] and the system to be developed. Requirements are derived from the answers to these questions.

Take notes that might be important to your team from the answers you receive from the "client".

---

Stage 2: Create User Stories

User stories first emerged within the Agile software development framework (Incremental Model) as a way to capture user requirements and have since become a widely adopted method for outlining user needs. A user story is a concise, plain-language explanation of a feature or function, framed from the viewpoint of the end-user seeking that capability.

These stories are usually structured in a standardized template: "As a [user role], I want [specific action] in order to [achieve a goal]." For instance, if your team chose the task Upload an image from the "Artwork Display" feature, a user story (using the standard Agile format) can be:

Teams often write the User Stories on physical cards for planning and progress tracking during development. The front of the card typically contains the information about the story (ID, Title, Description or the story itself) and the back of the card the confirmation area with the Acceptance Criteria. According to www.agilebusiness.org:

These acceptance criteria define, at a high level, the test criteria which will confirm that this user story is working as required. These are not intended to be the full test scripts, but will be used to expand into the appropriate test scenarios and test scripts during Timeboxes, as necessary. For User Stories at the highest level (sometimes called a project Epic), the acceptance criteria may be used to define the aims of the project using criteria that may be measured after the project has completed (as part of the Benefits Assessment).

Continuing with the User Story created for the task of Upload an image, an example of Acceptance Criteria for the back of the card can be:

To Do:

From the 3 tasks your team identified in Stage 1 and based on the answers to the interview with the "client", develop 3 User Story Cards for these three tasks. The cards must follow Agile standards:

• Front of the Card: Story ID, Story Title, Story.
• Back of the Card: Acceptance Criteria with some Functional Requirements and Non-Functional Requirements (like performance, security, reliability, scalability, usability, and compliance).

While your team develops the User Story Cards from the tasks, bear in mind what Sommerville (p. 79) states:

Software requirements always change. To handle these changes, agile methods do not have a separate requirements engineering activity. Rather, they integrate requirements elicitation with development. To make this easier, the idea of "user stories" was developed where a user story is a scenario of use that might be experienced by a system user.

Outcomes:

This activity will help your team focus on what users need from the software system at a high level, without getting into the details of how the product will fulfill those needs. It will also help you complete the User Scenarios in Stage 3.

---

Stage 3: Create Usage Scenarios

A Usage Scenario, often called a Scenario, provides a concrete example of how individuals or organizations interact with a system. It documents the sequence of steps, events, and actions involved in the interaction. Scenarios may vary in granularity: from step-by-step interface workflows to broader, high-level descriptions of essential business activities, omitting implementation details.

To create a Scenario, you take the story and start thinking about how a user can perform it. This can be written in a step-by-step flow, sometimes called "the happy path", since it is the ideal, error-free user journey or process flow where everything goes according to plan, allowing users to achieve their goals smoothly and efficiently.

Components of a step-by-step flow are:

• User Actions: What the user does at each step (e.g., clicks a button, fills out a form).
• System Responses: How the system reacts to each user action (e.g., loads a page, validates input, displays confirmation).
• Sequence: Ordered chronologically to reflect a natural interaction, from beginning to end of the task.
• Clarity and Simplicity: Each step should describe one clear interaction or system behavior.

The following is an example of how you can develop a Scenario for uploading and displaying a new painting, based on the User Story "001: Upload and Image":

To Do:

Create one Scenario for each of the User Stories your team created, following the example above. You Scenarios must have:

• Scenario Title
• Actor
• Precondition
• Step-by-Step Flow
• Postcondition

This post about Usage Scenarios: An Agile Introduction can be helpful to develop your own Scenarios.

Outcomes:

This activity will help your team practice a major artifact in the Agile software development process model. Scenarios build a bridge between design and implementation: developers can turn the steps into interface actions or code features. Scenarios also help to supports testing, since Testers can verify whether each step works as described. They also help non-technical stakeholders understand what the system does. Ultimately, Scenarios can reveal missing validations, feedback, or edge cases.

---

Report Preparation

Your team needs to compile and report the results of the previous Stages into a document. The report structure should contain the following:

• Names of team members.
• Brief description of the Client's request, capturing the essence of what the client wants in your own words.
• A section containing the selected Feature and the 3 identified Tasks. Each task should contain a brief paragraph with what the Client needs based on the "interview" your team performed.
• A section containing the three User Stories.
• A section containing the three Scenarios.
• A conclusion and reflection section, where your team talks about the experience of trying to define Software Requirements using Requirement Elicitation techniques through client interviews, User Stories, and Scenarios. Discuss challenges, insights, and what you learned as a team.

Prepare a PDF version of your document and submit to Kit.

---

Report Submission to Kit

Once the document (in PDF) is ready for submission, One member of the team will submit the report and invite the other team members to collaborate:

1. The team member uploads the PDF.
2. Once the document is successfully uploaded, the team member clicks the I Worked With Someone Else option and "Invite" the rest of the team members.
3. The rest of the Team member accepts the invitation.

---

Evaluation

Exercise #1 is worth 10 points. The following rubrics describe the criteria I will use to evaluate your team's work:

• Client Request Summary [1 point]
  • Clearly and concisely summarizes the client's goals and context. 0.5 pts.
  • The summary demonstrate understanding of the client's needs. 0.5 pts.
• Selected Feature & Tasks [1 point]
  • The tasks identified are meaningful, each with a clear explanation of what the client needs, based on simulated interviews. 0.5 pts.
  • Demonstrates thoughtful analysis and interpretation of user input. 0.5 pts.
• User Stories [3 points]
  • Three well-written user stories using the format: As a [user], I want [goal], so that [benefit]. 1.5 pts.
  • Each story reflects a different task and includes accurate and relevant acceptance criteria. 1 pt.
  • Meaningful Non-Functional requirements were identified. 0.5 pts.
• Usage Scenarios [3 points]
  • Provides three realistic and detailed Usage Scenarios based on the user stories. 1.5 pts.
  • Step-by-step flows are logically structured and clearly show the interaction between the user and the system. 1 pts.
  • Scenarios contain meaningful pre- and post- conditions. 0.5 pts.
• Conclusion & Reflection [1 point]
  • Thoughtful reflection on the team's experience with requirements elicitation. 1 pt.
• Organization [1 point]
  • The document is clearly organized with appropriate headings, readable formatting, and free of significant grammar or spelling errors. 1 pt.