REQUIREMENTS

• Requirements elicitation is not something that only

happens before development. You need to revisit
requirements often
• Ask good open-ended questions. Stay focused on
the goal and purpose of the product. Try to structure
the conversation to allow more organized thoughts
• Since you'll be revisiting the requirements often,
make sure that you number your requirements with
Involving some unique identifier. This will make them easy to
reference throughout development for everyone
Clients involved.
• Requirements do not have to specifically come from
the client as seen earlier
• Another tool that can ease client interactions is to
establish a glossary for the product/process. This
increases clarity because there will not be different
terms for the same thing.
 • One of the most important things to consider
when developing software is the end user. Who
are you making this product for? Who is going to
use this product?
• What user aspects do you have to consider when
you're developing a product?
User • The end user is anyone that is going to be directly
using the product
Considerations • A stakeholder is anyone who is affected by or has
an effect on the success of a project. This does
include the end user, but it also includes others,
such as the client, managers of the end user, and
system administrators. 
 • Users are often be more comfortable using a
poor product that they know how to navigate
rather than a superior product that is new to
them
• Why would we develop new products for
User customers that are just use old ones?
• That's why developing user friendly, intuitive user
Considerations interfaces is so important.
• It encourages users to get out of their shell, but
that only works if the product is intuitive to learn,
and easy to use. 
 An association that represents senior citizens with
diabetes has approached your team to develop a
mobile application, that will allow seniors to track
their blood glucose levels. The representative from
the association specified that users will be above
the age of 65. Also, the application must be easy
enough to use without assistance.
User What features could you add to the product that
would better accommodate its end-user?
Considerations • A. Voice command.
• B. Many menus.
• C. Large text.
• D. Icons.
 • We're looking to develop some software for in-
house use at our restaurants. My goal is to take
the restaurant ordering process and make it
more efficient. I'm thinking that customers
should be able to view the menu of the
restaurant they're in, and once they're ready,
place an order. I'd really like there to be a kids'
page where you can see the kids' menu. Maybe
there's a few games for the kids to play, but most
Client Speak importantly, it should be easy enough to use that
kids can make an order themselves. Customers
should also be able to specify any changes they'd
like to make for their meal, and they should be
able to list any dietary restrictions they may have
before they submit their order to the kitchen. The
kitchen should then be able to view these orders
as they come in. Customers should be able to view
and pay their bill within the system
UX Design
• A user interface or UI is anything that the end user will be interacting with. Elements like
the windows, buttons, scroll bars, check boxes, and text boxes all make up the user
interface

• Perceptual Limitations: Colour Blindness (Contrast)

• Physical Limitations: Left-right hander
• Cognitive Limitations: Memory limitations (recall)
• Cultural Limitations: X mark in Checkbox

*Acknowledgement: Coursera Software Product Management

Use Cases
• A use case is a way to identify, clarify,
and organize the details of a task. They
consist of a set of possible sequential
interactions between users and systems
to achieve a goal
• Use-case is a high- level visual
representation of all the tasks supported
• A use case is typically made up of a
name for the use case, the participating
actors, the goal, the triggers, the pre and
post-conditions, the basic flow,
exceptions and qualities.
Use Case
Diagram
 • First, you need to give your use case a name.
• Next, you need to identify participating actors. These actors
should be roles. They need to be in the general case.
• You specify the goal in your use case.
• Identify triggers or events that prompt the use case to
begin. This could be something like the push of a button.
• You need to identify pre-conditions and post-conditions.
Pre-conditions are conditions that must be met before this
use case can occur. Post-conditions are conditions that are

Use Cases met once the use case is complete.

• The basic flow is a walk through of all the steps that occur
in the use case. You want the basic flow to be
representative of a sunny day scenario. Any other
scenarios can be outlined as alternate flows if necessary.
• Alternate flows (exceptions) highlight any situation where
this use case would not work
• Qualities are any quality specifications that you want to
meet
 • We'll look at the requirement that allows the customer to view their
bill from a restaurant example. Let's say that this is first use case and
that it corresponds to the requirement in the product backlog. So we
will give this use case the ID number one. For name, we call this use
case, View Bill.
• The only participating actor in the story is the end user, or in our
scenario, we'll call them the Customer. The goal of this use case is to
view the bill for their order.
• A trigger is an event that prompts this use case to happen. In this
scenario, the customer request to view their bill in the app.

View Bill Use • Pre-conditions for this action to occur would include having the menu
items on the menu. The user selecting a dish and the user placing an

Case order.
• A post-condition for this action would be that the customer can view
and pay the bill.
• The basic flow for this use case would be, number one, user requests
to view bill from app. Number two, user views bill.
• An alternate flow to this action would be, the user gets the wait staff to
print and bring them the bill.
• Finally, a quality could be that the bill takes less than 7 seconds to
load. Typically, qualities are non-functional requirements.
 • How requirements fit into the scope of Agile software
development?
 Agile and its 12 core principles
• satisfying the customer through early and continuous delivery.
• delivering working software frequently.
• using working software as the primary measure of progress.
• welcoming changing requirements.

Agile • attention to technical excellence and good design.

