Detailed System Specification Document | SEPE module

Online Art Gallery | Cube Art Studios ©

Online
Art
Gallery
|
Cube
Art
Studios
©

Detailed
System
Specification

Version:
2.0

13th

March
2015

Darren
Martin
Leith

Detailed System Specification Page ii
Revision
History

Date
Description
Author
Comments

20/02/2015
1.0
Darren
M.
Leith
User
Stories
moved
to
Appendix
3

13/03/2015
2.0
Darren
M.
Leith
N/A

Document
Approval

The
following
Detailed
Specification
has
been
accepted
and
approved
by
the
following:

Signature
Printed
Name
Title
Date

Darren
M.
Leith

Lead
Software
Eng.
13/03/2015

Michael
C.
CEO,
Cube
Art
Studios
13/03/2015

Detailed System Specification Page iii
Table
of
Contents

Revision
History
.................................................................................................................................
ii

Document
Approval
..........................................................................................................................
ii

1.
Introduction
...................................................................................................................................
5

1.1
Purpose
...................................................................................................................................................
5

1.2
Scope
.......................................................................................................................................................
5

1.3
Definitions,
Acronyms,
and
Abbreviations
........................................................................................
6

1.4
References
..............................................................................................................................................
6

2.
General
Description
......................................................................................................................
6

2.1
Product
Perspective
..............................................................................................................................
7

2.2
User
Characteristics
...............................................................................................................................
7

3.
Specific
Requirements
..................................................................................................................
7

3.1
External
Interface
Requirements
........................................................................................................
7

3.1.1
User
Interface
..................................................................................................................................................
7

3.1.2
Hardware
Interfaces
.....................................................................................................................................
7

3.1.3
Software
Interfaces
.......................................................................................................................................
7

3.1.4
Communications
Interface
..........................................................................................................................
8

3.2
Functional
User
Stories
.........................................................................................................................
8

3.3
ORM
and
Classes
....................................................................................................................................
8

3.4
Non-‐Functional
Requirements
............................................................................................................
9

3.4.1
Performance
....................................................................................................................................................
9

3.4.2
Reliability
&
Availability
.............................................................................................................................
10

3.4.2.1
Internet
Service
Provider
.......................................................................................................................
10

3.4.2.2
Database
Servers
......................................................................................................................................
10

3.4.3
Security
............................................................................................................................................................
10

3.4.3.1
Data
Transfer
.............................................................................................................................................
10

3.4.3.2
Data
Storage
...............................................................................................................................................
10

3.5
Design
Constraints
..............................................................................................................................
10

3.5.1
Standard
Development
Tools
..................................................................................................................
10

3.5.1.1
Developers
Choice
...................................................................................................................................
10

3.5.2
Web
Based
Product
.....................................................................................................................................
11

3.6
Database
Requirements
....................................................................................................................
11

3.7
Other
Requirements
...........................................................................................................................
11

3.7.1
Legal,
Copyright,
and
Other
Notices
......................................................................................................
11

4.
Analysis
Models
...........................................................................................................................
11

4.1
Process
Model
.....................................................................................................................................
11

4.1.1
An
Overview
of
Process
Models
.............................................................................................................
11

4.2
Prescriptive
Process
Models
.............................................................................................................
12

4.2.1
Linear
Process
Flows
...................................................................................................................................
12

4.2.2
Incremental
and
Evolutionary
.................................................................................................................
13

4.2.3
Specialized
Process
Models
......................................................................................................................
15

4.3
Agile
Process
Models
.........................................................................................................................
16

4.3.1
Agile
Overview
..............................................................................................................................................
16

4.3.2
Extreme
Programming
(XP)
......................................................................................................................
16

4.3.3
Scrum
...............................................................................................................................................................
17

4.3.3.1
Srum
Methodology
..................................................................................................................................
17

4.3.3.2
Srum
Practices
...........................................................................................................................................
18

Detailed System Specification Page iv
4.3.3.3
Srum
Roles
..................................................................................................................................................
18

4.3.3.4
Why
Scrum?
...............................................................................................................................................
19

5.
Change
Management
Process
...................................................................................................
20

6.
Evaluation
of
First
Release
.........................................................................................................
21

6.1
CW1
Official
Website
.........................................................................................................................
21

6.1.1
Home
Page
–
Carousel
Slider
...................................................................................................................
21

6.1.2
Home
Page
–
Full
Screen
Part
1
..............................................................................................................
22

6.1.3
Home
Page
–
Full
Screen
Part
2
..............................................................................................................
23

6.1.4
Home
Page
–
Gallery
...................................................................................................................................
24

6.1.5
Clicking
on
an
Art
Image
............................................................................................................................
25

6.1.6
Clicking
on
an
Artist
.....................................................................................................................................
27

6.1.7
Navbars
and
Footers
...................................................................................................................................
28

6.1.8
Login
to
IMS/CMS
from
Official
website
..............................................................................................
29

6.2
CW2
IMS
...............................................................................................................................................
31

6.2.1
Dashboard
......................................................................................................................................................
31

6.2.2
Navbars
and
Layout
.....................................................................................................................................
31

6.2.3
Inventory
–
Viewing
....................................................................................................................................
32

6.2.4
Inventory
–
Adding
......................................................................................................................................
32

6.2.5
Inventory
–
Editing
.......................................................................................................................................
33

6.2.6
Artists
–
Viewing
...........................................................................................................................................
34

6.2.7
Artists
–
Adding
.............................................................................................................................................
35

6.2.8
Artists
–
Editing
.............................................................................................................................................
36

6.2.9
Staff
Members
...............................................................................................................................................
37

6.2.10
Events
–
Viewing,
Creating
.....................................................................................................................
38

6.2.11
Events
–
Editing
..........................................................................................................................................
39

6.3
CW3
CMS
..............................................................................................................................................
39

6.4
Project
Management
.........................................................................................................................
41

6.4.1
Project
Velocity
.............................................................................................................................................
41

6.4.2
Release
Burn
Down
.....................................................................................................................................
42

6.4.3
Points
Break
Down
......................................................................................................................................
43

A.
Appendices
...................................................................................................................................
44

A.1
Appendix
1:
Definitions,
Acronyms,
and
Abbreviations
..............................................................
44

A.2
Appendix
2:
References
....................................................................................................................
45

A.3
Appendix
3:
User
Stories
and
Development
Schedule
.................................................................
47

A.4
Appendix
4:
Minutes
of
First
Meeting
............................................................................................
61

A.5
Appendix
5:
Pivotal
Tracker
..............................................................................................................
63

Detailed System Specification Page 5
1.
Introduction

This
Detailed
System
Specification
(henceforth
referred
to
as
DSS)
document
contains
all
of

the
information
required
for
a
software
engineer
to
adequately
design
and
implement
the

‘Online
Art
Gallery’
product
as
described
by
the
requirements
listed
in
this
document.
It
also

included
a
detailed
evaluation
of
the
first
beta-‐release
of
the
software.

1.1
Purpose

The
purpose
of
this
document
is
to
provide
a
detailed
specification
of
the
system.
It
shall
be

divided,
broadly
speaking,
into
3
main
topics:

1. Requirements,
including:

• Scope.

• Functionality.

• Schedule.

2. Process
Model,
including:

• An
overview
of
Process
Models,
and
justification
for
choice
on
this
project.

3. Evaluation
of
the
first
release
of
the
system,
including:

• Detailed
evaluation,
and
improvements.

1.2
Scope

Product
Name

(1)
Online
Art
Gallery
|
Cube
Art
Studios
©
(henceforth
known
as
the
product).

(2)
This
product
will
perform
the
following
functionalities:

(a)
Official
website
for
Cube
Art
Studios
(henceforth
known
as
the
client).

(b)
Information
Management
System
(IMS)
to
manage
the
client’s
business.

(c)
Content
Management
System
(CMS)
to
manage
the
display
of
online
art
products.

(3)
Application(s)
of
the
product:

(a)
Delight
online
customers
by
presenting
a
modern,
visually
appealing
website
that

enhances
the
experience
of
buying
art
by
making
it
easy,
convenient
and
welcoming

for
both
collectors
and
artists.

(b)
Provides
a
core
management
tool
for
client
employees
to
run
the
day-‐to-‐day

operations
of
the
business.
Art
products,
artists,
customers,
orders,
staff,
reports,

statistics,
etc,
will
all
be
manageable
from
within
the
IMS/CMS
web
portal.

1.3
Definitions,
Acronyms,
and
Abbreviations

Please
reference
Appendix
1
for
a
full
list
of
definition,
acronyms,
and
abbreviations

pertaining
to
this
DSS.

1.4
References

Please
reference
Appendix
2
for
a
full
list
of
references
pertaining
to
this
DSS.

2.
General
Description

This
section
provides
a
general
description
of
the
product’s
three
main
functionalities.

Please
refer
to
section
3
of
this
DSS
for
a
more
detailed
description.

(a)
Official
website

The
official
website
has
the
following
general
requirements:

1.
Present
itself
as
the
store-‐front
for
advertizing
the
client’s
online
business:

1.1.
Home
page
displaying
a
gallery
of
art
items
with
pictures,
titles,
price,
etc.

1.2.
Search
functionality
to
look
for
art
items
based
on
genre,
price,
artist,
etc.

1.3.
Detail(s)
page
for
art
items
showing
more
information
relevant
to
any
particular
art

item
when
clicked/searched.

1.4.
Detail(s)
page
for
artists
showing
more
information
relevant
to
any
particular
artist

when
clicked/searched.

1.5.
Standard
features
and
pages
–
About
Us,
FAQ,
Blog
links,
Exhibitions,
navigation

bars,
etc.

2.
Act
as
a
“web
portal”
for
the
IMS/CMS.

2.1 Login
page
to
the
IMS
accessible
from
a
defined
URI
that
is
not
readily
visible
to
the

public.

(b)
IMS

The
IMS
has
the
following
general
requirements:

1.
Present
itself
as
a
repository
that
provides
client-‐employees
with
the
tools
to
efficiently

manage
various
facets
of
the
business.

1.1.
Dashboard
page
displaying
links
to
relevant
business
sub-‐components
such
as

Inventory,
Artists,
Customers,
Orders,
Staff,
Events,
etc.

1.2.
Database
driven
Create,
Read,
Update,
Delete
(CRUD)
functionality
for
all
of
the

sub-‐components
mentioned
in
point
1.1.

1.3.
Reports
and
Site
Statistics.

(c)
CMS

The
CMS
has
the
following
general
requirements:

1.
Present
itself
as
a
media-‐manager,
specifically
related
to
art
gallery
pictures.

1.1.
Support
the
easy
management
of
the
official
website
show-‐room,
allowing
the

client
employee
to
select
which
art-‐item
will
display
on
the
Home
Page.

2.1
Product
Perspective

The
client’s
business
model
is
that
of
a
family-‐run
modern
art
gallery.
The
client
currently

has
no
online
presence,
hence
this
product
will
be
the
client’s
first
venture
into
online

marketing
and
web-‐based
applications.

2.2
User
Characteristics

The
users
of
this
product
will
fall
into
the
following
demograhic
market
segment:

