Transcript PowerPoint

You will need to…
 Sort out your teams
 Know your assessment schedule
 Identify your personal project title
 Discover the core functionality
 Agree the shared components
 Document all meeting with your SCRUM log
 Create clear lines of communication
 Work together – don’t form cliques
Software tools…
 Some mechanism for sharing documents
 Google docs?
 You all have Office 365 accounts?
 GitHub?
 Visual Studio Online?
 Development environment
 Decide on architecture
 Front end – back end
Two deliverables to focus on
 Product Contract – what you plan to do
 Clearly state core functionality
 Why is the product needed?
 What components will be shared?
 Social impact study – identify topic
 Ethical review – cannot start project till this is approved
 Initial Deliverable
 Analysis and design documentation

Class diagrams, use cases etc.
 Testing – how will you approach this
 Smoke and Mirrors Prototype
So where do you start?
 Once you know your project title and I have said it is
suitable need to get to grips with the requirements
 Discuss with your team where the overlaps are
 Bounce ideas for how might the products work
 Use each other as test users
 Follow the strategies outlined in IMAT2204 last year
Role Play the Scenario
 Who what when where and why?
 (If you are not clear on any of these points then you
must return to the client and find out.)
Create detailed written
description
 The consultant sits at their desk with a stack of
business cards and flyers. They pick up a business card
and start to input the details into system. The first
field they enter is the name of the company. While
doing this the system looks up the company name to
see if it is already on the system. The next field the user
enters is the name of the contact. Whilst dong this, the
list of contacts for that company is displayed such that
if the contact is already on the system the user may
move onto another business card. At this point the
user should have the opportunity to update the details
on the system should they note that some aspect has
change e.g. email address.
The Event Table
 Probably the most useful tools for digesting the
problem
 Informs your use cases
 Informs your class diagram
 Don’t get hung up on it being right
 Better to add more events and discount them later
 Understanding will still be fuzzy at this stage of the
game
Address Book Event Table
Subject
User
Verb
Views
Object
Address
List
User
Filters
Address
List
User
Adds
Address
User
Updates
Address
User
Deletes
Address
System
Validates
Address
Response
Addresses
are listed
by the
system
Address list
is filtered
based on
pattern
Address is
added to
the system
Address is
updated on
the system
Address is
deleted
from the
system
Address
data is
accepted or
error is
displayed
Identify Candidate Events from the
Specification
The consultant sits at their desk with a stack of business cards
and flyers. They pick up a business card and start to input
the details into system. The first field they enter is the name
of the company. While doing this the system looks up the
company name to see if it is already on the system. The
next field the user enters is the name of the contact. Whilst
dong this, the list of contacts for that company is displayed
such that if the contact is already on the system the user
may move onto another business card. At this point the
user should have the opportunity to update the details on
the system should they note that some aspect has change
e.g. email address.
Some Filtering Required
 Not events but still contain important information
about the system
 “consultant sits at desk”
 “pick up a business card”
 Are these the same thing?
 “input the details”
 “enter the company name”
 “enter the name of the contact”
Identify the Verbs in the Event
Table
Subject
User
Verb
Views
Object
Address
List
User
Filters
Address
List
User
Adds
Address
User
Updates
Address
User
Deletes
Address
System
Validates
Address
Response
Addresses
are listed by
the system
Address list
is filtered
based on
pattern
Address is
added to the
system
Address is
updated on
the system
Address is
deleted
from the
system
Address
data is
accepted or
error is
displayed
This Informs the Selection of Use
Cases
The Subject Column Identifies the
Actors
Subject
User
Verb
Views
Object
Address
List
User
Filters
Address
List
User
Adds
Address
User
Updates
Address
User
Deletes
Address
System
Validates
Address
Response
Addresses
are listed by
the system
Address list
is filtered
based on
pattern
Address is
added to the
system
Address is
updated on
the system
Address is
deleted
from the
system
Address
data is
accepted or
error is
displayed
Create Use Case Descriptions
Use Case Name
(Short two or three
word name)
Use Case
Description (Short
description)
Use Case Author(s)
(Who wrote this)
Actor(s) (Who does
this)
Locations (Where
does this happen)
Primary pathway
(What is the normal
“happy path” for
this use case?)
Alternate pathways
(What other paths
are there that are
not the “happy
path”?)
Exception pathways
(What could
possibly go wrong?)
List Addresses
The user views a list of addresses in the system
Matthew Dean
User
On-line
List addresses
User enters the system
A list is displayed to the user at system start
There is no data in the system – a message is displayed
saying so
User applies filter
A filtered list is displayed to the user
User clears filter
Full list is displayed to the user
Database connection fails
Error displayed to the user advising of connection problem
Documenting Use Case
Diagrams
 Do not cram too much on one page
 Make sure they can be read without the aid of a
microscope
 Keep them clear and simple