Operational Concept Description _OCD_

Document Sample
Operational Concept Description _OCD_ Powered By Docstoc
					System and Software Architecture
     Description (SSAD)

            Personnel Records Management System




                           Team 6




Anandi Hira – Life Cycle Planner, Operational Concept Engineer
                Allen Kou – Software Architect
          Jabari Pulliam – IIV&V, Project Manager
    Tim Wahmhoff – Requirements Engineer, Prototyper




                                                       February 23rd, 2011
System and Software Architecture Description (SSAD) for Architected Agile                  Version 4.0


Version History
Date       Author     Version   Changes made                                 Rationale

10/03/10   AK         1.0        Original template for use with              Initial draft for use with Instructional
                                  Instructional ICM-Sw v1.0                    ICM-Sw v1.0
10/04/10   AK         1.1        Updated Use Case Tables                     To Be consistent with updated SSRD
10/10/10   AK         1.2        Updated all Diagrams                        System context and use case
                                 Fixed some formatting issues.                diagrams were modified to accurately
                                                                               reflect business model. Also
                                                                               changed the diagrams to RSM
                                                                               diagrams.
10/12/10   AK         1.3        Simplified the System Context Diagram       Updates to diagrams and tables are
                                  by removing unnecessary actors               based on input from UML model
                                 Updated Use Case Diagram to be               review in class and LADoT input.
                                  consistent with the new System Context      Completed Section 2 for FCP
                                  Diagram and User Roles document
                                 Redid Artifacts & Information Diagram
                                 Updated corresponding tables for each
                                  updated diagram
                                 Added Section 2.1.4
                                 Added Section 2.2
10/15/10   AK         1.4        Modified Artifacts & Information            Made changes based on TA and
                                  Diagram                                      client input. Added some attributes
                                                                               to the artifacts.
10/21/10   AK         1.5        Modified Artifacts & Information            Made changes based on TA feedback
                                  Diagram and System Context Diagram           from ARB session
11/03/10   AK         1.6        Updated all instances of “LDAP” to          LADoT has informed the team that
                                  “AD”                                         they will be migrating their LDAP
                                                                               systems to Active Directory.
11/07/10   AK         1.7        Added “User” to use case and system         Updated the diagrams based on
                                  context diagrams                             IIV&V and TA feedback
                                 Added missing artifacts to artifact and     Made some minor changes based on
                                  information diagram                          IIV&V feedback
                                 Removed reset password use case
                                 Made several minor changes according
                                  to bug reports
11/19/10   AK         2.0        Added Technology Dependent Model            Part of draft Development
                                  (Section 4)                                  Commitment Package.
                                 Added Architectural Styles, Patterns,
                                  and Frameworks (Section 5)
11/22/10   AK         2.1        Added a missing use case                    Made changes based on information
                                 Modified relationships in class diagrams     from the in class architecture
                                                                               workshop




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc        ii                              Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                 Version 4.0

Date       Author     Version   Changes made                                 Rationale

12/6/10    AK         2.2        Modified relationships in class diagrams    There were some incorrect
                                 Changed formatting and layout of class       bidirectional association relationships
                                  diagrams and sequence diagrams              Some diagrams were difficult to read
                                 Specify the architecture is a three-tier     due to the size
                                  architecture instead of Model-View-         Avoid ambiguity when talking about
                                  Controller                                   records
                                 Replaced references to folders with         Added attributes and replaced MVC
                                  records                                      with three tier architecture based on
                                 Added attributes to some classes in the      feedback at ARB
                                  class diagrams
                                 Noted that the client may not use Active
                                  Directory in which case our system will
                                  be responsible for authentication
                                 Noted that LADoT is in the process of
                                  deciding which company to select for
                                  scanning records. Therefore, details
                                  about record upload and format are
                                  currently unclear.
2/9/11     AK         3.0        Updated all class diagrams                  Updated diagrams to reflect use of
                                 Updated software component class             ASP.NET form validation,
                                  diagram                                      authentication, authorization,
                                                                               database access, and SMTP
                                 Updated Artifact and Information class       functionality.
                                  diagram
                                                                              Added PdfSharp to software
                                 Updated deployment diagram                   component class diagram
                                 Updated sequence diagrams                   Added missing operations and
                                                                               attributes to class diagrams
2/12/11    AK         3.1        Added cases where user does not have        Using MVC 3 and .NET 4 now
                                  permission to sequence diagrams              instead of MVC 2 and .NET 3
                                 Slight modification to class diagrams       Minor changes based on TA / peer
                                 Specify using MVC 3 and .NET 4               review suggestions
2/23/11    AK         4.0        Added NHibernate interfaces and             Team decided to use LINQ and
                                  classes for database access to the class     NHibernate for database access
                                  diagrams.                                   Split the employee model because in
                                 Updated Artifact and Information             some cases not all users will be
                                  Diagram                                      employees
                                 Added employee controller                   Each workflow will have multiple
                                 Split employee model into user model         actions, so dividing the workflow
                                  and employee model                           controller into multiple controllers
                                                                               will make the code more clear.
                                 Divided the workflow controller to
                                  controllers for each workflow




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc iii                                    Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                                                   Version 4.0



Table of Contents
System and Software Architecture Description (SSAD) ............................................................ i
Version History ............................................................................................................................. ii
Table of Contents ......................................................................................................................... iv
Table of Tables .............................................................................................................................. v
Table of Figures.......................................................................................................................... viii
1. Introduction ............................................................................................................................. 1
     1.1       Purpose of the SSAD .................................................................................................... 1
     1.2       Status of the SSAD ....................................................................................................... 1
2. System Analysis ....................................................................................................................... 2
     2.1       System Analysis Overview ........................................................................................... 2
     2.2       System Analysis Rationale ......................................................................................... 30
3. Technology-Independent Model ...........................................Error! Bookmark not defined.31
     3.1       Design Overview ..........................................................Error! Bookmark not defined.31
     3.2       Design Rationale ..........................................................Error! Bookmark not defined.33
4. Technology-Specific System Design ...................................................................................... 31
     4.2       Design Rationale ......................................................................................................... 45
5. Architectural Styles, Patterns and Frameworks .................................................................. 47




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc iii                                                                   Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                                                           Version 4.0


Table of Tables
Table 1: Actors Summary................................................................................................................ 4
Table 2: Artifacts and Information Summary ................................................................................. 6
Table 3: Process Description – Submit Leave of Absence Form.................................................... 9
Table 4: Typical Course of Action – Submit Leave of Absence Form ............................................ 9
Table 5: Alternate Course of Action – Submit Leave of Absence Form: Incomplete ..................... 9
Table 6: Process Description – Submit Auto Accident Form (Form 88) ..................................... 10
Table 7: Typical Course of Action – Submit Auto Accident Form (Form 88) .............................. 10
Table 8: Alternate Course of Action – Submit Auto Accident Form (Form 88): Incomplete ....... 10
Table 9: Process Description – Run Service Pin Report .............................................................. 11
Table 10: Typical Course of Action – Submit Run Service Pin Report ........................................ 11
Table 9: Process Description – Professional License Reimbursement Form .............................. 11
Table 10: Typical Course of Action – Professional License Reimbursement Form ..................... 12
Table 11: Alternate Course of Action – Professional License Reimbursement Form: Incomplete
....................................................................................................................................................... 12
Table 15: Process Description – Temp Bonus Form .................................................................... 12
Table 16: Typical Course of Action – Temp Bonus Form ............................................................ 13
Table 14: Process Description – Upload Scanned Documents .................................................... 13
Table 15: Typical Course of Action – Upload Scanned Documents: Valid Formats ................... 13
Table 16: Alternate Course of Action – Upload Scanned Documents: Invalid Formats ............. 13
Table 17: Process Description – Approve or Reject Requests ..................................................... 14
Table 18: Typical Course of Action – Approve or Reject Requests: Approved ............................ 14
Table 19: Alternate Course of Action – Approve or Reject Requests: Rejected ........................... 14
Table 20: Process Description – Mark Report as Completed ...................................................... 14
Table 21: Typical Course of Action – Mark Reports as Completed ............................................. 15
Table 15: Process Description – Login ........................................................................................ 15
Table 16: Typical Course of Action – Login: Successful.............................................................. 16
Table 17: Alternate Course of Action – Login: Failure ............................................................... 16
Table 18: Exceptional Course of Action– Login: Three Consecutive Login Failures ................. 16
Table 19: Process Description – Logout ...................................................................................... 16
Table 20: Typical Course of Action – Logout............................................................................... 17
af7da39e-e14a-4a4a-a9b7-f4460a925096.doc                                    v                                          Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                                 Version 4.0

