Scribd
Upload
9 views3 pages

Understanding Software Requirements

Chapter 11 discusses the importance of requirements in software development, likening them to a blueprint for building a house. It outlines various types of requirements, including functional, non-functional, data, and environmental, and emphasizes the need for effective data gathering techniques like contextual inquiry. The chapter also introduces personas and scenarios to make requirements more relatable, and explains the use of use cases to capture user interactions with the system.

Uploaded by

thdr12d
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views3 pages

Understanding Software Requirements

Chapter 11 discusses the importance of requirements in software development, likening them to a blueprint for building a house. It outlines various types of requirements, including functional, non-functional, data, and environmental, and emphasizes the need for effective data gathering techniques like contextual inquiry. The chapter also introduces personas and scenarios to make requirements more relatable, and explains the use of use cases to capture user interactions with the system.

Uploaded by

thdr12d
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Chapter 11: Discovering Requirements

11.1 Introduction
You cannot build a house without a blueprint. In software, "Requirements" are that blueprint. If
you get this stage wrong, you will build the wrong product perfectly—which is a total failure.

11.2 What, How, and Why?


●​ What: A statement about an intended product that specifies what it should do or how it
should perform.
●​ How: By talking to stakeholders (users, managers, developers).
●​ Why: To avoid the "I thought you meant X" disaster. Requirements clarify vague goals into
concrete rules.
●​ Vivid Example: A client says, "I want a safe car." (Vague). The Requirement says, "The
car must stop within 30 meters when braking at 60km/h." (Concrete).

11.3 What Are Requirements? (The Checklist)


Different types of rules for the system.

1. Functional Requirements
●​ Concept: What the system must do. The features.
●​ Vivid Example: "The system must allow the user to reset their password via email."

2. Non-Functional Requirements
●​ Concept: Constraints on the system (performance, security, look).
●​ Vivid Example: "The password reset email must arrive within 5 seconds." (Performance
constraint).

3. Data Requirements
●​ Concept: What info needs to be stored?
●​ Vivid Example: "The system must store the user's age, not their date of birth."

4. Environmental Requirements
●​ Concept: Where will it be used?
○​ Physical: Is it dark? Noisy? (e.g., An ATM screen must be readable in direct sunlight).
○​ Social: Is it private? (e.g., A bank app shouldn't speak your balance out loud).
○​ Technical: What OS? (e.g., Must run on iOS 12+).

11.4 Data Gathering for Requirements


●​ Concept: Using the techniques from Chapter 8 (Interviews, Observation) specifically to
write the blueprint.
●​ Contextual Inquiry: A specific technique where you interview the user while they work in
their environment (Master/Apprentice model).
●​ Vivid Example: You sit next to a receptionist. You see her stick a Post-it note on the
screen because the software hides the patient's ID. You write a requirement: "Patient ID
must be visible on the home screen."

11.5 Bringing Requirements to Life: Personas and


Scenarios
Raw requirements ("System must do X") are boring. We turn them into stories.

1. Personas
●​ Concept: A fictional character that represents a user group. They are not real, but they
are based on real data.
●​ Structure: Name, Photo, Bio, Goals, Frustrations.
●​ Vivid Example: "Bob, 55, Construction Worker. Has thick fingers and hates small buttons.
Goal: Log his hours quickly." (Now the developer knows not to make the buttons tiny).

2. Scenarios
●​ Concept: An informal narrative story describing a user trying to achieve a goal. It focuses
on the human side, not the technical buttons.
●​ Vivid Example: "Bob arrives at the site. It is raining. He pulls out his phone with wet
hands. He tries to tap the 'Log In' button to start his shift..."

11.6 Capturing Interaction with Use Cases


●​ Concept: A formal list of steps describing the interaction between a user (Actor) and the
System.
●​ Structure:
1.​ Actor: User.
2.​ Goal: Buy a ticket.
3.​ Main Flow: 1. User clicks buy. 2. System asks for card. 3. User enters card. 4. System
confirms.
4.​ Alternative Flow (Edge Case): 3a. Card is declined. System shows error.
●​ Difference: Scenarios are stories (messy/human). Use Cases are scripts

📖 HCI Decoder
(logical/step-by-step).

●​ Stakeholder:
○​ Regular Meaning: Someone holding a bet.
○​ HCI Context: Anyone who is affected by the success or failure of the system (Users,
Developers, Managers, the CEO, even the person who cleans the server room).
●​ Persona:
○​ Regular Meaning: A mask or social role.
○​ HCI Context: A user archetype. "Designing for everyone is designing for no one."
Personas help you design for someone specific.
●​ Volere Shell:
○​ HCI Context: A standard template card used to write down requirements. It forces
you to write the "Rationale" (Why do we need this?) and the "Fit Criteria" (How do we
prove it works?).

Common questions

Powered by AI

Functional requirements specify what the system must do, outlining the features and actions it should perform, such as allowing a user to reset their password via email. In contrast, non-functional requirements define constraints on the system, including performance, security, and appearance factors, like ensuring a password reset email is delivered within 5 seconds .

Contextual inquiry is a data gathering technique where interviews are conducted while the user works in their environment, following a master/apprentice model. An example of its application is observing a receptionist who uses a Post-it note to compensate for a software flaw, which leads to the requirement that 'Patient ID must be visible on the home screen' .

Scenarios differ from use cases in that they are informal narrative stories focused on a user trying to achieve a goal, capturing the messy and human side of interactions. Use cases, on the other hand, are formal, step-by-step descriptions of interactions between a user and the system, outlining main flows and alternative flows logically, like buying a ticket and handling card errors .

Persona creation impacts design decisions by providing a fictional yet data-driven representation of user groups, helping to focus the design process on specific needs and preferences. For instance, creating a persona like 'Bob, a construction worker with thick fingers' informs developers not to use small buttons, ensuring the design is accessible and user-friendly .

Environmental requirements determine the context in which a software system will operate by specifying physical, social, and technical conditions, which influence system design. Physical aspects include considerations like screen readability in sunlight, social aspects involve privacy concerns such as voice output in banking apps, and technical aspects pertain to compatibility with operating systems .

The contextual inquiry technique enhances requirement elicitation by providing in-depth insights into user behaviors and challenges within their natural work environment. This technique allows for the identification of implicit requirements and real-world issues that might not be captured through traditional interviews, leading to more relevant and usable requirements, such as the need for visible patient ID on software interfaces .

The 'Volere Shell' in HCI is a standard template used to write down software requirements. It includes components such as the 'Rationale,' which explains why a requirement is necessary, and the 'Fit Criteria,' which defines how to prove that the requirement has been successfully met. This structure ensures that requirements are clear, justified, and verifiable .

Defining requirements is crucial in software development because they serve as the blueprint for building the product. If this stage is done incorrectly, it results in building the wrong product perfectly, which means total project failure. Requirements clarify vague goals into concrete rules to avoid misinterpretations such as the 'I thought you meant X' disaster .

Personas and scenarios are useful because they translate abstract requirements into relatable, realistic representations of users and their contexts. Personas provide a specific focus by representing user archetypes, helping designers cater to particular audiences. Scenarios narrate user interactions in story form, aligning technical specifications with real user goals and behaviors, thereby improving user requirements alignment and empathy .

Non-functional requirements significantly impact the overall user experience by defining aspects such as performance, usability, and reliability. For instance, a non-functional requirement might ensure that a password reset email is sent within 5 seconds, which directly affects user satisfaction. Failure to meet these constraints can lead to frustration and reduced trust in the system, affecting its adoption and success .

You might also like