CIS 591 Systems Analysis Report and Presentation

Dr. John Satzinger

Summer 2010

The systems analysis presentation and report for your system development project is a major
deliverable. The presentation will include background information from the project planning
report, the requirements models developed during analysis, and some design prototypes
completed to date. Expectations for the amount of detail and for the quality of requirements
models are high. Recall that minimum goals for scope are 18 to 20 use cases and 10 to 12
domain classes.

The detail required in the report has been kept to a minimum so you have the time to focus on the
requirements models. Make sure you complete all of the deliverables required. This should not
be a first draft of your event table and diagrams. It should be the final draft. You have had lots of
time to review and inquire about proper naming of events and use cases, for example.

You should have quite a bit of work done by now on the application, implementing key use cases
including user interface and data access for the core functionality. Just because the requirements
report is the deliverable does not mean you have not started design and implementation. Much of
the database could be implemented for example (based on your Domain Model). You should
have answered questions by now about how you will get queries and reports to run. You should
have the key use cases fully implemented. You should have a good idea of the main menu for the
system that organizes the dialogs (based on the use cases detailed below plus controls,
preferences, and help). Just make sure your design and implementation is based on your
requirements models.

The report is due the first day of presentations. Attendance at all presentations is required. The
presentation and report are worth 25 points. Points will be awarded based on completeness,
internal consistency, and overall quality.

Presentation

The presentation should be supported by power point slides. You must turn in copies of your
slides/overheads before your presentation begins. The presentation should last about 10 to 12
minutes. It should cover the following topics.

1. Brief System Background (from Planning Report). Make sure the audience understands what
the system is used for.

2. Feasibility Study (from Planning Report). Give a brief overview of each type of feasibility,
emphasizing the benefits and costs.

3. Requirements Models (from Analysis Report below). Although you have completed all
detailed models for the report, show just some of them in the presentation. Include a clear
discussion of the actors and use cases. Show some use case diagrams discussing how they are

1
based on the event table and walk us through a key use case description. Show and discuss the
domain model class diagram. Please don't rush here.

4. Prototypes. Show some prototypes, including screen designs and report designs. Include the
menu hierarchy design. Show how the prototypes are related to specific events in the event table.
(Do not attempt to run the code for the prototype; show the details from the report as we will be
short on time).

5. Application Architecture. Describe the technology and the working environment you are
actually using. What is your design for the application architecture (Three layer? Two layer?).
Your approach to designing each layer (OO? or procedural code module?). Show a detailed
structure chart or sequence diagram for one use case to illustrate the design approach you are
using. Do your best to represent the design based on the development environment you are using.

Report

Although your presentation will cover background information and feasibility, the report only
needs to focus on the requirements, alternative design concepts, prototypes, and design and
implementation to date. Include a cover page with you name and project name. Use section
headings as follows.

System Requirements Models (OO/UML Approach)

1. Brief overview of system scope (based on use cases (from event table) and domain model
class diagram).

2. Event Table – see chapter 5

3. Use Case Diagrams (several versions, by subsystem or by actor as most appropriate for your
system)

4. Domain Model Class Diagram (with attributes listed and including associations and
multiplicity)

5. Use Case Descriptions (fully described for at least half of them, brief for other simple ones)

6. System Sequence Diagrams (SSDs) (one for each of the use cases with fully described use
case descriptions)

7. Attribute Definitions (all) (name, meaning, data type, validation rules if any)

Alternative Design Concepts and Recommendation

1. Discuss how alternatives could be defined specifically for your system by a) varying the scope
of the system b) by varying the degree of automation c) varying the type of technology used and
d) varying the approach to implementation

2
2. Based on the full range of possibilities discussed above, define four (4) concrete alternatives
that would be feasible for your project

3. Recommend your selected design alternative and discuss your reasoning.

Design and Implementation to Date

You should have completed some prototyping, in this case probably to test the technology you
are planning to use (prototyping for feasibility) as well as initial design ideas (prototyping for
design details). You should also have completed the core functionality of your system.

1. Describe the technology and the working environment you are actually using. What is your
design for the application architecture (Three layer? Two layer?). Your approach to designing
each layer (OO? or procedural code module?). Show a structure chart or sequence diagram for
one use case to illustrate the design approach you are using. Include all layers.

2. What exactly have you implemented to date? List the activities/use cases that are
implemented and tested. Be specific. Include an example showing one use case implemented that
represents the core architecture as you intend to have the final application handle application
architecture and database interaction. Starting with the complete main menu, show screen prints
of the example running with the database working (show a series of screen prints making up a
dialog between user and system much like the storyboard in figure 11-9 page 461). Include the
source code and the database schema. Include a printout of the test data in the table(s).

3. Show the initial menu hierarchy for the system (based on event table plus system controls,
preferences, and help). See A&D text figure 11-8 page 458.

4. Show at least two reports produced by the system (can be a mockup or real). This should
match reports that are responses on the event table. Put some effort here as indicated on the first
day of class.

Project Monitoring/Reporting To Date

Update your hours worked by task per week based on the list of activities/tasks developed for the
planning report. Remember that you are using an iterative approach to the project, so you should
report time spent on all activities and tasks of all disciplines. You should have a worksheet
(Excel) with Disciplines, Activities, and Tasks and a column for each week of the project.
Update this worksheet each week. You will also turn it in when the project is complete.

Copyright © 2009 by J. W. Satzinger. All Rights Reserved.