Overview

System requirements are clearly articulated statements of what a system must be able to do in order to satisfy stakeholder needs and requirements and are derived from business requirements and user requirements, as per the “Requirements Hierarchy” figure below. They should be defined in two clear categories, functional and non-functional. Functional requirements describe the required behaviour and functions of the system. Non-functional requirements describe specific criteria that can be used to judge the operation of a system e.g. performance, security, availability.

Requirements Hierarchy

Requirements Hierachy

Steps:

The Target System Architecture describes the desired system end-state, but implementing all functionality at once in one release is likely to be unmanageable and not deliver stakeholder expectations. Depending on the gap between current capabilities and the desired end-state, you will need to define the scope for each release in terms of business functions and CRVS processes to be supported, considering what is realistic and will deliver early benefits.

1

Document a high-level implementation roadmap that defines the scope of all releases and their implementation schedule to realise the Target CRVS Processes and Target System Architecture. This roadmap should show releases being implemented over time using a modular and incremental approach, as per the indicative figure below.

For each release, follow the steps detailed below.

Implementation-Roadmap

Principles for defining release scope

  • Ensure the target CRVS processes and system architecture are confirmed before defining the scope of the first release
  • Modularity: supporting one business function or process at a time (e.g. birth registration then death registration)
  • Incrementalism: providing stepped levels of support for business functions, with an emphasis on smaller releases first to build skills and confidence in the system
  • Consider initial release to digitise unchanged processes to minimise user disruption
  • Initial releases to include business priorities so that results can be seen early, promoting further buy-in and investment
  • Releases should be planned based on what technical infrastructure and legislation exists, without waiting for long term improvements and changes
  • Keep It Small and Simple “KISS”!
  • Defining the scope of releases is critical to project success and requires significant experience – consider the use of external consultants.

See Design-Reality Gap Techniques for more advice.

2

Define system use cases for the release scope using the CRVS Use Case Template, based on the user/system interactions defined in the target CRVS processes.

How to write a good use case

  • Identify all the different users of the system and the roles they play within the system
  • For each user role, identify all the significant goals the users have that the system will support.
  • Create a use case for each goal, following the use case template. Maintain the same level of detail throughout the use case. Steps in higher-level use cases may be treated as goals for lower level (i.e., more detailed) use cases.
  • Structure the use cases but beware of over-structuring, as this can make the use cases harder to follow.
  • Review and validate with users
3

Document user personas for all actors involved in the system use cases for the release scope using the User Personas Template­ to identify key characteristics of the user. Using input from user research at the focal point of design decisions ensures that the system works in such a way that fulfils user needs.

4

Define the full list of functional requirements for the release scope by reviewing the target system architecture, processes, use cases, and user personas in order to identify required functionality.

5

Define the full list of non-functional requirements for the release scope considering required operational standards and non-functional standards provided below. Defining a comprehensive list of non-functional requirements mitigates the risk of the system not performing as expected, allowing you to define performance standards.

Type of Non-Functional Requirements Description

Performance related, observable requirements

These requirements allow you to define how you want and need the system to perform within defined parameters to ensure high quality performance, minimise down-time and fulfil user needs. This will include reliability, availability, usability and security.

Requirements that support system evolution over time

These requirements allow you to define ways in which the system can be adapted and evolve as the number of users and amount of data in the system increases and requirements further develop. These will include scalability, adaptability, maintainability and extensibility

Key Non-Functional Requirements: Defining Performance Standards

Consider the below standards when defining your non-functional requirements to take advantage of pre-existing internationally recognised standards.

 

Category

Sub-category

Sample Standards

Technical

IT Network

ISO/IEC/IEEE 8802
 

Software quality management system construction

ISO 9001:2000
 

Biometrics

ISO/IEC 19784/5
 

Scanning (of historical paper records)

United Nations Department of Management Archives and Records Management Section, Standard, April 2009, Recod-keeping Requirements for Digitization

Electronic Communications and Transactions Act, 2002 (Act No. 25 of 2002) South Africa
 

Telecommunications

ISO ICS 33.040

