0% found this document useful (0 votes)
2 views9 pages

Week 2 Slides

layered architecture

Uploaded by

bsse23018
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views9 pages

Week 2 Slides

layered architecture

Uploaded by

bsse23018
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 9

Week 2 Slides

Requirements
Engineering & MVP
Backlog
Welcome to Week 2! This session will equip you with essential tools
to define, prioritize, and manage software requirements,
culminating in the creation of a Minimum Viable Product (MVP)
backlog.
Introduction to Requirements
Engineering
Requirements Engineering is the foundational process of understanding and documenting what a software system
should do. It's about translating ideas and needs into concrete specifications that guide development.

Discovering System Types of Our Goal


Functionality Requirements
• Functional: Define what the To produce clear,
The core of Requirements system does (e.g., "The unambiguous, and testable
Engineering is to identify system shall allow users to requirements that everyone
what the system should log in"). on the team can understand
do to solve a user's problem • Non-functional: Specify and verify.
or meet a business need. how the system performs
(e.g., security, performance,
usability).
Why Requirements
Matter
Poorly defined requirements are a leading cause of project
failure. By investing time upfront, we prevent costly
mistakes and ensure our development efforts are always
aligned with user needs.

• Prevents Costly Rework: Fixing errors in later stages is


significantly more expensive.

• Aligns Stakeholders: Ensures everyone shares a common


understanding of the project scope and goals.
• Meets User Needs: Guarantees developers build features
that genuinely solve user problems.
• Strong Foundation: Provides a solid base for effective
design, development, and testing activities.
User Stories
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually
a user or customer of the system.

The "As a... I want... so Example Key


that..." Format “As a student, I want to register for Characteristics
• Short and concise.
This structured format helps keep the courses online so that I can manage • User-centered (focus on the
story focused on the user, their need, my schedule easily.”
• 'who').
Testable (can you verify if it's
and the value they derive.
This clearly identifies the role, the done?).
desired feature, and the benefit.
Acceptance
Criteria
Acceptance criteria define the boundaries of a user story and are used to
confirm when a story is complete and working as intended. They are the
conditions that must be met for the story to be accepted by the customer.

1 2

Defines precisely when a story Provides clear, testable


is “done” from the user's conditions for developers and
perspective. testers.

Example: Course
Registration
• User must log in with valid credentials.
• User can view all available courses with descriptions.
• User can add and drop courses before the registration deadline.
Story Mapping
Story mapping is a visual technique for organizing user stories to create a holistic view of the product's functionality and user journey. It helps teams understand
the flow and prioritize development.

View Schedule

Display course timetables

Confirm Enrollment

Verify and approve student sign-ups

Add Course

Create new course entries

Course Management

Manage course lifecycle and enrollments

• Organizes user stories into a coherent narrative of the user's experience.

• User Activities: Represents the major steps a user takes (e.g., "Course Management").

• Tasks: Details the smaller steps within each activity (e.g., "Add Course", "Confirm Enrollment").
MoSCoW
Prioritization
The MoSCoW method is a prioritization technique used to understand the importance of requirements to stakeholders
and provides a clear framework for determining scope.

• Must have: Essential for the solution to be viable.


• Should have: Important but not critical; adds significant value.
• Could have: Nice to have; adds value but not necessary for the current
iteration.
• Won’t have: Out of scope for this release, may be considered later.
Defining MVP
Backlog
The MVP backlog is a curated list of prioritized features required for the Minimum Viable
Product
the smallest set of features that deliver core value to early users and allow for validated
learning.
What is an MVP?
• The core set of features that solve a primary problem.
• The first working version of your project that can be released.
• Designed for early user feedback and validated learning.

Steps to Create Your MVP


Backlog
1. Collect all identified user stories.
2. Prioritize these stories using the MoSCoW method.
3. Select only the “Must Haves” to form your MVP backlog.
Lab Activity: Backlog
Creation
Now it's your turn! Apply what you've learned to kickstart your project's development with a well-defined MVP
backlog.
01 02 03

Write User Define Acceptance Create a Story


Stories
Develop 5-6 user stories for your
Criteria
For each story, specify clear and
Map
Organize your stories visually with
project, focusing on core testable acceptance criteria. user activities and tasks.
functionality.
04 05

Apply MoSCoW Finalize MVP


Prioritization
Categorize your stories to identify "Must Haves" for
Backlog
Compile your "Must Haves" into a concrete MVP
the MVP. backlog for development.

You might also like