Table 21: Exceptional Course of Action – Session expires .......................................................... 17
Table 22: Process Description – View Employee Record ............................................................ 17
Table 23: Typical Course of Action – View Employee Record: Successful .................................. 17
Table 24: Alternate Course of Action – View Employee Record: Unsuccessful .......................... 18
Table 34: Process Description – View Confidential Record ........................................................ 18
Table 35: Typical Course of Action – View Confidential Record: Successful ............................. 18
Table 27: Process Description – Print Employee Record ............................................................ 18
Table 28: Typical Course of Action – Print Employee Record .................................................... 19
Table 38: Process Description – Print Confidential Record ........................................................ 19
Table 39: Typical Course of Action – Print Confidential Record ................................................ 19
Table 29: Process Description – Print Records ........................................................................... 20
Table 31: Typical Course of Action – Print Records: Confirm Yes ............................................. 20
Table 32: Alternative Course of Action – Print Records: Confirm No......................................... 20
Table 25: Process Description – Search for Record .................................................................... 21
Table 26: Typical Course of Action – Search for Record ............................................................. 21
Table 27: Process Description – Edit a “Pending” Record......................................................... 21
Table 28: Typical Course of Action – – Edit a “Pending” Record .............................................. 22
Table 29: Process Description – Delete Records ......................................................................... 22
Table 30: Typical Course of Action – Delete Records: Confirm Yes ........................................... 22
Table 31: Alternate Course of Action – Delete Records: Confirm No ......................................... 23
Table 29: Process Description – Transfer Employee Record ...................................................... 23
Table 30: Typical Course of Action – Transfer record to Confidential Records ......................... 23
Table 31: Alternate Course of Action – Transfer record to Employee records............................ 24
Table 35: Process Description – Archive Records ....................................................................... 24
Table 36: Typical Course of Action – Archive Records: Confirm Yes ......................................... 24
Table 37: Alternate Course of Action – Archive Records: Confirm No ....................................... 25
Table 38: Process Description – Activate Records ...................................................................... 25
Table 39: Typical Course of Action – Activate Records: Confirm Yes......................................... 25
Table 40: Alternate Course of Action – Activate Records: Confirm No....................................... 26
Table 41: Process Description – Set Deletion Date for Archived Record ................................... 26
Table 42: Typical Course of Action – Set Deletion Date for Archived Record: Valid Date ........ 26
Table 43: Alternate Course of Action – Set Deletion Date for Archived Record: Invalid Date... 27
af7da39e-e14a-4a4a-a9b7-f4460a925096.doc iii                                                   Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                                       Version 4.0

Table 51: Process Description – Add New Employee .................................................................. 27
Table 52: Typical Course of Action – Add New Employee - Valid ............................................... 27
Table 53: Alternate Course of Action – Add New Employee - Invalid ......................................... 28
Table 54: Process Description – Create Special User ................................................................. 28
Table 55: Typical Course of Action – Create Special User - Valid.............................................. 28
Table 56: Alternate Course of Action – Create Special User - Invalid ........................................ 28
Table 68: Process Description – Edit User Settings .................................................................... 29
Table 69: Typical Course of Action – Set User Roles .................................................................. 29
Table 70: Process Description – Set User Roles .......................................................................... 29
Table 71: Typical Course of Action – Set User Roles .................................................................. 30
Table 7: Hardware Component Description ...............................Error! Bookmark not defined.31
Table 8: Software Component Description..................................Error! Bookmark not defined.32
Table 9: Supporting Software Component Description ...............Error! Bookmark not defined.32
Table 10: Design Class Description ............................................Error! Bookmark not defined.32
Table 11: Hardware Component Description .............................................................................. 33
Table 12: Software Component Description................................................................................. 33
Table 14: Interface Class Description .......................................................................................... 35
Table 77: Records Management Class Description ..................................................................... 38
Table 78: Workflow Management Class Description ................................................................... 40
Table 79: User Application Class Description ............................................................................. 42
Table 15: Architectural Styles, Patterns, and Frameworks .......................................................... 47




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc iii                                                         Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                                            Version 4.0



Table of Figures
Figure 1: System Context Diagram ................................................................................................ 3
Figure 2: Artifacts and Information Diagram ................................................................................ 6
Figure 3: Process Diagram ............................................................................................................ 7
Figure 4: Hardware Component Class Diagram ........................Error! Bookmark not defined.31
Figure 5: Software Component Class Diagram ..........................Error! Bookmark not defined.31
Figure 6: Deployment Diagram...................................................Error! Bookmark not defined.31
Figure 7: Supporting Software Component Class Diagram........Error! Bookmark not defined.31
Figure 8: Design Class Diagram .................................................Error! Bookmark not defined.32
Figure 9: Process Realization Diagram ......................................Error! Bookmark not defined.33
Figure 10: Hardware Component Class Diagram ....................................................................... 31
Figure 11: Software Component Class Diagram ......................................................................... 32
Figure 12: Deployment Diagram.................................................................................................. 33
Figure 14: Interface Class Diagram............................................................................................. 35
Figure 15: Process Realization Diagram ..................................................................................... 44




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc iii                                                             Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile          Version 4.0


1. Introduction


1.1 Purpose of the SSAD
The purpose of the SSAD is to document the results of the analysis and design of the Personnel
Record Management System. The developers use the SSAD as a reference to the system’s
architecture. Therefore, the system should be faithful to the architecture. The SSAD is also used
by maintainers and clients to understand the structure and design of the system once the system
is delivered.


1.2 Status of the SSAD
The current version of the SSAD is version 4.0 and is part of the Rebaselined Development
Commitment Package (DCP). The document provides an overview of the system, describes the
system context, describes artifacts and information created by the system, and describes the
behavior of the system.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc       1                        Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile        Version 4.0


2. System Analysis

2.1 System Analysis Overview

The primary purpose of the Personnel Records Management System is to manage Los Angeles
Department of Transportation (LADoT) personnel records. The system will store digital copies
of each employee’s personnel records and confidential records. Documents can be added to an
employee’s records by uploading a scanned version of the document or by filling out a digital
version of the document. Email notifications will be sent to alert employees what forms need to
be completed or uploaded. Due to the sensitive nature of each employee’s records, the system
will provide secure and limited access the records.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc      2                        Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile      Version 4.0


2.1.1 System Context

Figure 1 shows the operation context of the Personnel Records Management System.




                            Figure 1: System Context Diagram

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc     3                       Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile          Version 4.0



