0000 BA Template Business Requirements v116

Information Technology Services
You are using Version 16 of the Business Requirements Template. Please ensure that you use the latest version of this template every time you start a new document. Notes on using this document template. Ensure that you delete all the blue paragraphs appearing in the ITS_BA: Guidelines style, i.e. the same style as this paragraph. A macro called RemoveGuidelinesText is attached to this template that will do this for you. These guidelines paragraphs are only a guide for YOU. Their presence may, in some cases, appear to throw out the alignment of pages. This should be resolved when you delete them. Any sample requirements written appearing in this template are examples or hints and should be deleted if not relevant to your project. Some sections of this document may not necessarily be applicable for a particular project so remove them where necessary.
Document Identification
Programme Name The Programme Name should be set here if there is a larger programme of work sitting above your project. Delete this line if it is not applicable. Project Name
<Set project name in Properties : Summary : Subject>
The Project Name should be set using the Subject field in the document Properties dialog. After setting it, you should select the above field and hit F9 to refresh the field. You will need to do the same for the field in the page headers. Make sure you do this in every section of the document. Document Name
Business Requirements 0.1 29 September 2010
The Document Name has already been set using the Title field in the document Properties dialog. Version Date
Responsible Authorities
Project Sponsor Senior User Senior Supplier <To Be Advised> <To Be Advised> <To Be Advised>
Service Owner System Owner Project Manager Prepared by
<To Be Advised> <To Be Advised> <To Be Advised> <To Be Advised>
Document Purpose
This document captures the known functional and non-functional business requirements that will drive the outcomes of this project. It is designed to fulfil several purposes: o As a means of verifying that the project team correctly understands the business requirements. We will seek approval of this document as confirmation that our understandings are correct. o As a means of communicating the business requirements to the people who will design, implement and test the solution. o As a baseline document to be referred to when determining whether issues with the solution are to be treated as defects or change requests. This document is solution independent. It is intended to be a statement of what the solution is to do, not of how it will be implemented. Any reference to the use of a specific technology or interface design elements is entirely inappropriate in a requirements document.
Business Requirements
Document Control
The File Name appearing below is a field. After saving your document for the first time, and if you ever change the file name, you should right click the field and select Update Field.
Document Title File Name Prepared By Status
Business Requirements 82910115.doc DRAFT / FINAL
Version History
No Date By Comment
0.1
Original
File Name: 82910115.doc
Page 3 of 43
Table of Contents
1 Introduction........................................................................................................................6
1.1 Audience.................................................................................................................................6 1.2 References..............................................................................................................................7
2 Requirements Overview....................................................................................................8
2.1 Document Scope.....................................................................................................................8 2.2 Drivers.....................................................................................................................................8 2.3 In Scope..................................................................................................................................8 2.4 Out of Scope...........................................................................................................................9 2.5 Assumptions............................................................................................................................9 2.6 Dependencies.........................................................................................................................9 2.7 Constraints............................................................................................................................10
3 Roles and Responsibilities..............................................................................................11

3.1 <role name>..........................................................................................................................12 3.2 <role name>..........................................................................................................................12
4 Business Processes and User Groups...........................................................................13

