0000 ba template business requirements v116

8/3/2019 0000 BA Template Business Requirements v116

http://slidepdf.com/reader/full/0000-ba-template-business-requirements-v116 1/43

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

The Document Name has already been set using the Title field in the document Properties dialog.

Version 0.1

Date 29 September 2010

Responsible Authorities

Project Sponsor <To Be Advised>Senior User <To Be Advised>

Senior Supplier <To Be Advised>



Service Owner <To Be Advised>

System Owner <To Be Advised>

Project Manager <To Be Advised>

Prepared by <To Be Advised>

Document Purpose

This document captures the known functional and non-functional business requirements that will drive theoutcomes 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.



<Set project name in Properties : Summary : Subject> 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 Business Requirements

File Name 82910115.docPrepared By

Status DRAFT / FINAL

Version History

No Date By Comment

0.1 Original

File Name: 82910115.doc 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



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 ...............................................................................................................356.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





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 project’s

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





1 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 thedocument may be approved more than once in its lifecycle if significant changes to therequirements 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 itapproaches completion.

o Senior User

• The nominated Senior User is usually expected to review the document and approve its use as thebasis 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 andvalidate 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 selectionand/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 designand implementation of the solution.

o Testers

• This document will be a key resource for testers as they develop their test scripts and acceptancecriteria. 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 theeffort and costs involved in delivering the desired outcomes.

o Business Analysts

•

Other business analysts may use this document as a basis for developing further detailedrequirements documents such as use cases if needed or for producing tender documents. Theywill also use the most recently approved version for determining whether issues raised should betreated as defects or change requests.





o Other ITS Staff

• Other staff may refer to this document to help them improve their understanding of the project andhow it may relate to work they are undertaking.

1.2 References

It is expected that most projects will be make use of the following documents types:

- Project Brief

- Stakeholder Analysis spreadsheet

- Feasibility Study

- Non-Functional Requirements

- Business Impact Assessment

- Risk Log

- Issues Log

- Business Case

- Project Initiation Document

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 <document name>, <author>, <publisher>, <version>, <year>

2 <document name>, <author>, <publisher>, <version>, <year>3





2 Requirements Overview

2.1 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 University’s or business unit’s 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:





o

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 system’s 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 NetworkRemediation 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





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 thisproject:

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 projectsRisks and Issues logs.





3 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.





3.1 <role name>

3.2 <role name>





4 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 Associated User GroupsA f f i l i a t e s ?

C ol l e g e s ?

D e p ar t m en t s ?

F a c ul t i e s ?

F i n an c i al

O p er a t i on s

H um an

R e s o ur c e s

E x t er n al

Or g ani s a t i on s ?

I T S

M ar c om s

Of f i c e of t h e

V i c e-

C h an c el l or

P r o p er t y an d

C am p u s

S er v i c e s

R e s e ar c h er s

S c h o ol s ?

S t u d en t s

S t u d en t

A d mi ni s t r a t i on

P l anni n g

Of f i c e

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 project’s Business Impact Assessment document.

If no processes are being impacted by this project, you may delete this section.


http://en.wikipedia.org/wiki/SIPOC






5 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 thebest 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.

Description Describe the requirement that you have gathered from stakeholder(s). Remember the 4 C’s 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 Where appropriate, you should describe why the requirement is important. This is optional.

Raised by The initials of the contributor(s) should be listed with every requirement statement they have raised. All contributors should be listed at the start





of document.





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 Raisedby

PriorityM/D/O

ACC1 Students must be authenticated by the University identity system before theycan complete an online survey.

Protects the privacy of students. Enables anenforcement of single responses.

DH M

5.2 <name of the subject area or topic>


PriorityM/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.





6 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 doesn’t 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.





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.


PriorityM/D/O

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.


PriorityM/D/O

Legal and Regulatory






PriorityM/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






PriorityM/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:

- The solution’s 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.

CON

CON

Licensing






PriorityM/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 system’s 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






PriorityM/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.


PriorityM/D/O

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






PriorityM/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?


PriorityM/D/O

Change






PriorityM/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






PriorityM/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






PriorityM/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.

PORPOR

Data Migration and Conversion






PriorityM/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).


PriorityM/D/O

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






PriorityM/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)






PriorityM/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






PriorityM/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






PriorityM/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.)


PriorityM/D/O

RPR1

RPR





6.9 Reusability

Reusability is the ability to (re)use in future systems.


PriorityM/D/O

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





- 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 university’s minimisation of waste?


PriorityM/D/O

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






PriorityM/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?






PriorityM/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






PriorityM/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:

- 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).

UAA

UAA





7 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 discussionswith the various contributors. The table below lists the meetings and discussions that took place along withthe 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 project’s Stakeholder Analysis

spreadsheet.

Date Meeting Title / Topics Discussed Attendees

7.3 <Appendix 3>

0000 ba template business requirements v116

Documents