1.
Casual
web
surfers,
not
necessarily
intending
to
purchase
art.

2.
Curious
shoppers
that
may
be
interested
in
purchasing
art.

3.
Art
collectors
and
enthusiasts
that
are
actively
seeking
to
purchase
art
items.

4.
Previous
clientelle.

5.
Client
employees
that
will
use
the
IMS/CMS
component
of
the
product.

3.
Specific
Requirements

This
section
will
give
the
detailed
requirements
that
are
used
to
guide
the
project’s
software

design,
implementation,
and
testing.

3.1
External
Interface
Requirements

The
following
types
of
interfaces
are
supported
by
the
product,
namely
the
User
Interface,

Hardware
Interface,
and
Software
Interface.

3.1.1
User
Interface

a) The
user
interface
for
the
product
shall
constitute
a
web-‐based
user
interface
(WUI)

that
is
viewed
via
any
web
browser
i.e.
Chrome,
Mozilla
Firefox,
Internet
Explorer,

Safari,
Opera,
etc.

b) The
product
shall
provide
a
uniform
look
and
feel
between
all
web
pages.

c) The
product
must
not
be
constrained
by
screen
size.
The
product
must
be
readily

usable
on
mobile
and
tablet
technologies,
with
adaptable
layouts
to
match
those

technologies.

3.1.2
Hardware
Interfaces

Since
the
product
must
run
over
the
Internet,
hardware
interfaces
include
standard

technologies
that
allow
a
user
to
connect
to
the
Internet
such
as
an
Ethernet
cable
or
WIFI,

a
modem,
and
suitable
LAN/WAN
connectivity.

3.1.3
Software
Interfaces

a) The
product
user
interface
(WUI)
is
independent
of,
and
communicates
with,
all

operating
systems
e.g.
OSX,
Windows,
Linux.

b) The
product
shall
communicate
with
a
suitable
database
back-‐end
e.g.
SQL,
MySQL.

c) The
product
will
not
have
e-‐commerce
billing.
However,
the
client
requires
the

product
to
have
the
ability
to
integrate
e-‐commerce
components
in
the
future.

3.1.4
Communications
Interface

Requirements
for
communication
functions
include:

a) The
TCP/IP
protocol
used
for
communication
over
the
internet
shall
be
HTTP.

b) The
Port
number
used
in
production
will
be
80.

c) There
shall
be
a
logical
address
of
the
product
in
IPv4
format.

3.2
Functional
User
Stories

The
software
process
model
adopted
for
this
product
is
SCRUM
(reference
Section
4.3.3
for

a
detailed
description).
As
such,
a
list
of
functional
user
stories
or
Product
Backlog
was

created
in
which
the
highest
priority
items
were
placed
at
the
top
of
the
list,
and
the
lower

priority
items
further
down
the
list.
Figure
1
below
illustrates
a
typical
user
story,
and

Appendix
3:
Users
Stories
and
Development
Schedule
provides
a
comprehensive
overview

of
all
user
stories.

Figure
1:
example
of
a
User
Story

3.3
ORM
and
Classes

As
referenced
later
on
in
section
3.5.1.1
–
“Developers
Choice”,
the
framework
used
by
this

Development
Team
is
Laravel,
ref.
Laravel
(2015).
Laravel
employs
“Eloquent
ORM”
which
is

a
simple
ActiveRecord
implementation
for
working
with
the
database
back-‐end.
Each

database
table
has
a
corresponding
“Model”
which
is
used
to
interact
with
that
table.

Reference
Figure
2
which
displays
entities,
attributes,
and
relationships
from
the
MySQL

database
at
the
product’s
Prototype
stage,
and
note
how
they
correlate
with
the
code.

Figure
2:
ORM
and
Classes

3.4
Non-‐Functional
Requirements

3.4.1
Performance

a) The
product
is
based
on
the
web,
and
must
be
run
from
a
web
server.

b) The
product’s
initial
load
time
will
be
dependent
on
the
internet
connection

strength,
which
also
depends
on
the
media
from
which
the
product
is
run.

c) The
performance
is
dependent
upon
the
hardware
components
of
the
user.

3.4.2
Reliability
&
Availability

3.4.2.1
Internet
Service
Provider

The
product
shall
have
an
internet
service
provider
using
a
Tier
3
or
higher
Data
Centre

service
with
99.9999%
uptime
availability
through
their
network
services.

3.4.2.2
Database
Servers

The
produt
database
shall
be
stored
on
redundant
servers
that
possess:

a) automatic
switchover.

b) replication
of
databases
to
off-‐site
storage
locations.

c) RAID
5/6
block-‐level
striping
on
all
database
storage
disks.

3.4.3
Security

3.4.3.1
Data
Transfer

a) The
product
shall
use
password
encryption
when
logging
the
client
employee
onto

the
IMS/CMS.

b) The
product
shall
use
measures
to
prevent
SQL
injection(s),
mass
assignment(s),
and

cross-‐site
request
forgeries.

c) The
product
shall
confirm
all
IMS/CMS
deletions
with
the
client
employee’s
web

browser
before
actioning
(in
essence,
a
notification
to
confirm
the
deletion).

d) The
system
shall
not
leave
any
cookies
on
the
client
employee’s
computer
containing

the
user’s
password,
unless
the
client
employee
requests
the
browser
to
do
so.
If

required,
the
cookie
will
be
encrypted.

3.4.3.2
Data
Storage

a) The
client
users
web
browser
shall
never
display
their
password.
It
shall
always
be

echoed
with
special
characters
representing
typed
characters.

b) The
products
back-‐end
database
shall
only
store
a
hashed
version
of
the
users

password
in
the
‘users’
table.
The
client
users
password
may
be
reset,
but
never

shown.

c) The
products
back-‐end
servers
shall
only
be
accessible
to
authenticated

administrators.

d) The
products
back-‐end
production
database
shall
be
encrypted.

3.5
Design
Constraints

3.5.1
Standard
Development
Tools

The
product
shall
be
built
using
any
web
page
development
tool
that
conforms
to
W3C
web

design
and
application
standards,
reference
W3C
(2015).

3.5.1.1
Developers
Choice

The
following
web
page
development
tools
were
used
by
this
development
team:

1. MAMP
development
platform,
version
3.0.7.3
(AppSolute,
2015).

2. Laravel
PHP
framework,
version
4.2
(Laravel,
2015).

3. MySQL
workbench,
version
6.2.4
(MySQL,
2015).

4. PhpStorm
IDE
(JetBrains,
2015).

3.5.2
Web
Based
Product

a) There
are
no
memory
requirements

b) Computers
accessing
the
product
must
be
equipped
with
web
browsers.

c) A
general
knowledge
of
basic
computer
skills
is
required
to
use
the
product.

3.6
Database
Requirements

The
IMS
component
of
the
product
stores
information
related
to
many
facets
of
the
clients

business,
including
inventory,
artists,
customers,
orders,
employees,
etc.
A
suitable

database
will
be
required
for
this
product
e.g.
SQL,
MySQL,
etc.
Reference
Figure
2
which

shows
the
entities,
attributes,
and
relationships
that
were
used
in
creating
a
functional

prototype
of
the
product.

3.7
Other
Requirements

3.7.1
Legal,
Copyright,
and
Other
Notices

Software
product
should
display
the
disclaimers,
copyright,
word
mark,
trademark
and

product
warranties
of
Cube
Art
Studios
©.

4.
Analysis
Models

4.1
Process
Model

The
process
model
chosen
for
developing
the
product
identified
in
this
DSS
is
‘Scrum’,
which

is
discussed
in
greater
detail
in
section
4.3.3. To
begin,
we
shall
provide
a
general

introduction
to
software
engineering
process
models,
citing
various
examples
along
the
way

which
will
serve
as
a
useful
comparative
frame
of
reference
in
our
analysis
of
Scrum.

4.1.1
An
Overview
of
Process
Models

“...most
software
development
is
a
chaotic
activity,
often
characterized
by
the
phrase
‘code

and
fix’,
and
a
process
model
offers
an
inherent
structure
that
is
designed
to
reduce
risk
and

uncertainty
and
increase
manageability”
–
Fowler
(2005).

What
is
a
software
process
model,
and
why
should
we
use
one?
Any
model,
at
its
core,
is
an

abstraction
or
mental
distillation
of
the
‘details’
down
to
the
‘essentials’.
A
software
process

model
attempts
to
impose
stability,
control,
and
order
to
the
complexities
inherent
in
any

software
development
project.
The
term
process
model
is
now
widely
used
to
refer
to
the

system
life
cycle
model,
and
determines
the
order
in
which
activities
are
carried
out
(“in

sequence,
or
maybe
in
parallel?”,
“what
do
we
do
next?”),
and
the
transition
criteria

between
activities
(“how
do
we
know
when
to
stop
doing
what
we
are
currently
doing?”).

Having
a
clearly
defined
process
model
is
essential
for
successful
project
management.

Without
one,
how
can
we
plan,
set
milestones
and
deliverables,
allocate
resources,
monitor

progress,
etc?
Process
models
may
be
categorized
as
either
prescriptive
or
agile,
which
are

elaborated
upon
in
the
proceeding
sections.

4.2
Prescriptive
Process
Models

4.2.1
Linear
Process
Flows

Prescriptive
or
traditional
models
have
been
around
for
decades,
an
oft-‐cited
example
being

the
waterfall
model
displayed
in
Figure
3
which
was
originally
proposed
by
Royce
(1970)

based
on
his
experience
with
the
“development
of
software
packages
for
spacecraft
mission

planning”.
The
waterfall
model
is
typified
by
extensive
planning
at
the
beginning
of
the

project,
which
sets
rigid
milestones
and
deliverables.
Once
established,
such
a
process
is

mostly
static,
which
is
widely
perceived
as
a
disadvantage
since
stakeholder(s)
requirements

and
the
environment
in
which
the
system
is
to
be
used
will
inevitably
change
during

development.
The
waterfall
model
generally
involves
highly
structured
development

methodologies
in
which
the
production
of
elaborate
design
documentation
can
occupy
a

large
part
of
the
development
effort.
As
Royce
(1970:5)
puts
it
–
“how
much

documentation?
My
own
view
is
‘quite
a
lot’...
the
first
rule
of
managing
software

development
is
ruthless
enforcement
of
documentation
requirements”.

Figure
3:
The
waterfall
model,
sometimes
called
the
“classic
life
cycle”.
Note
the
linear

process
flow,
beginning
with
communication,
and
culminating
in
deployment.

A
variation
on
the
waterfall
model
is
the
V-‐model
proposed
by
Forsberg
and
Mooz
(1991),

displayed
in
Figure
4.
The
‘Vee”
model
(as
it
was
originally
named)
places
greater
emphasis

on
systems
engineering
as
“...the
role
of
system
engineering
as
a
vital
part
of
the
project

team
is
frequently
ignored”.
Quality
assurance
via
testing
activities
such
as
planning
and

test-‐designing
happen
long
before
coding.
In
practice
there
are
no
real
fundamental

differences
between
the
waterfall
model
and
the
V-‐model,
other
than
the
application
of

‘verification’
and
‘validation’
methodologies
earlier
on
in
the
V-‐model.