4.1 <business process name>....................................................................................................14 4.2 <business process name>....................................................................................................14 4.3 <business process name>....................................................................................................14
5 Functional Requirements................................................................................................15
5.1 <name of the subject area or topic>......................................................................................15 5.2 <name of the subject area or topic>......................................................................................17 5.3 Reporting..............................................................................................................................17
6 Non-Functional Requirements........................................................................................19
6.1 Auditability.............................................................................................................................20 6.2 Conformity.............................................................................................................................20 6.3 Efficiency...............................................................................................................................23 6.4 Flexibility...............................................................................................................................25 6.5 Maintainability.......................................................................................................................26 6.6 Portability..............................................................................................................................29 6.7 Reliability...............................................................................................................................31 6.8 Reports Production...............................................................................................................35 6.9 Reusability............................................................................................................................36 6.10 Security...............................................................................................................................37 6.11 Sustainability.......................................................................................................................37 6.12 Usability and Accessibility...................................................................................................39
7 Appendices.......................................................................................................................43
7.1 Glossary................................................................................................................................43 7.2 Requirements Elicitation Record...........................................................................................43 7.3 <Appendix 3>........................................................................................................................43
Page 4 of 43
Contributors
The Contributors section is used to capture the details of any stakeholder who has contributed to the requirements presented in this document. All contributors listed here should also appear in the projects Stakeholder Analysis spreadsheet. The initials of each contributor will appear besides the requirement statements that they have been the source of. The Position is sometimes referred to as title. Example of this are Director, Project Services, ITS and Associate Dean, MDHS. You should provide each contributors phone number in the contact details section. You may also provide their email address if you wish. An appendix has also been provided that can be used to capture the meetings you have had with the contributors.
Name Position Contact Details Initials
Reviewers
Name Position Contact Details Date
Approvals
The Approvals section is used to capture the details of those stakeholders who are responsible for approving the contents of this document. Their details should be added here during the early draft stages of the document. The Approved checkbox should be checked and the date entered only when an approval has been provided by the stakeholder in the form of an email or an actual signature. Checking the Approved checkbox is most easily achieved by double-clicking the box to open the Properties dialog and changing the Default value option to Checked.
Name Position Approved Date
Page 5 of 43
Introduction
You should provide here a brief overview of the project that is no more than two paragraphs long. This should present in as few words as possible the background and aims of the project. This section must reflect the content in the Project Brief / Business Case (depending on which stage the BRD is at). While this may seem needlessly repetitive, keep in mind that the audience may not have seen the preceding project documents for months if at all.
1.1
Audience
You are free to leave the text below as is or alter it according to your needs. The typical audience for a Business Requirements document such as this is: o Project Sponsor Reviews the document as it approaches completion. Approves the document as a baseline for solution design and implementation. Note that the document may be approved more than once in its lifecycle if significant changes to the requirements are identified through the life of the project. o Project Steering Group Members of the project steering group may review and provide feedback on the document as it approaches completion. o Senior User The nominated Senior User is usually expected to review the document and approve its use as the basis for solution design and implementation. o Business Subject Matter Experts These people are key contributors to the contents of this document and will be asked to review and validate that what has been captured accurately represents the business requirements. o ITS Architects Architects will review the requirements presented in this document and use it to guide selection and/or design of the most appropriate solution. o Developers or Solution Suppliers Developers, where the solution is being built, will use this document to guide the detailed design and implementation of the solution. o Testers This document will be a key resource for testers as they develop their test scripts and acceptance criteria. Any defects raised may refer back to the requirements listed here. o Project Manager The project manager will use this document as a basis for planning the project and estimating the effort and costs involved in delivering the desired outcomes. o Business Analysts Other business analysts may use this document as a basis for developing further detailed requirements documents such as use cases if needed or for producing tender documents. They will also use the most recently approved version for determining whether issues raised should be treated as defects or change requests.
File Name: 82910115.doc Page 6 of 43
o Other ITS Staff Other staff may refer to this document to help them improve their understanding of the project and how it may relate to work they are undertaking.
1.2
-
References
Project Brief Stakeholder Analysis spreadsheet Feasibility Study Non-Functional Requirements Business Impact Assessment Risk Log Issues Log Business Case Project Initiation Document
It is expected that most projects will be make use of the following documents types:
If these documents have been created for your project, they should be listed in this section. It is important to list all relevant documents here so add as many entries as needed. Other documents such as meeting minutes and those created by external parties may also be referenced. The reference structure provided below is a guide only. Include as much information as makes sense for each document. We generally do not include the location of documents as these are typically not very stable and are often inaccessible to the audience anyway. 1 2 3 <document name>, <author>, <publisher>, <version>, <year> <document name>, <author>, <publisher>, <version>, <year>
Page 7 of 43
2
2.1
Requirements Overview
Document Scope
This section explicitly states which types of information are included and excluded from this document. The following statements should apply to most projects. Any desired changes should be discussed with your project manager and the BA manager or team lead. The scope of this document includes: o functional business requirements o high-level business process descriptions o roles and responsibilities of the parties involved in, or impacted by, this project o business rules. Specifically excluded from the scope of this document are: o use cases o detailed functional specifications o non-functional requirements o solution identification or design o technical design o business impact assessment.
2.2
Drivers
The project drivers can usually be copied from the Project Mandate or Project Brief document. Drivers for a project are usually high-level statements of the Universitys or business units visions, goals or aspirations that can be sourced from other documents such as divisional plans and strategy documents. If you find yourself trying to list problems here, ask yourself Why is that problem a problem?. The answer will usually trace back to a high-level vision, goal or objective that the University or business unit is aspiring to achieve.
2.3
In Scope
Scope statements should define the boundaries for what the project will be attempting to deliver. They may refer to subjects such as high level functionality, organisational units, roles, processes or things. Examples: Payroll processing. Workspace computing requirements of the Melbourne Law School. Leave approval processes for all staff at a HEW 9 level and below. Surveying requirements in support of the Quality of Teaching business processes. Upgrade of VLSCI servers in the Q3 data hall iDataplex rack.
The scope of a project, what is to be included and excluded, should have been negotiated in discussions between the project manager, senior users and the business sponsor. The following are considered to be within the scope of this project:
Page 8 of 43
2.4
Out of Scope
List any specific exclusions from this project or programme of work. It is important to be explicit and precise with each of the statements listed here. These statements should be reviewed carefully by the project manager, senior users and business sponsor. Examples: Credit card payments. Enrolments for post-graduate students. Southbank campus network. Migration of data from Merlin.
The following are considered to be excluded from the scope of this project: o
2.5
Assumptions
Clearly document any assumptions that have been made that are important for understanding the context of these requirements. During the course of a project, it is common for assumptions to be clarified and removed or transformed into dependencies or constraints. If any of the listed assumptions prove to be invalid, it could be expected that there will be a substantive impact upon the project scope, the business requirements and the solution design. Examples: Users of the systems web interface will have Javascript enabled. All suppliers will accept payments in Australian dollars. The Q3 data hall has sufficient power and cooling capacity to cater for the additional servers.
The following assumptions have been made when formulating these requirements: o
2.6
Dependencies
List any activities or deliverables that the successful outcome of this project is depending on but for which the project is not directly responsible for providing. Examples: Implementation of a full Internet proxy for the Parkville campus to be delivered by the Network Remediation project. A shared hosting agreement with Monash University needs to be established before a solution for these requirements can be fully implemented.
The successful delivery of this projects intended outcomes are dependant upon the following: o
Page 9 of 43
2.7
Constraints
A constraint describes any known restrictions or limitations imposed on the solution that do not support the business or stakeholder needs. Constraints are normally expressed by the project sponsor or steering group. As with assumptions, any changes to these constraints are likely to have an impact upon the project scope, the business requirements and the solution design. Examples: The solution must be implemented before the 28th of February 2011 in order to be ready for the intake of semester 1 students. Suppliers will not be able to provide real time updates of stock levels due to insufficient project funding.
Be wary of including statements here that may be better expressed as non-functional requirements or items that are out of scope. Examples of non-functional requirement statements which should not be listed here: The solution must comply with national privacy laws. The system must be available 24 hours a day, 7 days a week. The system must provide data feeds to ISIS in a format that it currently recognises.
The following constraints have been identified that may limit the solution designs and implementation of this project: o
RISKS and ISSUES As you are gathering and documenting the requirements, you should continually ask yourself What are the risks and issues associated with this? All identified risks and issues should be captured in the projects Risks and Issues logs.
Page 10 of 43
Roles and Responsibilities
Establishing a thorough understanding of all the relevant roles and responsibilities is an essential step in gathering a complete set of requirements. The significant roles and responsibilities of people who are involved in, or may be impacted by, this project should be listed and briefly described in this section. Please refer to the Stakeholder Analysis or Business Impact Assessment artefacts to ensure information is consistent. Examples: 4.1 Student User The student user is responsible for: - Logging into the survey system through a student interface (ie. Student Portal, LMS, SIS) or through the University QoT website. - Logging in within the timeframe stipulated. - Completing a survey for each taught subject enrolled in, or series of surveys relating to that subject. 4.2 Academic Staff Academic staff are responsible for: - Requesting additional questions for the survey of their subject or subjects - Encouraging users to complete the surveys - Providing feedback to users on QoT survey results through a student interface ie. LMS 4.3 General staff member General staff members are responsible for: - Submitting their leave applications. 4.4 Supplier The suppliers will be responsible for: - Receiving and acknowledging purchase orders. - Fulfilling purchase orders. - Communicates issues with stock shortages and catalogue changes to the ITS Procurement team. 4.5 ITS Operations Team The ITS Operations team will be responsible for: - Notifying all nominated staff members when revisions to the reference data are available. The roles and responsibilities listed in this section represent an initial analysis of the people and groups who are involved in, or may be impacted by, this project. Further, more detailed, analysis may be captured at a later stage in the Stakeholder Analysis, Project Initiation and Business Impact Assessment documents.
Page 11 of 43
3.1
<role name>
3.2
<role name>
Page 12 of 43
Business Processes and User Groups
Use this mandatory section to identify the high level business processes supported by these requirements. A brief description of each process listed should be provided in the following sub-sections. The numbers of those sub-sections should be used as a prefix to the process name in this table. Place a in the matrix cell if the group is involved in a business process or NA if it is not. The key purposes of this table is to promote rigour in the thinking of the BA and other contributors when it comes to considering which user groups and business processes may be involved in, or impacted by, the project and its outcomes. It is quite common for BAs, contributors and other audience members to suddenly realise or point out that other user groups or processes may also be impacted and that their requirements should also be considered. The first row of data and the user groups listed below are examples only. You should change them to reflect the user groups and business processes that are relevant to your project. It may be appropriate to supplement this section with a SIPOC analysis/diagram. If you need help with doing a SIPOC, please contact the BAM or an SBA.
Business Processes
Affiliates? Colleges? Departments? Faculties? Financial Operations Human Resources
Associated User Groups

