• Author / Uploaded
• Luis Arry

Citation preview

 

 

           

CSU Technical Solution Design  Document  for Project           V1.00       

 

 

CSU Technical Solution Design Document     

Document Status and Revision History    Version 

Author 

Issue date 

Revisions   

V1.00 

Paul Cullen 

23/07/2009 

First release version 

 

 

 

 

 

 

 

 

 

 

 

 

 

Document Authorisation    Name: 

Paul Cullen 

 

Position: 

Manager, Enterprise Solution Services, DIT 

Name: 

Brian Roberson 

Position: 

Manager, Technology Integration 

 

 

     

Document Distribution    No. 

Recipient 

Position and Division   

1.

 

Tim Archer 

Enterprise Solution Architect ‐ Testing 

2.

 

Wayne Marr 

Enterprise Solution Architect – Applications 

3.

 

Craig Patterson 

Enterprise Solution Architect – Integration 

4. 

Conrad Dare‐Edwards 

Enterprise Solution Architect – Infrastructure 

5. 

Luke Weston 

Enterprise Solution Architect ‐ Security 

6. 

Dot Cottee 

Team Leader, Technology Integration 

7. 

Shane Jeffries 

Team Leader, Technology Integration 

8. 

Brian Roberson 

Manager, Technology Integration 

      Document Purpose  The purpose of this document is to serve as a template for the creation of the technical solution design document. For the technical  solution design document to be completed the following cpmpleted and signed off documents need to be delivered via the  EA&L/ESS gateway:  • Business Requirements 

    Page 2 of 19 

CSU Technical Solution Design Document      • •

Functional Requirements  Relevant Enterprise Architectural Standards 

  Each section contains notes, considerations and suggestions to guide an enterprise solution architect in the completion of the  document. Depending on the type of project, eg internally or externally sourced, some components may be optional or completed  from suppliers documentation. Sections can be renamed, as appropriate, to suit the type and complexity of the project. 

   

Table of Contents  TABLE OF CONTENTS ..................................................................................................................................................................... 3  1. 

PROJECT SUMMARY ............................................................................................................................................................. 6 

2. 

APPLICATION DESIGN ........................................................................................................................................................... 6 

2.1. 

User interfaces ................................................................................................................................................................. 6 

2.2. 

User Management ........................................................................................................................................................... 6 

2.3. 

Data Output ..................................................................................................................................................................... 6 

2.4. 

Data Management ........................................................................................................................................................... 6 

2.5. 

Coding Requirements ....................................................................................................................................................... 6 

3. 

INTEGRATION DESIGN .......................................................................................................................................................... 7 

3.1. 

Integration Schematic ...................................................................................................................................................... 7 

3.2. 

Enterprise Data Requirements ......................................................................................................................................... 7 

3.3. 

Master Data Definitions ................................................................................................................................................... 7 

3.4. 

Integration Scope ............................................................................................................................................................. 7 

3.5. 

Master Data Document Types .......................................................................................................................................... 7 

3.6. 

Enterprise Interface Requirements ................................................................................................................................... 7 

3.7. 

Data Transfer Volumes ..................................................................................................................................................... 8 

3.8. 

Data Availability .............................................................................................................................................................. 8 

3.9. 

Latency ............................................................................................................................................................................ 8 

4.  4.1. 

SECURITY DESIGN ................................................................................................................................................................. 9  Security requirements analysis and specification .............................................................................................................. 9 

    Page 3 of 19 

CSU Technical Solution Design Document      4.2. 

Assessing security risks .................................................................................................................................................... 9 

4.3. 

Treating security risks ...................................................................................................................................................... 9 

4.4. 

Correct processing in applications. ................................................................................................................................... 9 

4.5. 

Cryptographic controls. .................................................................................................................................................... 9 

5.  5.1. 

INFRASTRUCTURE DESIGN .................................................................................................................................................. 10  System Architecture (development, qa and production implementations) ...................................................................... 10 