Figure
4:
The
V-‐model.
The
software
team
initially
moves
down
the
left-‐hand
side
of
the
V

which
follows
the
well
established
waterfall
model.
Once
code
has
been
generated
the
team

moves
up
the
right
hand-‐side,
performing
quality
assurance.

Advantages
of
the
waterfall
and
V-‐model
include:

a) Useful
when
requirements
are
clearly
defined,
and
fixed.

b) Useful
when
projects
are
small
to
medium
sized.

c) Project
is
well
documented
and
quality
assurance/testing
is
closely
adhered
to.

Disadvantages:

a) Requirements
must
be
explicitly
detailed
up-‐front,
which
is
often
difficult
for
the

client
to
do
at
the
beginning
of
a
project.

b) Rigid
and
inflexible
–
the
process
flow
does
not
reflect
experience.
Projects
rarely,
if

every,
conform
to
a
linear
process
flow.
Of
the
V-‐model,
Liversidge
(2005:1)
states:

“in
the
software
development
world,
you
can
bet
your
last
dollar
that
the
plan
will

change...[it]
does
nothing
to
accommodate
change,
and
this
is
the
primary
reason

why
it
fails
as
a
model.”

4.2.2
Incremental
and
Evolutionary

Incremental
process
models
(Basili
1975)
replicate
linear
process
flow
methods
however

they
proceed
in
a
staggered
fashion
as
time
increases.
This
is
best
illustrated
in
Figure
5.


Figure
5:
The
incremental
model.
The
technique
involves
the
development
of
a
software

product
“through
a
sequence
of
successive
design
and
implementation
steps”
–

Basili(1975:395)

An
incremental
model
combines
elements
of
the
waterfall
model
(it
is
sometimes
referred

to
as
a
‘multi-‐waterfall’
cycle)
with
the
iterative
philosophy
of
prototyping,
with
each
linear

sequence
producing
a
deliverable
increment
of
the
software.
Each
iteration
is
a
self-‐
contained
mini-‐project
composed
of
activities
such
as
communication,
planning,
modeling,

construction,
and
deployment.
For
each
iteration,
all
the
software
across
all
the
teams
is

integrated
into
a
release.

Advantages
include:

a) Useful
when
we
need
to
provide
a
limited
set
of
software
functionality
to
the
client

as
early
as
possible,
and
then
refine
that
functionality
in
later
software
releases.

b) In
many
instances
the
first
increment
is
a
core
product
(i.e.
a
prototype)
that
can
be

evaluated
by
the
client.

c) The
smaller
increments
can
provide
better
quality
assurance
as
it
is
easier
to

test/debug.

Disadvantages:

a) Like
the
previously
mentioned
methods,
there
is
a
need
for
up-‐front
requirements.

While
some
requirements
can
evolve
over
time,
the
major
requirements
for
the

complete
system
must
be
explicitly
delineated.

Evolutionary
process
models,
like
incremental
models,
produce
increasingly
more
complete

versions
of
the
software
with
each
iteration.
They
differ
somewhat
from
the
other
models
in

that
the
requirements,
plan,
estimates,
etc.
evolve
over
the
course
of
the
iterations
rather

than
being
fully
defined
“up-‐front”.
They
are
consistent
with
a
pattern
of
unpredictable

discovery.
Once
such
example
is
the
spiral
model
(Boehm
1998).
This
model
represents
a

risk-‐driven
approach
to
software
process
analysis.
It
incorporates
an
evolutionary
process

model
combining
the
iterative
nature
of
prototyping
with
the
systematic
aspects
of
the

waterfall
model.

Figure
6:
A
simplified
spiral
model.
Each
linear
sequence
produces
a
deliverable
increment

of
the
software
e.g.
the
first
spin
around
the
spiral
might
produce
a
prototype,
subsequent

spins
produce
progressively
more
sophisticated
versions.

Advantages
include:

a) Well
suited
to
the
development
of
large-‐scale
systems.

b) Risk
analysis,
quality
assurance
and
documentation
control
are
heavily
emphasised.

c) Suitable
for
mission-‐critical
projects.

Disadvantages:

a) As
identified
by
Pressman(2015:49):
“it
demands
considerable
risk
assessment

expertise
and
relies
on
this
expertise
for
success.
If
a
major
risk
is
not
uncovered
and

managed,
problems
will
undoubtedly
occur”.
In
summary,
the
project’s
success
is

highly
dependent
on
the
risk
analysis
phase.

b) Extensive
and
elaborate
risk
analysis
can
lead
to
spiralling
costs.

c) Does
not
necessarily
work
well
for
smaller
projects.

4.2.3
Specialized
Process
Models

Aside
from
those
already
mentioned,
there
are
many
other
process
models
that
can
be

categorized
as
prescriptive.
Each
of
these
models
suggest
a
slightly
different
process
flow,

but
all
perform
the
same
set
of
generic
framework
activities
that
we
have
seen
so
far
i.e.

communication,
planning,
modeling,
construction,
and
deployment.
Below
are
three

examples,
with
suitable
references
for
further
reading.

a) Unified
Process
–
Kruchten
(2004),
Rational
Software
(1998)

b) Component
Based
Development
–
(Pressman:53)

c) Personal
and
Team
Software
Process
–
(Pressman:59-‐61)

4.3
Agile
Process
Models

4.3.1
Agile
Overview

“Agile
development
is
popular.
All
the
cool
kids
are
doing
it:
Google,
Yahoo,
Symantec,

Microsoft,
and
the
list
goes
on”
–
Shore
and
Warden
(2008:3).

Agile
is
an
overarching
term
that
covers
many
processes
that
share
a
set
of
core
values
and

principles
as
defined
by
the
“Manifesto
for
Agile
Software
Development”
–
Beck
(2001).

An
agile
philosophy
stresses
the
following
key
components:

1. Communication
between
both
team
members
and
stakeholders
is
critical
to
success.

2. Teams
must
be
self-‐organizing,
and
have
control
over
the
work
that
they
perform.

3. Adaptive
rather
than
predictive
–
agile
processes
welcome
change.

4. Rapid
development
that
satisfies
the
customer.

Agile
models
focus
on
maneuverable,
adaptable,
lightweight
processes
that
are
aligned
with

the
rapidly
changing
market
conditions
that
define
modern
business
practices.
Examples
of

agile
processes
include
Extreme
Programming
(Shore,
et
al
2008),
Crystal
(Cockburn,
2004),

Scrum
(Sutherland,
1995),
Kanban,
FDD,
etc.

4.3.2
Extreme
Programming
(XP)

Programmer
Beck
(2005)
developed
Extreme
Programming
(familiarly
known
as
XP)
while

serving
as
project
leader
on
Chrysler
Comprehensive
Compensation
(Copeland,
2001).
Beck

(2005:2)
refers
to
XP
as
being
a
“style
of
software
development
focusing
on
excellent

application
of
programming
techniques,
clear
communication,
and
teamwork”.

XP’s
philosophical
core
values
include:

1. Feedback.

2. Simplicity.

3. Communication.

4. Respect.

5. Courage.

It
distinguishes
itself
from
other
methodologies
by
the
following:

a) Short
development
cycles
with
continuous
feedback.

b) An
incremental
planning
approach
that
rapidly
creates
an
evolving
project
plan

through
the
life-‐cycle
of
the
project.

c) Extreme
flexibilty
and
adaptability
to
changing
requirements.

d) Reliance
on
automated
tests,
written
by
all
stakeholders.

e) Close
collaboration
and
communication
with
stakeholders

Advantages
of
XP
include:

a) Lightweight
methodology
for
small-‐to-‐medium
sized
teams.
Development
Teams

only
do
what
is
necessary
to
create
value
for
the
customer.

b) The
Development
Team
can
concentrate
on
the
code,
not
on
the
paper-‐work.

c) Embraces
test
driven
development.
Testing
begins
before
coding,
and
each
piece
of

code
must
categorically
pass
the
unit
test.

Disadvantages:

a) Pair
programming.
Two
developers
work
side
by
side
on
a
single
assignment.
Beck

claims
this
approach
leads
to
higher-‐quality
code
requiring
less
time
to
test
and

debug.
This,
however,
does
not
work
for
every
company,
or
software
engineer.

b) XP
is
a
philosophical
mindset,
which
can
be
difficult
for
many
software
developers
to

accept
in
practice
i.e.
it
is
not
structured,
in
the
typical
sense.

c) XP
embraces
code-‐centric
as
opposed
to
design-‐centric
development.
This
can
be

problematic
when
programs
become
very
large.

d) XP
emphasizes
continuous
refactoring
of
the
code
during
the
development
process.

It
is
debatable
whether
continuous
refactoring
is
productive
in
the
long
run.

4.3.3
Scrum

As
stated
from
the
outset,
the
product
described
in
this
DSS
utilizes
a
Scrum
development

framework.
Scrum
was
conceived
by
Sutherland
(1995)
as
an
iterative
and
incremental
agile

software
development
framework
for
cross-‐functional
teams.
Scrum
has
gained
massive

popularity
in
the
agile
development
community
due
to
its
simplicity,
proven
productivity,

and
ability
to
act
as
a
wrapper
for
various
engineering
practices
promoted
by
other
agile

methodologies.
4.3.3.1
Srum
Methodology

With
any
Scrum
methodology,
the
“Product
Owner”
works
closely
with
a
Development

Team
to
identify
and
prioritize
system
functionality
in
form
of
a
“Product
Backlog”.
The

Product
Backlog
consists
of
features,
bug
fixes,
chores,
etc.
–
whatever
is
required
in
order

to
successfully
deliver
a
working
software
system.
With
priorities
driven
by
the
Product

Owner,
cross-‐functional
teams
estimate
and
sign-‐up
to
deliver
“potentially
shippable

increments”
of
software.
Scrum
structures
development
in
cycles
of
work
called
Sprints,

usually
1-‐4
weeks
in
length,
with
each
Sprint
taking
place
one
after
the
other
without
pause.

The
overall
flow
of
a
typical
scrum
process
is
shown
in
Figure
7.


Figure
7:
The
Scrum
process
flow.
The
overall
Sprint
length
is
usually
between
1-‐4

weeks.

4.3.3.2
Srum
Practices

a) At
the
beginning
of
each
Sprint,
a
cross-‐functional
team
selects
items
from
a

prioritized
list
or
Product
Backlog.

b) The
team
agrees
on
a
collective
target
for
what
they
believe
can
be
achieved
by
the

end
of
the
Sprint.
During
the
Sprint,
no
new
items
may
be
added
–
Scrum
embraces

change
for
the
next
Sprint,
but
the
current
short
Sprint
is
meant
to
focus
on
a
small,

concise,
achievable
goals.

c) Every
day
the
team
gathers
briefly
to
inspect
its
progress,
and
adjust
the
next
steps

needed
to
complete
the
remaining
work.

d) At
the
end
of
the
Sprint,
the
team
reviews
the
Sprint
with
stakeholders,
and

demonstrates
what
it
has
built.
Feedback
is
obtained
that
can
be
incorporated
into

the
next
Sprint.

