Creating a System Design Document for a University Registration System with Agile (UML/OOD) methodology

PROBLEM:

Course Project#1: Agile software development with UML (Unified Modeling Language)

1) I NEED HELP IN CREATING A SYSTEM (ARCHITECTURE) DOCUMENT, TO SOLVE:

**This will translate the SRS Document listed in Posting #256393 into this design document. This will be the technical solution for this project, written from the project's perspective, mainly for the technical people who will be coding and building the system. The design document will include architectural diagram of the project and data models**

1. CASE EXAMPLE: creating an University Registration Information System :

**CASE BACKGROUND**

a.Most schools experience a challenge matching up faculty, courses & classrooms. Some considerations they must keep in mind are making that every courseis offered at least once a year, making certain the right professors are assigned to the right courses, and making certain studetns most in need of courses to graduate get preference. There are many variables to do assignments manually. A simple information system could make this task easy. In addition, by publishing the schedule online, students & professors alike, will know their assignments in advance.

**STATEMENT OF WORK**

a. For a local University design a system that will meet the below requirements:

**SYSTEM REQUIREMENTS**

a. Assign course & professors to classrooms each term
b. Assign students to those course based on priorities given to seniors & those in major tracks
c. Publish class rosters for each classroom
d. Publish a report showing which professors will be assigned where
e. Online Access: Information produced by this system should be accessible online
f. Pre-requisites: Enrollment rights are contingent on completion of course pre-requisites
g. Academic Calendar: The academic calendar starts in the Fall and ends in the Summer
h. Software and Hardware: Evaluate system needs by providing a budget proposal for hardware, software and licensing costs. Such as for server systems, operating systems and software environments. Suggestions: Enterprise x86 Servers with Microsoft Windows 2008 64-bit Operating systems, Multi-Processors, TCP/IP Networking, IIS7 ASP.Net 3.5 web application environment, Microsoft SQL Server with licenses.
i. Browser: should support Microsoft IE6
j. System Resolution: 1024x680 minimum
k. Probation Status: The automatic registration system must ensure students on probation status aren't allowed to enroll in more than 15 credits per term
l. Delinquent Payment: The automatic registration system must not allow enrollment by students with past due course payments
m. Usage Forecast: Worst case: Professors=75, Students=800-1000. Highest system demand (traffic) = 1 week before & 1 week after each semester starts.
n. Administrative Support: The University currently has 11 registration administrators, covering two staggered shifts. Work schedule is Mon - Fri. The system should be available 24/7.
o. Course Cancellation: System should send automatic email notification to Students and Professors when course is cancelled (i.e. less than 10 students)
p. Staffing: The automatic registration system must have a minimum/maximum enrollment requirement: 10 Students minimum, and 25 Students maximum
q. User requirements: each should be assigned a priority level (high/medium/low)

**ASSUMPTIONS**:

a) A DBMS database management system with student, professor, administrator and course information does currently exist.
b) An accounting system with student payment statuses also currently exists.
c) The system design will use existing data where available, but will add database tables for new system functionality as needed.
d) Currently, the university uses a number of offline tools. None of these offline systems communicates with each other, which means the Registration Administrators use multiple MS Excel files to manage the process. Unfortunately, the biggest problem they have with the files includes no centralized storing, multiple data entry errors, and some incomplete files.

2. Just a note, the format that you produce doesn't have to be in a finished state, I'm more concerned about the developed concepts

3. I also have attached various supporting documents from my course to assist you with the different topics I list below. And I can send additional examples of each of the phases I've described below.

2) Then assistance with creating the software concept:

SYSTEM DESIGN (ARCHITECTURE) DOCUMENT:

Should at minimum consist of the following:

1. Introduction (i.e. recap project scope)
a. Purpose

2. Architectural Design
a. Data Design
i. model to be used
ii. data term dictionary
b. Technical Design
i. Hardware design requirements
ii. Network architecture, etc

3. Document Evaluation Criteria

