Software

Development and
Prototyping
Software Development Methodologies
Topics
• Software development life cycle (SDLC)
• Waterfall
• Spiral
• Agile
– Scrum
 Learning Objectives
1 Understand the roots of agile modeling in prototyping and the
four main types of prototyping
2 Understand agile modeling and the core practices that
differentiate it from other development methodologies
3 Understand Scrum as an agile method to improve development
of complex projects.
4 Learn about DevOps as a cultural shift in the way to organize
rapid systems development and operations
5 Learn the importance of values critical to agile modeling
6 Understand how to improve efficiency for users who are
knowledge workers using either structured methods or agile
modeling
Software Development Life Cycle (SDLC)
• A process is needed to develop software for complex
systems
– Waterfall
– Spiral
– Prototyping
– Agile
▪ Scrum
Waterfall Model
Waterfall Process (1)
• Requirement
– What the project is suppose to accomplish
▪ Describe in a requirement document
• Design
– Plan for how to implement the system
– What OO classes will be needed
▪ Attributes and methods
▪ Determine relationship between objects (inheritance)
▪ Determine hardware/software/language/OS/etc
• Implementation
– Develop software/hardware
Waterfall Process (2)
• Testing
– Verify software against the requirement document
▪ Unit and system
• Maintenance/Deployment
– Install and use the software for the intended use
Issues with Waterfall (2)
• If a problem shows up in a later phase, the cause may be
in an earlier phase
– For example, an problem in testing may stem from a
design issue
– Customers do not see the final product until
deployment
▪ Wrong product could have been built
– Therefore, V Model came to exist in order to perform
verification on each process.
V model
V model
Waterfall Process Improved
• To get customer involvement and feedback earlier in the
software development cycle (SDLC), Barry Boehm (USC)
developed the spiral model
– Iterate the waterfall process
– Early phases focus on the development of prototypes
▪ A prototype is a small system that shows some
aspects of the final system
– Should be able to be developed quickly
• Graphical user interfaces (GUIs), interfaces, etc.
– The spiral process has a greater chance to delivering a
system that meets the customers expectations
Spiral Model
Spiral Process Improved
• To get consistent customer involvement and feedback
throughout the entire in the software development cycle,
the Agile development methodology was created
• The premise behind agile is documented in the Agile
Manifesto
– See next slide and
– http://agilemanifesto.org/
Agile Modeling, but First Prototyping
• Agile modeling is a collection of innovative, user-centered
approaches to system development
• Prototyping is an information-gathering technique useful
in seeking
– User reactions
– Suggestions
– Innovations
– Revision plans
Prototyping

 Prototypes are to elicit requirements in situations

where stakeholders have only a vague
understanding of what is to be developed.
 Potential consequences of new or changed
requirements can be identified easier.
 For example, user interface prototypes are
frequently used in practice to find additional
functional requirements.
Prototyping
 It is the technique of constructing a partial
implementation of a system so that
customers, users, or developers can learn
more about a problem or a solution to that
problem.
Prototyping

• Types of Prototyping
• 1) Throw-away prototyping
• 2) Evolutionary prototyping
 Prototyping

Throw-away Prototyping
 Intended to help elicit and develop the system
requirements
 The requirements which should be prototyped
are those which cause most difficulties to
customers and which are the hardest to
understand. Little documentation is needed.
Prototyping
 Prototyping

Evolutionary Prototyping
• Intended to deliver a workable system quickly to
the customer
• The requirements which should be supported by
the initial versions of this prototype are those
which are well-understood and which can deliver
useful end-user functionality.
Prototyping
Prototyping

Approaches to Prototyping
• 1) Paper prototyping
• 2) ‘Wizard of Oz’ prototyping
• 3) Executable prototyping
Paper Prototyping

• A paper mock-up of the system is developed and

used for system experiments
• This is very cheap and very effective approach to
prototype development
• No executable software is needed.
Paper Prototyping
Paper Prototyping

• Paper versions of the screens, which might be

presented to the user are drawn and various
usage scenarios are planned
• For interactive systems, this is very effective way
to find users’ reactions and the required
information
Example full paper prototype
Paper prototyping

• Why paper prototype?

– paper prototype is much faster to create than code
– can make changes to paper faster than code
(editable)
– paper has more visual bandwidth (can see more at
once)
– paper prototyping is more conducive to working in
teams than most programming or normal prototyping
– paper prototyping can be done by non-technical
people, or people with programming experience in
different languages
‘Wizard of Oz’ Prototyping
 A person simulates the responses of the system
in response to some user inputs
 Relatively cheap as only user interface software
needs to be developed
 The users interact through this user interface