e) At
the
end
of
the
Sprint
the
working
product
should
be
integrated,
fully
tested,
end-‐
user
documented,
and
potentially
shippable.

4.3.3.3
Srum
Roles

There
are
three
roles
in
Scrum:

a) Product
Owner
–
responsible
for
maintaining
the
Product
Backlog
and
prioritizing

the
user
stories.

b) Development
Team
–
responsible
for
implementing
the
user
stories
by
breaking

them
up
into
tasks.

c) Scrum
Master
–
responsible
for
ensuring
that
the
team
is
following
the
Scrum

process
e.g.
making
sure
that
there
is
a
Daily
Scrum
meeting
and
that
everyone

answers
the
standard
three
questions
as
shown
in
Figure
7.
The
Scrum
Master
can

be
a
member
of
the
Development
Team.
Furthermore,
different
people
can
take
on

the
role
of
the
Scrum
Master
over
time.
The
Scrum
Master,
however,
cannot
be
the

Product
Owner.

4.3.3.4
Why
Scrum?

There
were
a
number
of
deciding
factors
in
choosing
Scrum
for
the
product
detailed
in
this

DSS
over
other
process
models,
including:

a) Size
of
the
system

! The
product
scope
is
small-‐to-‐medium
sized.
Larger
sized
projects
involving

hundreds
of
developers
may
benefit
from
more
structured,
prescriptive
models.

! Agile
process
models
are
people-‐oriented,
and
place
a
lot
of
emphasis
on
face-‐
to-‐face
contact.
For
this
project,
the
client
requested
a
weekly
meeting
to

review
progress.
This
tied
in
nicely
with
the
concept
of
weekly
sprints,
and
a

weekly
review
meeting.

b) Predictability

! For
this
project,
the
requirements
and
overall
scope
are
initially
unclear,
or

sketchy
at
best.
This
is
the
client’s
first
venture
into
online
web
applications

which
is
reflected
somewhat
in
the
scant
initial
requirements
(reference
A.4

Appendix
4:
Minutes
of
First
Meeting).

! The
client
requested
an
initial
prototype
in
order
to
“get
a
feel”
for
what
was

required.
Any
situation
in
which
exploration
is
needed
to
resolve
uncertainty
will

naturally
benefit
from
prototyping,
which
implies
an
iterative
approach.

! Projects
in
which
the
requirements
are
initially
unclear,
or
where
there
is

uncertainty
about
the
scope
may
not
be
well
served
by
prescriptive
approaches.

c) Customers

! The
client
is
prepared
to
be
(or
expects
to
be)
very
involved
in
the
project.

However,
the
client
does
not
have
enough
staff
to
sit
in
with
the
Development

Team
every
day,
which
ruled
out
an
XP
methodology.

! After
the
initial
first
meeting,
the
client
showed
great
enthusiasm
for
the

concept
of
agile-‐executed
“user
stories”
i.e.
short,
concise
statements
to

describe
what
he/she
wants.

! Some
prescriptive
approaches
provide
for
little
or
no
involvement
after
an

intensive
initial
requirements
phase.


d) Experience
and
ability
of
developers

! The
developers
on
this
project
are
experienced,
and
have
all
worked
on
agile

projects
before.
Two
members
of
the
Development
Team
were
on
XP
projects
in

the
past
and
disliked
having
to
do
pair-‐programming.

! Scrum
provides
for
excellent
quality
assurance.
Every
sprint
produces
a
fully

integrated,
and
tested
product.
Some
members
of
the
Development
Team

employ
test
driven
development,
which
ties
in
well
with
an
XP/Scrum
agile

philosophy.

e) Project
Management
Tools

! The
Development
Team
have
all
benefitted
from
the
use
of
excellent
online

Scrum
project
management
tools
on
previous
projects.

! For
this
project,
the
client
and
the
Development
Team
were
all
excited
at
the

prospect
of
using
Pivotal
Tracker

(ref.
Pivotal
Tracker,
2015),
and
A.5
Appendix

5:
Pivotal
Tracker
for
further
information).
The
client
was
particularly
pleased
to

be
able
to
track
project
progress
and
status
24/7,
and
liked
the
idea
of
having

the
authority
to
approve/reject
each
user
story.

5.
Change
Management
Process

a) As
the
process
method
is
agile
Scrum
(reference
previous
section)
the
Development

Team
strive
to
manage
change
–
not
prevent
it.

b) As
requirements
will
change
frequently,
Scrum
tends
to
treat
all
requirements
like
a

prioritized
stack.
The
Product
Owner,
with
assistance
on
this
project
from
the
Scrum

Master,
are
responsible
for
prioritizing
requirements,
and
the
Development
Team

are
responsible
for
estimating.

c) The
priorities
of
non-‐requirement
work
items
will
be
negotiated
by
the
Scrum

Master
with
the
Product
Owner.

6.
Evaluation
of
First
Release

This
section
will
provide
an
overview
and
evaluation
of
the
first
release
of
the
product.
This

section
must
be
read
in
conjunction
with
A.3
Appendix
3:
User
Stories
and
Development

Schedule
in
order
to
correlate
how
each
feature
has
evolved
alongside
the
development

process
model,
and
to
see
requested
improvements
and
time-‐frames.

6.1
CW1
Official
Website

6.1.1
Home
Page
–
Carousel
Slider

Figure
8:
Home
Page
–
Carousel
Slider.

Notes:

! 4
second
delay
between
each
carousel
slide.

! Carousel
image
selection
to
be
controlled
by
the
administrator
from
within
the
CMS

! Buttons
overlaying
the
images
are
clickable,
and
direct
the
shopper
to
relevant
page.

6.1.2
Home
Page
–
Full
Screen
Part
1

Figure
9:
Home
Page
–
Full
Screen
Overview
Part
1.

6.1.3
Home
Page
–
Full
Screen
Part
2

Figure
10:
Home
Page
–
Full
Screen
Overview
Part
2.

Notes:

! “NEW
ARTWORK
FOR
SALE”
and
“RECENTLY
SOLD
ARTWORK”
are
nice
features

based
on
simple
queries
to
the
database.
Each
image,
art
title,
artist
name
is

clickable
and
directs
the
shopper
to
relevant
page.

! Use
of
uniform
footer
throughout
the
site.

6.1.4
Home
Page
–
Gallery

Figure
11:
Home
Page
–
Gallery
Notes:

! All
images
and
art
titles
are
clickable,
and
direct
the
shopper
to
a
more
detailed
view

of
the
art
item.

! The
artists
links
(in
blue
text)
are
clickable,
and
direct
the
shopper
to
a
more
detailed

view
of
the
artist.

6.1.5
Clicking
on
an
Art
Image

Figure
12:
Detailed
View
of
an
art
item
–
SUMMARY
OF
FEATURES
Notes:

! “Views”
indicates
how
many
times
the
image
has
been
viewed
by
the
public.

! The
artists
links
(in
blue
text)
are
clickable,
and
direct
the
shopper
to
a
more
detailed

view
of
the
artist.

! Use
of
DISQUS
for
leaving
comments
related
to
the
art
item.

! “MORE
BY”
and
“YOU
MIGHT
LIKE”
(shown
in
Figure
13)
are
nice
features
based
on

simple
queries
to
the
database.

Figure
13:
Detailed
View
of
an
art
item
–
full
length
view

6.1.6
Clicking
on
an
Artist

Figure
14:
Detailed
View
of
an
artist
Notes:

! Use
of
3rd
party
i.e.
FaceBook,
Google+
embedded
like
buttons.

! Views,
DISQUS,
and
no.
of
Artworks
by
this
artist.

! “ALL
ARTWORK
BY”
is
a
nice
feature
based
on
a
simple
query
to
the
database.
All

images
are
clickable
and
direct
the
shopper
to
a
detailed
view
of
that
art
item.

6.1.7
Navbars
and
Footers

Figure
15:
Navbars
and
Footers
–
basic
functionality
in
first
release.
Navbars
will
incorporate

advanced
search
functionality
in
final
release

6.1.8
Login
to
IMS/CMS
from
Official
website

Figure
16:
Login
screen
to
the
IMS
portal
via
“www.websitename/admin”

Figure
17:
Login
screen
field
validation
–
“Invalid
Credentials”


Figure
18:
Login
screen
field
validation

Figure
19:
Code
Snippet
for
Login
authentication
and
URL
redirection.

6.2
CW2
IMS

6.2.1
Dashboard

Figure
20:
The
IMS
Dashboard
–
initial
login.
Graphical
Reports
and
Stats
will
be
a
major

feature
of
the
Dashboard
in
final
release.

6.2.2
Navbars
and
Layout

Figure
21:
The
IMS
Dashboard
–
close
up
of
navigational
drop-‐downs

6.2.3
Inventory
–
Viewing

Figure
22:
Viewing
Inventory.

6.2.4
Inventory
–
Adding

Figure
23:
Adding
Inventory.

6.2.5
Inventory
–
Editing

Figure
24:
Editing
Inventory.

6.2.6
Artists
–
Viewing

Figure
25:
Viewing
all
Artists

Figure
26:
Code
Snippet:
querying
the
database
to
search
for
“Last
Name”

6.2.7
Artists
–
Adding

Figure
27:
Adding
a
new
Artist
–
full
length
view.

6.2.8
Artists
–
Editing

Figure
28:
Editing
an
Artist

6.2.9
Staff
Members

Figure
29:
CRUD
for
Staff
Members

6.2.10
Events
–
Viewing,
Creating

Figure
30:
Events
–
Viewing
and
Creating

6.2.11
Events
–
Editing

Figure
31:
Events
–
Editing

6.3
CW3
CMS

Notes:

! As
stated
in
section
6.1.4
Home
Page-‐
Gallery,
the
client
requested
a
gallery
of
12
art

images
on
the
Home
Page.

! It
should
be
possible
to
select
which
12
art
items
are
displayed
on
the
Home
Page
via

the
IMS/CMS
portal.

! The
Development
Team’s
solution
was
to
provide
a
“Media”
section
on
the
IMS

navigation
bar
(left-‐hand
side
of
Dashboard).
From
there
it
is
possible
to
view
the

existing
gallery,
and
edit
which
item
is
displayed
in
which
position
(see
Figure
32).

This
is
then
reflected
on
the
Home
Page
using
a
simple
database
query.

Figure
32:
Editing
the
Art
Gallery
Page

6.4
Project
Management

Appendix
5:
Pivotal
Tracker
provides
a
detailed
overview
of
the
online
project
management

tool
used
in
the
development
of
this
project.
All
diagrams
in
the
proceeding
sections
were

extracted
from
Pivotal
Tracker.

6.4.1
Project
Velocity

Figure
33:
Project
Velocity
–
avearging
at
8.4.
The
volatility
is
slightly
higher
than
expected

due
to
points
over/under
estimation
by
some
members
of
the
Development
Team.
This

artefact
was
resolved
after
the
Iteration
2’s
weekly
Scrum
Meeting.

6.4.2
Release
Burn
Down

Figure
34:
Project
Release
Burn
Down.
The
Projected
Completion
date
based
on
current

velocity
and
points
progress
is
April
19th

2015,
approximately
a
week
ahead
of
schedule.

