$$ Phase $1$ Rubric

Each phase is graded over a series of categories. You will be judged on a scale of $1-4$ for

each criterion, where a $1$ corresponds to a $60\%,$ a $2$ corresponds to $75\%,$ a $3$ corresponds to

$90\%,$ and a $4$ corresponds to $100\%.$ If there is no work for a criterion or it is clear that even a

minimal amount of effort was not put in$,$ you will receive a $0\%$ for that section of the assignment.

Organization $(25)$

$4$ Have a good organization including a logical layout, requirements grouped

by similarity, all sections present, requirements formatted to be easily understood,

uses good grammar, and has a single voice. No irrelevant data $($i$.$e$.,$ made up

$$satisfaction numbers$).$

$3$ Most sections present, layout mostly logical$,$ and requirements are

easily understood. Lacks single voice and has some grammar issues.

$2$ Missing some sections, illogical layout, and requirements are hard to understand.

Lacks a single voice, many grammar issues.

$1$ Missing major sections, layout illogical, and requirements are not readable. Hard to

read and understand.

Use Cases $(35)$

$4$ Captures core usage scenarios of the system. Present and well formatted diagram.

Descriptions are clear. Actors are clear and correct both in diagram and document.

$3$ Some mistakes in UC diagram or descriptions. Missing descriptions

or actors incorrect. Internal activities discussed in description.

$2$ UC is unclear and incorrect in several areas.

$1$ UC mostly incorrect.

Context$-$Level Data Flow Diagram $(10)$

$4$ Captures the system as one process and key entities that will interact with it$.$

$3$ Minor errors in data flow.

$2$ Too many processes or incorrect entities.

$1$ Mostly incorrect.

Context$-$Level Entity Relationship Model $(30)$

$4$ Captures core entities in a well$-$formed diagram.

$3$ Most entities captured, or minor errors in relationships.

$2$ Missing major entities.

$1$ Mostly incorrect.

CPS $310$ Systems Analysis Document Structure

You should organize the document to fit the needs of your project and organization, the following

suggestion is based on the IEEE recommendations for software engineering requirements

documentation.

You are free to customize these templates for the needs of your project. Do NOT include

a section $($or a field in a requirement$)$ if it is not necessary $($or you do not have the right

information to complete it do not make up values$).$

$1.$ Introduction

a$.$ Purpose

i$.$ Summarize the project, including a short description of the purpose of the

system being built.

b$.$ Scope

i$.$ A clear description of what portions of this project that this document is

intended to cover.

c$.$ Definitions & Acronyms

i$.$ Define any terms used in the document that may not be obvious to the reader.

d$.$ References

i$.$ Any documents referred to in the creation of this systems analysis.

e$.$ Overview

i$.$ A short description of the rest of the document, detailing what each section

covers and where information may be found.

$2.$ Overall Description

a$.$ Product Perspective

i$.$ An overview of the environment that this system must operate within,

including other software and hardware systems that will interface with this

system.

b$.$ Product Functions

i$.$ An overview of the features to be provided by the software.

c$.$ User Characteristics

i$.$ Description of the types of users that will interact with this software and

assumed properties of those users.

d$.$ Constraints

i$.$ Any constraints that have been placed on the project $($that are not, in

themselves, requirements$)$

e$.$ Assumptions

i$.$ Any assumptions that are being made in specifying these requirements.

$3.$ Systems Analysis

a$.$ Context level data flow diagram

b$.$ Context level entity relationship diagram

c$.$ Use Cases

i$.$ Scenarios

ii$.$ Diagram$($s