Table 1: Actors Summary describes the actors and their responsibilities related to the system.
Note: Power users are named in the description of the actors summary. However, “power user” is
the terminology LADoT specified as the actors of the system.

                                  Table 1: Actors Summary

     Actor                    Description                         Responsibilities
 Administrator       The administrators for the          Specify deletion of employee
                     system are the IT staff and          records
                     personnel records supervisor.       Create new special users
                     Administrators have complete
                     access to the system.
 Power User 1        Personnel records staff that        Submit, view, edit, update, archive,
                     are responsible for managing         and transfer employee records
                     the personnel records.              Submit, view, and edit confidential
                                                          records
                                                         Submit and edit reports
                                                         Submit and edit requests

 Power User 2        Assistant Personnel Director        Authorize approvals for requests
                     and Personnel Director. They
                     can authorize all necessary
                     approvals at all levels.
 Power User 3        Personnel Analyst that has          View and verify requests
                     viewing access to all records.      Recommend approval or denial of
                                                          Temp Bonus

 Supervisor          Supervisor has access to            Edit a Leave of Absence request
                     approve subordinate                 Approve Leave of Absence request
                     employee requests.                  Approve Temp Bonus request
                                                         Submit F88 (Auto Accident Report)

 Employee            LADoT employee with                 Submit Leave of Absence request
                     limited access to the system.       Submit Temp Bonus request
                                                         Submit Professional License
                                                          Reimbursement request

 Payroll Employee    Payroll employees have              View approved Temp Bonus report
                     limited viewing access to           Print Temp Bonus report
                     employee records.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc         4                      Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile          Version 4.0


      Actor                    Description                         Responsibilities
 Accounting           Accounting Employees have           View approved Professional
 Employee             limited viewing access to            License Reimbursement report
                      employee records.                   Print approved Professional License
                                                           Reimbursement report

 Viewer               Employees and non-LADoT             View an employee’s records
                      employees (employees from
                      different departments) must
                      access the system through a
                      kiosk provided by the
                      personnel records staff to
                      view personnel records.
 User                 Every person with access to         Login
                      the system is a user that can       Logout
                      login and logout of the system
 Active Directory     LADoT Active Directory              Authenticate users during login so
 Server               authentication server                our system does not need to have its
                                                           own user tables for login



2.1.2 Artifacts & Information
This section of the document describes the artifacts and information created by the system.
Artifacts can be used by the user or the system to produce other artifacts. The artifacts for the
Personnel Records Management are presented in the diagram and table below.

Note: There are many artifacts (records) that will be scanned and uploaded to the system which
have been omitted because they are not part of the main workflows and listing them all would be
redundant.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc       5                        Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile          Version 4.0




                           Figure 2: Artifacts and Information Diagram

Table 2 contains a description of each artifact shown in Figure 2.

                           Table 2: Artifacts and Information Summary

          Artifact                                          Purpose
 ATF-1: Leave of Absence         Contains leave of absence information, which will be verified
 Form                            and approved by supervisors.

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc        6                        Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile        Version 4.0


 ATF-2: Leave of Absence       Contains all leave of absence information for an employee.
 Report                        Stored in personnel records.
 ATF-3: Professional           Contains information required to receive reimbursement for
 License Reimbursement         professional license fees.
 Form
 ATF-4: Temp Bonus Form        Contains information to submit a temp bonus request.
 ATF-5: Auto Accident Form     Contains information for an employee to fill out when he or
 (F88)                         she is involved in an accident involving a LADoT vehicle.
 ATF-6: Auto Accident          Contains information about an accident to a LADoT vehicle.
 Report                        Stored in personnel records.
 ATF-7: Employee Profile       Contains information about the employee.
 ATF-8: Service Pin            Award for an employee after X years of service at LADoT.
                               Stored in personnel records.
 ATF-9: Record                 Contains various scanned documents including forms,
                               approvals, recommendations, photos, etc.
 ATF-10: User                  Contains registration and login information.
 ATF-11: Permission            Represents specific permissions that users have.


2.1.3 Behavior
The two use case diagrams below show the use cases that were identified when analyzing the
capabilities in the Operational Concept Description.




                                 Figure 3: Process Diagram




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc      7                       Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile      Version 4.0




                                Figure 4: Process Diagram


af7da39e-e14a-4a4a-a9b7-f4460a925096.doc     8                       Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                    Version 4.0



2.1.3.1 Business Workflow
2 . 1 . 3 . 1 . 1 S u b m i t L e a v e o f Ab s e n c e F o r m

                    Table 3: Process Description – Submit Leave of Absence Form

      Identifier             UC-1: Submit Leave of Absence Form
      Purpose                Allow employees to digitally submit a Leave of Absence request
                             so that employees do not have to submit paper documents and the
                             personnel department does not have to maintain the paper
                             documents.
      Requirements           CR-16, CR-21, CR-22
      Development             None
      Risks
      Pre-conditions            User is an employee
                                User is logged into the system.
                                Database is initialized
      Post-conditions           Leave of Absence status is “pending”.
                                Leave of Absence Form is stored in the database.


                 Table 4: Typical Course of Action – Submit Leave of Absence Form

          Seq#                Actor’s Action                           System’s Response
      1            Fill in all required fields
      2            Click “Submit”
      3                                                      Check form for completeness and valid
                                                             information
      4                                                      Display a message to indicate the form
                                                             has been submitted
      5                                                      Send email notification to alert
                                                             personnel stating action needs to be
                                                             taken in the workflow.

           Table 5: Alternate Course of Action – Submit Leave of Absence Form: Incomplete

          Seq#               Actor’s Action                            System’s Response
      1            Fail to fill in all required fields
      2            Click “Submit”
      3                                                      Check form for completeness and valid
                                                             information
      4                                                      Reload the form page and indicate
                                                             which required fields were not correctly


af7da39e-e14a-4a4a-a9b7-f4460a925096.doc                 9                        Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                Version 4.0


                                                          completed

2 . 1 . 3 . 1 . 2 S u b m i t Au t o Ac c i d e n t F o r m ( F o r m 8 8 )

                   Table 6: Process Description – Submit Auto Accident Form (Form 88)

      Identifier              UC-2: Submit Auto Accident Form (Form 88)
      Purpose                 Allow employees to digitally submit an Auto Accident Form
                              (Form 88) so that employees do not have to submit paper
                              documents and the personnel department does not have to
                              maintain the paper documents.
      Requirements            CR-19, CR-21, CR-22
      Development              None
      Risks
      Pre-conditions             User is an employee
                                 User is logged into the system.
                                 Database is initialized
      Post-conditions            Auto Accident Form status is “pending”.
                                 Auto Accident Form is stored in the database.


                 Table 7: Typical Course of Action – Submit Auto Accident Form (Form 88)

          Seq#                 Actor’s Action                       System’s Response
      1             Fill in all required fields
      2             Click “Submit”
      3                                                   Check form for completeness
      4                                                   Display a message to indicate the form
                                                          has been submitted
      5                                                   Send email notification to alert
                                                          personnel action needs to be taken in
                                                          the workflow.

     Table 8: Alternate Course of Action – Submit Auto Accident Form (Form 88): Incomplete

          Seq#                Actor’s Action                        System’s Response
      1             Fail to fill in all required fields
      2             Click “Submit”
      3                                                   Check form for completeness
      4                                                   Reload the form page and indicate
                                                          which required fields were not
                                                          completed




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 10                                    Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile               Version 4.0


2.1.3.1.3 Run Service Pin Report

                        Table 9: Process Description – Run Service Pin Report

     Identifier             UC-3: Run Service Pin Report
     Purpose                Allow personnel records staff and administrators to generate a
                            service pin report.
     Requirements           CR-20
     Development             None
     Risks
     Pre-conditions            User is logged into the system as personnel records staff or as
                                an administrator
     Post-conditions           Service Pin Report for the selected employee is stored in the
                                system.
                               Email notification is sent to the employee.


                Table 10: Typical Course of Action – Submit Run Service Pin Report

         Seq#                Actor’s Action                      System’s Response
     1            Fill in all required fields
     2            Click “Submit”
     3                                                Generate service pin report.
     4                                                Store service pin report in database.
     5                                                Send email notification to the employee
                                                      regarding service pin report.