6.4.3
Points
Break
Down

Figure
35:
Points
Break
Down
–
High
acceptance
rate
by
the
client.
Some
minor
rejections

on
February
21st

that
were
then
re-‐worked
into
the
Product
Backlog.

A.
Appendices

A.1
Appendix
1:
Definitions,
Acronyms,
and
Abbreviations

CMS
Content
Management
System
is
a
computer
application
that
allows
for
the

publishing,
editing,
modifying,
organizing,
deleting
and
maintenance
of
content

from
a
central
interface.

CRUD
Create,
Read,
Update,
Delete
refers
to
all
of
the
major
functions
that
are

implemented
in
relational
database
applications.

DSS
Detailed
System
Specification,
an
acronym
for
this
overall
document.

IMS
Information
Management
System
is
a
computerized
database
of
information

relevant
to
the
management
of
a
particular
business
process.

LAN
Local
Area
Network
is
a
computer
network
covering
a
small
geographic
area,

like
a
home,
office,
school,
or
group
of
buildings.

WAN
WAN
(Wide
Area
Network)
is
a
computer
network
that
covers
a
broad
area

(e.g.,
any
network
whose
communications
links
cross
metropolitan,
regional,
or

national
boundaries
over
a
long
distance).

URI
Uniform
Resource
Identifier.
The
most
common
form
of
URI
is
the
uniform

resource
locator
(URL),
frequently
referred
to
informally
as
a
web
address.

HTTP
Hypertext
Transfer
Protocol
is
an
application
protocol
and
the
foundation
of

data
communication
for
the
World
Wide
Web.

WI-‐FI
Wi-‐Fi
is
a
local
area
wireless
technology
that
allows
an
electronic
device
to

participate
in
computer
networking.

TCP/IP
Transmission
Control
Protocol
/
Internet
Protocol
defines
how
electronic

devices
(like
computers)
should
be
connected
over
the
Internet,
and
how
data

should
be
transmitted
between
them.

WUI
Web
User
Interface
which
accept
input
and
provide
output
by
generating
web

pages
which
are
transmitted
via
the
Internet
and
viewed
by
the
user
using
a

web
browser.

IPV4
Internet
Protocol
version
4
is
the
fourth
version
in
the
development
of
the

Internet
Protocol
(IP)
Internet,
and
routes
most
traffic
on
the
Internet.

RAID
Redundant
array
of
inexpensive
disks
is
a
storage
virtualization
technology.
It

combines
multiple
disk
drive
components
into
a
logical
unit
for
the
purposes
of

data
redundancy
and/or
performance
improvement.

MAMP
Mac
OS
X
–
the
operating
system;
Apache
–
the
Web
Server;
MySQL
–
the

database
management
system,
P
–
PHP.
MAMP
is
a
solution
stack
composed
of

free
and
open-‐source
and
proprietary
commercial
software
used
together
to

run
dynamic
web
sites
on
Apple
Macintosh
computers.

IDE
Integrated
Development
Environment.
A
software
application
that
provides

comprehensive
facilities
to
software
engineers
for
developing
software.

ORM
Object
Relational
Mapping
is
a
programming
technique
for
converting
data

between
incompatible
systems
in
object-‐oriented
programming
languages.

A.2
Appendix
2:
References

AppSolute.
(2015)
Mamp
&
Mamp
Pro.
Available
at:
http://www.mamp.info/en/downloads/

[Accessed
01st

February
2015].

Basili,
V.
R.,
&
Turner,
A.
J.
(1975)
Iterative
Enhancement:
A
Practical
Technique
for
Software

Development,
IEEE
Trans.
Software
Engineering,
1
(4)
pp.
390-‐396.

Beck,
K.
(2005)
Extreme
Programming
Explained:
Embrace
Change,
2nd

ed.
Boston:
Addison-‐
Wesley.

Beck,
K.
et
al.
(2001).
Manifesto
for
Agile
Software
Development.
Available
at:

http://agilemanifesto.org/
[Accessed
07th

February
2015].

Boehm,
B.
(1998)
‘A
Spiral
Model
of
Software
Development
and
Enhancement’.
ACM

SIGSOFT
Software
Engineering
Notes.
11
(4)
pp.14-‐24.

Cockburn,
A.
(2004)
‘Crystal
Clear:
A
Human-‐Powered
Methodology
for
Small
Teams:
A

Human-‐Powered
Methodology
for
Small
Teams,
1st

ed.
Addison-‐Wesley.

Copeland,
L.
(2001).
How-‐To
Extreme
Programming.
Available
at:

http://www.computerworld.com/article/2585634/app-‐development/extreme-‐
programming.html
[Accessed
07th

February
2015].

Forsberg,
K.
&
Mooz,
H.
(1991)
‘The
Relationship
of
System
Engineering
to
the
Project

Cycle’,
presented
at
the
National
Council
on
System
Engineering,
Center
for
Systems

Management
pp.
57–65.

Fowler,
M.
(2005)
The
New
Methodology,
[Online]
Available
at:

http://martinfowler.com/articles/newMethodology.html#rationalUnifiedProcess
[Accessed

01st

February
2015].

JetBrains.
(2015)
PhpStorm.
Available
at:
https://www.jetbrains.com/phpstorm/
[Accessed

01st

February
2015].

Kruchten,
P.
(2004)
The
Rational
Unified
Process:
An
Introduction
(3rd
Ed.).

Laravel.
(2015)
The
PHP
Framework
For
Web
Artisans.
Available
at:
http://laravel.com/

[Accessed
01st

February
2015].

Liversidge,
E.
(2005),
The
Death
of
the
V-‐Model.
Available
at:

http://www.harmonicss.co.uk/index.php/tutorials/software-‐engineering/56-‐the-‐death-‐of-‐
the-‐v-‐model
[Accessed
01st

March
2015].

MySQL.
(2015)
MySQL
Workbench
6.2.
Available
at:

http://www.mysql.com/products/workbench/
[Accessed
01st

February
2015].

Pivotal
Tracker.
(2015)
PivotalTracker.
Available
at:
http://pivotaltracker.com/
[Accessed

25th

Jan
2015].

Pressman,
R.S.
&
Maxim,
B.R.
(2015)
Software
Engineering:
A
Practitioner’s
Approach,
8th

ed.
New
York:
McGraw-‐Hill.

Royce,
W.W.
(1970)
‘Managing
the
Development
of
Large
Software
Systems:
Concepts
and

Techniques’,

Reprinted
from
Proceedings,
IEEE
Wescon,
pp.
1-‐9.

Rational
Software.
(1998)
Rational
Unified
Process:
Best
Practices
for
Software

Development
Teams,
Rational
Software
White
Paper,
TP026B,
REV
11/01

Shore,
J.
&
Warden,
S.
(2008)
The
Art
of
Agile
Development,
1st

ed.
California:
O’Reilly

Media,
Inc.

Sutherland,
J.,
Victor,
J.,
Schwaber,
K.
(1995).
Business
object
design
and
implementation:

OOPSLA
'95
workshop
proceedings.
The
University
of
Michigan.
pp.
118A.3
Appendix
3:

W3C.
(2015)
Web
Design
and
Applications.
Available
at:

http://www.w3.org/standards/webdesign/
[Accessed
15th

February
2015].

A.3
Appendix
3:
User
Stories
and
Development
Schedule

Note
1:
This
appendix
is
to
be
considered
part
of
the
DSS’s
overall
set
of
requirements.

Note
2:
See
Table
1
for
a
list
of
conventions
to
classify
each
user
story:

Id

unique
identifier
for
the
user
story

User
Story
content
of
the
user
story

Tags
useful
tags
for
classifying
the
scope
of
the
user
story

Week
week
number
that
the
user
story
will
start

Iteration
Start
start
date
of
the
iteration

Iteration
End
end
date
of
the
iteration

Points

estimate
by
the
development
team
for
the
relative
amount
of
time
to

complete
the
task

Created
at
date
the
user
story
was
created
by
the
client

Accepted
at
date
the
user
story
was
accepted
by
the
client

Deadline
yellow
row
indicates
that
it
is
a
milestone
deadline

Table
1:
Conventions
used
to
classify
a
User
Story

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

87306484
As
a
shopper
I
want
to

be
presented
with
a

header,
navigation
bar

and
footer
on
the

main
page
of
the

website

betalaunch,

main
page,

module
1:

create
website,

prototype

2
Feb
9,

2015

Feb
15,

2015

1
Jan
30,

2015

Feb
10,

2015

87319238
As
a
developer,
I
need

to
create
a
database

for
the
application.
To

begin
with,
I
need
the

following
tables:
ARTS,

ARTISTS,
CUSTOMERS,

EMPLOYEES,
EVENTS,

ORDERS.

betalaunch,

database,

developer,

module
1:

create
website,

prototype

2
Feb
9,

2015

Feb
15,

2015

Jan
30,

2015

Feb
15,

2015

87307170
As
a
shopper
I
should

be
able
to
see
a

gallery
of
images

displaying
art
items
on

the
main
page
that

correspond
to
works

for
sale.
Works
for

sale
should
show
the

name
of
piece,
artist,

price.

betalaunch,

main
page,

module
1:

create
website,

prototype

3
Feb
16,

2015

Feb
22,

2015

4
Jan
30,

2015

Feb
18,

2015

87310766
As
a
shopper
I
can

click
on
an
art
image

(product)
on
the
main

page
of
website
and

be
redirected
to
a

page
showing
more

details
related
to
that

product

betalaunch,

main
page,

module
1:

create
website,

prototype

3
Feb
16,

2015

Feb
22,

2015

2
Jan
30,

2015

Feb
18,

2015

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

87311922
As
an
administrator

when
logging
into
the

IMS
I
should
be
shown

helpful
validation

messages
if
I
enter
in

the
wrong
password

or
if
the
username
is

left
out

betalaunch,

login,
module
2:

ims,
prototype,

validation

3
Feb
16,

2015

Feb
22,

2015

2
Jan
30,

2015

Feb
18,

2015

87312366
As
an
administrator
I

am
presented
with
a

dashboard
for
the
IMS

system.
I
should
be

able
to
navigate
to

INVENTORY,
SALES

CONTRACTS,
BUYERS,

ARTISTS,
STAFF,

EVENTS,
REPORTS.

betalaunch,

dashboard,

module
2:
ims,

prototype

3
Feb
16,

2015

Feb
22,

2015

1
Jan
30,

2015

Feb
18,

2015

87305590
Prototype:
As
a
client
I

want
to
see
a
basic

demo
for
the
site.

Should
display
basic

functionality
for
all
3

modules.

deadline
3
Feb
16,

2015

Feb
22,

2015

Jan
30,

2015

Feb
18,

2015

87319372
As
an
administrator
I

should
be
presented

with
a
link
to
the

Content
Management

System
from
within

the
Information

Management
System.

betalaunch,

module
3:
cms,

prototype

3
Feb
16,

2015

Feb
22,

2015

1
Jan
30,

2015

Feb
18,

2015

88591568
As
a
shopper,
I
want

to
see
"New
Artwork

For
Sale"
in
groups
of

3-‐6
images,
and

"Recently
Sold

Artwork"
also
in
image

