Software Requirements Specification
From TeamF::CGT
Revision:
Abstract
This document formally specifies the requirements of the Corporate Governance Toolkit. The purpose of this document is to facilitate an agreement between the client and Team F as to the software product to be created. It will also be used in design, testing, and validation and verification in the later stages of this project.
Introduction
Purpose of the Document
The purpose of this document is to formally outline all the software requirements for the Corporate Governance Toolkit and to ensure the software produced satisfies the client’s expectations.
Also, this document serves as:
- a technical contract that binds the client and team to an agreement. The client agrees that the requirements specified are accurate while the team consents to producing the software according to the requirements specified;
- a reference for the stake holders involved in the development of the software. The document serves to present the requirements to the technical and non-technical stake holders in a concise manner.
The intended audience of this document are the team members and the client.
Scope of the Document
This SRS will provide details about the general and specific requirements that are associated with the software. This SRS will propose a proof of concept with each functional requirement stated. The reasoning behind for the proof of concept is that the software is abstract and flexible.
Project Information
Team F
The team that will be responsible for creating the software will be 433-440[1] Team F, also known as Team F. The members are:
| Name | Team Role | Email(@students.csse.unimelb.edu.au) |
|---|---|---|
| Stephan Taitz | Project Manager | sptaitz |
| Tim Fang | Project Manager | tfang |
| Derek Tong | Client Liaison | tong |
| Amiel Zwier | Quality Assurance | aczwier |
| Fan Zhang | Software Admin | fzhan |
| Ivan Seow | Research Manager | iwhs |
| Jack Gao | Design Manager | jbgao |
| Luke Jones | Risk Manager | ljjones |
| Shankar Sribalachandran | Requirements | srib |
| Sie Ming Huang | Requirements | smhuang |
| Yan Ming (Eric) Huang | Implemenation Manager | ymh |
| Zhao Hui (Gary) Liang | Test Manager | zhl |
The Supervisor
The project supervisor is Steele Griffiths.
The Client
The Client is Risk Wizard. Risk Wizard provides corporate governance software and services for risk management, performance, voting systems and whistle-blowing. Risk Wizard has clients based in North America Europe, Middle East and Australasia. Risk Wizard’s Risk Management Software is a user-friendly system for managers to analyze risk and adopt a holistic approach regardless of size, industry, location or complexity. For more information regarding the current system, please refer to Existing System.
Acronyms
| Term | Definition |
|---|---|
| CGT | Corporate Governance Toolkit |
| Client | Risk Wizard |
| ChartFX | A Graphical Program |
| Dundas | Another Graphical Program |
| End-User | The users of the End-System |
| End-System | A system created with the CGT |
| GUI | Graphical User Interface |
| Portable Document Format | |
| Stakeholders | People who have a share in the project |
| SRS | Software Requirements Specification |
| RW | Risk Wizard |
| W3C | World Wide Web Consortium |
Definitions
| Definition | Description |
|---|---|
| Core | In the context of the Corporate Governance Toolkit project, the term ‘core’ is used throughout this document to describe requirements that are essential functionalities of CGT. All core requirements must be implemented satisfactorily for the software to be accepted by the client. |
| High Non-Core | The term “High Non-Core” used to describe requirements that are not essential to the functionalities of CGT. But they must be implemented satisfactorily for the software to be accepted by the client. |
| Medium Non-Core | The term “Medium Non-Core” used to describe requirements that give desirable functionalities to CGT. While these requirements are expected to be implemented, but they are not included as part of the requirements that must be implemented for the software to be accepted by the client. |
| Low Non-Core | In the context that the term “Low Non-Core” is being used throughout this document, it refers to requirements which have the lowest priority in being implemented. These additional requirements are to be implemented only if the time permits. |
References
Risk Wizard Website - http://www.riskwizard.com
Overview Description
Project Information
The Corporate Governance Toolkit (CGT) is a toolkit that can be used to create customised corporate governance applications. These customised applications may include:
- Risk Management Systems;
- Compliance Systems;
- Performance Management Systems; and
- other Corporate Governance Systems.
The Client
The Client will use the Corporate Governance Toolkit in multiple ways. The Client may:
- Distribute the Corporate Governance Toolkit as is, with the intention that the end-user will use the Corporate Governance Toolkit in order to create their own corporate governance software; or
- Consult with an end-user, create customised corporate governance software for the end-user, then distribute it to the end-user.
Existing System
Context
The existing system, Risk System is a tool that assists an organisation identify, analyse, measure and report the risks it faces. The Risk system essentially provides an organisation with a central database that holds information about risks from all the different division and produce a report that calculates the risk profiles and the impact on each division and on the whole organisation.
Risk System was developed by our client, Risk Wizard to manage the risks as recommended by Australian Risk Management Standards. It has been sold to their clients as packaged software.
System Functionalities
Risk System software breaks the risk management into Identification, Analysis, Evaluation, Treatment, Review and Reporting phases. It allows the users to enter information about a risk after a user has completed the recommended risk management procedures in these phases. Risk System also produces necessary reports to support the analysis of risks.
The functions of the system are described below during each phase of risk management:
- Identification: Allows the users to create new risk by entering information about its characteristics.
- Analysis: Allows the users to enter information from the analysis of a risk such as the impact of the risk and parties affected
- Evaluation: isk System calculates the risk rating for the entity for a particular risk before and after a preventive action is taken.
- Treatment: Allows the users to enter information about how to tackle a risk.
- Review: User enters the information from the outcome of the review of risk.
- Reporting: Produces the a comprehensive report that details attributes of the risk such as source of risk and parties affected and calculates the impact of risk for the work group that risk belongs to and for the whole organization.
Software Environment
The Risk System is currently available as both a web-based system and stand-alone to be used on personal computers. Both web-based and stand-alone offers the same functionalities and similar user interfaces.
User Characteristics
The Risk System is currently used in medium businesses to large multi-antinational companies and government departments. The primary users of the current software are professionals working in an organization.
Problems
The major limitation of the current software is the inability to easily customize the software to match the users’ needs. Risk System is based on the recommended Australian Risk Management Standards however the risk management policies tend to vary across the organizations, as the result, the existing system can not support the organizations’ needs. In particular, the fields of data become irrelevant and certain phases are not applicable to certain organization. This makes it cumbersome for the organizations to implement their risk management policy using Risk System. The lack of flexibility reduced the opportunity for Risk Wizard to sell the product.
There are also some technical deficiencies with the current system. Risk System acts more of a data collection and presentation tool with capacity to produce only one non-customizable report.
Although the current system is unable to meet different organisation needs, it provides a good platform to build more powerful and sophisticated software.
Proposed System
Context
The purpose of Corporate Governance Tool
The aim of the proposed system, the Corporate Governance Toolkit (CGT) is to provide organizations with a single system to manage all their corporate governance needs. CGT must not only overcome the lack of customization of the existing system, but also provide multiple integrated tools as part of a single system to record, analyze and report on different corporate governance issues.
In order to better understand the purpose of the CGT, the nature of corporate governance must be understood.
Corporate Governance
Corporate governance is a term used to describe the organizational structure, business policy, guidelines, internal and external regulation and performance monitoring mechanisms that ensure that the corporate affairs are conducted in a transparent and accountable manner. The objectives of the corporate governance policies are to promote efficient use of resources and give a sense of direction and control to an organization.
While the corporate governance policies of different organization may share some common principles, they are often different and are tailored to suit each organization’s unique culture, their set of goals and the industry they operate in. For example, organizations, operating in different industries need to comply with different government, accounting, health and environmental regulations. These organizations need tools to assist them with compliance and control. An Organization that operates in a dynamic market such financial trading will need regular risk assessments of its operations and will require tools that assist in risk management. All organizations typically measure the performance of their various business units and staffs to formulate their business strategy and reward their staff.
Given the nature of corporate governance, a centralized software that contain integrated multiple tools that are tailored to manage different aspects of an organization’s corporate governance would provide an organization with a powerful and sophisticated business tool.
Project Objective and Scope
CGT aims to provide an organisation with a single centralised system that consists of all the different tools needed to implement an organisation’s corporate governance policies. Given that each organization’s corporate policy is quite different, any tool built must be tailored to an organization’s needs.
CGT addresses these two identified needs for the corporate governance software by providing web-based software that gives the users the capacity to build their own corporate governance tool kit.
In order to achieve this goal, CGT must be able to dynamically build any tools needed to address an area of corporate governance and integrate these different tools into a single functioning system.
CGT endeavors to able to create applications to support Risk Management, Control and Compliance Management, Privacy Management, Dashboards, Activity Alert, Performance Management, Incident management and Issue Registers. However, given the limited the resources and time constraints of the 440 team, the CGT software will only be able to dynamically create applications or end-system that support:
- Risk Management
- Compliance Management
- Performance Management
CGT will be expanded in the future by Risk Wizard to support the creation of other types of tools.
User Characteristics
The CGT software and the End-System will be used within medium to large multinational organizations. The End-System will be accessible to the users of End-System on the organization's intranet, internet or iva the LAN/WAN.
The target users of CGT belong to three categories:
- Toolkit Administrators
- End-System Administrators
- End-System Users
Toolkit Administrators
Toolkit Administrator are the users of CGT who create an end-system using CGT. The Toolkit Administrators are typically the employees of our client, Risk Wizard who may be asked by an organisation to build them a particular corporate governance tool.
In some cases, Toolkit Administrators also be the employees of the clients of Risk Wizard. Toolkit Administrators will be expected to have comprehensive knowledge of the corporate governance policy of an organization. They are also expected to be familiar with the basics of database structure such as different data-types and the constraints placed on them, in order to create an end-system in CGT.
End-System Administrators
End-System Administrators refer to employees of the clients of Risk Wizard who will modify or maintain the end-product. They will be given access to more functionalities of the end-system in order to maintain the end-system. They will be given permissions to delete records and modify the appearance of the end-system.
End-System Users
The users of the end-system developed using CGT will typically be employees of an organization. These users are expected to possess good computer skills and are not expected to require any training to familiarize them with the interface of the end-system of CGT.
System Characteristics
The CGT should be robust in order to allow rapid development of applications that facilitate implementation of a corporate governance policy. While the software is geared towards dynamically building corporate governance tools, it is essential that software remains as much flexible as possible in order for it to be extended. The key success factors of CGT software are as follows (not in any order of importance):
- Flexibility to cater for organization differences.
- Provide facilities to easily customize the end-system.
- Graphic aesthetics of the end-system
- Support for languages other than English.
- Build applications that interact and inter-link and remain integrated within a single system
- Efficient information sharing, filtering and retrieval in the end-system
- Extendibility to facilitate future development
- Process automation
- Ease of maintenance
System Functionalities
Since CGT is used to dynamically build an application, the functionalities of the end-system of CGT must be understood so that CGT can provide the means to build the end-system with the required functionalities.
High Level Description of a Typical End System of CGT
While not all the corporate governance tools are same, there are fundamental principles or similarities across all corporate governance tools.
A typical corporate governance tool, therefore the end system of CGT must have the following functionalities:
- Information Collection and Storage: The end-system must have means of collecting information from users and store them in a data repository for future retrieval. Since collection of the information about various corporate aspects is fundamental to allow analysis, the information must be validated to ensure the integrity of data and shared in an efficient manner. The user must be able to view the information and update the information in the database. For example, In an end-system for risk management, the users of that end system will need to define risk and enter information about the risks.
- Analysis of Information: The end-system must be able to facilitate analysis of information, stored in the database. The end-system must perform calculations and interpret the information to produce meaningful reports. These reports must be displayed to the users. For example, an end-system for risk management must be able to retrieve information about risks of a particular department and produce risk profile for that department based on the specified risk-rating calculations.
- Generation of Reports and Graphs: The end-system will need to produce various reports and graphs based on the information. For example, the end-system for performance management may need to generate a bar graph that shows the sales of different business units.
- User Communication: The end-system must be able to automatically send alerts by email to the users of an impending event. For example, an end-system for risk management may send a warning message by email to the users from a department when the risk rating for a particular risk increases above a certain level.
- Privacy and User Permissions: The end-system may contain sensitive information the operation of an organization. Therefore the access to such information must be restricted to only few users. The end-system must be able to define the access of each users based on their level of authority in the organization and permission.
High Level Description of the Functionality of CGT
CGT will provide the functionality to build a typical end-system (see Generate End-System).
The primary functions of CGT are as follows:
- Set up structure of the end-system
- CGT will provide the means to set up the structure of database to collect and store information and organise the information in a meaningful form.
- CGT must also provide means to design the reports needed for the end-system and the facilities to view those reports in the end-system. This will require the CGT to provide functionalities that allow the mathematical calculations to be performed on the relevant information.
- CGT must also provide ways to build an email communication in the end-system and the automatically send emails to users if a specified condition is met.
- Set up the interface for the end-system
- CGT must provide means to create Graphical User Interface (GUI) for the end-system. The interface must be easily linked to the information stored in the database of the end-system and the defined reports to facilitate the collection of information, viewing of information reports and graphs in the end-system. CGT must allow the interface of the end-system to be easily customised.
- Compile and generate the end-system
- CGT must be able to automatically compile the end-system once it has been built and allow the end-system to be deployed and used by the users of the end-system.
Low-Level Description of the Functionalities of CGT
The functionalities of CGT can be categorized into three broad groups:
- Setting up the Structure of End-System
- Designing the Interface for the End-System
Setting up the Structure of End-System
CGT must provide functionalities to set up the structure of the end-system by allowing the users to create the data structure and design reports for the end-system. The user of CGT will be expected to have a comprehensive understanding the corporate governance policy to be implemented and the knowledge of basic database design.
CGT provide the functionality to create a database as part of the end-system. The database table will be used as the fundamental unit of data structure to represent an object. CGT will create database table by providng the means to specify the name, its attributes and any constraints that apply on the table. For example, in a risk management end-system, a “risk” will be represented by a database table with all its attributes as the fields of the table. CGT will also have the functionalities to add, delete or modify any database tables. The CGT will allow the users to set the dependencies between the database tables.
In order to organise the information contained in the database in a meaningful form, CGT will allow the users to create a hierarchical tree structure. The tree structure will show the relationships between each database table.
CGT will have the functionalities to create reports. CGT will allow the users to select the database tables and attributes to be used to generate the reports and support mathematical functions used in report generation. CGT will produce reports in a format that can be read by Dundas or Chartfx reporting tools.
CGT will provide standard database structures and process automation to speed up the process of creating the end-system.
Designing the interface for the End-System
Once the structure of the end-system has been set up, CGT must provide the functionalities to set up the interface of the end-system so that the users of the end-system can enter information and view reports.
CGT will allow the users to define views for the objects in the database tables. CGT will provide a CSS editor to design the look and feel of the interface. CGT will also contain ready-made templates for the interface that users can import for the interface.
CGT will support the report design by using ActiveReports, Dundas Chart and ChartFX.
Software Interface
CGT and the end-system will be interfaced through a web browser that supports .NET UI control rendering, mainly Internet Explorer and FireFox. The interface of the software should be intuitive enough to allow rapid development of end-system. The interface of the end-system is extra important as it is one of the key success factors of the software. The software must provide an intuitive yet very eye-catchy and customisable interface. The interface must facilitate very pleasant interaction with the users.
High Level Use Case Diagrams
Functional Requirements for First Stage - Setting up System Structure
This section outlines the functional requirements of the first stage of using the CGT system. In this stage a Toolkit Administrator creates and configures the database structure of an End-System for use by an End-User. A sample GUI of how this stage may look is provided below for guidance only.
Create Database Tables
A Toolkit Administrator shall be able to create a database table through a GUI by specifying:
- a name;
- the number of attributes;
- the name of each attribute;
- the permission level for the table (see Set Permission Level);
- the foreign keys of the table (if applicable);
- the data type of each attribute (see Support Data Types);
- the constraints of each attribute.
Proof of Concepts
Please refer to Proof of Concepts: Create Database Tables.
Dependencies
Selectable Data Types (see Support Data Types).
Set Icons for Tables and Attributes
A Toolkit Administrator shall be able to set icons to represent each table and each attribute in a table.
Proof of Concepts
N/A
Dependencies
Create Database Tables (see Create Database Tables).
Set Permission for Table
Description
A Toolkit Administrator shall be able to set the permission level for a table such that in the End-System, only an End-System Administrator can add, edit or delete records in that table. An End-System End-User will only be able to view records in that table. This may result in making the Proof of Concept: Create Table that Represents Users a compulsory table that must be created in every End-System.
Proof of Concepts
N/A
Dependencies
Create Database Tables (see Create Database Tables).
Set Special Attribute Properties
Description
A Toolkit Administrator shall be able to set states for each individual attribute of each table created above through a GUI.
Proof of Concepts
Please refer to Proof of Concepts: Set Special Attribute Properties.
Dependencies
Create Database Tables (see Create Database Tables).
Support Data Types
Description
For each attribute of each database table created, a Toolkit Administrator shall be able to use a GUI to specify the type of the attribute as one of:
- bitint
- int
- tinyint
- nchar
- nvarchar
- ntext
- bit
- datetime
- images
- money
- xml
- double
- float
- varchar
- blob
Proof of Concepts
Please refer to Proof of Concepts: Create Database Tables.
Dependencies
Create Database Tables (see Create Database Tables).
Edit Table Properties
Description
A Toolkit Administrator shall be able to edit table properties through a GUI, including:
- the table name;
- the number of attributes;
- the name of each attribute;
- the permission level of the table (see Set Permission Level);
- the foreign keys of the table (if applicable);
- the data type of each attribute (see Support Data Types);
- the constraints of each attribute.
Proof of Concepts
N/A
Dependencies
Create Database Tables (see Create Database Tables).
Delete Tables
Description
A Toolkit Administrator shall be able to delete a selected table through a GUI.
Proof of Concepts
N/A
Dependencies
Create Database Tables (see Create Database Tables).
Define Values in Relation to Other Values in Database
Description
When inputting data into a table, a Toolkit Administrator shall be able to define a values in relation to values in other tables through a GUI. The user shall be able to do this by:
- concatenating strings; or
- arithmetic data manipulation; or
- arithmetic number manipulation.
Proof of Concepts
Please refer to Proof of Concepts: Define Values in Relation to Other Values.
Dependencies
- Create Database Tables (see Create Database Tables).
- Input Records into Tables (see Input Records into Tables).
Set Constraints (High Non-Core)
Description
A Toolkit Administrator shall be able to set the behaviour of an object to be dependent on certain values in the database using a GUI.
Proof of Concepts
Please refer to Proof of Concepts: Set Constraints.
Dependencies
- Create Database Tables (see Create Database Tables).
- Input Records into Tables (see Input Records into Tables).
Set Triggers (High Non-Core)
Description
A Toolkit Administrator shall be able to use a wizard system in order to define an event that if occurs, will make the system perform one of the following:
- Send an email to an address either manually entered from stored as a value in any table in the database.
- Create a log of attributes that are set to be logged.
- Take a snapshot of the database.
- Create a new record.
- Duplicate an existing record.
Proof of Concepts
Please refer to Proof of Concepts: Set Triggers.
Dependencies
- Create Database Tables (see Create Database Tables).
- Input Records into Tables (see Input Records into Tables).
Create Tree Structure
Description
A Toolkit Administrator shall be able to create tree structures using tables. The user shall be able to specify the:
- name of the tree;
- value of each node in the tree;
- type of each node in the tree;
- parent of each node in the tree (if any);
- child(ren) of each node in the tree (if any).
Proof of Concepts
Please refer to Proof of Concepts: Create Tree Structure.
Dependencies
- Create Database Tables (see Create Database Tables).
Create Multiple Labels for Attributes
Description
A Toolkit Administrator shall be able to define each attribute in a table as having multiple values.
Proof of Concepts
Refer to Proof of Concepts: Support Multiple Labels for Attributes.
Dependencies
None.
Functional Requirements for Second Stage - Defining Views
This section contains functional requirements for the second stage of the system. During this stage, a Toolkit Administrator would customise the visual appearance of the End-System to be created by:
- defining views for objects created in the First Stage; and
- styling the End-System through CSS.
A sample GUI of how this stage of the system may look is provided below for reference only.
View Database Trees
Description
A Toolkit Administrator shall be able to view the Trees of an End-System created in the First Stage in order to define the views for each object in the Tree. When a Tree is selected, all attributes of each object in the Tree shall be displayed.
Proof of Concepts
N/A
Related Requirements
Set Report as View
Description
A Toolkit Administrator shall be able to define a report as a view for a particular object in the End-System.
Proof of Concepts
Please refer to Proof of Concepts: Set Report as View.
Dependencies
Set CrystalReports Report as View (Low Non-Core)
Description
The Toolkit Administrator shall be able to define an Crystal Reports report as a view for a particular object in the End-System.
Proof of Concepts
N/A
Dependencies
Set Dundas Chart as View (Low Non-Core)
Description
The Toolkit Administrator shall be able to define a Dundas chart as a view for a particular object in the End-System.
Proof of Concepts
Please refer to Proof of Concepts: Set Dundas Chart as View.
Dependencies
Set ChartFX Chart as View (Low Non-Core)
Description
The Toolkit Administrator shall be able to define a ChartFX chart as a view for a particular object in the End-System.
Proof of Concepts
N/A
Dependencies
Set Default View
Description
When a record is selected, the Toolkit Administrator shall be select which view to be the default view for either:
- all records of that type; or
- the selected record only.
Proof of Concepts
N/A
Dependencies
- Create Database Tables
- View Database Trees
- Set ActiveReports Report as View
- Set Dundas Chart as View
Plain Text Browser-Based CSS Editor (Low Non-Core)
Description
The Toolkit Administrator shall be able to use a hierarchical plain-text web-based CSS editor to edit the appearance of the End-System.
Proof of Concepts
N/A
Dependencies
None.
Load CSS Templates
Description
The Toolkit Administrator shall be able to change the appearance of the End-System by loading an existing .css file into the plain-text web-based CSS editor.
Proof of Concepts
N/A
Dependencies
None.
Support Multiple Labels for Attributes
Description
If a Toolkit Administrator has created a table attribute with multiple labels through the Create Multiple Labels for Attributes feature in the First stage, the End-System shall have an option whereby the different values can be shown.
Proof of Concept
Refer to Proof of Concepts: Support Multi-value Attributes.
Dependencies
None.
Generate End-System
Description
At the end of this stage, after a Toolkit Administrator has defined all appropriate views, the system shall be able to generate an End-System that satsifies all the requirements set out in Functional Requirements for Third Stage - Using the End-System
Proof of Concept
N/A
Dependencies
None.
Functional Requirements for Third Stage - Using End-System
This section outlines the requirements for a created End-System. A sample GUI of a possible End-System is provided below for reference only.
View Records by Tree
Description
A created End-System shall allow an End-System Administrator or End-System End-User to view all Trees created in the First stage. When a Tree is selected, all records in that Tree shall be displayed hierarchically according to their level in the Tree.
Proof of Concepts
N/A
Dependencies
View Records by Spider Web View (Medium Non-Core)
Description
The system shall allow an End-System Administrator or End-System End-User to view records in a spider web.
Proof of Concepts
None.
Dependencies
None.
View Records from Bird’s Eye View (Medium Non-Core)
Description
The system shall allow an End-System Administrator or End-System End-User to view records as a bird’s eye view. The data shall be displayed in terms of rings. The size of each ring is dependent on the total number of records that fall within the band. Each ring can then be segmented according to the number of members that they have.
Proof of Concepts
N/A.
Dependencies
None.
Filter Records
Description
There will be a filter function for viewing records that allows an End-System Administrator or End-System End-User to view only certain records in the selected Tree.
Proof of Concepts
N/A.
Dependencies
Show Views
Description
When an End-System Administrator or End-System End-User, a record within the Tree is selected, the default view for that record will be displayed.
Proof of Concepts
N/A
Dependencies
Context-Specific Buttons
Description
The End-System shall show buttons relevant to the current record selected. For End-System Administrators, there will always be buttons to perform each of the following functions:
- Add new record of type currently selected
- Edit selected record
- Delete selected record
- Duplicate selected record
However, for End-System End-Users, some of these buttons may be unavailable if the Set Permission Level has created restrictions for that type of object.
Proof of Concepts
N/A
Dependencies
Select View for Record Type
Description
Once a record has been selected and the default view has been displayed, there shall be a drop-down box in a panel within the web browser window that allows an End-System Administrator or End-System End-User to change the view for that record. The available views shall be those created for that record type in Functional Requirements for Second Stage - Defining Views.
Proof of Concepts
N/A.
Dependencies
[[Software Requirements Specification#View Records by Tree|View Records by Tree]
Select Default View
Description
Once a view has been selected, the End-System Administrator or End-System End-User will be able to set that view as the default view so that either:
- the next time a record of that type is displayed, the current view will be displayed as the default; or
- the next time that specific record is displayed, the current view will be displayed as the default.
Proof of Concepts
N/A
Dependencies
Non-Functional Requirements
This subsection outlines the non-functional requirements and constraints of each of the three systems that form the CGT.
Browser Compatability
The system shall be able to run on IE 6.0+ and Firefox 1.5+.
Software System Attributes
There are three quality goals that the software system has to achieve:
- Correctness;
- Completeness;
- Consistency.
User Documentation
User documentation will include a User Manual, Maintenance Document and Online Help.
Tool Tips
The system shall be able to show tool tips on all the relevant entities or attributes of the system. The tool tips shall be information on the entity or attributes itself. The tool tips for each of the entities are provided to help inexperienced users of the system.
User Manual
A user manual will be supplied with the software, incorporating the installation documentation. The user manual will also include a brief description of all the functional requirements and a simple tutorial aim at the inexperienced users.
The user manual will come in the form of a PDF and also an HTML file.
Maintenance Documentation
All of the code will be provided to the client. The code will be documented so that the code can be maintained.
Online Help
There will be an online tutorial incorporated in the documentation.
Acceptance Criteria
Given the generic nature of the proposed system, completeness of many of the functional requirements will be difficult to verify. For functional requirements that will be difficult to verify, one or more Proof of Concepts have been created. A Proof of Concept will be a specific example of the functional requirement, that upon completion will deem the functional requirement to be satisfied.
When all the Proof of Concepts are completed, they will together form an overall Proof of Concept End-System. This End-System will be a risk compliance system, that allows End-System Administrators and End-System End-Users to monitor compliance with certain risks.
The Corporate Governance Toolkit will be deemed acceptable when the following Proof of Concepts have been met (excluding non-core Proof of Concepts).
Proof of Concepts: Create Database Tables
For the following proof of concepts, a "*" after an attribute shall indicate that it is a multi-value attribute. Multi-value attributes may require extra resolving tables in order to be implemented. Unless indicated otherwise, all Proof of Concepts are core.
Please refer to Create Database Tables.
Create Table that Represents Risk
The system must be able to create a table that represents a risk, including the following attributes:
- Name;
- Description;
- Categories;
- Owner;
- Impact;
- Party Impacted (see Create Table that Represents Party);
- Average Likelihood;
- Severity;
- Cause (see Create Table that Represents Cause of Risk);
- Total Control Cost;
- State (Treatment Required, etc).
Create Table that Represents Location
The system must be able to create a table that represents a location, including the following attributes:
- Long title;
- Short title.
Create Table that Represents Control
The system must be able to create a table that represents a control, including the following attributes:
- Associated Action;
- Way to reduce risk;
- Cost/Effectiveness rating;
- Last date reviewed;
- State (New/Existing).
Create Table that Represents Party
The system must be able to create a table that represents a party impacted by a risk, including the following attributes:
- Party Name;
- Impact;
- Control (see Create Table that Represents Control).
Create Table that Represents Cause of Risk
The system must be able to create a table that represents a cause of a risk, including the following attributes:
- Description of Cause;
- Likelihood;
- Control (see Create Table that Represents Control).
Create Table that Represents Treatment Plan
The system must be able to create a table that represents a treatment plan, including the following attributes:
- Treatment Plan Task (see Create Table that Represents Treatment Plan Task);
- Percentage complete;
- Sign-off/Completed boolean.
Create Table that Represents Treatment Plan Task
The system must be able to create a table that represents a treatment plan task, including the following attributes:
- Name;
- Control (see Create Table that Represents Control);
- Percentage complete.
Create Table that Represents Review
The system must be able to create a table that represents a review, including the following attributes:
- Risk to be reviewed (see Create Table that Represents Risk).
Create Table that Represents Employment Position
The system must be able to create a table that represents an employment position, including the following attributes:
- Title;
- Description.
Create Table that Represents Contact Details
The system must be able to create a table that represents contact details, including the following attributes:
- Mobile number;
- Email;
- Address;
- Pager number.
Create Table that Represents Users
The system must be able to create a table that represents a user including the following attributes:
- User ID; and
- Permission Level.
Create Table that Represents Employee
The system must be able to create a table that represents an employee, including the following attributes:
- User (see Create Table that Represents Users);
- Contact details (see Create Table that Represents Contact Details);
- Employment title (see Create Table that Represents Employment Position);
- Work Group (see Create Table that Represents Work Group).
Create Table that Represents Work Group
The system must be able to create a table that represents a work group, including the following attributes:
- Title;
- Description.
Create Table that Represents Category
The system must be able to create a table that represents a category, including the following attributes:
- Name;
- Description.
Create Table that Represents Measure Scale
The system must be able to create a table that represents a measure scale, including the following attributes:
- Upper bound for scale;
- Lower bound for scale;
- Upper bounds for band (if any);
- Lower bounds for band (if any);
- Band name (if applicable);
- Band colour (if applicable);
- Band description (if applicable).
Create Table that Represents an Indicator
The system must be able to create a table that represents an indicator, including the following attributes:
- Name;
- Description;
- Type;
- Value;
- Frequency to be recorded;
- Measure Scale (see Create Table that Represents Measure Scale);
- Above Tolerance Boolean.
Create Table that Represents Email
The system must be able to create a table that represents a Email message, including the following attributes:
- To field;
- From field;
- Subject field;
- Body field;
- Attachment (see Create Table that Represents Email Attachments).
Create Table that Represents Email Attachments
The system must be able to create a table that represents an Attachment, including the following attributes:
- File or URL.
Create Table that Represents a Survey Template
The system must be able to create a table that represents a Survey Template, including the following attributes:
- Owner (see Create Table that Represents Users);
- Associated Work Group (see Create Table that Represents Work Group);
- Frequency;
- Duration;
- Start Date;
- End Date;
- Governing Document;
- Question (see Create Table that Represents a Question);
- State (Deleted, inactive, active);
- Associated Risk (see Create Table that Represents Risk);
- Associated User Guide for Template.
Create Table that Represents a Survey
The system must be able to create a table that represents a survey, including the following attributes:
- Owner (see Create Table that Represents Users);
- Associated Work Group (see Create Table that Represents Work Group);
- Frequency;
- Duration;
- Start Date;
- End Date;
- Question (see Create Table that Represents a Question);
- Associated Risk (see Create Table that Represents Risk).
Create Table that Represents a Question
The system must be able to create a table that represents a question, including the following attributes:
- QuestionID;
- Question;
- Required Answer format.
Create Table that Represents a Result
The system must be able to create a table that represents a result, including the following attributes:
- Question ID;
- Answer.
Create Table that Represents a Question Pool
The system must be able to create a table that represents a question pool, including the following attributes:
- Question pool ID;
- Question (see Create Table that Represents a Question).
Create Table that Represents an Audit
The system must be able to create a table that represents an audit, including the following attributes:
- Question (see Create Table that Represents a Question);
- Performance rating.
Proof of Concepts: Set Special Attribute Properties
Please refer to Set Special Attribute Properties.
Log Attributes
For each attribute in each table above under Proof of Concepts: Create Database Tables, a boolean logging option shall be able to be set to specify whether changes to that property’s value should be recorded in a log file that can be used as input for charts and matrices.
Set Visibility of Attributes
For each attribute in each table created under Proof of Concepts: Create Database Tables, a boolean visibility option shall be able to be set to specify whether that property shall be visible when records are displayed at the front-end.
Report on Attributes
For each attribute in each table created under Proof of Concepts: Create Database Tables, a boolean reporting option shall be able to be set to specify whether that property is available as an option in a report or chart designer.
Proof of Concepts: Define Values in Relation to Other Values
Please refer to Define Values in Relation to Other Values in Database.
Calculation of Risk Attribute
The system shall allow a Risk's Impact attribute (see Create Table that Represents Risk) to be calculated as the sum of each impact for each associated Party Impacted by the Risk (see Create Table that Represents Party).
Calculation of Risk Average Likelihood
The system shall allow a Risk's Average Likelihood (see Create Table that Represents Risk) attribute to be calculated as the highest likelihood for all associated Cause's of the risk (see Create Table that Represents Cause of Risk).
Calculation of Risk Severity Attribute
The system shall allow a Risk's Severity attribute (see Create Table that Represents Risk) to be calculated as the product of its average impact and average likelihood.
Calculation of Treatment Plan’s Attribute
The system shall allow a Treatment Plan's Percentage Complete attribute to be defined as the average of percentage complete attributes of each of its treatment plan tasks.
Calculation of Risk’s Total Control Cost
The system shall allow a risk's Total Control cost to be the sum of all costs of each of the control for each of its parties impacted and causes.
Calculation of Tolerance Attribute
The system shall allow an indicator's above tolerance attribute to be set to true of the value entered is within the tolerance thresholds for that indicator.
Calculation of Risk Attribute in Relation to Child
The system shall be able to define a attribute in the Risk table in relation to attributes of its child nodes as defined in Proof of Concepts: Create Tree Structure.
Proof of Concepts: Create Tree Structure
Please refer to Create Tree Structure.
Hierarachical Tree Structure
A tree structure must be created that represents a hierarchical organisation structure, i.e.:
(Work Group (Work Group*))
Employment Title Hierarachies
A tree structure must be created that represents employment title hierarchies, i.e.:
(Employment Title (Employment Title*))
Risk Hierarchies
A tree structure must be created that represents a risk hierarchy, i.e.:
(Risk (Cause* (Control*), PartyImpacted* (Control*)))
Compliance Hierarchies
A tree structure must be created that represents a compliance tree, i.e.:
(Template (Question*))
Categorical Hierarchies
A tree structure must be created that represents a hierarchical category structure, i.e.:
(Category (Category*))
Proof of Concepts: Set Constraints (High Non-Core)
Please refer to Set Constraints.
Constraints on Treatment Plans (High Non-Core)
The system shall be able to prevent treatment plans from being signed off unless all of its treatment plan tasks are completed.
Constraints on Viewing Risks (High Non-Core)
The system shall be able to restrict the viewing of risks, to be dependent on any of the following:
- Certain level or higher in Employment Title hierarchy (See Section 10.1.9);
- Particular Category;
- Particular Work Group.
Constraints on Controls (High Non-Core)
The system shall be able to restrict the changing of the state of a control from "new" to "existing" once the associated risk's state becomes "treatment required".
Read-Only Option (High Non-Core)
The system should allow a record to be set as read-only.
Proof of Concepts: Set Triggers (High Non-Core)
Please refer to Set Triggers.
Record Trigger (High Non-Core)
The system shall be able to send an email or report when a record is:
- Created;
- Deleted.
Cost/Effectiveness Trigger (High Non-Core)
The system shall be able to send an email or report when a cost/effectiveness rating exceeds a given value.
Overdue Trigger (High Non-Core)
The system shall be able to send an email or report when an action is overdue.
Changed Category Trigger (High Non-Core)
The system shall be able to send an email or report when a category is changed.
Out-of-Tolerance Trigger (High Non-Core)
The system shall be able to send an email or report when an indicator becomes out of tolerance.
Survey Trigger (High Non-Core)
The system shall be able to generate a new survey from a template when the period for the survey recurrence has come, and send an email or report.
Snapshot Trigger (High Non-Core)
The system shall be able to take a snapshot of the entire database in response to a particular event.
Duplicate Trigger (High Non-Core)
The system shall be able to duplicate a record in the database in response to a particular event.
Create Log (High Non-Core)
The system shall be able to create a log whenever a property set to be logged is changed (see Set Triggers).
Proof of Concepts: Set ActiveReports Report as View (Non-Core)
Please refer to Set ActiveReports Report as View.
Create ActiveReport Report from Risk Data (Non-Core)
The system shall allow export of Risk attributes to be used as input to ActiveReports.
Proof of Concepts: Set Dundas Chart as View (Non-Core)
Please refer to Set Dundas Chart as View.
View Risk Data in a Matrix (Non-Core)
The system shall be able to create a Dundas Chart to view data in a matrix form, by allowing a Toolkit Administrator to specify:
- the data for the x, y and z axes;
- the cell structure and number of cells;
- the color, borders, shades, text content and icons of the cell;
- the scale of the axes;
- a legend for the matrix;
- comments for the matrix;
- tooltips for cells.
Active cells in Matrix (Non-Core)
The cells in View Risk Data in a Matrix shall be active and may contain relative data.
Drill Down (Non-Core)
The cells in View Risk Data in a Matrix shall be able to have a "drill down" capacity where an open cell is able to show a line of information in a grid or to display the nodes within a related tree view.
Combined or Overlayed Matrices (Non-Core)
A matrix created in View Risk Data in a Matrix will be able to be combined with other matrices. For example, matrix with current impact and current probability as the y and x axes respectively shall be able to be combined with another matrix with different x and y axes like target impact and target probability.
Lines Between Items (Non-Core)
A matrix created in View Risk Data in a Matrix shall be able to have tie lines in-between like items.
Legends for Matrices (Non-Core)
A matrix created in View Risk Data in a Matrix will able to have a legend that possesses a value of the following types:
- Currency;
- Percentages;
- Number;
- Fraction;
- Text Description.
Interchangable Legends (Non-Core)
A legend created in Legends for Matrices The system shall be able to inter change legends and axes.
Searchable Matrix (Non-Core)
A matrix created in View Risk Data in a Matrix will be able to have a search filter applied to it.
Client Sign-off
This SRS will act as a formal agreement between the client and Team F as to the specifications of the system to be developed. Any changes to the SRS after the sign off will need to follow the change control procedures outlined in the SPMP.
I (the client) hereby assent that the requirements specified in this document agree with the my requirements and expectations from the product.
Signatures
.........................(Client Signature)
.........................(Client Name)
.........................(Team F Representative Signature)
.........................(Team F Representative Name)
.........................(Witness Signature)
.........................(Witness Name)
.........................(Date)
Notes
- ↑ University of Melbourne, 433-440 Advanced Software Engineering Project, 2006