5.2.  Infrastructure Management ........................................................................................................................................... 13  5.2.1.  Availability requirements ................................................................................................................................................. 13  5.2.2.  Business continuity fail over and fail back ....................................................................................................................... 13  5.2.3.  Archival requirements ...................................................................................................................................................... 13  5.2.4.  Maintenance .................................................................................................................................................................... 13  5.2.5.  Log file rotation ................................................................................................................................................................ 13  5.2.6.  Starting and stopping the application .............................................................................................................................. 13  5.2.7.  Monitoring interfaces ...................................................................................................................................................... 13  5.2.8.  Dependences.................................................................................................................................................................... 13  Access Control ............................................................................................................................................................... 14  5.3.  5.3.1.  Business Requirement for Access Control ....................................................................................................................... 14  5.3.2.  User Access Management ................................................................................................................................................ 14  5.3.3.  User Responsibilities ........................................................................................................................................................ 14  5.3.4.  File System Access Control ............................................................................................................................................... 14  5.3.5.  Network Access Control ................................................................................................................................................... 14  5.3.6.  Mobile Computing and Tele‐working ............................................................................................................................... 14  5.3.7.  Operating System Access Control .................................................................................................................................... 14  5.3.8.  Third Party management and access ............................................................................................................................... 14  5.3.9.  Physical and Environmental Security ............................................................................................................................... 14  5.3.10.  Application and Information Access Control ................................................................................................................... 14  5.4.  Application Management ............................................................................................................................................... 15  5.4.1.  Third Party Service Delivery Management ....................................................................................................................... 15  5.4.2.  Operational Procedures and Responsibilities .................................................................................................................. 15  5.4.3.  Upgrade and code migration ........................................................................................................................................... 15  5.4.4.  OS patching and security patching ................................................................................................................................... 15  5.4.5.  Solution dependencies ..................................................................................................................................................... 15  5.4.6.  Job management (cron, timed processes, ...) .................................................................................................................. 15  5.4.7.  User interactions (printing, output folders, http, ssh, ... ) ............................................................................................... 15  5.4.8.  Licensing ........................................................................................................................................................................... 15  5.4.9.  On going costs .................................................................................................................................................................. 15  5.5.  Client Applications ......................................................................................................................................................... 15  5.5.1.  Architecture ..................................................................................................................................................................... 15  5.5.2.  Installation ....................................................................................................................................................................... 15  5.6.  Migration ....................................................................................................................................................................... 16  5.6.1.  Migration strategy (how are we going to go into production) ........................................................................................ 16  5.6.2.  Rollback strategy .............................................................................................................................................................. 16  5.6.3.  Decommissioning ............................................................................................................................................................. 16 

    Page 4 of 19 

CSU Technical Solution Design Document      6. 

TEST DESIGN ....................................................................................................................................................................... 17 

6.1.  PSC/SDLC Analysis Phase (Requirements Testing) ........................................................................................................... 17  6.1.1.  Use Cases ......................................................................................................................................................................... 17  6.1.2.  Risk Register ..................................................................................................................................................................... 17  6.1.3.  Requirement validation ................................................................................................................................................... 17  6.2. 

PSC/SDLC Design Phase (Functional Testing) ................................................................................................................... 17 

6.3. 

PSC/SDLC Testing Phase (Verification Testing) ................................................................................................................ 18 

6.4. 

Implementation Phase ................................................................................................................................................... 19 

   

 

    Page 5 of 19 

CSU Technical Solution Design Document     