1) REQUIREMENTS STATEMENT
a. Problem Statement/Scope
b. Goal/Objective

1. FUNCTIONAL DECOMPOSITION DIAGRAM

2. DESCRIPTION OF THE FUNCTIONAL ELEMENTS

3. CONTEXT DATA FLOW DIAGRAM (DESCRIBING THE SOFTWARE PROCESS MODELS INTERACTIONS)
a. Level 0
b. Level 1
c. Level 2
d. Level 3

4. REQUIREMENTS MATRIX. (TAKING EACH FUNCTIONAL DECOMPOSITION DOCUMENT ELEMENT AND LISTING ITS ROLL WITHIN THE MATRIX)

5. USAGE SCENARIO (A USAGE SCENARIO FOR THE DESIGNED SOFTWARE, ORGANIZED INTO USE-CASES)
a. User profiles (profiles of all user categories described)
b. Use-Cases (all the use-cases for the software)
c. Business Process Model
d. Work Flow Chart
e. Special requirements associated with the use of the software

6. DATA MODEL AND DESCRIPTION
a. Description of the Data Objects that are managed by the software
b. Data Objects and their major attributes described
c. Data Objects relationships
- Relationships between the data objects in ERD form (no detailed information is needed here)
d. Complete Data Model (in ERD form for the main software)
e. Data dictionary (to maintained in electronic form)

7. FUNCTIONAL MODEL AND DESCRIPTION (A DESCRIPTION OF THE EACH MAJOR SOFTWARE FUNCTIONAL, ALONG WITH DATA FLOW OR CLASS HIERARCHY (OBJECT ORIENTED)
a. Description of each software function in Function n format
i. Processing narrative (PSPEC) for function n. (Processing narrative for function n here)
ii. Function n flow diagram. (A diagram showing the flow of info through the function and the transformation it undergoes)
iii. Function n interface description. (Detailed description of the input and output interfaces for the function is presented.
iv. Function n transforms. (Detailed description for each transform (sub functions) for functions n.)
b. If required, then the same above items for the transform k descriptions
i. Transform k description
ii. Transform k interface description
iii. Transform k lower level flow diagrams
iv. Transform k interface description
c. System performance issues. (Special performance required for the subsystem specified)
d. Software Design Constraints (Any design constraints that will impact the subsystem noted)

8. SOFTWARE INTERFACE DESCRIPTION (SOFTWARE INTERFACE TO THE OUTSIDE WORLD DESCRIBED)
a. External machine interface
- Interfaces to other machines(computer or devices) described
b. External system interfaces
- Interfaces to other systems, products or networks described
c. Human interface
- Overview of any human interfaces to be designed for the software is presented
d. Control flow description
- control flow for the system is presented

9. BEHAVIORAL MODEL AND DESCRIPTION (A DESCRIPTION OF THE BEHAVIOR OF THE SOFTWARE DESCRIBED)
a. Description for software behavior (detailed description of major events described)
b. Events (Listing of events (control, items) that will cause behavioral change within the software system developed)
c. States (listing of states (modes of behavior) that will result as a consequence of events described)
d. State Transition Diagram (depicting the overall behavior of the system)
e. Control Specification (CSPEC). (Depicting the manner in which control is managed by the software)

10. RESTRICTION, LIMITATIONS AND CONSTRAINTS. (SPECIAL ISSUES WHICH IMPACT THE SPECIFICATION, DESIGN OR IMPLEMENTATION OF THE SOFTWARE DESCRIBED)

11. VALIDATION CRITERIA (DESCRIBING THE SOFTWARE VALIDATION PROCESS OR APPROACH)
a. Classes of tests. (types of tests to be conducted specified, focused on black-box testing to be described)
b. Expected software response (expected results from testing described)
c. Performance bounds. (special performance requirements are described)

12. SYSTEM TRACEABILITY MATRIX INFORMATION. (DESCRIPTION OF STATED SOFTWARE REQUIREMENTS BACK TO THE SYSTEM SPECIFICATION)