This section should paraphrase the project vision and include a short jargon- free statement stating what the project is intended to deliver. This can be found in the project brief.

This describes the objective of the project, and might include describing how the future organisation will look and feel, how it will conduct business be developed and what impact it will have on the business.

Having set the overall context by outlining the project vision, the text should now establish the need/purpose of the requirements as well as background/internal and external drivers.

Describe who will use the product and for what purpose. For example, describe its usefulness as an input to the package selection/assessment processes and how it will inform the selection criteria applied within those processes.

Describe the inputs to the products. (These are documents which feed into this requirement specification, for example strategy documents which drove this project's creation).

Describe the structure of the product.

This section covers the areas of the project which are within the scope of this high-level requirements specification, and the areas which are excluded from this specification. This is useful either when the HLBR is one of several different sets of requirements for different pieces of the project, or when there is a need to explicitly state the scope of requirements (for example, “this requirement specification will cover requirements for the X system, but not for the reporting sub-system which is covered by a separate project”)

N.B: Service, Technical, Commercial and Financial Requirements will be detailed separately in the SSR_RFP.

State areas which are explicitly included in the scope of this requirements document.

State areas which are explicitly excluded from the scope of this document (e.g. requirements which will be addressed in a later phase).

This section covers the two main types of requirements - functional and non-functional. For more information about establishing user requirements please see the best practice “Compiling Business Requirements”.

Please Note: Once these requirements are baselined and agreed, any changes to them will have to be made via formal change-control processes.

Appendix 2 contains a detailed requirements checklist for you to use in checking that the requirements captured are verifiable requirements.

This section is for the capture of functional requirements (please see the “Compiling Business Requirements” best practice guideline for more information on different kinds of requirements. Also - it is highly recommended that anyone involved in eliciting requirements and the capture thereof should have completed departmental standard Business Analyst Training - http://www.paritytraining.co.uk/mpo/cstm/dwp/group.asp?jra=16&sc=17). In brief, however, Functional Requirements typically cover requirements on a system which govern functions that the system can offer (generally describing an activity that the user can do with the system). An example would be “Capture New Application”. Non-functional requirements are generally requirements on a system which are not describing an activity which a user could perform on the system - for example “Response times must be quicker than 3 seconds”.

It is recommended that functional requirements are captured in use-cases (for more on use-cases, please see the “Capturing Business Requirements” best practice).

Key areas to consider are:

These functional requirements could cross reference against a business process (since an action-step in a business process may relate to a system function)

This section specifies requirements for reports or printed output from the solution - some examples may be:

Report requirements would generally be specified in a large amount of detail, and so the grid below may refer to a detailed report definition. At HLBR stage, this would probably only specify the data which the report should contain, but at detailed requirements stage this should also include a mock-up of the final report (for layout purposes).

Here, please consider requirements for help functions such as:

Here, please consider user System Management function requirements such as:

This section captures the non-functional requirements on the system in question. Please see Annexe 1 - Sample Non-Functional Requirement Areas for a list of areas that you may consider as candidate non-functional requirements.

Where security requirements relate to functions that the user must perform (e.g. create user account, or update user permissions), these requirements should be captured in section 3.1. Where security requirements don't involve a function that a user will perform, but are embedded in the system (e.g. “users should only have access to the system components which are allowed by their user-profile”), they should be captured within the table presented below:
(Please Note: Specific guidance on Security Requirements applicable to the DWP environment is available from the DWP Security Group - these requirements are mandatory, so the reader is advised to make contact with this group early in the development of the requirements).

All projects that involve elements of IT should ensure compliance to UK Government and DWP security standards. Please see link to the Information Systems Security Standards (ISSS) - the Department's overarching security principles and policies. There are other more specific policies which can be accessed via the intranet on the DST site.

http://intralink.link2.gpn.gov.uk/1/corp/sites/dsg/standards/dwp_m127343.pdf

IT Projects should cover security in all stages of development and should not only consider the IT security aspects while in development but should assess how that will translate once the service goes `live' For advice on IT Security operational issues contact the IT Security Operations Management (ITSOM) team.

Capture here requirements of when the system must be available for end users (although it is tempting to say “24x7”, this may have a cost implication, and it's valuable to specify the true required availability for the system).

Here, please consider user access requirements such as:

3.2.4 Accessibility

All projects introducing change for DWP staff and or customers must ensure that they meet the requirements of the Disability Discrimination Act (DDA) (1995), as amended. This section should be used to capture the high-level requirements relating to accessibility for disabled people. These are likely to focus heavily on the IT elements of the project; however consideration should also be given to other areas of impact on disabled people, not directly related to IT, including customer interactions, staff processes and job roles.

Development of specific accessibility requirements will also be informed by undertaking an Equality Impact Assessment at an early stage of the project. An outline assessment of the potential impact of the project/system on disabled people (both staff and customers) should have been undertaken in the Assess Feasibility phase but this will need to be built-on in order to fully define accessibility requirements.

In order to help deliver our responsibilities under the DDA, all IT systems developed or purchased for DWP must comply with the DWP IT Accessibility Standards Version 2.0. These incorporate the DWP E-Communications Intranet and Internet Accessibility Standards, applicable to all web-based IT systems.

An Accessibility Best Practice Note is now available highlighting the mandatory activities projects will undertake to meet DDA requirements. Accessibility is an integral part of the Department's Enterprise IT Architecture. Projects will be assessed at gated reviews against key accessibility criteria within the Enterprise Architecture Assurance Dashboard.

All projects introducing change for DWP staff and or customers must ensure that they meet the requirements of the Disability Discrimination Act (DDA) (1995), as amended. This section should be used to capture the high-level requirements relating to accessibility for disabled people. These are likely to focus heavily on the IT elements of the project; however consideration should also be given to other areas of impact on disabled people, not directly related to IT, including customer interaction processes and staff processes and job roles.

In order to help deliver our responsibilities under the DDA, all IT systems developed or purchased for DWP must comply with the DWP IT Accessibility Standards Version 2.0. These are an integral part of the Department's IT Enterprise Architecture and Technology Policies, and incorporate the DWP E-Communications Intranet and Internet Accessibility Standards, requiring web-based IT systems to meet the W3C Web Accessibility Initiative Web Content Accessibility Guidelines to at least “AA” standard.

In practice this means that IT systems must be designed to be used effectively by everyone, regardless of visual, hearing, physical/motor or cognitive impairment. Systems for use by DWP staff will need specifically to be compatible with the major assistive technology products used in the DOI environment. More information about types of impairment, how each can affect an individual's ability to use IT, and about current DWP assistive technology packages can be found in the DWP IT Accessibility Standards document.

Development of specific accessibility requirements will also be informed by undertaking an Equality Impact Assessment at an early stage of the project. An outline assessment of the potential impact of the project/system on disabled users (both staff and customers) should have been undertaken in the Assess Feasibility phase but this will need to be built-on in order to fully define accessibility requirements.

For more information about the full range of activities, projects will need to undertake to ensure the requirements of the DDA are met, see the Accessibility Best Practice Guidance.

3.2.5 Sustainable Development

The Department is committed to contributing to the delivery of UK Strategy for Sustainable Development, and this is outlined within the Department's Sustainable Development Policy Statement.

The core work of the Department explicitly supports the social and economic pillars of sustainability. We need to ensure that the way that we deliver our business contributes to these priorities and also contributes to the third, environmental pillar.

There are a number of cross Government targets in place that cover key environmental issues. The following issues are particularly pertinent, and should be highlighted within the HLBR allowing suppliers to develop efficient solutions.

Energy - The Department spends in excess of £17,000,000 per annum on electricity. There are cross Government targets in place that require us to increase energy efficiency at the same time as reducing overall usage. All projects need to consider if there are ways that new IT systems can contribute to these aims.

Waste - the Department produces over 30,000 tonnes of waste each year. The majority of this is paper waste and this is recycled wherever possible. However, the main cross Government waste targets require departments to reduce the amount of waste that is generated. All new IT systems and processes should seek ways to reduce the amount of waste, particularly paper waste that is produced. For example, reducing the number of paper prints produced, and storing information electronically would mean a reduction in paper consumption, waste generation, transport costs and associated storage issues. All these would in turn generate financial savings.

Resource use - generation of waste is closely associated with resource use. One of the main priorities of the current UK sustainable development strategy is to encourage more sustainable patterns of production and consumption. All IT solutions should seek to support this priority. For example, reducing the volume of paper used within a process would provide resource and financial savings to the Department.

3.2.6 Usability

The following are some examples of possible areas for usability requirements:

IT Service Continuity is a separate non-functional requirement area (separate from availability) including recoverability and covering the requirements below. These must be reviewed by ITSCM as part of the quality review. NB: Some of these requirements can be populated from known contractual provisions already in place. Only variations need to be specified.

The following Service Continuity requirements must be covered:

: Number of updates annually - essential

3.2.8 Performance

Please capture here any requirements on the system in terms of performance - some examples of possible requirements may be:

3.2.9 Capacity/Volume

Please capture here any requirements on the system in terms of capacity/volume - some examples of possible requirements may be:

3.2.10 Interoperability

Two types of interoperability need to be considered within this section: -

Real time interoperability refers to interchange of information between systems that occurs on a real time basis, i.e. the operator is unaware of the transfer process between repositories, manual intervention not being required. This applies to situations when vendors consider there to be an advantage in the interchange, usually within the context of open standards.

Batched interoperability refers to interchange that is not achievable synchronously. This usually applies to situations where a utility needs to be run in order to render an output in some intermediate format that conforms with a standard, XML for example. A corresponding import process is usually then required by the exchange partner.

Having established this definition, interoperability standards may now be identified via consideration of: -

3.2.11 Data

Data is central to integration/interchange between systems and is therefore presented within its own section. In addition, new DWP systems will still need to exploit the legacy domain and existing data repositories Data standards for exchange will therefore be of primary importance.

The aim of this section is to document any requirements on the system in question, in terms of accessing data in a particular format. Some examples may be:

For the above specified data sets, it is useful to look at the following (especially when investigating the next level of detail):

3.2.12 Interfaces

This section defines inter-system interfaces that this system must comply-to or implement. Some examples may be:

Please note: There may be overlaps between this section and the data-section - where overlaps do exist, please make an explicit note of this overlap and use cross-references to highlight.

3.2.13 Audit

If there are specific requirements which relate to creating an audit trail in the system, then these would be covered here. An example may be “every attempt to access customer records should be logged with the user-name, date, time, etc”.