software and all requests are channeled to the a
person, who simulates the system’s responses.
 Wizard of Oz simulations may consist of paper
prototypes, fully-implemented systems and
everything in between.
Wizard of Oz’ Prototyping
• A user sits a terminal and interacts with a program.
Hidden elsewhere, the requirement Engineer (the
wizard) watches what the user does and, by
responding in different ways, creates the illusion of a
working software program.
• In some cases, the user is unaware that a person,
rather than a computer, is operating the system.
• It is useful to give users the impression that they are
working with a real system, even before it exists
Wizard of Oz’ Prototyping

• For example, you could prototype a vending

machine without creating the mechanics and use
a hidden person to deliver the selected
purchases.
• Another Example is ChatBot which is
programming that simulates the conversation or
"chatter" of a human being through text or voice
interactions. In the wizard of Oz prototype , AI
response can be replaced by human.
Executable Prototyping

• A fourth generation language or other rapid

development environment is used to develop an
executable prototype
• This is an expensive option and involves writing
software to simulate the functionality of the
proposed system
Executable Prototyping
Executable Prototyping

•Visual programming languages such as Visual

Basic , ObjectWorks, prototyper,…etc.
•These languages are supported by powerful
development environments, which include access
to reusable objects and user interface
development utilities.
•Internet-based prototyping solutions based on
WWW browsers and languages. Here, we a
ready-made user interface and Java applets can
be used to add functionality to the user interface
Prototyping : Advantages

 Prototyping provides the detail information by

investing each and every prototype by the
customer
 Prototypes are mostly used in conjunction with
other elicitation techniques such as interviews
and JAD.
 Prototypes provide a good chance to the
stakeholders an effective rule and to be involved
in the requirements engineering.
 JAD Meeting Room

JPEG Figure 5-5 Goes Here

Slide 35
Prototyping : Disadvantages

 In many cases prototypes are expensive to

produce in terms of time and cost.
 User confusion: The worst-case scenario
of any prototype is customers mistaking it
for the finished project. Customers seeing
a rough prototype may not understand it
merely needs to be finished or polished.
Agile Outline

 Introduction
 Epic
 Feature
 User Story
 Behavior-Driven Development
Agile Requirements

• In an agile project; the customer doesn’t

need to work out all their requirements in
detail up front.
• Instead the broad scope of the project is
defined upfront; and then each iteration he
analyses enough requirements to support
the delivery of that iteration’s functionality.
Agile Requirements

• Most importantly the customer gets the

result of that iteration’s delivery very
quickly, which means that they have the
confidence to ask for what is most
important to them today, knowing that as
the project progresses they can refine what
they need.
Agile Requirements

• Additionally, if a new requirement they hadn’t

thought of comes in they can re-prioritise the
functionality without going through expensive
change control.
• For example, if a competitor comes out with a
new capability, the customer can schedule in a
response quickly, pushing other requirements
down the priority order.
Agile Requirements
 Finally, the customer, the analyst and the development
team learn more and more as the project progresses,
particularly once the software is actually in use.
 This means that they have more experience and can
write better requirements.
 For example, the analyst will have learned more about
the problem domain having seen the software in use, and
they’ll have a better handle on what works best for
recording requirements based on their interactions with
the developers.

Agile Requirements

Agile Manifesto
 Manifesto principle #1 - Our highest priority is to
satisfy the customer through early and
continuous delivery of valuable software.
 Manifesto principle #2 - Welcome changing
requirements, even late in development. Agile
processes harness change for the customer's
competitive advantage.
Agile Requirements
Key Principles for Agile Requirements
 Active user involvement is very important
 Agile teams must be empowered to make decisions
 Requirements emerge and evolve as software is
developed
 Agile requirements are ‘barely sufficient’
 Requirements are developed in small, bite-sized
pieces
 Cooperation, collaboration and communication
between all team members is essential
Agile Requirements

• In the agile battle of date versus scope, the

date wins.
• In other words, with agile methods, we’ll fix
two things, schedule and resources, and
we’ll float the remainder, scope
(requirements),
Agile Requirements

• It refine requirements over time.

• Start high level, just enough to remind us to have
a conversation, then fill in the detail just as we
need it.
• They start as course Epic, then features, which
are split into small user stories, and end up as
test scenarios
Agile Requirements
Agile Outline

 Introduction
 Epic
 Feature
 User Story
 Behavior-Driven Development
Epic

 An Epic can be defined as a big chunk of

work that has one common objective.
 Epic Comprised of a large collection of
features
 Epics allow you to keep track of large,
loosely defined ideas in your backlog
without the need to overpopulate your
backlog with multiple items.
Epic

 Epics are high-level features or activities that