Security

Information and Records Management

ISO 15489 
 

Information Security Management

ISO/IEC 27002
 

Business Continuity Management

ISO 223.1

Privacy

Data Protection

ISO/IEC 27001
 

Freedom of Information

PAIA Act No. 2, 2000, South Africa
 

Biometrics

ISO/IEC 19794/5

Auditing

Information and Records Management

ISO 15489 

International Standards for Non-Functional Requirements

6

Define system integration requirements for the release scope, considering the data consumed and provided by each application and consistent with the entity-relationship diagram.

7

Define data migration requirements:

  • What data will need to be migrated to the new system?
  • What level of transformation, weeding and cleansing is required to ensure that the data meets the requirements and constraints of the target system?
8

Selecting a Platform for the Long-Term

When considering proposals from potential vendors, it is critical to assess which platform type is appropriate for your context and that will adapt and grow as the solution evolves; this will also help prevent vendor and technology lock-in, a fact that the World Bank’s Digital Identity Toolkit, A Guide for Stakeholders in Africa (June 2014) clearly identifies as a challenge for National ID systems as well.

“Vendor and technology lock-in is an important consideration since identity systems tend to develop a network effect, i.e. they increase in size and value as more people enroll and more governmental and non-governmental programs depend on them. This dependency – whose effect is often seen at the time of contract renewal, in the form of incumbent or legacy system advantage – makes it harder (or more costly) to migrate from one vendor or technology to another.”

Consider whether you want to define what type of platform should be developed. If developing the system internally, you will need to carefully consider the below options. If procuring the system from an external vendor, you can also ask for specific justification of the use of one platform type and decide based on different proposals.

The below table outlines the pros and cons of different platform types.

Platform Type Pros Cons

Out-of-the-box software

  • Lower up-front costs

  • Know what you’re getting

  • Shorter delivery timescale

  • Support often included

  • Upgrades often free/at a reduced cost

  • Already tested/refined through other implementations

  • Community support available (through forums & expert users)

  • May have to adjust processes to meet software limitations

  • Feature requests ignored if larger customer base do not demand it

  • High customisation fees

  • If costs are charged per user, costs can be very high

Custom-developed software

  • Get what you need/want

  • Freedom to change the software to align with business needs

  • Built with your business and employees in mind

  • Potential to engage local IT industry

  • No licensing costs

  • Ability to brand the software

  • Specific application support from people who know the platform

  • High up-front costs

  • All changes to the software come with an associated cost

  • Software might still not fulfil all needs/wants

  • Dependent on technical capabilities of the team hired to develop

  • Support dependent on availability of developers and people who know the custom software

Open Source software

  • Few, if any, licensing fees.

  • Easy to manage due to the absence of licensing requirements

  • Continually evolving as developer add and modify it

  • Ability to update the software to meet the needs of your business

  • Not tied to a particular vendor’s platform that only works with their other systems

  • No guaranteed support, dependent on community of users to respond to and fix problems

  • Software can be orphaned when developers stop updating it

  • Evolves with developer’s wishes rather than user/business needs

  • Malicious users could negatively update the software

Cloud Hosted Solution

  • Cost-effective – lower up-front costs, removes need to buy expensive software and pay for licensing and lower traditional server costs;

  • Reduces the need for specialised skills to maintain the service;

  • Accessibility – allows access from multiple platforms;

  • Adaptability – enables almost immediate use without application setup and installation;

  • Data centralisation – all your data in one place that can be accessed remotely

  • Scalability – allow for easier and more flexibility scalability to cope with increased transaction loads as and when needed

  • Cloud security

  • Provides a flexible testing environment

  • Low bandwidth will negatively affect performance;

  • Lack of insight into your network – difficult to resolve bugs;

  • Data protection legislation and/or government policies may prohibit the use of cloud-based data storage
9

Review System Requirements with relevant stakeholders as per the RACI Matrix defined in your Project Implementation Document.

10

Define a change control process that will ensure that any changes are approved through the correct channels and communicated to all parties. See the Change Control Guide for guidance on how to do this.