2.1.3.1.4 Submit Professional License Reimbursement Form

            Table 11: Process Description – Professional License Reimbursement Form

     Identifier             UC-4: Submit Professional License Reimbursement Form
     Purpose                Allow employees to digitally submit a Professional License
                            Reimbursement Form so that employees do not have to submit
                            paper documents and the personnel department does not have to
                            maintain the paper documents.
     Requirements           CR-18, CR-21, CR-22
     Development             None
     Risks
     Pre-conditions            User is an employee
                               User is logged into the system.
                               Database is initialized
     Post-conditions           Professional License Reimbursement Form status is

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 11                                 Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile              Version 4.0


                                “pending”.
                               Professional License Reimbursement Form is stored in the
                                database.


          Table 12: Typical Course of Action – Professional License Reimbursement Form

         Seq#                Actor’s Action                      System’s Response
     1            Fill in all required fields
     2            Click “Submit”
     3                                                  Check form for completeness
     4                                                  Display a message to indicate the form
                                                        has been submitted
     5                                                  Send email notification to alert
                                                        personnel action needs to be taken in
                                                        the workflow.

 Table 13: Alternate Course of Action – Professional License Reimbursement Form: Incomplete

         Seq#               Actor’s Action                       System’s Response
     1            Fail to fill in all required fields
     2            Click “Submit”
     3                                                  Check form for completeness
     4                                                  Reload the form page and indicate
                                                        which required fields were not
                                                        completed



2.1.3.1.5 Submit Temp Bonus Form

                          Table 14: Process Description – Temp Bonus Form

     Identifier             UC-5: Submit Temp Bonus Form
     Purpose                Allow employees to digitally submit a Temp Bonus Form so that
                            employees do not have to submit paper documents and the
                            personnel department does not have to maintain the paper
                            documents.
     Requirements           CR-17, CR-21, CR-22
     Development             None
     Risks
     Pre-conditions            User is an employee
                               User is logged into the system.
                               Database is initialized
     Post-conditions           Temp Bonus Form status is “pending”.
                               Temp Bonus Form is stored in the database.
af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 12                                  Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile            Version 4.0




                      Table 15: Typical Course of Action – Temp Bonus Form

         Seq#               Actor’s Action                     System’s Response
     1           Fill in all required fields
     2           Click “Submit”
     3                                               Check form for completeness
     4                                               Display a message to indicate the form
                                                     has been submitted
     5                                               Send email notification to alert
                                                     personnel action needs to be taken in
                                                     the workflow.

2.1.3.1.6 Upload Scanned Documents

                    Table 16: Process Description – Upload Scanned Documents

     Identifier            UC-6: Upload Scanned Documents
     Purpose               Allow employees to upload scanned documents.
     Requirements          CR-3, CR-4
     Development            None
     Risks
     Pre-conditions           User is logged into the system
                              User has access to upload a document
     Post-conditions          Images are saved on the file server and referenced by the
                               database


          Table 17: Typical Course of Action – Upload Scanned Documents: Valid Formats

         Seq#              Actor’s Action                      System’s Response
     1           Fill in required fields.
     2           Select files to upload.
     3                                               Check the formats – valid formats.
     4                                               Store scanned documents on the file
                                                     server and store references on the
                                                     database.
     5                                               Notify the user that the documents have
                                                     been uploaded.

         Table 18: Alternate Course of Action – Upload Scanned Documents: Invalid Formats

         Seq#              Actor’s Action                      System’s Response
     1           Fill in required fields.

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 13                                Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                   Version 4.0


      2            Select files to upload.
      3                                                    Check the formats – invalid formats.
      4                                                    Notify the user the documents have
                                                           invalid file formats.
      5                                                    Redirect user to upload page.

2 . 1 . 3 . 1 . 7 Ap p r o v e o r R e j e c t R e q u e s t s

                     Table 19: Process Description – Approve or Reject Requests

      Identifier             UC-7: Approve or Reject Requests
      Purpose                Allow supervisors to approve requests in the business workflow.
      Requirements           CR-16, CR-17, CR18, CR-19, CR-20
      Development             None
      Risks
      Pre-conditions            User is logged into the system
                                User has authority to approve request
                                Record is “pending”
      Post-conditions           Email notification is sent out
                                Record is updated in the database


             Table 20: Typical Course of Action – Approve or Reject Requests: Approved

          Seq#             Actor’s Action                            System’s Response
      1            View report / request
      2            Approve the request
      3                                                    Workflow status is updated
      4                                                    Email notification is sent out

            Table 21: Alternate Course of Action – Approve or Reject Requests: Rejected

          Seq#              Actor’s Action                           System’s Response
      1            View report / request
      2            Reject the request
      3                                                    Workflow status is updated
      4                                                    Email notification is sent out

2.1.3.1.8 Mark Report as Completed

                      Table 22: Process Description – Mark Report as Completed

      Identifier             UC-8: Mark Reports as Completed
      Purpose                Personnel Records Staff can mark a report (record) as completed

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 14                                      Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile             Version 4.0


                           to close and store the report.
     Requirements          CR-16, CR-17, CR18, CR-19, CR-20
     Development            None
     Risks
     Pre-conditions           User is logged in as personnel records staff or administrator
                              Report is “pending”
     Post-conditions          Report is “Completed”
                              Report is stored in database
                              Report is no longer editable
                              Notification is sent to the employee.


                  Table 23: Typical Course of Action – Mark Reports as Completed

         Seq#              Actor’s Action                       System’s Response
     1            Select a “pending” report.
     2            Mark the report as completed.
     3                                               Store the report.
     4                                               Notify the user the report is completed.
     5                                               Send email notification that the report
                                                     has been completed.



2.1.3.2 Authentication
2.1.3.2.1 Login

                               Table 24: Process Description – Login

     Identifier            UC-9: Login
     Purpose               Authorize a user to log into the system and determine the users
                           role(s) and access privileges.
     Requirements          CR-13, CR-38
     Development            Development team has no experience using Active Directory
     Risks                     or a third party authentication component
     Pre-conditions         System database is properly initialized
                            User is on a computer behind the LADoT firewall
                            User has entry in Active Directory database
     Post-conditions        If the user’s log in information is authorized, the user is able
                               to access system within the specifications of the user’s role
                            If the user’s log in information is not authorized, the system
                               tells the user he has entered an invalid username and password



af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 15                                Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile             Version 4.0

                      Table 25: Typical Course of Action – Login: Successful

         Seq#             Actor’s Action                       System’s Response
     1           Enter a username and password
     2           Click the “Login” button
     3                                               Validate username and password
     4                                               Redirect the user to their Personnel
                                                     Record home page.

                        Table 26: Alternate Course of Action – Login: Failure

         Seq#             Actor’s Action                       System’s Response
     1           Enter a username and password
     2           Click the “Login” button
     3                                               Check username and password
     4                                               Return the user to the log in page and
                                                     notifies the user that he has entered an
                                                     invalid username and password.

          Table 27: Exceptional Course of Action– Login: Three Consecutive Login Failures

         Seq#             Actor’s Action                       System’s Response
     1           Unsuccessfully attempt to log in
                 to the system (as described in
                 table 17) three consecutive
                 times.
     2                                               Lock the user out of the system.
     3                                               Notify the user that he will need to
                                                     contact a personnel employee to reset
                                                     his password before he can log in to the
                                                     system again.

2.1.3.2.2 Logout

                              Table 28: Process Description – Logout

     Identifier           UC-10: Logout
     Purpose              Log a user out of the system
     Requirements         CR-13
     Development           None
     Risks
     Pre-conditions          The user is logged into the system
                             The user’s session exists
     Post-conditions         The user is logged out of the system and session is terminated