span Sprints, or even Releases.
Epic

 An agile epic is a body of work that can be

broken down into specific task (features) based
on the needs/requests of customers or end
users.
 Epics are a helpful way to organize your work
and to create a hierarchy.
 The idea is to break work down into shippable
pieces, so that large projects can actually get
done and you can continue to ship value to your
customers on a regular basis.
Epic
Epic

 There is no standard form to represent

epics.
 Some teams use the familiar user story
formats (“As a <type of user>, I want
<some goal>, so that I can <reason>”)
While other teams represent the epics with
a short phrase.
Epic

Example of Epics:
 As a bank, we want to extend our services by
offering life and health insurances.
 We want to add a biometric recognition to
increase security without hassle.
 As the marketing department, we want to
create an interactive app to cater to more
customers.
Epic

For example, an epic “Book flight” of an online

flight portal can be broken down into the individual
process steps. So “Log in”, “Search flight”,
“Confirm booking”, “Pay with PayPal”, and so on.
Epic
Epic

Important guidelines when creating an epic:

 Create epics that managers and executes would
want to track.
 An epic could be a product feature, customer
request or business requirement.
 Let your organisational culture dictate the size of
your epic.
 Epics should not take too short or too long to
complete.
Agile Outline

 Introduction
 Epic
 Feature
 User Story
 Behavior-Driven Development
Feature

• Feature A distinguishing characteristic of a

software item.
• A feature is a distinct element of functionality
which can provide capabilities to the business.
Feature
Big picture / Story Map
Big picture / Story Map Examples
Agile Outline

 Introduction
 Epic
 Feature
 User Story
 Behavior-Driven Development
User Stories

 User story represents a small piece of

functionality that provides some value to the
business.
 Providing some value to the business is the
important phrase there. We need to focus on
delivering value for our customers.
User Stories

Example
As a user, I want to upload photos so that I can
share photos with others.

As an administrator, I want to approve photos

before they are posted so that I can make
sure they are appropriate.
User Stories

• User Stories basis for:

• Requirements
• Test Cases (evaluation)
• Project Plan
• Estimate by User Story
• Velocity for overall tracking
User Stories

User story:
A short, written description of a piece of
functionality that will be valuable to a
user
(or owner) of the software.
It provides a simple way for developers
and customers to split up what the
system needs to do so the system can be
delivered in pieces.
User Stories

• The emphasis on the word simple is essential.

There are many books out there that go into
great detail about requirements engineering,
use case design, and similar topics. These
present some useful ideas, but as ever agile
looks for the simplest approach that could
possibly work.
• So as we look at stories, remember that the
whole point is to make them too simple to
work in the hope that we might just get away
with it.
User Story Vs. Feature
1. Features usually tend to describe what your
software do:
- Editing the customer information

User stories tend to express what the user want

to do:
As bank clerk,
I want to be able to modify the customer
information
So that I can keep it up to date.
User Story Vs. Feature

2. Features will turn into multiple User Stories

each with several Scenarios.
User Story Vs. Feature
Features might be:
Display information Home Screen
- As a User, I want to access the Home screen, so that I
can enter the website
- As a user, I want to be able to see specials that I can see
the current deals
User Registration
- As a User, I need to able to register as a new user, so
that I can have more access to the site
- As a User, I need to able to register with my Google
account
User Stories

• User stories are part of an agile approach

that helps shift the focus from writing about
requirements to talking about them. All
agile user stories include a written
sentence or two and, more importantly, a
series of conversations about the desired
functionality.
User Stories
Principles of good stories:
• Customers write stories.
– Developers do not write stories.
• Stories must be understandable to the customer
• The shorter the better. No detailed specification!
• Each story must provide something of value to the
customer
• A story must be testable
– then we can know when it is done
The Story Writing Process
• The process of writing stories is iterative, requiring lots of
feedback.
1. Customers will propose a story to the programmers.
2. The programmers will ask themselves if the story can
be tested and estimated, and if it is of appropriate size.
3. If the story cannot be estimated, the programmers will
ask the customer to clarify the story.
4. If the story is too big, the developers will ask the
customer to split the story.
User Story Cards parts
User Story Cards have 3 parts
1. Card - A written description of the user story for planning purposes
and as a reminder

2. Conversation - A section for capturing further information about

the user story and details of any conversations

3. Confirmation - A section to convey what tests will be carried out to

confirm the user story is complete and working as expected
User Story Description

User Story Description (Card)

As a [user role] I want to [goal]
so I can [reason]
For example:
• As a registered user I want to log in
so I can access subscriber-only content
User Story Description

• Who (user role)

• What (goal)

