Chapter 3 - Requirements Flashcards
What are requirements?
define what a system should do and the constraints under which it should operate
Functional Requirements
What a system should do; include features
frequently specified in natural language (e.g., in English)
Non-Functional Requirements
the constraints; tied to the system’s quality attributes
specified using metrics (performance, space, reliability, robustness, usability, portability)
user requirements
high-level, non-technical, and are usually written by users in natural language.
closer to the problem
system requirements
more technical, precise, and defined by developers
closer to the solution
Requirements Engineering
activities such as the identification, analysis, specification, and validation of a system’s requirements
these activities should be performed systematically throughout the system’s lifecycle
Requirements Elicitation
The process of identifying, discovering, and understanding a system’s requirements
drawing out the main requirements of the system from discussions and interactions with stakeholders and developers
Requirements Specification Document
describes the requirements of the software to be built—including functional and non-functional requirements— typically in natural language
Requirements should be
correct, precise, complete, consistent, and verifiable
use cases
comprehensive documents for specifying requirements
Minimum Viable Product (MVP)
a functional system that can be used by real customers. However, it only includes the features necessary to prove its market feasibility, i.e., its ability to solve a problem faced by some customers.
User Stories
a user story has three parts, also termed the three Cs:
User Story = Card + Conversations + Confirmation
Card
used by customers to write, in their own language and in a few sentences, a feature they hope to see implemented in the system
Conversations
between customers and developers to allow the former to gain a better understanding of what is detailed on each card
Confirmation
a high-level test—specified by the customer—to verify whether the story was implemented as expected.
acceptance tests
It is not an automated test, like a unit test, but rather a textual description of the scenarios, examples, and test cases that the customer will use to confirm the implementation of the story
User stories should have what properties?
Independent: It should be possible to implement any two stories in any order.
Negotiable: Both parties should be open to changing and adapting their opinions as a result of these discussions.
Valuable: Stories should add value to the customers’ business.
Estimable: It should be possible to estimate the size of a story, i.e., to define the effort needed to implement it.
Small: stories at the top of the backlog should be short and small to facilitate understanding and estimation.
Testable: Stories should have clear acceptance tests.
Epics
Complex and large stories
user roles (or personas)
the key users who will interact with the system
story writing workshop
brings together the system’s main users to discuss the system’s objectives, main features, and other key aspects.
By its conclusion, we should have a list of user stories for implementation over multiple sprints.
gold plating
situation where developers independently decide to elaborate on certain stories—or requirements, more generally—without the customer’s input
spikes
tasks for knowledge acquisition or for creating a proof-of-concept implementation
Use Cases
textual documents used to specify requirements
offer more detailed descriptions than user stories and are typically used in Waterfall-based methods
Although user cases are written by developers, users should be able to read, understand, and validate them
written from the perspective of an actor interacting with the system to achieve specific objectives
actor
Typically, the actor is a human user, although it can also be another software or hardware component. In all cases, the actor is an entity external to the system.
main flow
consists of steps required to successfully complete an operation
extensions
represent alternatives for executing particular steps of the main flow or for handling errors
glossary
a document that lists the terms and vocabulary used in a project
Use Case Diagram
This diagram serves as a visual catalog of use cases, depicting the actors of a system (illustrated as stick figures) and the use cases (depicted as ellipses). Additionally, it shows two types of relationships: (1) a line linking an actor to a use case indicates the actor’s participation in a given scenario; (2) an arrow linking two use cases indicates that one use case either includes or extends the other.
MVP cycle
(build), one has a product idea and implements an MVP to test it
(measure), the MVP is made available to real customers to collect data on its usage
(learn), the collected data is analyzed, resulting in what is termed validated learning
pivot
abandoning the original vision and attempting a new MVP with major changes
vanity metrics
superficial metrics that serve to inflate the egos of developers and product managers while offering limited insight into enhancing the market strategy
actionable metrics
those that can inform decisions about the MVP’s future
funnel metrics
These metrics measure the different levels at which users interact with a system
Acquisition: Number of users who visited our system.
Activation: Number of users who created an account.
Retention: Number of users who returned after creating an account.
Revenue: Number of users who made a purchase.
Referral: Number of users who recommended the system to others.
Design Sprint
a method for testing and validating new products using prototypes
Time-boxed (A design sprint lasts five days)
Small and multidisciplinary teams (seven people)
Clear objectives and rules
A/B Testing (or split testing)
used to choose between two versions of a system based on user interest
control version
(original system, requirements A)
treatment version
(requirements B).
Hypothesis Test
In such tests, we start with a Null Hypothesis that represents the status quo. That is, the Null Hypothesis assumes that there is no significant difference between the current version (A) and the new version (B) of the system. The hypothesis that challenges the status quo is called the Alternative Hypothesis.
a decision-making procedure that starts with the assumption that H0 (Null Hypothesis) is true and then attempts to find evidence against it.