1. Project Summary  Provide a description of what application/system/product will be developed using this solution design. Include a summary of:  Current application, system or product in use, if any. This will provide a reference point.  The main features of this solution including a description of general functionality, main components, output expectations and target  user groups. This applies to both internally and externally sourced applications. 

  2. Application Design  This section is flexible in that components may or may not be included depending on the complexity of the project and whether it is  sourced/developed internally. Provide sufficient detail to allow a technical build document to be generated by TI using this  document as a base. The depth of detail is dependent on the relationship of the solution to the existing system. For example, a new  DEEWRS report will follow well defined conventions and elements whereas a third party application will only have higher level  design elements, or none at all. 

  2.1. User interfaces  Define specific elements of the user interface such as web pages, oracle forms, etc., and include mock ups as agreed with the client. 

  2.2. User Management  Define the owners and groups for the application/system and the generic, administrative and/or system user logins and their  functions, if any. Include any third party access requirements. Identify the job position that has ownership and administrative  responsibility for the application/system. 

  2.3. Data Output  Define any output artefacts such as reports, files, screen displays, data transfers to database tables, or third party applications, etc.  Include comments regarding frequency of output or transfer and any requirements to automate processes, such as overnight batch  processing. 

  2.4. Data Management  Define requirements for each environment including folder structures, filestore locations, database elements ‐ schemas, tables,  packages, triggers and sequences, as applicable. 

  2.5. Coding Requirements  Define specific requirements that must be coded in the solution. Include: the preferred code platform; the need to use include files  and/or database packages; data validation requirements; specific methodologies or algorithms required to derive data values;  significant specific output requirements expected based on input data, including logs; reference to any existing code elements that  can be reused; any inter system transfer requirements; authentication and access methodology. 

     

   

 

    Page 6 of 19 

CSU Technical Solution Design Document     

