INFORMATION SYSTEMS @ X
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X



You have defined your problem and built a
set of activity diagrams that outline what the
new/modified information system needs to
do.
You have defined key functional and nonfunctional requirements
Its time to logically model the requirements
from an event and object perspective.
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X

Your team’s objectives are to:
◦ Develop an Event Table modeling 4-6 key events
the system must respond to…. Your ‘to be’
diagrams from D2.
◦ Develop a Domain Class diagram that models the
classes required to support your events
◦ Develop use case scenarios and a use case
diagram to model the uses of the system, based
on your events
◦ Develop a system sequence diagram for each of
your use case scenarios
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X





A Word document
11 point Arial font
Double spaced – 1.25 inch margin top and
bottom. 1 inch left and right.
Good document format – same as previous
deliverables
Your audience: your sponsor and the user(s)
you interviewed to define requirements. Your
models will also be used by designers to
develop physical design documents, but this
is a secondary consideration.
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X





Document structure and grammar – 10%
Event table – 10%
Class Diagram/descriptions – 20%
Use Case Diagram/Descriptions – 30%
Sequence Diagrams – 30%
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X

Introduction (couple of paragraphs)
◦ What’s in this document

Background (1/2 page – 1 page)
◦ No more than a page – tell reader what has happened to get to
this point in the project
Remember to Introduce each section
of your document – tell the reader
what to expect!! When presenting a
model, describe what the symbols
mean!
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X

Event Table.
◦ 4-6 Events – corresponds to the business processes
you modeled using activity diagrams in deliverable
2
◦ Use the Event Table
◦ Make sure you introduce the section – describe
what is in the table!
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X

Class Diagram
◦ Part 1: Diagram.
 Must have at least 6 classes in your model.
 At least 1 class must be associative (resolves a many to
many relationship)
 At least 1 class must store information about an event or
transaction
 Label each relationship in two directions
 No many to many relationships!
 Use class cardinality notation from text
◦ Part 2: Class Descriptions. For each class provide:
 Description for each class (what information does the class
contain?)
 Primary Key.
 A minimum of 4 non-key attributes
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X
Use a table like the
following to
document each
class
Class Name
Entity X
Description
This entity contains information regarding….
Attributes
Attribute
Name(s)
Description
Primary Key
Key Attribute
(may be more
than one
attribute)
Describes the attribute
Non-Key
Attributes
Attribute 1
Describe…
Attribute 2
Etc.
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X


For each event in the event table, generate a use
case description. Develop ‘intermediate’ level
descriptions (main flow and exceptions). See
text pp. 172-173 for examples. OR you can
use an activity diagram instead of each text
description – see pages 251-252 for examples.
If you choose to use Activity diagrams, you still
need to list exception conditions.
Develop one Use Case diagram that models all
Use Cases in one picture. Break into
subsystems if appropriate.
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X

System Sequence Diagrams
◦ One diagram per use case scenario
◦ Make sure that each diagram has a label
◦ Sample diagram posted on the web – in class
example
◦ Ensure objects are properly labeled
◦ Messages should have proper syntax
◦ You need only model most important messages –
don’t worry about exception conditions
INFO415: Systems Analysis
INFORMATION SYSTEMS @ X


Start NOW – there is a large amount of work in this
deliverable.
Divide and Conquer! You will struggle if you don’t
do this successfully. Suggest that you:
◦ Meet initially to divide work and come up with a plan –
when wil you meet to review and consolidate
◦ Go off and work individually on your piece of the
project
◦ Meet to review, as required.
◦ Have a final meeting to consolidate.
◦ Assign one person to be responsible for final
document edits – document should read as if written
by one person!! This means you may decide to give
one group member less modeling work – document
consolidation is time consuming.
◦ Each team member should read the consolidated
document, suggest revisions, before handing the
document in.
INFO415: Systems Analysis