groups
of
3-‐6.
I
want

this
on
the
main
page

betalaunch,

main
page,

module
1:

create
website

3
Feb
16,

2015

Feb
22,

2015

2
Feb
18,

2015

Feb
18,

2015

88591416
As
a
shopper,
I
want

to
see
3
or
4
really

large
pictures
on
the

main
page
that
"fly-‐
by".
I
have
seen
this

on
other
sites,
and

believe
its
called
a

CAROUSEL

betalaunch,

carousel,
main

page,
module
1:

create
website

3
Feb
16,

2015

Feb
22,

2015

8
Feb
18,

2015

Feb
18,

2015

88591974
As
a
developer,
I
need

to
implement
BugZilla

to
start
tracking
bugs,.

I
need
to
get
bugzilla

up
and
running
and

get
the
team

members
leveraging

its
capabilities
as
the

defacto
bug
tracking

tool.

betalaunch,

bugzilla,

developer

3
Feb
16,

2015

Feb
22,

2015

4
Feb
18,

2015

Feb
18,

2015

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

88640736
As
an
administrator,
I

want
to
see
a
"you
are

logged
out"
message

when
I
log
out
of
the

IMS
portal.
A
pop
up

would
be
nice

betalaunch,

logout,
module

1:
create

website,

module
2:
ims,

popup
message

3
Feb
16,

2015

Feb
22,

2015

1
Feb
18,

2015

Feb
18,

2015

88640330
As
an
administrator,
I

want
to
see
a

welcome
pop
up

notice
when
I
log
into

the
IMS
portal.

betalaunch,

login,
module
1:

create
website,

popup
message

3
Feb
16,

2015

Feb
22,

2015

1
Feb
18,

2015

Feb
18,

2015

87310436
As
an
administrator
I

should
be
presented

with
a
log
in
page
in

order
to
access
the

Information

Management
System.

The
log
in
page
should

only
be
accessible

from
something
like

http://www.yoursiten
ame/admin

betalaunch,

login,
module
1:

create
website

3
Feb
16,

2015

Feb
22,

2015

1
Jan
30,

2015

Feb
19,

2015

88711104
As
an
administrator,
I

would
like
to
see
small

icons
beside
each
of

the
navigational
text

descriptions
on
the

IMS
main
page.
For

example,
a
home
page

icon,
an
icon
for

artists,
inventory,

customers,
staff,
etc

betalaunch,

icons,
module

2:
ims

3
Feb
16,

2015

Feb
22,

2015

1
Feb
19,

2015

Feb
19,

2015

88767410
As
an
administrator,
I

would
like
to
see
my

username
on
the
IMS

dashboard.
I
would

like
to
see
it

positioned
on
the

right
hand
side,
similar

to
something
I
have

seen
on
wordpress,

etc.

betalaunch,

dashboard,

display

username,

module
2:
ims

3
Feb
16,

2015

Feb
22,

2015

1
Feb
20,

2015

Feb
20,

2015

87318622
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

Artists
from
within
the

IMS.
For
CREATE,
I

should
be
presented

with
a
form
and
be

able
to
enter
fields

related
to
first
name,

surname,
address,

country,
about,
email,

social
site
URLs,
and

be
able
to
upload
a

picture
of
the
artist

betalaunch,

create,
crud,

module
2:
ims

4
Feb
23,

2015

Mar
1,

2015

2
Jan
30,

2015

Feb
26,

2015

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

87318538
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

INVENTORY
from

within
the
IMS.
For

CREATE,
I
should
be

presented
with
a
form

and
be
able
to
enter

fields
related
to
artist

(via
drop
down
box),

title,
category,
price,

description,
subject,

medium
(dropdown),

and
be
able
to
upload

a
photograph
of
the

art
item.

betalaunch,

create,
crud,

dropdown,

inventory,

module
2:
ims

4
Feb
23,

2015

Mar
1,

2015

2
Jan
30,

2015

Feb
26,

2015

89336840
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

Artists
from
within
the

IMS.
For
READ,
I

should
see
a
table
of

all
artists,
showing

details
related
to

name,
address,

country,
picture,
and

links
to
buttons
that

will
allow
me
to
view

the
artist
on
main

website,
edit
the
artist

in
IMS,
and
delete
the

artist
in
IMS.

artist,
crud,

module
2:
ims,

read

4
Feb
23,

2015

Mar
1,

2015

2
Feb
28,

2015

Feb
28,

2015

89336876
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

Artists
from
within
the

IMS.
For
UPDATE,
I

should
be
presented

with
a
form
and
be

able
to
edit
existing

fields
related
to
first

name,
surname,

address,
country,

about,
email,
social

site
URLs,
and
be
able

to
change
the
picture

of
the
artist.
I
should

also
be
able
to
see
all

art
items
related
to

the
artist

crud,
module
2:

ims,
update

4
Feb
23,

2015

Mar
1,

2015

1
Feb
28,

2015

Feb
28,

2015

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

89336902
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

INVENTORY
from

within
the
IMS.
For

READ,
I
should
see
a

table
of
all
art
items,

showing
details

related
to
art
id,
title,

category,
price,

subject,
medium,

artist
(hyperlink
to

edit
artist),
picture,

date
added
and
links

to
buttons
that
will

allow
me
to
view
the

artist
on
main

website,
edit
the
art

item
in
IMS,
and

delete
the
art
item
in

IMS.

crud,
inventory,

module
2:
ims,

read

4
Feb
23,

2015

Mar
1,

2015

1
Feb
28,

2015

Feb
28,

2015

89336910
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

INVENTORY
from

within
the
IMS.
For

UPDATE,
I
should
be

presented
with
a
form

and
be
able
to
edit

existing
fields
related

to
artist
(be
able
to

change
the
artist
if

required
via

dropdown),
title,

category,
price,

subject,
medium
and

be
able
to
change
the

picture
of
the
art
item.

crud,
inventory,

module
2:
ims,

update

4
Feb
23,

2015

Mar
1,

2015

1
Feb
28,

2015

Feb
28,

2015

87318726
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for
STAFF

from
within
the
IMS.

For
UPDATE,
I
should

be
presented
with
a

form
and
be
able
to

edit
existing
fields

related
to
the
staff

member.

betalaunch,

crud,
module
2:

ims,
staff

4
Feb
23,

2015

Mar
1,

2015

1
Jan
30,

2015

Feb
28,

2015

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

89340604
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for
STAFF

from
within
the
IMS.

For
READ,
I
should
see

a
table
of
all
staff,

showing
details

related
employee

number,
name,

address,
country,
date

added,
picture,
and

links
to
buttons
that

will
allow
me
to

edit/delete
the
staff

member
in
IMS

crud,
module
2:

ims,
read,
staff

4
Feb
23,

2015

Mar
1,

2015

1
Feb
28,

2015

Feb
28,

2015

89340656
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for
STAFF

from
within
the
IMS.

For
CREATE,
I
should

be
presented
with
a

form
and
be
able
to

enter
fields
related
to

name,
address,

country,
email,
and
be

able
to
upload
a

photograph
of
the

staff
member

create,
crud,

module
2:
ims,

staff

4
Feb
23,

2015

Mar
1,

2015

1
Feb
28,

2015

Feb
28,

2015

87318644
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

EVENTS
from
within

the
IMS.
For
READ,
I

should
see
a
table
of

all
events,
showing

details
related
to

TITLE,
DATE
OF
EVENT,

DESCRIPTION,

PICTURE
and
links
to

buttons
that
will
allow

me
to
edit/delete
the

event
in
IMS

betalaunch,

crud,
events,

module
2:
ims,

read

6
Mar
9,

2015

Mar
15,

2015

2
Jan
30,

2015

Mar
12,

2015

90177490
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

EVENTS
from
within

the
IMS.
For
UPDATE,
I

should
be
presented

with
a
form
and
be

able
to
edit
existing

fields
related
to
the

event,
including

changing
the
date
and

time.

crud,
events,

module
2:
ims,

update

6
Mar
9,

2015

Mar
15,

2015

1
Mar
12,

2015

Mar
12,

2015

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

90177958
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

EVENTS
from
within

the
IMS.
For
CREATE,
I

should
be
presented

with
a
form
and
be

able
to
enter
fields

related
to
TITLE,

DATE/TIME
OF
EVENT,

DESCRIPTION,
and
be

able
to
upload
a

photograph
of
the

event

create,
crud,

events,
module

2:
ims

6
Mar
9,

2015

Mar
15,

2015

1
Mar
12,

2015

Mar
12,

2015

87318672
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

CUSTOMERS
from

within
the
IMS.
For

READ,
I
should
see
a

table
of
customers,

showing
details

related
to
NAME,

ADDRESS,
COUNTRY,

EMAIL
and
links
to

buttons
that
will
allow

me
to
edit/delete
the

customer
in
IMS.

betalaunch,

crud,

customers,

module
2:
ims,

read

6
Mar
9,

2015

Mar
15,

2015

2
Jan
30,

2015

Mar
12,

2015

90178228
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

CUSTOMERS
from

within
the
IMS.
For

UPDATE,
I
should
be

presented
with
a
form

and
be
able
to
edit

existing
fields
related

to
the
customer.

customers,

module
2:
ims,

up

6
Mar
9,

2015

Mar
15,

2015

1
Mar
12,

2015

Mar
12,

2015

90177828
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

CUSTOMERS
from

within
the
IMS.
For

CREATE,
I
should
be

presented
with
a
form

and
be
able
to
enter

fields
related
to
name,

address,
country,

email.

create,
crud,

customers,

module
2:
ims

6
Mar
9,

2015

Mar
15,

2015

1
Mar
12,

2015

Mar
12,

2015

89284706
As
a
shopper,
when
I

arrive
at
the
detailed

view
of
any
item
of

art,
I
expect
to
see

link(s)
to
the
artist

which
will
redirect
me

to
the
detailed
view
of

the
artist

artist,
detailed

view,
module
1:

create
website

6
Mar
9,

2015

Mar
15,

2015

1
Feb
27,

2015

Mar
12,

2015

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

89284952
As
a
shopper,
when
I

arrive
at
the
detailed

view
of
any
item
of

art,
I
expect
to
see
a

bigger
picture
of
the

art
item.
I
also
want
to

see
"picture
link"
to

MORE
BY
this
artist,

and
maybe
also

include
items
YOU

MIGHT
LIKE,
which
are

a
similar
category

art
item,

detailed
view,

module
1:

create
website

6
Mar
9,

2015

Mar
15,

2015

2
Feb
27,

2015

Mar
12,

2015

87323550
As
a
shopper
I
can

click
on
social
media

like
buttons
for
any

artist

(facebook,

google+,
etc)

facebook,

google+,
like,

twitter

6
Mar
9,

2015

Mar
15,

2015

2
Jan
30,

2015

Mar
12,

2015

87698238
As
a
shopper
I
can

leave
a
comment
on

any
item
of
art
or

artist.
(As
discussed
in

the
scrum
meetings,

as
a
client
I
want
to

use
the
DISQUS

package
to
implement

this).
I
should
see

DISQUS
at
the
bottom

of
the
page

betalaunch,

commenting,