• Why (reason)
– gives clarity as to why a feature is useful
– can influence how a feature should function
– can give you ideas for other useful features
that support the user's goals
User Story Example: Front of Card

User Story Example

User Story Example: Back of Card
User Stories are Not

Requirements documents
Use Cases
Scenarios
Not good user stories
 Stories are too small
 Dependent stories
 Too Many details
 Including UI detail too soon
 Thinking too far ahead
 Splitting too many stories
 Customer has trouble prioritizing
 Customer won’t write and prioritize the stories
Example

• Only for VIPs (OVIPs) is a software system

that manages restaurant requests such as
customers’ orders and table reservation.
• The system requirements have been
expressed in the following user stories:
Example

001 Customer Registration

As a customer, I want to register in the OVIPs Restaurant Database so I can
use the restaurant system.

002 Customer Booking

As a registered customer in the OVIPs Restaurant System, I want to book a
table at a specific date and time so I can visit the restaurant the time that
suites me.

003 Customer Book Cancelling

As a registered customer in the OVIPs Restaurant System, I want to able to
cancel the booking I had made before so I can come back later.
Example

004 Customer Book Changing

As a registered customer in the OVIPs Restaurant System, I want to able to
change the booking I had made before so I pick another suitable time for
me.

005 Customer Orders

As a registered customer in the OVIPs Restaurant System, I want to review
the available menus so I can order the food, drink, or sweets that I like more.

006 Adding Staff Members

As a restaurant manager for the OVIPs Restaurant System, I want to add staff
members and their relative information so I can assign each of them role
description.
Example

007 Staff Member Management

As a restaurant manager for the OVIPs Restaurant System, I want to be able
to change the staff roles so I can better manage them.

008 Menus Management

As a restaurant manager for the OVIPs Restaurant System, I want to be able to
create new menus and manage current menus so I can better serve my
customers

009 View Orders

As a restaurant manager for the OVIPs Restaurant System, I want to be able to
view tables’ orders sorted by date or customers so I can track them in case I
need to.
Example

010 Editing Orders

As a restaurant manager, or dedicated staff member in the OVIPs
Restaurant System, I want to be able to edit tables’ orders so I can respond
to the customers’ needs.

011 Orders Discount

As a restaurant manager for the OVIPs Restaurant System, I want to be able
to give discounts for any tables’ orders so I can better market for my
restaurant.
Agile Outline

 Introduction
 Epic
 Feature
 User Story
 Behavior-Driven Development
Behavior-Driven Development

• Each user story provides a description of a

feature that provides value to a user.
• Once a story has been identified we then focus
on the scenarios that describe how the user
expects the system to behave using a sequence
of steps.
• This is called Behavior-Driven Development
Behavior-Driven Development

• Behavior-Driven Development is about

implementing an application by describing its
behavior from the perspectives of its users.

• Behavior-driven development is a set of best

practices that advise you on how to develop
software by centering your users.
Example
Feature: Returned items go back to stock
As a store owner
I want to add items back to stock when they are
returned, so I can keep track of stock
Scenario 1: Refunded items should be returned to stock
Given a customer previously bought a black sweater
from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock
Example
Feature: Returned items go back to stock
Scenario 2: Replaced items should be returned to
stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock
When he returns the garment for a replacement in
black
Then I should have three blue garments in stock
And two black garments in stock
Behavior-Driven Development

• Scenario written using Behaviour Driven

Development
• Behavior Driven Development combines
requirements and testing into one integrated
approach resulting in improved understanding by
both the business and the technical team
Behavior-Driven Development

• Benefit
• BDD is helpful in communicating requirements
effectively.
• Requirements are specified in a way that they
are explicit, executable and testable.
• A common language is used to allow the
business, development and testing staff to
understand requirements, thus facilitating
communication with less ambiguity.
Behavior-Driven Development

 The goal is to build requirement Scenarios using

a series of examples.
 These examples support the creation of a
common language that everyone on the team
can use to gain a common agreement on the
objectives of the system being built.
Behavior-Driven Development

• Scenarios document the conversation took

place
Given <some initial context>
When <this happens>
Then <this should be the result>
Behavior-Driven Development
• Scenarios provide a narrative described the
sequencing of events necessary to complete specific
Acceptance Criteria. An example of scenario following
the BDD format is :
• It starts by specifying the initial condition that is
assumed to be true at the beginning of the scenario.
This may consist of a single clause, or several.
• It then states which event triggers the start of the
scenario.
• Finally, it states the expected outcome, in one or more
clauses.
Example
• Feature: Daily car maintenance
As a car owner
I want to be able to fuel my car
So I can get where I want
Scenario: Fuelling
Given a car with 10 liters of fuel in the tank
When you fill it with 50 liters of fuel
Then the tank contains 60 liters
Example