af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 16                                Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                Version 4.0

                                 Table 29: Typical Course of Action – Logout

          Seq#              Actor’s Action                         System’s Response
      1            Click the “log out” hypertext.
      2                                                  Log the user out of the system and
                                                         terminate the session.
      3                                                  Notify the user that he has logged out of
                                                         the system.


                        Table 30: Exceptional Course of Action – Session expires

          Seq#              Actor’s Action                         System’s Response
      1            Log into the system for the
                   amount of minutes before the
                   session expires.
      2                                                  Log the user out of the system and
                                                         terminate the session.
      3                                                  Notify the user that the session has
                                                         expired and that he has been logged out
                                                         of the system.


2.1.3.3 Accessing Employee Records
2 . 1 . 3 . 3 . 1 V i e w E m p l o ye e R e c o r d

                         Table 31: Process Description – View Employee Record

      Identifier             UC-11: View Employee Record
      Purpose                Allow authorized users to view an employee record.
      Requirements           CR-26, CR-27
      Development             None
      Risks
      Pre-conditions              User is logged in to the system
                                  User is authorized to view the employee’s record
      Post-conditions             System displays the selected employee’s record



                 Table 32: Typical Course of Action – View Employee Record: Successful

          Seq#              Actor’s Action                         System’s Response
      1            Select the employee.
      2                                                  Validate that the user has access to view
                                                         the employee’s records.

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 17                                    Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                 Version 4.0


      3                                                  Display a list of viewable records.
      4            Select a record.
      5                                                  Display the record.

          Table 33: Alternate Course of Action – View Employee Record: Unsuccessful

          Seq#              Actor’s Action                         System’s Response
      1            Select the employee.
      2                                                  Check that the user does not have
                                                         access to view any of the employee’s
                                                         records.
      3                                                  Notify the user that he does not have
                                                         privileges to view the employee’s
                                                         records.

2.1.3.3.1 View Confidential Record

                       Table 34: Process Description – View Confidential Record

      Identifier             UC-12: View Confidential Record
      Purpose                Allow authorized users to view a confidential record.
      Requirements           CR-26, CR-27, CR-29
      Development             None
      Risks
      Pre-conditions             User is logged into the system as a power user.

      Post-conditions            System displays the selected employee’s confidential record



              Table 35: Typical Course of Action – View Confidential Record: Successful

          Seq#              Actor’s Action                         System’s Response
      1            Select confidential record.
      2                                                  Display the record.



2 . 1 . 3 . 3 . 2 P r i n t E m p l o ye e R e c o r d

                        Table 36: Process Description – Print Employee Record

      Identifier             UC-13: Print Employee Record
      Purpose                Allow users with access to view a record to also print a record
                             whether it is scanned or inputted electronically.

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 18                                    Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile             Version 4.0


     Requirements          CR-23, CR-24
     Development            None
     Risks
     Pre-conditions           User is logged in to the system
                              User is authorized to view the specific employee record
     Post-conditions          System prints the selected employee record.



                     Table 37: Typical Course of Action – Print Employee Record

         Seq#              Actor’s Action                       System’s Response
     1            Select the employee.
     2            Select the employee record.
     3                                               Display the employee record.
     4            Select “Print”.
     5                                               Print the record.

2.1.3.3.3 Print Confidential Record

                      Table 38: Process Description – Print Confidential Record

     Identifier            UC-14: Print Confidential Record
     Purpose               Allow users with access to view a confidential record to also print
                           that record whether it is scanned or inputted electronically.
     Requirements          CR-23, CR-24
     Development            None
     Risks
     Pre-conditions           User is logged in to the system
                              User is authorized to view the specific confidential record
     Post-conditions          System prints the selected employee record.



                    Table 39: Typical Course of Action – Print Confidential Record

         Seq#              Actor’s Action                       System’s Response
     1            Select the employee.
     2            Select the employee record.
     3                                               Display the employee record.
     4            Select “Print”.
     5                                               Print the record.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 19                                Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile             Version 4.0


2.1.3.3.3 Print Records

                           Table 40: Process Description – Print Records

     Identifier            UC-15: Print Employee Records
     Purpose               Print all of the employee’s personnel or confidential records
                           without selecting records individually.
     Requirements          CR-25
     Development            None
     Risks
     Pre-conditions           User is logged in to the system
                              User is authorized to view the employee’s records
     Post-conditions          System prints out all of the documents in the employee’s
                               records.



                  Table 41: Typical Course of Action – Print Records: Confirm Yes

         Seq#              Actor’s Action                      System’s Response
     1            Select the employee.
     2            Select “Options”.
     3            Select “Print Personnel Records”
                  or “Print Confidential Records”
     4                                               Notify the user # of pages, # of records
                                                     to be printed and ask for print
                                                     confirmation.
     5            Confirm – “Yes”.
     6                                               Print the employee’s personnel records.


                Table 42: Alternative Course of Action – Print Records: Confirm No

         Seq#              Actor’s Action                      System’s Response
     1            Select the employee.
     2            Select “Options”.
     3            Select “Print Personnel Records”
                  or “Print Confidential Records”
     4                                               Notify the user # of pages, # of records
                                                     to be printed and ask for print
                                                     confirmation.
     5            Confirm – “No”.
     6                                               Redirect the user to the “Options” page.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 20                                Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile               Version 4.0


2.1.3.3.4 Search for Record

                         Table 43: Process Description – Search for Record

     Identifier            UC-16: Search for Record
     Purpose               Allow users to search for specific employee and confidential
                           records.
     Requirements          CR-2
     Development            None
     Risks
     Pre-conditions           User is logged in to the system
                              Database is initialized

     Post-conditions          System displays a list of search results that the user has access
                               to view



                       Table 44: Typical Course of Action – Search for Record

         Seq#               Actor’s Action                       System’s Response
     1            Fill out search parameters.
     2                                                Search the database using the given
                                                      parameters.
     3                                                Display a list of search results that the
                                                      user has access to view.

2.1.3.3.5 Edit a “Pending” Record

                      Table 45: Process Description – Edit a “Pending” Record

     Identifier            UC-17: Edit a “Pending” Record
     Purpose               Personnel Records Staff and administrators may make changes to
                           employee records with “pending” status. All records that do not
                           have “pending” status are not editable.
     Requirements          CR-14
     Development            None
     Risks
     Pre-conditions           User is logged into the system as a personnel records
                               employee or administrator.
                              Employee document is in “pending” status

     Post-conditions          Update the stored employee record
                              Record who modified the record and when it was modified

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 21                                  Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile             Version 4.0




                 Table 46: Typical Course of Action – – Edit a “Pending” Record

         Seq#            Actor’s Action                        System’s Response
     1          Select the employee record.
     2          Click on “Edit”.
     3                                               Verify that the user has access to edit
                                                     the employee record.
     4          Make changes to the record.
     5          Click on the “Submit”.
     6                                               Store modified record.
     7                                               Record who modified the record and
                                                     when it was modified.
     8                                               Notify the user the changes have been
                                                     saved and show the modified record.

2.1.3.3.6 Delete Records

                         Table 47: Process Description – Delete Records

     Identifier          UC-18: Delete an Employee Record
     Purpose             Allow administrators to delete employee records
     Requirements        CR-10
     Development          None
     Risks
     Pre-conditions           User is logged in to the system as an administrator
     Post-conditions          Records are deleted.



                Table 48: Typical Course of Action – Delete Records: Confirm Yes

         Seq#            Actor’s Action                        System’s Response
     1          Select the employee record.
     2          Click on “Options”.
     3                                               Re-direct the user to the “Options” page
                                                     for the record.
     4          Select records to delete.
     5                                               Warn user this will permanently delete
                                                     the record and ask user for
                                                     confirmation.
     6          Select “Yes”
     7                                               Delete the selected record from the

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 22                                Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile             Version 4.0


                                                      database.
     8                                                Notify the user that the record has been
                                                      deleted.


                  Table 49: Alternate Course of Action – Delete Records: Confirm No

         Seq#              Actor’s Action                       System’s Response
     1            Select the employee record.
     2            Click on “Options”.
     3                                                Redirect the user to the “Options” page
                                                      for the record.
     4            Select records to delete.
     5                                                Warn user this will permanently delete
                                                      the record and ask user for
                                                      confirmation.
     6            Select “No”
     7                                                Redirect the user to the “Options” page