3. Integration Design  The integration design provides details on how the solution application will integrate with other CSU   applications and/or applications outside the university. 

  3.1. Integration Schematic  A context diagram is to be provided showing how the solution integrates with other applications. Also include   any sources that may be required for masterdata. 

  3.2. Enterprise Data Requirements   Any Solution Data which already exists in the Master Data Catalogue must be sourced from there. If known, list these data objects  and indicate if any of this Master Data will be changed within the solution. Indicate the flexibility for the solution to be able to  consume data from an external source and contribute data to an external target (as master data). Describe the ability/flexibility to  select which tables or attributes will be populated from master data, and which will contribute to master data. 

  3.3. Master Data Definitions  Master Data definitions are available in the following documents located in the UNC path, S:\Administrative\Information  Technology\Architecture\6 Information Architecture\Master Data Definition\1 Current Approved 

  3.4. Integration Scope  ERD showing the master data entities to be used by the solution consultation may be with the Enterprise Data Architect, e.g: 

    3.5. Master Data Document Types  Define enterprise data structures to be used by the application. In the case of new structures being required that are not  implemented in the defined Enterpise Data Model or not implemented in webMethods or MDR, then consultation with the  Enterprise Data Architect will be required. For this consultation, you should gain the necessary information to complete the  structure. i.e Name, Attributes, Sizes(?) and sql necessary to gather from the source application. This needs to be recorded in the  design, preferentially in a table structure for TI to implement. 

  3.6. Enterprise Interface Requirements  The IT Data Architecture Standard shows the standard methods of interaction with CSU data. Show details on how this solution will  connect to the Master Data and/or other CSU applications  • Will the solution use webMethods or other methods to exchange data with other applications? If so, refer to 4.2.1 to  provide details on requirements.  • Will the application require master data to be provided to its local database?  • Will services be called inside webMethods to return data from master data?if so, provide details on service i.e name, desc,  inputs, outputs, select to use (or flow design)  • Will there be connections to Active Directory or LDAP for authentication?  • Will there be generic vendor provided integration between applications? i.e Degreeworks and Banner, Dentistrys Salud and  Romexis  • Will passwords need to be pushed to the application? (Currently we don’t provide this service as a number of security  questions are raised... You will need to consult with the Enterprise Integration Architect, Enterprise Data Architect,  Enterprise Application Architect and Security Architect to discuss if it becomes a requirement.  • Will data be required to be pushed to an external hosted application? i.e Heims  • Will Transactional Control need to be implemented? i.e. XA Transactions.. don’t commit unless transactions are successful  on more than one database.  Note: When creation of webmethods services or transfers are required, there is a webMethods Developers Handbook in the  following location – S:\Administrative\Information Technology\Architecture\Integration Centre\Handbooks\Developers\Developers  Handbook.doc 

    Page 7 of 19 

CSU Technical Solution Design Document        3.7. Data Transfer Volumes  Provide estimates on the volume of data to be transferred to and from the solution.  This should include size for current demands  and future growth. 

  3.8. Data Availability  Describe how the solution will cope if access to the Master Data is unavailable for a period of time. Address specific situations such  as how the solution will respond if user authentication information is unavailable, or if CSU Interact is unavailable.This can become a  problem for the application where services to select from Masterdata are to be used. Currently there is only one MDR database so if  it becomes unavailable, this will need to be catered for in the application  . 

3.9. Latency  When using Master Data within the Solution’s own schemas. How quickly will this data have to be refreshed? Eg real time, within an  hour, overnight etc. Is there the potential for an adverse effect on performance where a data transfer is running between  campuses? 

     

 

    Page 8 of 19 

CSU Technical Solution Design Document     

4. Security Design The goal of security design in the SDLC is to ensure security is an integral part of the information system solutions developed “All  security requirements should be identified at the requirements phase of a project and justified, agreed and documented as part of  the overall business case for an information system.” – AS/NZS ISO/IEC 27002:2006.   The business requirements for new solutions, or enhancements to existing solutions should specify the requirements for security  controls. The risk management process can be used to identify the requirements for security controls.  Specifications for solutions should consider both automated controls and the need for governance processes to support manual  controls. This also needs to be considered when evaluating software, both developed and purchased.  The security requirements and controls should reflect the business value of the information assets involved, and the potential  impact to CSU should a failure or absence of security occur. ( See also CSU Master Data Governance.doc)  Purchased products need to undergo a formal testing and acquisition process that includes security functionality. 

  4.1. Security requirements analysis and specification    4.2. Assessing security risks  The potential risks associated with the implementation of a new solution need to be assessed at the beginning of the SDLC. The  assessment of security risks should be included in the solution co‐ordinators checklist and follow the method specified in the  Solution Risk Assessment Methodology for Solution Design.   Risk assessments should identify, quantify, and prioritize risks against criteria for risk acceptance (or avoidance) and the objectives  of the solution being developed and/or the objectives of DIT. They should be performed in a methodical, standardised, reproducible  manner.   The risk assessment should have a clearly defined scope. For the purposes of the document the scope would usually be the  individual solution being developed, however it should include relationships with risk assessments on other solutions in  development or production. It may also have to include elements of risk to the entire organisation.  The output of a risk assessment should then determine the appropriate level of risk management. The appropriate level of risk  management will guide and determine priorities when implementing controls to minimise risk.  Risk assessments should include a systematic approach of measuring or estimating the magnitude of risks (risk assessment) and the  process of comparing the estimated risks against risk criteria to determine the significance of the risks (risk evaluation).  Risk assessments should also form part of the SDLC review process that includes re‐assessing the risks of a solution periodically  and/or when significant changes occur. 

  4.3. Treating security risks  Once the security requirements and risks have been identified and the decision for the treatment of risks has been made, the  appropriate controls should be selected and added to the design document. Controls can be selected from the ISO27002 standard or  from other control sets, or new controls can be designed to meet specific needs as appropriate.    The selection of security controls is dependent upon the solutions criteria for risk acceptance, and risk treatment options and should  also be subject to all relevant national and international legislation and regulations. 

  4.4. Correct processing in applications.  Correct processing in applications is needed to prevent errors, loss, unauthorised modification or misuse of information in  applications.Security controls should be implemented that ensure the validation of input data, internal processing and output data. 

  4.5. Cryptographic controls.  Cryptographic controls can be used to protect the confidentiality, authenticity and integrity of information.  The need for cryptographic controls can be determined by risk assessment processes and also  the data’s classification level as  determined by the CSU Master Data Governance process.  Cryptographic controls may be needed in both information storage and transmission.  If the use of cryptographic keys is to be considered, a key management process is essential to ensure distribution, storage, changing,  revoking, recovery, archiving, destroying of keys. 

    Page 9 of 19 

CSU Technical Solution Design Document       

5. Infrastructure Design  Infrastructure design provides details and guidance on the common design considerations that are required to made when designing  infrastructure solutions within the CSU DIT.   

  Environments required ‐ Mark required environments with an “X”  Environment 

Role

Production  

clients conduct business

Quality Assurance  

Functional testing of in‐house enhancements

Development  

In‐house enhancements developed and tested

Training  

Client application training

Implementation   

New versions implemented and tested prior to  migration to production 

  Life span of environments    

Permanent 

AdHoc

Production  Quality Assurance  Development  Training   Implementation 

                 

  5.1. System Architecture (development, qa and production implementations)    Operating System     Server Spec  Architecture  Number of CPU’s  RAM  Data centre 

 RedHat Enterprise 5 (x86) 

       

  Allocated storage  Raid Type  raid1+0 (SAS fibre channel) 

Size   20G 

Mount Point /

   

         

raid 5 (SAS fibre channel)  raid 5 (Sata)  Local Attached storage   

    Page 10 of 19 

CSU Technical Solution Design Document      Disk 

Size 

Type

C1t1d0 

146G

SAS

   

           

  Disk 

Mount Point

Raid Type

C1t1d0  

/ 

Raid 1

C1t2d0 

/ 

Raid 1

 

           

Meta Devices  Device 

Sub mirror of 

Mount Point

Raid Type

d10 

 

/

Raid 1

 

 

/

Raid 1

 

Mount Point 

         

Raid Type

d11 

Raid 1

  Operating System Partitions  Partition 

         

/ 

Raid 1

Size 

Type

/ 

10G

/var 

20G

 

           

Network  DNS 

VLAN (campus, public,  secure) 

Ip  

 

       

Shares  Protocol 

Location 

     

Version 

   

    Required Installed Software  Software    

 

Backup  

    Page 11 of 19 

CSU Technical Solution Design Document      Partition 

Frequency 

Rotational/ Archive 

Timeframe

 

 

Database  Vendor  Version  Machine  Partition  DB Name  DB Service Name      DB User  DB Pw 

   

 

                   

 

    Page 12 of 19 

CSU Technical Solution Design Document      5.2. Infrastructure Management  5.2.1. Availability requirements  How long can the system be unavailable before it starts to impact on the business. Is this impact felt only during business hours or  does this extend after hours or during weekends.  

  5.2.2. Business continuity fail over and fail back  Business continuity provides a level of backup that will enable the service/application to be restored to working order in a defined  period. What standby systems are available for fail over of the application services. How is fail over achieved and what procedures  are in place to perform this process. 

5.2.3. Archival requirements  Are there any archival requirements with logs or other created data. If any, what are the retention periods for this information?  Remember backup storage is rotated so if you need data from a point in time greater than the frequency of the backups you need to  specify this as an archival requirement. 

5.2.4. Maintenance  Are there any maintenance plans for any of the systems. What level of maintenance is provided.  

5.2.5. Log file rotation  Are there any logs produced by the application. What information is available in the log files and for what period are they required  to be kept. 

5.2.6. Starting and stopping the application  What interfaces are available to start and stop the application. What documentation is available to operators to check the status of  the application. Are there any checks or dependencies that need to be considered before the application can be started or stopped. 

  5.2.7. Monitoring interfaces  

 

 

What external monitoring of the system can be done to alert people of an outage.Self monitoring ‐ Is there any configurations  required to allow the application to alert operators of potential issues (ping/Service based). 

  Nagios  Server Name 

Test 

Notification Timeframe

Contact Group

 

 

 

 

Server Name 

Test 

Notification Timeframe

Contact Group

 

 

 

 

  OEM 

  5.2.8. Dependences   What external dependencies does this application have. What impact would an external outage have on the functions of the  application. What depends on this system and how would an outage of this application impact on other systems. 

        Page 13 of 19 

CSU Technical Solution Design Document      5.3. Access Control  5.3.1. Business Requirement for Access Control  Define access control policy 

5.3.2. User Access Management  User registration, provisioning, privilege and password management. 

5.3.3. User Responsibilities  Password policies, unattended user equipment and clear desk and clear screen policy 

5.3.4. File System Access Control  Physical or logical access to systems by suppliers for support should be monitored and changes authorised using the change  management process. Protection of system test data and access to program source code security control. 

5.3.5. Network Access Control  What access controls are to be implemented on the network level. Are their policies that relate usage from specific machines or  locations?  

5.3.6. Mobile Computing and Tele‐working  What are the considerations around using the application from off campus. 

5.3.7. Operating System Access Control  Secure log‐on procedures, user identification and authentication, use of system utilities, session time‐out and limiting of connection  time 

5.3.8. Third Party management and access  Is this system managed by a third party if so who and how do we contact them. How do they access the system and who in CSU do  they report to. 

5.3.9. Physical and Environmental Security    5.3.10. Application and Information Access Control   Information access restriction and sensitive system isolation 

     

 

    Page 14 of 19 

CSU Technical Solution Design Document      5.4. Application Management  5.4.1. Third Party Service Delivery Management  Service delivery, monitoring and review of third party services and managing changes to third party services. 

5.4.2. Operational Procedures and Responsibilities   Documented operating procedures, change management, segregation of duties, separation of development, test, and operational  facilities 

5.4.3. Upgrade and code migration  How are upgrades to the application and or hardware delivered. 

5.4.4. OS patching and security patching  What level of OS patching is requested. Does any group need to be consulted about the timing of patching 

5.4.5. Solution dependencies  Are there any other applications or physical hardware that need to be installed? What version of the application? Are they installed  as part of the application and hardware installation or do they need to be acquired and installed separately? 

5.4.6. Job management (cron, timed processes, ...)  What timed processes are required and what is their purpose and frequency. 

5.4.7. User interactions (printing, output folders, http, ssh, ... )   How do users interact with the application output folders, web access, ssh, ftp, file shares, telnet or other access. Is printing required  from a Web or/and Application server, please specify any UNIX print queues that will be required and if they need any other settings  eg: portrait/landscape 

5.4.8. Licensing  What software and/or hardware licences have been purchased. What in summary are the limitations of these licenses. 

5.4.9. On going costs  What ongoing costs (licensing, maintenance) are associated with the application. What process is capturing these and managing  these. 

    5.5. Client Applications  5.5.1. Architecture   How do/will the clients connect to the application? 

5.5.2. Installation   How will the application be delivered and to what user base 

   

    Page 15 of 19 

CSU Technical Solution Design Document      5.6. Migration   5.6.1. Migration strategy (how are we going to go into production)  How is the system going to be made available without impacting on current systems. What changes to other systems need to be  made to make this service operational. 

5.6.2. Rollback strategy  What changes have been made to other systems to accommodate this application. Document how these can be removed without  impacting on other systems. 

5.6.3. Decommissioning   Does this system replace the functions of other production systems? What systems are these and what process is in place to remove  these systems that are now redundant? 

 

    Page 16 of 19 

CSU Technical Solution Design Document     

6. Test Design  Testing should occur at each stage in the Development Lifecycle.  Some of the activities below should be performed as part of  Project Management activities. 

  Note: Currently testing will occur in this document as an end to end process, but will have some sections moved to the SDLC intro  document as revisions occur so that there is a testing overlay in the intro doc and a checklist in this document of testing elements  that should cover the solution design. 

  6.1. PSC/SDLC Analysis Phase (Requirements Testing)  6.1.1. Use Cases  As the requirements are completed, Use Cases should be developed to model process flows. These are then used at multiple levels  throughout the process and once signed off by the business, are themselves a test to ensure requirements are correctly defined.  Use Cases should be developed by the Business Analyst (BA) and/or Business Expert (BE) and should include sample data which can  be used in test execution 

6.1.2. Risk Register  A key reason for testing is to reduce the level of risk and convey the current level of risk to the management and stakeholders.  In  real‐world situations testing is likely to be constrained by availability of resources or time or both and therefore it is imperative that  testing is prioritised based on the risks identified.  Risks should be identified for each requirement defined as well as for general  risks. Use of a risk checklist such as one modelled on ISO 9126 is highly recommended.    The Risk Register should be developed by the Project Manager (PM) in conjunction with the Project Team.  The following table shows the risk matrix: 

    Likelihood  Very High  High  Low  Very Low 

Severity  Very High  A  A  A  B 

High  A  B  B  C 

Low  A  B  C  C 

Very Low  B  C  C  C 

6.1.3. Requirement validation  At least one technique such as Cause‐Effect or State Transition testing should be applied to the requirements to unearth potential  problems before progressing further through the design.    These techniques should not be performed by the same person who wrote the requirements, and is likely to be the responsibility of  the PM or BE.   

6.2. PSC/SDLC Design Phase (Functional Testing)    Functional testing ensures that the functional components of the solution have been constructed in line with functional  specifications prior to undertaking integration and acceptance testing.     Test cases should be developed from the functional specification and use cases.  Use cases provide a valuable backbone to test case  preparation due to the correlation between a use case and associated test cases.    Test cases should identify the functional requirement, use case or risk being tested, the steps necessary to perform the test and the  expected outcome of the test. 

    Page 17 of 19 

CSU Technical Solution Design Document        Test Case preparation and execution should be prioritised based on the risk register for the system.  High risk items should have  more test cases associated with them and be tested more thoroughly and low risk items may not be tested at all given time and  resource constraints    Functional test cases are specific to the function being tested and test the execution of that function. However there should be  additional test cases that cover functionality of the system once the components are integrated together.    Unit Test Preparation  Description:  Unit Tests are usually automated and get run each time a build of the system   happens. While they add development time, they greatly assist in the confidence in the system components and reduce the risk that  changes will introduce defects. They are written at the very lowest level of testing outputs from known inputs.  Responsibility: Developer  Preconditions: Signed off Requirements Documents  Outputs: Unit test execution reports    Input Validation & Boundary Value Test Preparation  Description: Input Validation and Boundary Value tests ensure that invalid input to the system is correctly trapped and handled.  They try to make the data as ‘clean’ as possible to avoid data inconsistencies and unformatted error being reported to the end user.  Responsibility: Developer  Preconditions: Completed Unit Test Execution  Outputs: Test Case execution documentation    Unit Test Execution  Responsibility: Developer  Preconditions: Signed off Requirements Documents  Outputs: Unit test execution reports    Input Validation & Boundary Value Test Execution  Responsibility: Developer  Preconditions: Completed Unit Test Execution  Outputs: Test Case execution documentation    Accessibility Test Preparation  Description:  Accessible applications and systems are now legal requirements.  Systems should comply with the relevant  accessibility policies and guidelines, such as the CSU WDAAP.  Responsibility: Developer  Preconditions: All other design phase testing completed  Outputs: Accessibility Test cases    Accessibility Test Execution  Responsibility: Developer  Preconditions: All other design phase testing completed  Outputs: Accessibility report 

  6.3. PSC/SDLC Testing Phase (Verification Testing)    Integration Test execution  Description: Integration testing is performed once testing of discrete functions is completed and ensures that the functions of the  solution operate together as specified in the functional requirements  Responsibility: Systems Officer  Preconditions: System components individually tested and assembled  Outputs: Test Case execution documentation 

    Page 18 of 19 

CSU Technical Solution Design Document        System Test execution  Description: System tests focus not only on the design, but also the behaviour and even the believed expectations of the customer.  They also test up to and beyond the bounds defined in the requirements specification, and include areas such as regressions and  Security testing.  Responsibility: Systems Officer  Preconditions: System components individually tested and assembled  Outputs: Test Case execution documentation    Performance, Load and Stress Test execution  Description: Performance – measuring system response times and load under expected normal conditions including other  applications and user numbers Load – measuring system response times and load under expected peak periods Stress – finding the  breaking point of the system in terms of volume of traffic, numbers of users etc  Responsibility: Systems Officer  Preconditions: System Officer completes other testing, code moved to QA  Outputs: Performance metrics 

  6.4. Implementation Phase    User Acceptance Testing (UAT)  Description: Testing of real‐world situations with realistic data by actual users of the system.  Responsibility: Business Users with guidance from system officers  Preconditions: System Officer completes testing, system ready for release, code moved to QA  Output: Signed off document stating that the business is happy with releasing the product to production,  listing tests conducted in detail and the results of those tests. 

    Page 19 of 19