• Feature Transfer money from savings to current

Account
• Scenario: Savings account has enough money
Given my savings account balance is 100
And my current account balance is 50
When I transfer 20 from savings to current
Then my savings account balance should be 80
And my current account balance should be 70
 Example
001 Customer Registration
As a customer, I want to register in the OVIPs Restaurant Database so I
can use the restaurant system.
Scenario #1: The customer is new and never registered before
Given a customer who has never been registered in the system, when
he enters his information as indicated by the registration form, then
the customer will receive a new username and password to logon to
the system.
•Scenario #2: The customer is already registered and has a username
Given a customer who has been registered in the system, when he
tries to create a new account with the same username, then the
system will display an error message explaining that this username is
already taken and offer him either to create a new account or reset
the password for this account by sending a new one to the email
associated with this account.
 Example
002 Customer Booking
As a registered customer in the OVIPs Restaurant System, I want to book a
table at a specific date and time so I can visit the restaurant the time that
suites me.
• Scenario #1: Booking online
• Given a customer who has been registered in the system,
when he uses the restaurant online system to book a table at a
specific date and time, then the customer will be notified if his
booking is successful or not.
• Scenario #2: Booking by Phone
• Given a customer who has been registered in the system,
when he calls the restaurant to book a table at a specific date
and time, then the customer will be notified by phone and an
SMS to confirm his booking is successful or not.
 Example
003 Customer Book Cancelling
As a registered customer in the OVIPs Restaurant System, I want to able to
cancel the booking I had made before so I can come back later.
• Scenario #1: Online Book Cancelling
• Given a customer who has been registered in the system, when
he uses the restaurant online system to cancel a book that is not
due yet, then the customer will be notified if his book
cancellation is successful or not.
• Scenario #2: Cancelling a Book by Phone
• Given a customer who has been registered in the system, when
he calls the restaurant to cancel a book that is not due yet, then
the customer will be notified by phone and SMS to confirm his
book cancellation is successful or not.
 Example
004 Customer Book Changing
As a registered customer in the OVIPs Restaurant System, I want to able
to change the booking I had made before so I pick another suitable
time for me.
•Scenario #1: Online Book Changing
Given a customer with who has been registered in the system, when
he uses the restaurant online system to change his booking for a
table at a specific date and time to a new date and/or time, then the
customer will be notified if his book changing is successful or not.
•Scenario #2: Changing a Book by Phone
Given a customer with who has been registered in the system, when
he calls the restaurant to change his booking for a table at a specific
date and time to a new date and/or time, then the customer will be
notified by phone and SMS to confirm his booking changing is
successful or not.
005 Customer Orders
As a registered customer in the OVIPs Restaurant System, I want to review the
available menus so I can order the food, drink, or sweets that I like more.

Scenario #1: New Orders

• Given a customer with who has been registered in the system, when he reviews the
menu and request a new order for food and/or drink, then the customer can follow up
the status of the order by the restaurant online system and can see how much the
order will take to be ready.

• Scenario #2: Changing an Order

• Given a customer with who has been registered in the system, when he tried to add,
drop, or change a quantity of some items in his order, then the customer will be able
to know if his request is accepted or it was too late to change the order.

• Scenario #3: Cancelling an Order

• Given a customer with who has been registered in the system, when he tried to
cancel an order, then the customer will be able to know if his request is accepted or it
was too late to cancel the order.
Example
006 Adding Staff Members
As a restaurant manager for the OVIPs Restaurant System, I want to add staff
members and their relative information so I can assign each of them role
description.
• Scenario #1: Adding New Staff
• Given a restaurant manager with the required privileges, when he
adds new staff member to the system, then the manager will be able
to assign this staff an existing role from a list of available roles in the
system.
 Example
007 Staff Member Management
As a restaurant manager for the OVIPs Restaurant System, I want to be
able to change the staff roles so I can better manage them.
•Scenario #1: Editing Existing Staff Members Roles
Given a restaurant manager with the required privileges, when he
edits an existing staff member, then the manager will be able to
assign this staff member a new role from an existing role from a list of
available roles in the system.
•Scenario #2: Editing Existing Staff Members Information
Given a restaurant manager with the required privileges, when he
edits an existing staff member, then the manager will be able to
change the member information in the system such contact and
address information.
 Example
008 Menus Management
As a restaurant manager for the OVIPs Restaurant System, I want to be able to
create new menus and manage current menus so I can better serve my
customers
• Scenario #1: Creating New Menus