2.1.3.3.7 Transfer Employee Record

                     Table 50: Process Description – Transfer Employee Record

     Identifier            UC-19: Transfer Employee Record
     Purpose               Allow power users to transfer employee records from the
                           employee record to confidential record and vice versa.
     Requirements          CR-10
     Development            None
     Risks
     Pre-conditions            User is logged into the system as a power user

     Post-conditions           Move the record to the confidential records or the employee
                                records



           Table 51: Typical Course of Action – Transfer record to Confidential Records

         Seq#              Actor’s Action                       System’s Response
     1            Select the employee record.
     2            Click on “Options”.
     3                                                Re-direct the user to the “Options” page
                                                      for the record.
     4            Select “Transfer to Confidential
                  Records”

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 23                                Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                Version 4.0


      5                                                Move the record from the personnel
                                                       records to confidential records or from
                                                       confidential records to personnel
                                                       records.
      6                                                Notify the user the record has been
                                                       moved to the confidential records.


             Table 52: Alternate Course of Action – Transfer record to Employee records

          Seq#              Actor’s Action                       System’s Response
      1            Select the employee record.
      2            Click on “Options”.
      3                                                Re-direct the user to the “Options” page
                                                       for the record.
      4            Select “Transfer to Employee
                   Records”
      5                                                Move the record from the personnel
                                                       records to confidential records or from
                                                       confidential records to personnel
                                                       records.
      6                                                Notify the user the record has been
                                                       moved to the confidential records.


2.1.3.4 Record Archiving
2 . 1 . 3 . 4 . 1 Ar c h i v e R e c o r d s

                             Table 53: Process Description – Archive Records

      Identifier              UC-20: Archive Records
      Purpose                 Allow power users archive an employee’s records for a certain
                              period of time when an employee leaves LADoT.
      Requirements            CR-8, CR-9
      Development              None
      Risks
      Pre-conditions             User is logged in to the system as a power user
      Post-conditions            Employee’s record is changed from “Active” to “Archived”.


                  Table 54: Typical Course of Action – Archive Records: Confirm Yes

          Seq#              Actor’s Action                       System’s Response
      1            Select the employee.

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 24                                    Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile               Version 4.0


      2            Click on “Options”
      3            Select “Archive Records”
      4                                                 Display a message indicating that the
                                                        record will be archived for a certain
                                                        period of time and ask the user to
                                                        confirm.
      5            Confirm – “Yes”
      6                                                 Mark the record as “Archived”
      7                                                 Notify the user that the record has been
                                                        archived.


                  Table 55: Alternate Course of Action – Archive Records: Confirm No

          Seq#              Actor’s Action                        System’s Response
      1            Select the employee.
      2            Click on “Options”
      3            Select “Archive Records”
      4                                                 Display a message indicating that the
                                                        record will be archived for a certain
                                                        period of time and ask the user to
                                                        confirm.
      5            Confirm – “No”
      6                                                 Redirect the user to the “Options” page.

2 . 1 . 3 . 4 . 2 Ac t i v a t e R e c o r d s

                             Table 56: Process Description – Activate Records

      Identifier               UC-21: Activate Records
      Purpose                  Allow power users to activate an archived employee record. This
                               is used when an employee leaves LADoT and then returns to
                               LADoT.
      Requirements             CR-6
      Development               None
      Risks
      Pre-conditions              User is logged in to the system as a power user
      Post-conditions             Employee’s record is changed from “Archived” to “Active”.


                  Table 57: Typical Course of Action – Activate Records: Confirm Yes

          Seq#              Actor’s Action                        System’s Response
      1            Select the employee.
      2            Click on “Options”

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 25                                  Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile                    Version 4.0


      3            Select “Activate Records”
      4                                                     Display a message indicating that the
                                                            record will be activated and ask the user
                                                            to confirm.
      5            Confirm – “Yes”
      6                                                     Mark the record as “Activated”
      7                                                     Notify the user that the record has been
                                                            activated.


                 Table 58: Alternate Course of Action – Activate Records: Confirm No

          Seq#              Actor’s Action                              System’s Response
      1            Select the employee.
      2            Click on “Options”
      3            Select “Activate Records”
      4                                                     Display a message indicating that the
                                                            record will be activated and ask the user
                                                            to confirm.
      5            Confirm – “No”
      6                                                     Redirect user to the “Options” page.
2 . 1 . 3 . 4 . 3 S e t D e l e t i o n D a t e f o r Ar c h i v e d R e c o r d

                 Table 59: Process Description – Set Deletion Date for Archived Record

      Identifier             UC-22: Set Deletion Date for Archived Record
      Purpose                Allow administrators to set a future deletion date for a specific
                             archived record.
      Requirements           CR-11
      Development             None
      Risks
      Pre-conditions             User is logged in to the system as an administrator
      Post-conditions            The archived record’s deletion date is modified.


      Table 60: Typical Course of Action – Set Deletion Date for Archived Record: Valid Date

          Seq#              Actor’s Action                              System’s Response
      1            Select the employee.
      2            Click on “Options”.
      3            Select “Set Deletion Date”.
      4                                                     Display a message indicating that the
                                                            record deletion date will be changed
                                                            and prompt the user to enter a date.
      5            Enter a valid future date.

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 26                                        Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile             Version 4.0


      6                                              Check that the date is valid.
      7                                              Notify the user that the record deletion
                                                     date has been modified.


    Table 61: Alternate Course of Action – Set Deletion Date for Archived Record: Invalid Date

          Seq#            Actor’s Action                       System’s Response
      1          Select the employee.
      2          Click on “Options”.
      3          Select “Set Deletion Date”.
      4                                              Display a message indicating that the
                                                     record deletion date will be changed
                                                     and prompt the user to enter a date.
      5          Enter an invalid date.
      6                                              Notify the user the date entered was
                                                     invalid.
      7                                              Go to 4.


2.1.3.5 Administration
2 . 1 . 3 . 5 . 1 Ad d N e w E m p l o y e e

                         Table 62: Process Description – Add New Employee

      Identifier           UC-23: Create New Employee
      Purpose              Power users will be able to add new employees to the system.
      Requirements         CR-5
      Development           None
      Risks
      Pre-conditions          User is logged into the system as a power user.
                              Database is initialized
      Post-conditions         New employee added to the system.


                   Table 63: Typical Course of Action – Add New Employee - Valid

          Seq#              Actor’s Action                     System’s Response
      1          Fill in all required fields
      2          Click “Create New Employee”
      3                                              Check all fields have been entered and
                                                     fields are valid.
      4                                              Create a new employee.
      5                                              Send email notification to the new

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 27                                Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile              Version 4.0


                                                        employee that his personnel record
                                                        account has been created.

                  Table 64: Alternate Course of Action – Add New Employee - Invalid

         Seq#               Actor’s Action                        System’s Response
     1            Fail to fill in all required fields
                  or enter invalid inputs.
     2            Click “Create New Employee”
     3                                                  Check fields are missing or invalid.
     4                                                  Reload the page and indicate which
                                                        required fields were not completed or
                                                        invalid.