External Organisations? ITS Marcoms Office of the ViceChancellor Property and Campus Services Researchers Schools? Students Student Administration Planning Office
3.1 Report on survey results
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
Each of the business processes that are related to, or affected by, this project should be described in their own sub-section below. Under each heading, you should provide a brief description of the business process and how it relates to, or may be impacted by, this project. A detailed impact assessment may be captured in the projects Business Impact Assessment document. If no processes are being impacted by this project, you may delete this section.
Page 13 of 43
4.1
<business process name>
4.2
4.3
Page 14 of 43
Functional Requirements
A requirement is: 1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents. - A Guide to the Business Analysis Body of Knowledge. IIBA. 2009.
Break the functional requirements down into as many separate sections as appropriate. There are various approaches to doing this. You may decide to use high-level functional areas (eg. Reports) or business processes (eg. Equipment Requests) as a way of grouping requirements. You will have to determine the best approach according to the nature of your project.
5.1
<name of the subject area or topic>
Some examples of subject areas are: Authentication, Reporting, Auditing, Ordering, Sales. Provide a brief overview of each subject area or topic here before the table of requirements.
Use the table below to list out the requirements for the subject area. The first row of the table below is an example. Table column definitions ID All requirements statements should be allocated a unique ID. This supports traceability, aids communication and facilitates change impact assessment. The format of these IDs is XXXN. The XXX is a unique string that helps to associate the ID with the requirements sections to which it belongs. It is preferable to use a string that readers will easily associate with the subject name. For example, if the subject is Ordering, you might use ORD as the string. The N part of the ID is a sequential integer that uniquely identifies the requirement within the subject area. Eg. ORD1, ORD2, ORD3. Describe the requirement that you have gathered from stakeholder(s). Remember the 4 Cs when doing this. At a minimum, a high quality requirement must exhibit the following characteristics: Cohesive, Complete, Consistent, Correct, Feasible, Modifiable, Unambiguous & Testable. A Guide to the Business Analysis Body of Knowledge. Section 6.5.4. IIBA. Version 2.0. As part of being concise and consistent, you should aim to keep requirements descriptions to no more than 2 lines. Rationale Raised by Where appropriate, you should describe why the requirement is important. This is optional. The initials of the contributor(s) should be listed with every requirement statement they have raised. All contributors should be listed at the start
Page 15 of 43
Description
of document.
Page 16 of 43
Priority M/D/O Allowable values are: M for mandatory. Must be supported by the solution. D for desirable. Would like the solution to support this if possible. O for optional. Nice to have but can live without.
ID Description Rationale Raised by Priority M/D/O
ACC1
Students must be authenticated by the University identity system before they can complete an online survey.
Protects the privacy of students. Enables an enforcement of single responses.
DH
5.2
ID
<name of the subject area or topic>

