INFORMATION X INFO415: Systems Analysis

INFORMATION 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 non- functional requirements  Its time to logically model the requirements from an event and object perspective.

INFO415: Systems Analysis INFORMATION 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 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 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 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 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 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 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-KeyAttributes Attribute 1Describe… Attribute 2 Etc.

INFO415: Systems Analysis INFORMATION X  For each event in the event table, generate a use case description. Develop ‘intermediate’ level descriptions (main flow and exceptions). See text pp for examples. OR you can use an activity diagram instead of each text description – see pages 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 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 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.