• Given a restaurant manager or a staff member with the required privileges, when he
creates a new menu in the system, then he can add new menu items to this menu.

• Scenario #2: Editing Existing Menus

• Given a restaurant manager or a staff member with the required privileges, when he
edits an existing menu, then the manager will be able to add new menu items, delete
menu items, or move menu items from menu to menu.

• Scenario #3: Deleting an Existing Menus

• Given a restaurant manager or a staff member with the required privileges, when he
deletes an existing menu, then the system will no longer display this menu and its items
will be free to be added to other menus.
 Example
009 View Orders
As a restaurant manager for the OVIPs Restaurant System, I want to be able to
view tables’ orders sorted by date or customers so I can track them in case I
need to.

•Scenario #1: Listing Orders

Given a restaurant manager or a staff member with the required
privileges, when he queries for a specific order by customer name,
date, or table, then he can see the orders’ related information
such as, but not limited to, who order it, paid or not, date and
time of the order.
 Example
010 Editing Orders
As a restaurant manager, or dedicated staff member in the OVIPs
Restaurant System, I want to be able to edit tables’ orders so I can
respond to the customers’ needs.

•Scenario #1: Editing Orders

Given a restaurant manager or a staff member with the required privileges,
when he edits a specific order for a specific customer, then he can change this
order by any means such as adding more items to the order, dropping items
from the order or even cancelling list of items from this order.
•Scenario #2: Deleting Orders
Given a restaurant manager or a staff member with the required privileges,
when he deletes a specific order for a specific customer, then the customer will
no longer pay for this order, and the system will indicate that this order was
deleted by a privileged user and store that user information with this
transaction.
 Example

011 Orders Discount

As a restaurant manager for the OVIPs Restaurant System, I want to be able
to give discounts for any tables’ orders so I can better market for my
restaurant.

• Scenario #1: Editing Orders

• Given a restaurant manager or a staff member with the required
privileges, when he gives a specific customer a discount for a
specific order, then this discount will be directly reflected to the order
balance and the customer will be able to see this discount using the
restaurant system.
Restrictions

 The most common mistake when specifying

software is the lack of a clearly defined set of
restrictions that summarize the required quality.
 A restriction imposes conditions that set a limit to
comply with.
 Like any other specification element, each
restriction should be clear, simple, and
understandable.
Restrictions

 Should You express Nonfunctional Requirement

as User story?
 Expressing non-functional requirements as user
stories is certainly not usual.
 The main reason is stories are placeholders for
functional requirements.
 Non-Functional requirement can be restricted in
Scenario.
Restrictions
 Each restriction is specific for a scenario.
 Non-functional requirements as "constraints" we put on
the system. When a product owner says, "this system
must perform adequately with 100,000 concurrent users,"
the product owner is putting a constraint on the
development team.
 Fortunately constraints/non-functional requirements can
be easily handled as user stories. Here are a couple of
examples:
 As a customer, I want to be able to run your product
on all versions of Windows from Windows 95 on.
The Agile Development Process
• Listen for user stories
• Draw a logical workflow model
• Create new user stories based on the logical model
• Develop some display prototypes
• Create a physical data model using feedback from the
prototypes and logical workflow diagrams
Writing User Stories
• Spoken interaction between developers and users
• Seeking first and foremost to identify valuable business
user requirements
• The goal is prevention of misunderstandings or
misinterpretations of user requirements
Agile Frameworks
• Extreme Programming (XP)
• Scrum
• etc
Extreme Programming
• Extreme Programming (XP) is a software development
methodology which is intended to improve software
quality and responsiveness to changing customer
requirements
– Advocates frequent "releases" in short development
cycles, which is intended to improve productivity and
introduce checkpoints where new customer
requirements can be adopted
 Extreme Programming Paradigms(1)
• Pair programming
– While the first developer focuses on writing, the other one reviews code, suggests
improvements, and fixes mistakes along the way.
– Two developers working on the same computer
– Two eyes are better than one

• Small releases
– Small releases allow developers to frequently receive feedback, detect bugs early, and
monitor how the product works in production.
– Release software every two to four weeks

• System metaphor
– All programmers should understand the whole system

• Refactoring
– Continually clean up the code
– Refactoring is about removing redundancy, eliminating unnecessary functions, increasing
code coherency, and at the same time decoupling elements.
Extreme Programming Paradigms(2)
• Continuous integration
– Developers always keep the system fully integrated.
– Build the entire software baseline at least once a day
• Coding standards
– All programmers must following a well established
standard
• Collective code ownership
– All programmers should be able to change any
software
Extreme Programming Paradigms(3)
• Simplicity
– Design everything as simple as possible
• Planning game
– Iteration Planning: This plans the activities and tasks
of the developers
– Release Planning: This is focused on determining
what requirements are included in which near-term
releases, and when they should be delivered