2.1.3.5.2 Create Special User

                         Table 65: Process Description – Create Special User

     Identifier             UC-24: Create Special User
     Purpose                Administrators will be allowed to create special users such as
                            other administrators and power users.
     Requirements           CR-7
     Development             None
     Risks
     Pre-conditions            User is logged into the system as an administrator
                               Database is initialized
     Post-conditions           New special user added to the system.


                   Table 66: Typical Course of Action – Create Special User - Valid

         Seq#                Actor’s Action                       System’s Response
     1            Fill in all required fields
     2            Click OK
     3                                                  Check all fields have been entered and
                                                        fields are valid.
     4                                                  Create a new user with special
                                                        permissions.
     5                                                  Send email notification to the new
                                                        employee that his personnel record
                                                        account has been created.

                Table 67: Alternate Course of Action – Create Special User - Invalid

         Seq#               Actor’s Action                        System’s Response

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 28                                  Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile               Version 4.0


     1            Fail to fill in all required fields
                  or enter invalid inputs.
     2            Click OK
     3                                                  Check fields are missing or invalid.
     4                                                  Reload the page and indicate which
                                                        required fields were not completed or
                                                        invalid.

2.1.3.5.3 Edit User Settings

                          Table 68: Process Description – Edit User Settings

     Identifier             UC-25: Edit User Settings
     Purpose                Administrators are able to edit a user’s settings, information, and
                            permissions.
     Requirements           CR-7
     Development             None
     Risks
     Pre-conditions            User is logged into the system as an administrator
                               Database is initialized

     Post-conditions           Employee’s settings are modified


                          Table 69: Typical Course of Action – Set User Roles

         Seq#             Actor’s Action                          System’s Response
     1            Modify fields
     2            Press “OK”
     3                                                  System modifies the specified
                                                        employee’s settings / information.



2.1.3.5.4 Set User Roles

                            Table 70: Process Description – Set User Roles

     Identifier             UC-26: Set User Roles
     Purpose                Administrators are able to modify user roles.
     Requirements           CR-7
     Development             None
     Risks
     Pre-conditions            User is logged into the system as an administrator


af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 29                                  Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile         Version 4.0


     Post-conditions        Employee’s role is modified


                       Table 71: Typical Course of Action – Set User Roles

         Seq#            Actor’s Action                      System’s Response
     1          Enter required information
     2          Press “OK”
     3                                             System modifies the specified
                                                   employee’s roles.
     4                                             System notifies the user the employee’s
                                                   role has been updated.



2.1.4 Modes of Operation
The Personnel Records Management System has only one mode of operation so nothing else
needs to be said for this section.


2.2 System Analysis Rationale
The SSAD described in Version 1.2 had more actors, which were based on the LADoT personnel
hierarchy. However, some of those actors had identical use cases as other actors so they were
removed to simplify the system.

   1. Bureau Head – The bureau head has identical access to the system as a Supervisor but
      they provide a higher level of request authorization. The Bureau Head was removed and
      made part of the Supervisor.

   2. System Administrator – The system administrators consists of the IT staff and has full
      access to the system. The System Administrator was removed and replaced by
      Administrator.

   3. Security Administrator – The security administrator is the Personnel Records Supervisor
      and has full access to the system. The Security Administrator was removed and replaced
      by Administrator.

Employees, non-LADoT employees, and supervisors may not view personnel records unless they
access them through a kiosk at LADoT provided by the personnel records staff. A user
accessing the kiosk to view personnel records is represented as a Viewer in the System Context
Diagram and Use Case Diagram.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 30                             Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile      Version 4.0


4. Technology-Specific System Design

4.1.1 System Structure




                        Figure 4: Hardware Component Class Diagram




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 31                          Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile      Version 4.0




                        Figure 5: Software Component Class Diagram




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 32                          Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile         Version 4.0




                                  Figure 6: Deployment Diagram

The tables below contain descriptions of the hardware and software components that are a part of
the Personnel Records Management System.

                            Table 72: Hardware Component Description

  Hardware Component                                     Description
 Networked Computers         Computers behind the Los Angeles City firewall.
 Workstation                 A workstation within the Los Angeles City firewall that connects
                             to the Personnel Records Management System through the
                             Intranet.
 Windows Server              The servers that the application components reside on.
 Windows                     Machine using a Windows operating system


                            Table 73: Software Component Description

  Software Component                                     Description
 User Interface Component    This component contains the web pages (views) for users of the
                             Personnel Records Management System. The component has two
                             main functionalities. It provides forms for users to submit
                             digitally and provides access to personnel records.
 Workflow Management         This component contains functionality for managing online forms
 Component                   and business workflows.
 Records Management          This component contains functionality for viewing and managing
 Component                   personnel records and confidential records.

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 33                             Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile          Version 4.0

 User Application           This component performs functions related to managing user
 Component                  information and permissions.
 ASP.NET MVC 3              ASP.NET MVC is a web application framework that is based on
                            ASP.NET. It implements the model-view-controller pattern.
 Active Directory           Active Directory provides various network services such as
                            Lightweight Directory Access Protocol (LDAP) and Kerberos
                            based authentication. Active Directory will be used to
                            authenticate users.

                            Note: LADoT has not finalized whether they will use Active
                            Directory for authentication. So this component is tentative.
 SQL Server 2008            SQL Server 2008 is a relational model database server. It will be
                            used to store the data used by the Personnel Records Management
                            System.



4.1.2 Design Classes
The Design Class Diagrams shown below describe the relationships between the boundary,
entity, and control classes of the Personnel Records Management System.

Note: Some of the class diagrams are large. Therefore, I’ve rotated some of the diagrams to
make it easier to view and read when printed. Please zoom in and rotate the document if
necessary to view in digital format.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 34                             Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile            Version 4.0


4 .1. 2.1 I nter fa ce Cl a sse s




                                Figure 7: Interface Class Diagram

The table below contains the description for each design class described in the Interface Class
Diagram.


                              Table 74: Interface Class Description

               Class                  Type                         Description
LoginView                           Boundary      The login page.
Home                                Boundary      The user’s home page which will display
                                                  pending records.
Logout                              Boundary      Logout page.
UserSettings                        Boundary      The page will display the user’s settings and
                                                  allow privileged users to modify the user’s
                                                  settings and permissions.
Search Records                      Boundary      Allows users to search for records and it
                                                  displays record search results.
Record                              Boundary      Displays a single record.
SearchUser                          Boundary      Displays search information for users to
                                                  search for a specific user.
LeaveOfAbsence                      Boundary      Form for users to submit a leave of absence
                                                  request.
Accident                            Boundary      Form for users to submit an auto accident
                                                  report.
Reimbursement                       Boundary      Form for users to submit a request for a
                                                  professional license reimbursement.

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 35                               Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile       Version 4.0


TempBonus                        Boundary     Form for users to submit a request for a
                                              temporary bonus.
ServicePin                       Boundary     Form for users to submit a service pin
                                              request.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 36                          Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile      Version 4.0


4 .1. 2.2     Re c or ds M a nage m ent Cl as se s




                       Figure 15: Records Management Class Diagram



af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 37                          Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile          Version 4.0


The table below contains the description for each design class described in the Records
Management Class Diagram.

                       Table 75: Records Management Class Description

            Class                     Type                    Description
RecordController                   Component Controller responsible for determine what
                                             response to send back to a user when a user
                                             accesses records or searches for records.
EmployeeController                 Component Controller for the employee’s home page and
                                             actions associated with the home page.
IPermissionService                 Component Interface for checking a user’s permissions.
IFileService                       Component Interface to accessing the file server.
FileService                        Component Accesses the file server using .NET File
                                             class.
IRecordRepository                  Component Interface to access record database.
AbstractHibernateRepository        Component Basic base class for all of the repository
                                             classes.
NhibernateRecordRepository         Component Access the record database using LINQ and
                                             Nhibernate
RecordModel                        Entity    Contains the information regarding scanned
                                             records.
