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

Detailed System Specification Document | SEPE module

Detailed System Specification Document | SEPE module

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Detailed System Specification Document | SEPE module

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

Recently uploaded

Recently uploaded (20)

Detailed System Specification Document | SEPE module