• Whole team
– Everyone needs to be involved
▪ Customers, users, developers, testers, etc.
Extreme Programming Paradigms(4)
• Sustainable pace
– programmers should not work more than 40 hour
weeks
• Test driven development
1. Each new feature begins with writing a test
–This test must inevitably fail because it is
written before the feature has been
implemented
2. The next step is to write some code that causes the
test to pass
3. Go back to step 1
Test Driven Development
Scrum
• Iterative, incremental framework
• Encourages continuous improvement
• Small pieces of functionality are developed and tested
Scrum Definitions (1)
• Sprint
– The basic unit of development in Scrum
– A sprint is a “timeboxed" effort; that is, it is restricted
to a specific duration
▪ The duration is fixed in advance for each sprint
and is normally between one week and one month,
although two weeks is typical
Scrum Definitions (2)
• User story
– One or more sentences in the everyday language of
the end user that captures what needs to be
developed
▪ Use Case
▪ Format: “As a <type of user>, I want <some goal>
so that <some reason>
▪ Contains a detailed description, story point
estimation, priority, assignee(s), list of tasks and
tests, definition of done
Scrum Definitions (3)
• Backlog
– Work to be done
– Composed of stories
• Story point
– A story point is a relative measure used to determine (or
estimate) the difficulty of implementing a given user story
• Velocity
– Story Points earned per sprint
• Definition of Done
– A clear and concise list of requirements that software must
adhere to for the product owner to call it complete
Definition of Done
• Code produced that adheres to a coding standard
• Code commented
• Code checked into source control system
• Peer reviewed (or produced with pair programming)
• Unit tests written and passed
• Relevant documentation/diagrams produced and/or
updated
• Product owner concurs
Scrum (1 of 2)
• Begin the project with a high-level plan that can be
changed on the fly
• Success of the project is most important
• Individual success is secondary
• Project leader has some (not much) influence on the
detail
• Systems team works within a strict time frame (two to
four weeks for development)
Roles Played in Scrum
• There are three roles in Scrum:
– Product owner
– Scrum Master
– Team member
• Scrum Teams are cross-functional, meaning the
members have all the skills necessary to create value
each Sprint.
• They are also self-managing, meaning they internally
decide who does what, when, and how.
• The Scrum Team typically has 10 or fewer people.
Product owner
• The Product Owner is accountable for maximizing the
value of the product resulting from the work of the Scrum
Team.
• The Product Owner is also accountable for effective Product
Backlog management, which includes:
– Developing and explicitly communicating the Product Goal
– Creating and clearly communicating Product Backlog items
– Ordering Product Backlog items
– Ensuring that the Product Backlog is transparent, visible
and understood.
Product owner
• The Product Owner is one person, not a committee.
• The Product Owner may represent the needs of many
stakeholders in the Product Backlog.
• Those wanting to change the Product Backlog can do so
by trying to convince the Product Owner.
• For Product Owners to succeed, the entire organization
must respect their decisions.
Scrum Master
• The Scrum Master is accountable for the Scrum Team’s
effectiveness.
• The Scrum Master serves the Scrum Team in several
ways, including:
– Coaching the team members in self-management and
cross-functionality
– Helping the Scrum Team focus on creating high-value
Increments that meet the Definition of Done;
– Causing the removal of impediments to the Scrum
Team’s progress
– Ensuring that all Scrum events take place and are
positive, productive, and kept within the timebox.
Scrum Master
• The Scrum Master serves the Product Owner in several
ways, including:
– Helping find techniques for effective Product Goal
definition and Product Backlog management
– Helping the Scrum Team understand the need for
clear and concise Product Backlog items
– Helping establish empirical product planning for a
complex environment
– Facilitating stakeholder collaboration as requested or
needed
Team Members
• Team members:
– Work to create and improve user stories
– Generate estimates
– Self-organize to complete the work
– Exhibit willingness to participate in any activity to help
the project
– Creating a plan for the Sprint, the Sprint Backlog
– Instilling quality by adhering to a Definition of Done
– Adapting their plan each day toward the Sprint Goal
Scrum (2 of 2)
• Product backlog
• Sprint backlog
• Sprint
• Daily scrum
• Demo
Product Backlog
• Features and other deliverables designers intend for the
product based on user stories
• The list of user stories is reorganized so that the most
important user stories appear on the top
A Product Backlog Registry
Sprint Cycle
• Stories are deliverables the team accomplishes
• Tasks are parts of the story or units of work that each
team members does
• The sprint cycle can vary in length, but the usual is two
weeks
• At the end of the cycle, determine whether the product
should be released
Two-Week Release Advantages
• Team spirit remains high
• Completing the product is more real to the team
• Continual feedback from customers
Scrum vs. Waterfall (1)
• Volatile requirements
– Waterfall – may cause extensive rework
– Scrum – should require reduced rework due to the
iterative nature
• Product
– Waterfall – Customer views the finished product
– Scrum – Customer constantly sees the product (more
confidence)
Scrum vs. Waterfall (2)
• Visibility
– Waterfall – Little visibility
– Scrum – Progress is constantly demonstrated
• Verification
– Waterfall – Begins after implementation
(development) is complete
– Scrum – Constantly testing using continuous
integration
Lessons Learned from Agile Modeling (1 of 2)
• Short releases allow the system to evolve
• Pair programming enhances the overall quality
• Onsite customers are mutually beneficial to the business
and the agile development team
Other Unique Scrum Features
• Scrum planning meeting
• Planning poker
• Daily meetings
• Sprint burndown chart
• Sprint review
Scrum Planning Meeting
• Two parts to a Scrum planning meeting:
– Product owner presents the list of features on the
wish list of user stories
– Estimate the resources needed to complete all of the
features
▪ Common way to do this is to play planning poker
Planning Poker
• Planning poker is a way to help the team determine
estimates for completing the features from user stories
• There are rules for the game
Planning Poker Rules (1 of 3)
• A moderator keeps the estimation meeting running
efficiently
• The product owner presents one of the user stories that
needs estimating
• Each team member chooses a card with a number on it
and lays it face down
• A lower numbered card means that a project can be
completed faster
Planning Poker Rules (2 of 3)
• The numbers may represent the number of days it takes
to finish a feature, story points, or even difficulty in
abstract terms
• Team members turn over their cards at the same time
Planning Poker Rules (3 of 3)
• The team members with the highest and lowest estimates
may defend their ratings
• The entire team can discuss the estimates
• A new hand is then played and so on
Daily Scrum Meetings
• Called a stand-up meeting because it lasts only a few
minutes
• Team members tell each other what tasks they’ve been
working on since the previous daily Scrum
• Tasks they expect to complete during the current daily
Scrum
• Obstacles might get in their way
Sprint Burndown Chart
• Way to keep track of performance
– Horizontal axis tracks the time that has elapsed
– Vertical axis may track the number of tasks remaining
or the number of hours to complete the remaining
tasks
– Red line shows hours of work remaining, and the
yellow bars show the number of tasks remaining
A Burndown Chart
Lessons Learned from Agile Modeling (2 of 2)
• The 40-hour work week improves worker effectiveness
• Balanced resources and activities support project goals
• Agile values are crucial to success
Sprint Review
• Team gets together in a meeting to review the work done
• Note any tasks that were not completed
• User stories completed are prominently documented
• User stories the team committed to that were not finished
are noted
Scrum Process Summarized
Scrum Process Summarized
Scrum Meetings
Meeting Frequency Participants Output
Product Planning Before the first Product owner Product backlog
Sprint (PO) and
stakeholders
Sprint Planning 1 At the beginning PO, Scrum Sprint backlog
of each Sprint Master and Team