• promoting sustainable development at a constant pace.
Requirements • focusing on simplicity in order to maximize the amount of
work not done.
• building projects around motivated individuals.
• focusing on self organizing teams.
• daily collaboration between business people, and developers.
• encouraging face to face interaction.
• reflecting on the teams behavior and adjusting accordingly
 • A user story is just a simple way of expressing
requirements.  User Stories are meant to keep all
of the requirements of your system to a
consistent format. They're easy to write, easy to
read, and easy to evaluate.
• As a < >, I want to < >, So that < >
• The first blank signifies the stake holder role for
User Stories whom the requirement is being formed. You
might use words like “Administrator” or “Guest
user” here. In our example of the restaurant
menu application, the stakeholders are
customers and kitchen staff. (Who?)
 • The second blank signifies the task or function
the stakeholder wants to resolve using the
product. This part specifies the what of your
requirement. I want to browse the menu for
restaurant's that I'm in. I want to see the kid's
menu, or I want to view received orders.
• The final blank of the user story. Specifies “why”
User Stories the user story is needed in the first place. It gives
context to the requirement about the value or
benefit it offers, which aligns with the product's
goals or vision.
• As a Child Customer, I want to see the kids menu,
so that I see what meals and games interest me. 
 • What makes a good user story? 
•  INVEST
•  I stands for independent. The N stands for
negotiable. The V stands for valuable. The E
stands for estimable. The S stands for small. And,
User Story the T stands for testable.
• An Epic is a user story that can't be accomplished
in a short time period. Epics are vague, broad
descriptions of a requirement. 
 • As a customer, I want to pay for my bill so that I
can settle what I owe quickly. 
• Does the user pay for their bill within the app?
What methods of payment are accepted? 
• As a customer, I want to be able to see a bill,
with all the items in order so that I can see
how much my order will cost.
User story • As a customer, I want to be able to select a
"pay now" option when I view my bill so that I
can pay the bill immediately. 
•  As a customer I want to be able to enter
payment details for Visa or MasterCard credit
cards so that I can pay using a convenient
method
 • An acceptance test is basically a check for
whether a requirement is met.  If the acceptance
test passes, then the user story is considered
satisfied. 
• An acceptance criterion is a specific condition
which must be met, where an acceptance test is a
method for verifying whether the condition has
Acceptance been met or not.
Tests (User) • Each acceptance test should be an easy to
understand action with a verifiable condition that
the user story is implemented correctly.
• Each test should verify one small part of the user
story. If all the tests pass, then the acceptance
criteria are considered passed. 
 • As a customer, I want to be able to enter my
payment details for Visa and MasterCard credit
cards so that I can pay using a convenient
method.
• Acceptance criteria

Acceptance • Payment can be made using a Visa credit card.

Payment can be made using a Master Card credit
Criteria card. Payment can be made using an online
financial service. When paying with a credit card,
filling in the card number field auto detects the
card type. The customer sees only the relevant
input fields, depending on the selected payment
method. 
 • Be able to make payments using a Visa credit
card (criterion)
• Insert a Visa card into the chip reader, enter the
Visa's pin number, and confirm that payment was
accepted (verify)
• Acceptance criterion passed test

Acceptance • Acceptance criteria for user story verified

• User story acceptance tested
Tests • When your acceptance criteria and tests are
written along with the user story which they
accompany you're making sure that the
functionality you want to implement can have its
implementation verified
 • A Product backlog (scrum) is a list of software
features which you and your team intend to develop
 consisting mostly user stories
• The initial user stories you write with your client are
gathered together and placed into the backlog (no
sequence but with identifier)
•  Client sorts the previously unsorted list of user
stories from highest to lowest priority. The goal is to
Product have the highest value features listed at the top of
the backlog and the least important ones at the
Backlog bottom
•  Try to collaborate with your client as much as
possible and allow your development team to
communicate with your client throughout
prioritization and planning
• User stories are taken from the backlog and placed
into chunks of work, which should be done in a
certain time intervals called sprints.
 • Requirements can change from their originally
planned priorities.
• This can end up shifting the priority of other
items.
Product • Your backlog is bound to morph over time. It will
shift, grow, shrink and change order.
Backlog • The only place in Scrum which doesn't allow for
this sort of shift, is during the current sprint,
where development work is set to be done.
 Story Priority 1

Product Backlog Story Priority 2

Story Priority 3
 •  A story map is just a method for taking user
stories from your backlog and grouping them
into more specific functional categories
• It gives context to each individual requirement in
your project and brings a greater amount of
Story Maps organizational structure to your project.
• They give your developers and your clients a
sense of the product's entirety, offering a quick
idea of how things fit together.
 •  A story map is just a method for taking user
stories from your backlog and grouping them
into more specific functional categories
• It gives context to each individual requirement in
your project and brings a greater amount of
Story Maps organizational structure to your project.
• They give your developers and your clients a
sense of the product's entirety, offering a quick
idea of how things fit together.
 •It helps build a first release that’s a minimum viable product and
then iterate on it, bringing new value to the business and the
user with each new release.

Story Maps
Story Maps