Description Rationale Raised by Priority M/D/O
5.3
Reporting
A section for reporting requirements has been included here due to the importance of capturing reporting requirements early in the project life cycle. Requirements for a data element on a report often lead to data storage and processing requirements which in turn lead to data capture or integration requirements. The late identification of detailed reporting requirements can result in expensive changes to a system and/or impaired reporting abilities. Reporting requirements can be a difficult area to specify. In most cases, users seem to want to see examples of the reports before they can tell us what they need. To make this process easier, you may choose to subdivide this section into operational, technical, enterprise, ad-hoc, etc. You may remove this section if your project genuinely does not have any reporting requirements however this would be an exception to the norm. Provide a brief overview of the subject area or topic here.
Page 17 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
RPT1 RPT
Page 18 of 43
Non-Functional Requirements
Non-functional requirements capture conditions that do not directly relate to the behaviour or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface. - A Guide to the Business Analysis Body of Knowledge. IIBA. 2009. The purpose of the non-functional requirements section is to: - detail the non-functional or quality and supplementary requirements that the solution should meet - list the standards and specific stakeholder requirements related to performance, usability, etc. - identify any additional requirements or considerations that must be addressed by this project - provide sufficient information to enable the solution team to design a robust, UoM IT Architecture Principles & Standards compliant solution that will meet the needs of the business - provide sufficient information to enable the test team to confirm that the solution meets the needs of the business. During the early phases of the project, prior to the solution being selected and the Business Case document being approved, you should try to document non-functional requirements statements in a generic way that doesnt dictate how the solution will be implemented. The first rule of defining non-functional requirements is to ensure that they are testable. A requirement that cannot be tested may as well not be included as a requirement. The best way to ensure that non-functional requirements can be tested is to think about how they might be tested when they are written. If it is not obvious then ask a stakeholder how this could be tested, e.g. If there is a Legal requirement that all voice conversation must be recorded, can you test this? Some of the non-functional requirements sub-sections may not necessarily be applicable for your project. The relevant stakeholders (architects, support teams, operations teams, test managers, development tech leads, etc) should be consulted to determine the applicability of the various sections. If any of these sub-sections is not applicable to your project, do not remove it. Instead just enter Not Applicable in the sub-section. This will communicate to the audience that the sub-section has been considered explicitly rather than ignored or omitted by accident. The requirement categories contain all 5 non-functional quality characteristics from the ISO9126 standard (Usability, Efficiency, Maintainability, Reliability, Portability) as well as a number of other standard categories (Conformity, Reusability, Flexibility, Security, Auditability, Reporting) Table column Definitions: Please follow the same guidelines documented in the Functional Requirements section. Use the Delete Row function to remove the guidelines that appear within the tables.
Page 19 of 43
6.1
Auditability
Auditability is a non-functional requirement that concerns the transparency of a system with regards to internal and external audits. An environment in which an auditor can perform the audit functions is considered important. It may be worthwhile discussing the proposed system with the Audit Team to get their input on what is required. Examples: - Event X must be recorded in System Y. - Event X must not be recorded (e.g. Privacy Act). - Attribute A must be not be stored unencrypted/unobfuscated.
AUD1 AUD
6.2
Conformity
Conformity refers to the internal and external necessity to comply with certain standards, governance and laws. Ensure that the system conforms to these, as this will have direct implications for the University.
Legal and Regulatory
Page 20 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
What legal, regulatory, risk, policy, external affairs requirements or other factors must the solution for this business requirement comply with? For example, customer facing paperwork, such as Terms and Conditions, Disclaimers or the Product Development Procedure will need to be updated. Things to consider: - compliance requirements (e.g. laws/legislation) - privacy requirements (e.g. personal data storage) - industry standards requirements (e.g. PCI Compliance) - project specific terms and conditions that vendors will need to adhere to. CON1 CON CON Adherence to Standards (UoM & External) What standards must be adhered to? Examples: - The solution must adhere to all UoM IT architecture Principles. - The solution must comply with all UoM infrastructure standards. - The solution must be aligned with UoM Future State Roadmap/Strategy. - The solution must be deployable to any J2EE certified application server. The rationale may state the relevant UoM IT Architecture Principles or Infrastructure standards or refer to a document. If this document is going to an external group, ensure that they have a copy of those principles and standards documents. CON CON CON Enterprise Integration Requirements
Page 21 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - The solution must be able to use X LDAP Server for authentication. - The solution must be able to sync with the UoM Active Directory server. Get project specific integration requirements from the Architecture team. CON CON Branding Examples: - Logo usage. - Other branding & marketing requirements. - Copyright notice policy for public-facing web pages. CON CON Precision and Accuracy Examples: CON CON Licensing The solutions dollar figures must be calculated to 4 decimal places and displayed with 2 decimal places. Transaction times must be captured with an accuracy of seconds.
Page 22 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: CON CON Maximum users permitted to use component X is Component X must be licensed for N users.
6.3
Efficiency
Are there any speed, throughput, or response time constraints on the system? Are there size or capacity constraints on the data to be processed by the system? Be aware that optimizing efficiency might have a negative impact on, say, maintainability or portability. So it's essential for the users and developers to decide which attributes are most important to the overall success of the system / application. Ensure you capture them here.
Response Time Examples: - Average response time under normal load. - Maximum acceptable response time under normal load. - Average response time under peak expected load. - Maximum acceptable response time under peak expected load. - Per Screen/Form/Page, as above. - Per Service. - Per Hardware item interaction. - Timeout thresholds.
Page 23 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
EFF1 EFF Scalability and Load Handling Examples: - Average number of users. - Average number of transactions. - Peak number of users to be handled normally. - Peak number of transactions. - Expected growth in transactions per year. EFF EFF Performance Recording Find out who will care about/monitor the systems performance and ask what data they will need to measure it and improve it. EFF EFF Network Usage Examples: - Maximum and average message size required. - Minimum network bandwidth requirements. - Network protocol requirements. - Network prioritisation requirements. EFF EFF
ID
Description
Rationale
Raised by
Priority M/D/O
Data Capacity and Retention Examples: - Volume of relatively static data to be stored. - Number of transactions to be recorded and size. - Retention of transactions (e.g. to comply with the statutory minimums or business needs). - Expected growth of data. - Archiving/culling routines. - Project specific audit controls/procedures and record retention policy (or quote enterprise-wide practice/policy). EFF EFF
6.4
Flexibility
If UoM intends to increase or extend the functionality of the application / software after it is deployed, that should be planned now; it influences choices made during the design, development, testing, and deployment of the system.
Platform & Technology Examples: - Component X must be implemented using a platform-independent technology (e.g. Java). - Application X must be open-source & have a GPL, LGPL or BSD license. - BPEL code must not use proprietary extensions (e.g. IBM Human Task or Oracle BPEL Security extension). - Component X must be deployed on Technology Y (e.g. to not increase the foot print of Layer Z & to continue to use the same in-house Layer Z support model). FLE1
ID
Description
Rationale
Raised by
Priority M/D/O
FLE Interoperability Examples: - Interface X must be loosely coupled from System Y since System Y is likely to be replaced by System Z in near future. - Integration between Component X & Component Y must not be P2P but via an adapter/controller Z. - Separation of Concerns must be maintained between Component X & Component Y (e.g. dependencies between the underlying logic of Service X and its consumers Y & Z is to be limited to conformance of the service contract). - Service X must be autonomous: the service must not depend on other services for it to execute its governance. - Service X must be strictly atomic (e.g. WSDL to expose Operation W only). - Component X must be stateless, even if that means deferring state management elsewhere. FLE FLE
6.5
Maintainability
This is a vitally important requirement because if the developers, administrators, and operators cannot figure out how to manage the application, then it won't live past the first release. Let's assume you are an administrator tasked with having to run this solution. How do you configure it? How do you monitor it? What if you have to do things many times (for example, install dozens of applications)? Do you have a reproducible deployment process? Can you automate repetitive tasks to make it feasible in the large? What needs to be put in place to allow the system to be maintained and supported? How is the system configured?
Change
Page 26 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - It must be possible to apply a change to X without changing or compiling code. - It must be possible for an authorised business user to change Y without technical knowledge and without creating a Change Request through Change Management. MAI1 MAI Business Rules Modification Examples: - Business rules pertaining to X must be able to be maintained without software changes & stored in a rules engine. - Business rules pertaining to X must be looked-up from a spreadsheet Y, located at Z. MAI MAI Configuration Examples: - Aspect X of Component Y must be configurable. - (system level) Configuration for Component X is stored in database Y / file Z. MAI MAI Error Handling and Logging
Page 27 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - All exceptions must be logged with the keyword ERROR. - All Delete transactions must be logged with the keyword INFO. - Component X Error/Warning/Info logging format. MAI MAI Fault Diagnosis Examples: - Logs from locations X Y Z must be available immediately to support teams ABC. - Persons ABC / support teams KLM must be notified via Email if event X occurs. MAI MAI Fault Repair Examples: - Deployment to container (e.g. App Server) X must be achieved without an outage. - Automated build and unit test scripts must be provided to support team. - Support team X do the fault repair at layer X (e.g. Active Directory). MAI MAI Support Documentation
Page 28 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: The following documentation must be produced: - Operations Guide. - Updates to IT Service Desk Guidelines. - Updates to Documentation/Help published in a document X in knowledge base Y (e.g. LAN location / Wiki URL etc). MAI MAI Code Version Control Examples: - Store artefacts A B C (e.g. code, config files, build scripts, test harnesses...) in repository X, using tool XX. - Middleware: store in Repository Y, using tool YY. - Database: store in Repository Z, using tool ZZ. MAI MAI
6.6
Portability
How can this system / application be employed to provide some form of platform neutrality? Does UoM have a plan for moving applications to the latest version? What does UoM do when if the vendor withdraws support for that version? The set of attributes that are important on the ability of software to be transferred from one environment to another. What platforms and environments must the system run on? What environment upgrades / changes must the system be able to cope with? If the product is open source, how does UoM see the future of this product to exist?
Page 29 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Installability Examples: - System X must be platform independent, i.e. must run on all major operating systems (e.g. Linux, Unix, Solaris, AIX Microsoft Windows etc). - Component X must be deployable to any J2EE certified application server (e.g. Apache Tomcat). - Component X must be able to use any RDBMS (Oracle, DB2, MySQL, PostgreSQL, Microsoft SQL Server etc). POR1 POR Adaptability Examples: - Software upgrade / version compatibility requirement. POR POR Replaceability Examples: - System X currently running on hardware Y will have to be able to run on hardware Z without performance impact. - System X will not be impacted in any way (i.e. including no modification of its interfaces) when application A will be replaced by application B. POR POR Data Migration and Conversion
Page 30 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - Data to be converted into new system. Note: if there is significant amount of data conversion, this will need to be a separate document with data mappings. - Acceptable differences between converted data and new data. - Default values for data conversion. POR POR
6.7
Reliability
Reliability specifies the capability of the software or application to maintain its performance over time. Unreliable software fails frequently, and certain tasks are more sensitive to failure (for example, because they cannot be restarted, or because they must be run at a certain time).
Availability Examples: - Availability level required: NN.NNN%. Translates to N minutes per year/day. - Maximum planned outage duration: N minutes. - Maximum outage duration during ordinary software deployment: N minutes. - Mean time between failures should be at least N days. - Outage window: HH:MM to HH:MM on MTWTFSS. REL1 REL Network Bandwidth & Latency
Page 31 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - Minimum network bandwidth under which system must operate acceptably is: N kbps. - Minimum network latency under which system must operate acceptably is: N seconds. - Page load time less than N seconds at bandwidths X Y Z (including 56K dialup). REL REL Resilience Examples: - System must keep running if any combination of these components are unavailable: A B C - System must gracefully degrade in way X if these components are unavailable: D E F - Procedures when components A B C become operational after an outage are. REL REL Interruption Handling Examples: - System interruption on UI (e.g. PC shutdown while application is running). - System interruption on middleware. REL REL Severity Level and Recovery Time Objective (RTO)
Page 32 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - This system is severity level N. - RTO is N hours/minutes: the system must be able to be recovered and started completely within N hours/minutes of an outage occurring. Find out from support teams what else is required. REL REL Monitoring Examples: - Server logs must be monitored for keywords X Y Z. - Per keyword, actions A B C must occur. - UI logs must be monitored for keywords X Y Z. - Other things to monitor: JVM Heap size, database connections, thread count, number of transactions (e.g. alert if transaction count per hour drops below X). - Alerting an occurrence of event X must be through mechanism Y. REL REL Expected Volume Examples: - Expected average volume on go-live. - Expected max volume on go-live. - Expected increase per year over five years. - Expected volume fluctuation by day/week/month (e.g. when are the peaks and troughs). REL REL
ID
Description
Rationale
Raised by
Priority M/D/O
Disaster Recovery Examples: - Indicate if there are any special requirements for the provision of some form of disaster recovery capability which could be implemented in the event of a major system component failure. If a plan does not already exist, it may be necessary to develop requirements around DR needs which will initiate an appropriate project artefact for DR. - Does the business want a DR solution? - DR Server location. - Component X (e.g. backup tape) location. - Locations of components hosted externally by 3rd parties. - It may be sufficient to refer to the site standard disaster recovery plan in this section. REL REL Business Continuity This section must cover the high level requirements for business continuity for a given solution. This will initate appropriate project artefacts for details around business continuity Examples: - If this system is unavailable (planned) - If this system is unavailable (unplanned) REL REL Backup and Recovery
Page 34 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - What is the recovery point objective (RPO) for this system? i.e. what is the acceptable amount of data loss measured in time? - Transactional data must be backed up on a nightly basis and recoverable. - Static data must be backed up. - Code must be backed up on a nightly basis. - Recovery procedure is: (check UoM standards and specify differences or just refer to the standards). - Specific recoverability related requirement. REL REL
6.8
Reports Production
This section deals with the production of reports and not the make up or layout of reports; this is required in a detailed BRD and Use Case document. Example: - Report A: frequency, data, owner, business rules, reference to specification. - Enterprise data warehouse feeds (eg. Data D must be exported to the EDW table T once a week.)
RPR1 RPR
Page 35 of 43
6.9
Reusability
Reusability is the ability to (re)use in future systems.

