Junior Project I  
line decor
  HOME  ::  
line decor
large product photo

Systems Analysist

Business Case - Refined:

The business case is an argumentative document encompassing reasons in support of developing the system on which you are working. "Because I want a passing grade...", is not reason enough to build these systems. Your business case needs to contain:

  1. System Description - Generally what is the system you are proposing. What does it do? Why does it do this?
  2. Market Sector - Where in the world does your system fit in? Who would use your system? What would drive the users of your system (motivation)?
  3. Competing System Survey - What are the other systems on the current market you would consider competition? What do these systems do? What do these systems cost? What is good about each of these systems? What is bad about each of these systems? What will you use from each of these systems? How will your system improve on each of these systems?
  4. Cost analysis - How much will your system cost to develop (in man hours)? How much will your system cost to maintain?
  5. Final Argument - Summarize the benefits your system will impart to society and how this is far better than existing systems on the market.

You must provide good sources as references. You must include doucment annotation in a standard format for support of statements.

Evaluation will be based on:

  • Document Structure
  • System Description
  • Market Sector Narrative
  • Competing System Survey
  • Cost/Benefit Analysis
  • Closing Argument
  • Reference and Source Documentation
usecase eating the secondary actor


Use Case Specifications - High and Mid Priority:

Each use case in your system will have a specification. You must use a common template for each of your use case specifications. Each use specification must contain:

  1. Use Case Name
  2. Use Case Description
  3. Involved Actors
  4. Requirements Trace
  5. Preconditions
  6. Post conditions
  7. Invariant
  8. Event Flows
    1. Primary Event Flow
    2. Alternate Event Flows (if any)
  9. Scenarios
    1. Happy Day
      1. Assumptions
      2. Event Flow
    2. Rainy Day
      1. Assumptions
      2. Event Flow


large product photo


Use Case Architecture:

Use case architecture is similar to the functional architecture. Use case architecture is a package model containing package names and package dependencies. The package names initially derive from the functional architecture; however, they may change to better reflect re factoring decisions made in use case analysis. This deliverable shall contain a diagram created in a diagram or modeling tool and a document describing:

  1. Package names - Define the package names. What types of functional requirement will the group encompass.
  2. Dependency Defense - For each dependency, describe why the dependency exists.


Use Case Model:

Your use case model will show the interaction between actors and use cases. The use case model elements must have Each use case defined by your use case specifications must be modeled:

  1. Actor Model - Show hierarchy of actors in your system..
  2. Architecture Model - See above..
  3. For each package - At least one use case model showing actor and use case dependencies..
  4. For each model element - Notes describing the element assigned to the model element.

Use Case Refined Class Model (75 WP):

As you create use cases, begin to add classes to a logical model in your system. Your initial class model should contain at least a three tired architecture with classes resident in the correct packages.





Software Requirements Specification Challenge:

In this challenge, you will be going up against the "Specification Flemeth", Professor Linda Young. Here you will create a complete unified specification for your system. The specification must comply to any and all documentation requirements Specification Fleleth places upon you. The SRS must contain good technical references, appropriate reference citations, and supporting figures.

The initial list of specification elements will include:

  • Introduction
  • Overall Description
    • Business Case
    • Assumptions and Dependencies
  • Requirements Overview
    • Functional Requirements
    • Non Functional Requirements
  • Use Case Model Survey
  • Architecture Descriptions
    • Functional Architecture
    • Use Case Architecture
    • Logical Architecture
    • Component Architecture
    • Physical Architecture

Once you engage Flemeth, you will have four days to complete the task to the standards set. After four days, Flemeth gets angry and may turn you into a toad. This will require you to hop back to the village and find additional documentation related potions to purchase. You will most likely need to find a wizard to help for completion of this task.

As this challenge task gets older, the list of required elements will grow longer. Only the long list of topics in the realm of Specification Flemeth will determine the necessary end of what must be done.

SRS Template

large product photo

Bi-Weekly Status Reports:

Each status report must contain:

  • Tasks performed during the previous week.
  • Problems encountered..
  • Proposed problem solutions.
  • Tasks scheduled for the next week along with responsible parties.

Bi-Weekly Gantt Chart Update:

Each time you submit a status report, submit an updated Gantt chart to reflect your new time line based on the work that has been completed. Begin this submission after you have created an initial Gantt chart.

Technology Demonstrations:

Research some technology required of your project. Demonstrate how the technology works by building a small prototype and showing it. Specifically describe how the technology will be used in your project and demonstrate this use.

Anything else you would like to do.......just ask!