The System Requirement (SR) document template (IDA-MS-SR) provides guidance and template material for use by IDA projects in producing project-specific documents. This checklist summarises the recommended structure and contents of documents based on the template.
Sect No
Section Title
Activities
1
Introduction
Overview of the SR document and description of what is to be produced and delivered for the IDA Project• Document purpose and scope (1.1) – author(s), readership, system (products, benefits, relationship with other systems)
• Document overview (1.2)
• References (1.3) – all applicable and reference documents
• Definitions, acronyms and abbreviations (1.4)
2
Background
Information about the general factors that affect the product(s) and their requirements• Function and purpose (2.1) – expand on 1.1
• Environmental considerations (2.2)
• physical, hardware, operating environments
• specify where system is to be used and by whom; networks and platforms involved; operation in different member states etc
• Relation to other systems (2.3) – state whether the system is independent, subsystem of a larger one or a replacement
• Model (2.4)
• logical model at all levels, explained top-down
• describe functionality at all levels
• provide means to ‘walk through’ model level-by-level, function-by-function and flow-by-flow
• Relationship to other projects (2.5)
• put project in context of others past, present or future
• identify ‘parent’ projects or project(s) being replaced
• identify applications, tools and techniques used in other IDA or OSN projects
• General constraints (2.6)
• identify limitations on options for building software
• provide background information to justify constraints
• consider applications, tools and techniques from other projects especially Horizontal Actions and Measures
3
Specific
requirements
Information about project requirements:
• Overview (3.1)
• provide complete top-level statement of products and services to be delivered
• include pre-development services (eg requirements analysis), hardware, software, documentation, training, warranty etc
• provide overview of specific requirements pertaining to these deliverables
• Detailed requirements (3.2) structured top-down
• consider using requirements specification language
• only one requirement in each statement
• requirements must be verifiable
• some requirements may have to be provisional
• requirements to be marked essential or non-essential
• prioritise requirements
• Pre-development services (3.3)
• describe services to be procured at t he same time as main system development
• examples are: Feasibility study, Benchmarking study, Requirements Analysis, Project Planning, Evaluation of available products, Technological trials, Development of demonstrator (system mock-up)
4
Hardware
requirements
If the contract delivers hardware, specify requirements for each item of equipment; specify: type, number, functionality, standards, interfaces, performance, capacity, expansibility, reliability,
availability, durability, maintainability, running cost limitations, operational requirements etc
5
Tele-communication
services
Specify requirements if telecommunication facilities are to be delivered by the project. Omit this section if the project makes use of existing telecommunication facilities
6
System
capability
Sets of requirements to be described
• Functional (6.1) – purpose of system
• Interfaces (6.2)
• Software: e.g.,operating systems, software environments, file formats, database management systems and other software applications
• Hardware: hardware configurations
• Communications: for example, use of a particular network protocol
• External interface requirements should be described or referenced in Interface documents. User interface requirements should be specified under ‘Operational requirements’ (see be low). Interface requirements can be illustrated with system block diagrams
• Operational (6.3)
• running of system and its communication with users
• include all user interface and interactions
• include also logistical and organisational requirements
• examples are: screen layouts, error message contents etc
•
Security (6.4)•
protect against threats to confidentiality, integrity and availability•
take account of physical and electronic protective measures•
particular attention to telecommunication related securityrequirements, e.g. encryption, authentication, virus attack
•
Safety (6.5) – managing damage from system failure • Quality (6.6) – ensuring system is fit for purpose7
System
management
Requirements concerned with facilities to support operational management of system:
• Installation support (7.1) – facilities for installation and configuration of whole system or replacement components
• Diagnostic tools (7.2) – verification of correctness of system operation and diagnosis of faults
• Configuration, release control and faults (7.3) – system component registration, management and change control
• Instrumentation (7.4) – mechanisms to measure system activities and associated analytical/reporting tools
•
Tuning (7.5) – mechanisms to affect system performance•
Back-up and recovery (7.6) – mechanisms for back-up copies of data and system restoration including failure during recovery•
Operational control (7.7) (sometimes called SystemAdministration)
•
system support facilities, e.g. user registration•
focus on telecommunications aspects, e.g. network control•
Other (7.8) – system management requirements not yet covered8
Operational
characteristics
Requirements about system performance:
• Capacity (8.1) – physical resources required eg processing power, memory, disc space etc; include expansibility
• Performance (8.2) – must be quantitative, not qualitative, statements; possibly include worst/best cases and nominal value to be used for planning
• Availability (8.3) – details of days/times, tolerable breaks, system failure notification, usage during failure and availability monitoring
• Reliability (8.4) – acceptable mean time between failure (MTBF), minimum acceptable MTBF; reliability verification
9
System
architecture
Requirements specifically affecting the system architecture itself: • Maintaina bility (9.1) – fault repair and adaptability in
quantitative terms; influence of user availability/adaptability • Portability (9.2) – software ability to work on other (named)
systems
• Prescribed components (9.3) – applications, tools and
techniques available from other projects and OSNs; consider Horizontal Actions and Measures
• Software constitution and structure (9.4) – name actual products
10
Documentation
Requirements for project-specific documentation, including number of copies and medium of documentation.• Documents may include user training, user reference, system management, operational support, release notes, configuration control files, system maintenance, supplier reference, warranties
11
Other services
Requirements for services commissioned for provision during or after development. Need to specify for each: when detailed specification will be produced; procedure for approving these specifications; responsiveness and level of service to be provided by contractor; complaints and disputes procedure. Examples (not exhaustive) are:• Training (11.1) – specific courses, training material for users, support staff, system operators, maintainers and trainers
• Installation processes (11.2) – supply and delivery methods
• Data set-up (11.3) – developer or user to install data ?
• Parallel running (11.4) – developer involvement, if any
• Operational support (11.5) – developer provision, if any
• Warranty (11.6) – validity criteria for, and procedure to invoke, warranty; levels of service for corrections and warranty for corrections
• Maintenance (11.7) – developer’s obligations outside warranty including procedures for upgrades and system changes
12
Developmental
requirements
Requirements relating to the conduct of the contract:
• Roles and responsibilities (12.1) – details of team’s structure and roles to include points of contact, people with decision authority and quality control mechanisms
• Phases (12.2) – timing details for product delivery
• Verification (12.3) – details of constraints on how system will be verified, e.g. testing location, performers and timings; dispute resolution; validation of system against user needs
A
Requirements
traceability
matrix
Tabular information summarising how each requirement from User Requirement has been met in System Requirement document
B
Services
provided by the
Commission
Specify any tools, services or facilities to be provided by or on behalf of the European Commission. Examples are equipment, software licences, telecommunication facilities, software from earlier systems, office facilities and services, staff time.
(These are not requirements and are therefore shown in an appendix)
![1 [3 (4 Chlorophenyl)isoquinolin 1 yl] 3,5 diphenyl 1H pyrazole](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==)