Existing Components (UoM & third party) Example: - Specify which components need to be reused and in what way. REU1 REU New Components (UoM & third party) Examples: - Component Y must support these interfaces (API / Protocol). - LDAP Interface for Login/ Authentication; HTTPS/SOAP Web Service Interface for Profile Update, etc. REU REU Identity Management Examples: - User logon credentials must be the same as LAN username/password. - There must be a seamless SSO between Application X & Application Y. - Login and logout events must be recorded via the Enterprise IdM Auditing Tool. - Application X will be a the new Source Of Truth / Authoritative Source for Q. - Application X will require a new authentication check / workflow. REU REU
6.10
Security
Security requirements can come in many different forms. Examples: Privacy - Requirements can dictate protection for sensitive information. Some types of privacy requirements include: data encryption for database tables, policies regarding the transmission of data to 3rd parties (e.g., scrambling user account numbers), etc... Sources for privacy requirements could be legislative or corporate. Physical - These requirements relate to the the physical protection of the system. Other types of physical requirements include items such as elevated floors (for server cooling), fire prevention systems, etc. Access - Access requirements define account types / groups and their access rights. An example of an access requirements could be to limit each account to one login at a time or to restrict where an application can be deployed or used. Example Statements: - HTTPS/SSL must be used for all Web Pages with username/password fields. - All online financial transactions must comply with the PCI Data Security Standard 1.2. - Application X must be deployed in DMZ
SEC1 SEC
6.11
Sustainability
What sustainability directions should be achieved by this initiative? List these here. Points to note: Is this project going to produce waste? Are there products or equipment that will no longer be required? Please follow this hierarchy of waste management. - Avoidance. - Reuse.
- Recycling. - Recovery of energy. - Treatment. - Containment. - Disposal. Are the right people involved in this project from a sustainability view point? Ensure that you make it clear to all stakeholders as to what the sustainability outcomes will be for this project. What are the consequences of not proceeding with sustainability items in line with the universitys minimisation of waste?
Acquisition of new hardware Are purchases going to be made? Are the planned purchases being supplied by vendors that have a sustainability accreditation? Examples: - Hardware should be purchased from supplier with sustainability accreditation. Examples of Rationales: - It is a government requirement imposed on the university. - The hardware has been purchased by a procurement process that ensures sustainable principles. SUS1 SUS Disposal of Hardware Is hardware of any sort going to be disposed off? Ensure that it is done using the waste management hierarchy, refer above. Examples: - Hardware must be disposed of either for resale or disposed of with sustainability accreditation. - Recycling of hardware or products. Reuse of Hardware is preferred, eg Grays on-line. Refer to procurement for disposal of an asset
Page 38 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
SUS SUS
6.12
Usability and Accessibility
Provide an overview of the users of the application to be delivered how many users will there be, where will they be located, etc? Accessibility is a general term used to describe the degree to which a product, device, service, or environment is accessible by as many people as possible. Accessibility can be viewed as the "ability to access" and possible benefit of some system or entity. Accessibility is often used to focus on people with disabilities and their right of access to entities, often through use of assistive technology. Examples: - Vision difficulties (e.g. requirements for large fonts). - Deafness support. - Colour-blindness support. Examples: The solution will be accessible by web users via a browser with scalable fonts. The solution must be accessible by offline users / mobile laptop users / smart phone users.
When specifying usability requirements you should consider the following: What type of user will be using the system? Will more than one type of user be using the system? What sort of learning will be required for each type of user? Is it particularly important that the system be easy to learn? Is it particularly important that users be protected from making errors? What sort of input/output devices for the human interface are available and what are their characteristics?
Page 39 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
User Feedback Examples: The solution must provide a clear response to every user action.
UAA1 UAA User Interaction Examples: - Transaction X must be synchronous: user cannot do anything until transaction completes or times out. - Transaction Y must be asynchronous: user must be able to do other things while transaction is completing. - Keyboard accelerators. - Specify Ease of Use requirements UAA UAA Appearance Examples: - Colours. - Style standards. - Customisability. UAA UAA Internationalisation
Page 40 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - Languages required. - Location specific requirements. - Currencies required. UAA UAA Help Examples: - Online help is required. - Help file maintenance requirements. UAA UAA Training Examples: - Training requirements for project. - Training requirements ongoing. UAA UAA Understandability
Page 41 of 43
ID
Description
Rationale
Raised by
Priority M/D/O
Examples: - Acceptable terminology displayed by user interfaces (define particular terms here, e.g. semester). - Acceptable abbreviations displayed by user interfaces. - Acceptable images / icons. UAA UAA User Documentation Examples: UAA UAA What kind of documentation is required? What audience is to be addressed by each document? Indicate the documentation that will be created/modified (user manuals / online help / computer-based learning modules / circulation bulletins / mailouts; etc).
Page 42 of 43
Appendices
Add any appendices that are needed to support the requirements. Some standard tables are provided which you may delete if they are not appropriate for your project but we encourage you to make us of them. Examples: Bibliography Extracts of University policies
7.1
Glossary
It is common practice to provide a glossary of relevant terms. If you are debating on whether you should include a term in this table, it is better to err on the safe side and include it. Do not assume that the audience of this document has the same background knowledge that you do. You may include words and acronyms in the Term column. Please keep the table sorted alphabetically on the Term column. You can use the Sort command within the Table menu to do this.
Term Definition
7.2
Requirements Elicitation Record
The requirements presented in this document were gathered during a number of meetings and discussions with the various contributors. The table below lists the meetings and discussions that took place along with the dates and attendees. It would be normal for all of the attendees appearing in this table to also be listed (once) in the Contributors table at the start of the document. There may be some exceptions to this rule if there were attendees at meetings who were not significant providers of requirements. You should use the full name of the attendees in this table in preference to their initials. Please ensure that a record of these meetings also appears in your projects Stakeholder Analysis spreadsheet.
Date Meeting Title / Topics Discussed Attendees
7.3
<Appendix 3>
Page 43 of 43

0000 BA Template Business Requirements v116

Uploaded by

Copyright:

Available Formats

0000 BA Template Business Requirements v116

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0000 BA Template Business Requirements v116

Uploaded by

Copyright:

Available Formats

What is the purpose of this document?

What is the purpose of this document?

What information is captured in the document?

What information is captured in the document?

Information Technology Services

<Set project name in Properties : Summary : Subject>

Business Requirements 0.1 29 September 2010

Service Owner System Owner Project Manager Prepared by

<To Be Advised> <To Be Advised> <To Be Advised> <To Be Advised>

<Set project name in Properties : Summary : Subject>

Business Requirements 82910115.doc DRAFT / FINAL

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

3 Roles and Responsibilities..............................................................................................11

4 Business Processes and User Groups...........................................................................13

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

Roles and Responsibilities

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

Business Processes and User Groups

Associated User Groups

3.1 Report on survey results

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

<business process name>

<business process name>

<business process name>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

<name of the subject area or topic>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

Protects the privacy of students. Enables an enforcement of single responses.

<name of the subject area or topic>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

Legal and Regulatory

File Name: 82910115.doc

<Set project name in Properties : Summary : Subject>

File Name: 82910115.doc