IemployeeRepository                Component Interface to access the employee’s
                                             information.
EmployeeModel                      Entity    Contains the information about an employee.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 38                              Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile       Version 4.0


4 .1. 2.3     Work fl ow M a nage me nt Cl as s Di a gra m




                       Figure 16: Workflow Management Class Diagram


af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 39                           Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile         Version 4.0


The table below contains the description for each design class described in the Workflow
Management Class Diagram.

                       Table 76: Workflow Management Class Description

              Class                       Type                    Description
LeaveOfAbsenseController               Component Controller for Leave of Absence workflow.
AccidentController                     Component Controller for Accident workflow.
ReimbursementController                Component Controller for the Professional License
                                                 Reimbursement workflow.
ServicePinController                   Component Controller for the Service Pin workflow.
TempBonusController                    Component Controller for the Temp Bonus workflow.
WorkflowManager                        Component Encapsulates business logic associated with
                                                 the LADoT business workflows.
AbstractHibernateRepository            Component Base class for repositories using
                                                 NHibernate.
IFileService                           Component Interface for accessing the file server.
                                                 Responsible for accessing forms and
                                                 attachments on the file server.
IWorkflowRepository                    Component Interface for accessing workflows stored in
                                                 a database.
NHibernateWorkflowRepository           Component Accesses workflows stored in the database
                                                 using NHibernate and LINQ.
IEmailService                          Component Interface for sending emails
SmtpService                            Component Uses ASP.NET SmtpClient for sending
                                                 notification emails.
IPdfFormatter                          Component Interface to convert the digital forms to
                                                 PDFs for viewing and printing.
PdfFormatter                           Component Converts the digital forms to PDFs for
                                                 viewing and printing using PDFSharp.
IPermissionService                     Component Interface for checking if the user has
                                                 permission to perform the requested action.
WorkflowModel                          Entity    Base class for a workflow model object.
TempBonusModel                         Entity    Contains information stored in the temp
                                                 bonus form.
LeaveOfAbsenceModel                    Entity    Contains information stored in the leave of
                                                 absence form.
ServicePinModel                        Entity    Contains information stored in service pin
                                                 document.
AutoAccidentModel                      Entity    Contains information stored in the auto
                                                 accident form.
ProfLicenseReimbursementModel          Entity    Contains information stored in the
                                                 professional license reimbursement form.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 40                             Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile       Version 4.0


4 .1. 2.4     Us er Appl i ca tion




                          Figure 17: User Application Class Diagram

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 41                           Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile          Version 4.0


The table below contains the description for each design class described in the User Application
Class Diagram.

Note: LADoT is still deciding whether to use Active Directory for authentication so the
MembershipService class contains .NET membership provider objects for SQL and Active
Directory.

                          Table 77: User Application Class Description

            Class                 Type                     Description
AccountController              Component Controller responsible for authentication,
                                         searching for users, viewing and modifying
                                         user settings
IFormsAuthenticationService    Component Interface for form based authentication.
FormsAuthenticationService     Component Authenticates users using .NET
                                         FormsAuthentication
IPermissionService             Component Interface for checking, adding, and removing
                                         permissions.
IMembershipService             Component Interface for user membership functionality.
MembershipService              Component Manages users and checks permissions using
                                         custom permission management and .NET
                                         membership providers.
PermissionService              Component Responsible for checking, adding, and
                                         removing user permissions.
AbstractHibernateRepository    Component Base class for repository’s using NHibernate.
IPermissionRepository          Component Interface for accessing the Permissions
                                         database table.
NHibernatePermissionRepository Component Accesses the Permissions database table
                                         using NHibernate.
IUserRepository                Component Interface for accessing the user’s information
                                         from the database (if not using Active
                                         Directory)
NHibernateUserRepository       Component Accesses the user’s information from the
                                         database (if not using Active Directory)
                                         using NHibernate.
UserModel                      Entity    Model for user. Contains basic user
                                         information, roles, and permissions.
EmployeeModel                  Entity    Contains the information about an employee.
PermissionModel                Entity    Model for user permissions.


4.1.3 Process Realization
This section describes how major processes identified in System Analysis (2.1.3) are realized by
the designed architecture (4.1.1) and instances of the classes (3.1.2).



af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 42                              Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile         Version 4.0


Note: The sequence diagrams are large and difficult to view and read. Therefore, they have been
rotated to make them easier to read when the document is printed. To view in digital form,
please zoom in and rotate as necessary.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 43                            Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile         Version 4.0


The following diagram is the sequence diagram for submitting a leave of absence request.




                             Figure 8: Process Realization Diagram




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 44                            Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile           Version 4.0


The following diagram is the sequence diagram for viewing a personnel record.




                             Figure 9: Process Realization Diagram




4.2 Design Rationale
We adopted a Model-View-Controller architecture pattern because it’s widely used in web
applications and it provides encourages modular and flexible design. The client required that we
use C# and .NET so ASP.NET MVC was an ideal framework to use. It provides a clear
separation between the user interface, control flow, and business logic. This is important
because certain functionality such as allowing multiple record upload or record upload in general
may have to be implemented by LADoT after they find a scanning company which is a long
process.

The View consists of the User Interface Component. The Controller classes consists of classes
responsible for controlling the flow of control logic such as what responses to send when a user
makes a browser request. The Controller classes all end with “Controller”. The Model classes

af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 45                              Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile             Version 4.0


contain the business logic, validation logic, and database access. Classes that are not part of the
View or Controller belong to the Model.

The client also required that the system use SQL Server 2008 and possibly Active Directory to
work with existing software. LADoT has not decided if Active Directory will be used so it is
currently tentative in this document.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 46                                Version Date: 2/23/11
 System and Software Architecture Description (SSAD) for Architected Agile         Version 4.0


 5. Architectural Styles, Patterns and

     Frameworks

                    Table 78: Architectural Styles, Patterns, and Frameworks

    Name                      Description                    Benefits, Costs, and Limitations
Model View      The architecture is the Model-View-     Model-View-Controller provides several
Controller      Controller (MVC) pattern. The view      benefits. It makes code more
                consists of the user interface. The     maintainable by using modular
                controller contains the flow control    development and promoting loose
                logic. The model contains business      coupling. It allows maintainers to
                logic and data.                         modify the UI, control, and business
                                                        logic independently of each other. MVC
                                                        is also an extremely common
                                                        architectural pattern for web applications
                                                        so most developers will be familiar with
                                                        it.

                                                        The cost of using architecture is that not
                                                        all of our development team has
                                                        experience with it. It also takes more
                                                        effort and discipline to implement
                                                        correctly.

                                                        A limitation is programmers often
                                                        violate the architecture. For example it
                                                        is common for programmers to put
                                                        business logic inside of a controller.
ASP.NET         ASP.NET MVC is a web application        The benefit of using ASP.NET MVC is
MVC 3           framework that is based on .NET. It     that it generates a lot of code for the
                is an extension of .NET and it          development team and handles a large
                implements the model-view-              portion of the control logic. The team
                controller architectural pattern.       will also use .NET 4 libraries for Smtp,
                                                        authentication, membership, active
                                                        directory access, and database access.

                                                        The cost of using ASP.NET MVC is that
                                                        it will take some time for the team to
                                                        become familiar with the framework and
                                                        the model-view-controller pattern. There
                                                        is no monetary cost associated with using
                                                        ASP.NET MVC.

 af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 47                            Version Date: 2/23/11
System and Software Architecture Description (SSAD) for Architected Agile      Version 4.0



                                                      The limitation of ASP.NET MVC is that
                                                      there are no postbacks or viewstate.
                                                      Controls that take advantage of
                                                      postbacks or viewstate won’t work.




af7da39e-e14a-4a4a-a9b7-f4460a925096.doc 48                          Version Date: 2/23/11