module
1:

create
website

6
Mar
9,

2015

Mar
15,

2015

2
Feb
5,
2015
Mar
12,

2015

89284786
As
a
shopper,
when
I

arrive
at
the
detailed

view
of
any
item
of

art,
I
expect
to
see

information
related
to

the
art
items:
title,

artist,
artists
country,

category
of
art,
art

medium,
price,
art

description.
There

should
be
a
bigger

picture
of
the
art
item

also.

art
item,

detailed
view,

module
1:

create
website,

views

6
Mar
9,

2015

Mar
15,

2015

1
Feb
27,

2015

Mar
12,

2015

88882488
As
an
administrator,
I

would
like
to
add

SEARCH
functionality

in
the
IMS
artists

page.
There
should
be

an
input
box
where
I

can
type
in
the
name

of
an
artist,
and
filter

down
to
that

particular
artist

module
2:
ims,

search

6
Mar
9,

2015

Mar
15,

2015

2
Feb
23,

2015

Mar
12,

2015

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

89288690
As
an
administrator,

when
I
delete
an
artist

from
the
IMS
system,
I

do
not
expect
all
art

items
to
be
deleted

from
the
system
also

deleting,

module
2:
ims

6
Mar
9,

2015

Mar
15,

2015

0
Feb
27,

2015

Mar
12,

2015

87318700
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

ORDERS
from
within

the
IMS.
For
CREATE,
I

should
be
presented

with
a
form
and
be

able
to
enter
fields

related
to
selected
art

item
(maybe
drop

down?),
customer

name
(drop
down).

This
should
be

discussed
further
in

SCRUM
MEETING
but

functional
prototype

required
to
begin
with

betalaunch,

create,
crud,

module
2:
ims,

orders

6
Mar
9,

2015

Mar
15,

2015

4
Jan
30,

2015

in
progress

90180950
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

ORDERS
from
within

the
IMS.
For
READ,
I

should
be
presented

with
a
table
showing
a

list
of
orders
by
order

number.
Table
should

detail
customer,
date

of
purchase
and

button
links
to

details/delete

crud,
module
2:

ims,
orders,

read

6
Mar
9,

2015

Mar
15,

2015

2
Mar
12,

2015

in
progress

87319662
As
an
administrator
I

can
pick
and
choose

what
12
art
items

I

want
to
display
on
the

home
page
of
the

website
-‐
from
within

the
CMS.
This
will

serve
as
an
art-‐gallery

on
the
main
page.
I

should
be
able
to

search
through
all
art

items
in
database
and

pick
and
choose
12
art

items

art
gallery,

betalaunch,

main
page,

module
3:
cms

6
Mar
9,

2015

Mar
15,

2015

4
Jan
30,

2015

in
progress

87305162
CW1:
Beta
Launch
deadline
6
Mar
9,

2015

Mar
15,

2015

Jan
30,

2015

deadline

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

90181108
As
an
administrator
I

must
be
able
to

perform
CRUD

functionality
for

ORDERS
from
within

the
IMS.
For
UPDATE,
I

should
be
presented

with
a
table
showing

details
related
to
the

order
and
ability
to

update
field
including

customer,
art
item,

etc.

crud,
module
2:

ims,
orders,

update

7
Mar
16,

2015

Mar
22,

2015

2
Mar
12,

2015

unstarted

89283628
As
a
shopper,
I
should

see
a
detailed

navigation
bar
on
the

main
page.
I
should
be

able
to
be
redirected

to
art
items
that
are

either
PAINTINGS,

PHOTOGRAPHS,

DRAWINGS,

SCULPTURE,
COLLAGE

main
page,

module
1:

create
website,

navigation

7
Mar
16,

2015

Mar
22,

2015

2
Feb
27,

2015

unstarted

89283918
As
a
shopper,
I
should

be
able
to
search
on

the
main
page
of
the

website
for
art
based

on
its
style
and
price.
I

should
be
redirected

to
another
page
with

the
query
results.

Price
ranges
should
be

'UP
TO
E500,
500-‐
1000,
1000-‐2000,

2000-‐5000,
5000-‐
10000,
over
10,000"

main
page,

module
1:

create
website,

search

7
Mar
16,

2015

Mar
22,

2015

4
Feb
27,

2015

unstarted

89285048
As
a
shopper,
I
should

be
able
to
click
on
a

link
to
see
EVENTS,

ABOUT
US,
CONTACT

US,

FAQ,
BLOG
on
the

main
page
of
the

website.

main
page,

module
1:

create
website,

navigation

7
Mar
16,

2015

Mar
22,

2015

0
Feb
27,

2015

unstarted

89285264
As
a
shopper,
when
I

arrive
at
the
EVENTS

page,
I
expect
to
see
a

list
of
upcoming

events
and
art
shows.

events,
module

1:
create

website

7
Mar
16,

2015

Mar
22,

2015

2
Feb
27,

2015

unstarted

89301464
As
an
administrator,

when
I
perform
any

kind
of
deletion
in
the

IMS
for
an
artist,

buyer,
art
item,
etc,
I

expect
to
see
a
popup

reconfirming
whether

I
really
want
to

perform
the
deletion

crud,
deleting,

module
2:
ims,

popup
message

7
Mar
16,

2015

Mar
22,

2015

2
Feb
27,

2015

unstarted

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

90179776
As
an
administrator,
I

need
to
be
able
to

enter
the
dimensions

of
the
art
item.
This

should
be
length,

breadth,
depth,
in

inches.
Will
need
to

change
the
art

create/edit
form
to

include
this

art
dimensions,

create,
crud,

module
2:
ims,

update

8
Mar
23,

2015

Mar
29,

2015

2
Mar
12,

2015

unstarted

90179862
As
a
shopper,
I
need

to
be
able
to
see
the

dimensions
of
the
art

item.
This
should
be

length,
breadth,

depth,
in
inches.

Should
be
visible
from

the
detailed
art
item

page.
(prototype
and

betalaunch
are
hard-‐
coded
only)

art
dimensions,

detailed
view,

module
1:

create
website

8
Mar
23,

2015

Mar
29,

2015

1
Mar
12,

2015

unstarted

90180280
As
a
shopper,
when
I

view
an
artist
or
an
art

item,
I
expect
to
see

the
number
of
VIEWS

that
page
has
received

from
the
public.

(prototype
and

betalaunch
are
hard-‐
coded
only)

art
item,
artist,

module
1:

create
website,

number
of

views

8
Mar
23,

2015

Mar
29,

2015

4
Mar
12,

2015

unstarted

90180002
As
an
administrator,
I

need
to
be
able
to

enter
the
ADDRESS

field
of
CUSTOMERS,

ARTISTS,
STAFF
line
by

line.
It
is
currently
all

on
the
one
line.

Should
be
like:

STREET,
ADDRESS1,

ADDRESS
2,
CITY,

COUNTRY,
etc.

address,
crud,

module
2:
ims

8
Mar
23,

2015

Mar
29,

2015

4
Mar
12,

2015

unstarted

89285322
As
an
administrator,
I

should
be
able
to

manage
the
content

that
is
passed
into
the

EVENTS
section
of
the

main
website.
This

should
be
manageable

from
within
the

IMS/CMS

events,
module

3:
cms

9
Mar
30,

2015

Apr
5,
2015
4
Feb
27,

2015

unstarted

89283470
As
a
shopper,
I
should

be
able
to
search
for

art
items
or
an
artist

from
the
main
page
of

the
website.
This

should
then
show
me

a
page
of
all
items

related
to
my
search

main
page,

module
1:

create
website,

search

9
Mar
30,

2015

Apr
5,
2015
2
Feb
27,

2015

unstarted

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

89284384
As
an
administrator,
I

should
be
able
to

manage
the
content

that
is
passed
into
the

ABOUT
US
section
of

the
main
website.
This

should
be
manageable

from
within
the

IMS/CMS

about,
module

1:
create

website,

module
2:
ims,

module
3:
cms

9
Mar
30,

2015

Apr
5,
2015
4
Feb
27,

2015

unstarted

89284538
As
a
shopper,
I
should

be
able
to
click
on

links
to
the
websites

own
FACEBOOK,

TWITTER
and

GOOGLE+
pages

facebook,

google+,

module
1:

create
website,

twitter

9
Mar
30,

2015

Apr
5,
2015
1
Feb
27,

2015

unstarted

89284142
As
a
shopper,
when
I

arrive
at
the
BLOG

page
I
should
see
a

WORDPRESS
like
blog

page.
As
discussed
in

the
scrum
weekly

meeting,
if
we
opt
for

a
WORDPRESS
site

then
this
could
be

managed

independently
via

WORDPRESS).
Should

be
modeled
like
a

"magazine"

blog,
module
1:

create
website,

wordpress

9
Mar
30,

2015

Apr
5,
2015
4
Feb
27,

2015

unstarted

89283970
As
a
shopper,
I
should

be
presented
with
a

FEATURED
ARTIST
and

INVEST
IN
ART
section,

perhaps
on
the
main

page
of
the
website.

featured
artist,

invest
in
art,

main
page,

module
1:

create
website

10
Apr
6,

2015

Apr
12,

2015

2
Feb
27,

2015

unstarted

90180080
As
a
shopper,
on
the

detailed
artist
page,
I

should
be
able
to
see

the
FLAG
of
the

country
that
the
artist

is
from,
and
also
show

the
CITY
where
the

artist
is
based.

city,
crud,
flag,

module
1:

create
website,

module
2:
ims

10
Apr
6,

2015

Apr
12,

2015

4
Mar
12,

2015

unstarted

87324524
Testing:
full
testing
of

IMS
module

module
2:
ims,

testing

10
Apr
6,

2015

Apr
12,

2015

4
Jan
30,

2015

unstarted

87324540
Testing:
full
testing
of

CMS
module.

Customer
requests

document

module
3:
cms,

testing

10
Apr
6,

2015

Apr
12,

2015

4
Jan
30,

2015

unstarted

87324582
Testing:
Customer

requests
document

showing
one
module

thoroughly
tested

using
Bugzilla

bugzilla,
testing
11
Apr
13,

2015

Apr
19,

2015

4
Jan
30,

2015

unstarted

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

90181530
As
an
administrator,
I

would
like
to
have
the

ability
to
create
more

profiles
other
than

just
a
single
admin

account.
As
discussed

in
SCRUM
MEETING,

this
would
be
a
nice

optional
extra
if
time

permits
towards
the

end
of
the
project.

create
user

account,

module
2:
ims,

profile
page

11
Apr
13,

2015

Apr
19,

2015

4
Mar
12,

2015

unstarted

90181752
As
an
administrator,
I

would
like
to
be
able

to
change
the
3
slider

carousel
photographs

that
appear
on
the

home
page.
This

should
be
managed

via
the
CMS.
As

discussed
in
the

SCRUM
MEETINGS,

this
would
be
a
nice

optional
extra
if
time

permits

carousel,

module
3:
cms

11
Apr
13,

2015

Apr
19,

2015

4
Mar
12,

2015

unstarted

87324624
As
a
client
I
request
a

Post
Mortem
analysis

report

postmortem
11
Apr
13,

2015

Apr
19,