Sprint Planning 2 After Sprint Scrum Master Sprint backlog

Planning 1 and Team decomposed into
tasks
Daily standup Daily Scrum Master Updated status
(Scrum) and Team
Sprint At the end of PO, Scrum Completed or not
demonstration each Sprint Master and Tea completed stories
Sprint After the PO, Scrum Continually
Retrospective demonstration Master and Team improvement
meeting
Keep Track of Progress (to add more tools)
• Use an agile management tool
– Jira, Scrumworks, VersionOne, Rational Team Concert
(RTC)
• Use an agile task board
Velocity Metric Chart
Scrum at Large
• Scrum teams are 3 – 9 individuals
• If a project has 100 developers
– Multiple teams are formed
• Scrum of Scrums meetings are held
Scrum Advantages (1 of 2)
• Advantages:
– Quick product development
– Exercises a user-oriented approach
– Encourages teamwork
– Less confusing than more formal approaches
– Flexibility
Scrum Advantages (2 of 2)
• Advantages:
– Satisfying to team members
– Rewards smaller but meaningful accomplishments
– Provides feedback
– Adaptability
Scrum Disadvantages
• Disadvantages:
– Documenting features improperly
– Releasing products with errors
– Releasing products too soon for the user
– Completing the sprint backlog under pressure
– Working as a geographically dispersed team may be
difficult
– Working as a team when special skills are required may be
challenging
– Replacing team members who leave the team is difficult