2015

Jan
30,

2015

unstarted

87324680
As
a
client
I
request
a

video
providing

evidence
of

functionalities
and

features
of
the

application

video
11
Apr
13,

2015

Apr
19,

2015

Jan
30,

2015

unstarted

87324738
As
a
client
I
request
a

document
showing

diverse
versions
of

one
file
retrieved
from

CVS
Repository

cvs
11
Apr
13,

2015

Apr
19,

2015

Jan
30,

2015

unstarted

87324818
As
a
client
I
request

documents
showing

how
application

conforms
to
MVC

architectural
pattern

mvc
11
Apr
13,

2015

Apr
19,

2015

Jan
30,

2015

unstarted

87325176
As
a
client,
I
request
a

system
specification

document
relating
to

the
application.

system

specification

11
Apr
13,

2015

Apr
19,

2015

Jan
30,

2015

unstarted

87305240
Full
Production
Launch

-‐
CW2

deadline
11
Apr
13,

2015

Apr
19,

2015

Jan
30,

2015

deadline

87322500
As
a
registered

shopper
I
can
log
in

and
out
of
the

website.
Required
in

order
to
purchase
an

art
item

betalaunch,

commerce,

module
1:

create
website,

registered

not

scheduled

not

scheduled

Jan
30,

2015

not

scheduled

Id
User
Story
Tags
Week
Iteration

Start

Iteration

End

Points
Created
Accepted

87322316
As
a
registered

shopper
I
can
create
a

profile
page
with

various
details
about

myself,
and
payment

options

betalaunch,

commerce,

module
1:

create
website,

registered

not

scheduled

not

scheduled

Jan
30,

2015

not

scheduled

87322562
As
a
registered

shopper
I
can
edit
my

profile
page

betalaunch,

module
1:

create
website,

profile
page,

registered

not

scheduled

not

scheduled

Jan
30,

2015

not

scheduled

87323050
As
a
shopper
I
can
add

a
product
to
the

shopping
cart

commerce,

module
1:

create
website,

registered,

shopping
cart

not

scheduled

not

scheduled

Jan
30,

2015

not

scheduled

87323098
As
a
shopper
I
can

view
all
products
in

my
shopping
cart

commerce,

module
1:

create
website,

registered,

shopping
cart

not

scheduled

not

scheduled

Jan
30,

2015

not

scheduled

87322270
As
a
shopper
I
can

register
as
a
user
to

the
site
using
the

registration
feature

betalaunch,

commerce,

module
1:

create
website,

registered

not

scheduled

not

scheduled

Jan
30,

2015

not

scheduled

87323078
As
a
shopper
I
can

remove
a
product

from
my
shopping
cart

commerce,

registered,

shopping
cart

not

scheduled

not

scheduled

Jan
30,

2015

not

scheduled

Table
2:
User
Stories
and
Development
Schedule

A.4
Appendix
4:
Minutes
of
First
Meeting

Project:

Online
Art
Gallery
|
Cube
Art
Studios
©

Meeting
Title:

CubeArt-‐TayOz
Introductory
Meeting

Date:

28th
January
2015

Issue
Date:

28th
January
2015

Time
(start/end):
10:00-‐11:30am

Meeting
no:

001

Location:

TayOz
meeting
room

Agenda:

Requirements
gathering

Attendees
Cube
Art
Studios
TayOz
Visions

Michael
C.
(MC)
Darren
L.(TO)

Vito
C.
(VC)
Doug
G.
(DG)

Fay
C.
(FC)
Vinod
R.
(VR)

Joey
J.
(JJ)

Not
present
/

Additional
distribution

N/A

Item
Agenda
Action

Date

Minutes
of
Meeting

1.0

1.1

1.2

1.3

2.0

2.1

2.2

2.3

2.4

2.5

3.0

3.1

3.2

Basic
Requirements

The official website of a family-run online art gallery, as a main framework (or
“Web Portal”). From within the official website it should be possible to run items
1.2 and 1.3
A database-driven web-based application to manage relevant details of the
business, such as items like paintings and sculptures for sale (including sale
contracts), customers (artists and buyers), staff, events, etc. This application is the
Information Management System (IMS).

A Content Management System (CMS) to support the easy management of an
online show-room displaying details of any art-piece for sale.

Identify
Key
Stakeholders

TayOz
Visions
use
a
software
process
model
called
Scrum
when
developing

software.
An
overview
of
this
model
was
presented
to
all
attendees,
along

with
roles
that
are
used
in
its
implementation.

MC
identified
himself
as
the
Product
Owner.

TO
identified
himself
as
both
Senior
Software
Engineer
and
Scrum
Master.

To
identified
DG,
VR,
JJ
as
members
of
the
Development
Team

TO
described
Pivotal
Tracker
as
a
tool
used
by
TayOz
Visions
for
project

managing
their
software
development.
An
overview
of
the
tool
was

presented.
All
attendeed
agreed
it
was
a
suitable
tool
for
project

management.
MC
agreed
that
it
would
be
a
good
tool
to
use
for
this
project.

User
Stories

Using
a
previously
completed
project,
TO
showed/described
to
all
attendees

a
list
of
User
Stories
that
were
used
in
its
development.

TO
and
MC
agreed
that
User
Stories
should
be
created
immediately.
Over
the

Note

Note

Note

Note

MC

Note

Note

Note

Note

TO/MC

04.02.15

29.01.15


3.3

3.4

4.0

4.1

5.0

5.1

5.2

5.3

5.4

next
week
TO/MC
would
create
a
Product
Backlog
to
try
and
identify
as

many
requirements
as
possible.

TO
will
create
a
Pivotal
Tracker
Project
online.
TO
will
create
all
necessary

accounts
for
the
Development
Team,
Scrum
Master,
Product
Owner,
and

send
on
all
details
to
MC.
All
User
Stories
will
be
logged
into
the
Pivotal

Tracker
database.

It
was
agreed
that
all
attendees
would
meet
again
next
week
to
review
the

Product
Backlog.

Prototype

MC
requested
a
prototype
based
on
the
basic
requirements
identified
in

Items
1.1/1.2/1.3.
TO
agreed,
adding
that
it
would
only
have
very
basic

functionality,
but
would
give
MC
and
his
team
an
idea
of
what
they
are
trying

to
achieve.
TO
stressed
the
importance
of
a
Product
Backlog
ASAP.
It
was

agreed
by
all
attendees
that
February
16th
should
be
the
deadline
for
its

completion.

Target
Dates

The
following
dates
were
discussed
and
agreed:

Project
Start:
28th
Jan
2015

Prototype
Completion:
16th
Feb
2015

Project
Completion:
24th
April
2015

TO
suggested
a
“beta-‐launch”
intermediate
release
which
would
have
much

more
functionality
than
the
prototype,
but
a
few
iterations
shy
of
actual

project
completion.
TO
proposed
the
13th
March.
To
be
confirmed
by
all

parties.

Unless
comments
on
the
Minutes
of
Meeting
are
received
from
Cube
Art

Studios
within
3
days
from
the
date
of
issue,
this
forms
a
true
and
final

record
of
the
meeting
discussions

TO

All

TO

Note

TO/MC

04.02.15

16.02.15

Next
meeting
–
04th
Feb
2015

A.5
Appendix
5:
Pivotal
Tracker

! Pivotal
Tracker
(2015)
is
an
online
agile
management
tool
for
controlling
projects

that
are
aligned
with
Scrum
methodologies.

! For
the
product
detailed
in
this
DSS,
the
Product
Owner
and
Development
Team

agreed
to
use
Pivotal
Tracker
for
creating
user
stories
(see
Figure
36
below).

Necessary
user
accounts
with
relevant
permissions
were
created
for
the

Development
Team
members,
Scrum
Master,
and
the
Product
Owner.

! As
the
tool
is
available
online,
it
proved
to
be
invaluable
for
the
Product
Owner
to:

1. Create
User
Stories
and
upload
them.
These
were
vetted
by
the
Scrum
Master

before
they
went
live
into
the
system.
Once
live,
the
Development
Team
were

able
to
immediately
add
them
to
their
work-‐flow.

2. Get
a
high-‐level
overview
of
the
status
and
progress
of
the
project.
Velocity,

Current
Iteration
Burn-‐up,
Release
Burn
Down
Charts,
etc.
are
all
readily

available
from
the
dashboard.

3. The
project
is
available
online
at:

https://www.pivotaltracker.com/n/projects/1264654

Figure
36:
Actual
Project
Status
of
Online
Art
Gallery
(snapshot
taken
12th

March
2015)


How
to
use
Pivotal
Tracker
[text
extracted
from
Pivotal
Tracker
(2015)
website]:

In
brief,
the
simplest
Tracker
workflow
goes
as
follows:

1. Customer/PM/PO
prioritizes
stories
in
Backlog.

2. Team
discusses
and
collectively
estimates
each
story.

3. Developers
start
next
available
story
in
Current
or
Backlog.

4. Developers
check
in
code
to
finish
story.

5. Team
pushes
code
for
new
feature
to
demo/test
environment,
and
delivers
stories.

6. Customer/PM
accepts
or
rejects
story
(the
feedback
loop).

! To
elaborate
more
on
Step
3:
At
the
beginning
of
a
typical
day,
a
developer
will
pick

an
unstarted
story
in
the
current
iteration
and
click
its
Start
button
(thereby

becoming
its
owner).

! When
work
on
the
story
is
completed,
the
developer
will
click
the
Finish
button.
The

Deliver
button
will
appear;
when
the
product
is
ready
for
acceptance

testing/evaluation,
a
team
member
will
click
the
Deliver
button.
This
will
indicate
to

the
story
requester
(visually
in
Tracker
and
via
notifications)
that
they
can
now

provide
feedback
on
the
story
by
accepting
or
rejecting
it.

! If
the
story
requester
(or
someone
else
representing
the
customer)
accepts
the

story,
the
story
will
turn
green
and
move
to
the
top
of
the
current
iteration.
At
the

end
of
the
iteration,
accepted
stories
move
to
the
Done
panel.

! If
the
story
is
rejected,
its
state
will
be
set
to
Rejected,
and
a
Restart
button
will

appear.
This
indicates
to
the
owner
of
the
story
that
more
work
is
needed.
When
a

collapsed
story
is
rejected,
Tracker
prompts
the
rejecter
for
a
reason,
which

subsequently
appears
as
a
comment
in
the
story.
If
an
expanded
story
is
rejected,

there’s
no
prompt,
but
a
comment
should
be
added.
The
owner(s)
of
the
story

receive
a
notification.

! Things
that
are
stalling
workflow
can
he
highlighted
using
labels
such
as
“blocked,”

“needs
design,”
or
“needs
discussion.”
You
can
use
labels
(like
“as
designed”)
if
you

want
to
accept
a
story
as
one
that
won’t
be
worked
on
and
want
to
preserve
the

reason
why.
You
can
also
label
all
stories
planned
for
a
specific
release
to
help
clarify

what’s
happening
in
your
project.

Detailed System Specification Document | SEPE module

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Detailed System Specification Document | SEPE module (20)

Recently uploaded (20)

Detailed System Specification Document | SEPE module