1

SUMMARY

For: National Project Team
From: Ann Kinnear
Date: 5 March 2010
Subject: NON-FUNCTIONAL REQUIREMENTS
Antecedents:
None.

Background:
The functional requirements for NECS are one of the inputs to the determination of
an effective solution architecture for the system. Another necessary input is the non-
functional requirements or levels of performance required of the system. Defining the
non-functional requirements that will satisfy all stakeholders performance
expectations of NECS is as important as defining what the system must do.

Coverage:
This paper deals with the stakeholder performance expectations of NECS.
Audience:
This paper is likely to be of most interest to legal practitioners, licensed
conveyancers, financial institutions, mortgage processors and information brokers
who will rely on NECS as investors in legacy systems needed to interoperate with
NECS and/or as users dependent on it for continuing operational efficiency.

Relevance:
This paper is relevant to defining the requirements for NECS ahead of determining
the solution architecture and provisioning for the system that will sustain stakeholder
confidence.

Recommendations:
This paper recommends 44 specific non-functional requirements largely derived from
the Australian Standard for software engineering quality.
Total Pages:
8
Feedback Form:
Included and available separately.







2
For NPT Consideration

To: National Project Team
From: Ann Kinnear
Date: 5 March 2009
Subject: NON-FUNCTIONAL REQUIREMENTS

Purpose: To obtain the National Project Team (NPT)s views on draft non-functional requirements for NECS.

Background: A fundamental design consideration for NECS is to provide a system that stakeholders want to
use because it delivers obvious benefits in its functionality, efficiency, convenience, reliability and useability.
Characteristics such as efficiency, convenience, reliability and useability are non-functional requirements that
define how the system will perform in operation.

The significance of non-functional requirements is that they inform the determination of an appropriate solution
architecture for NECS that will deliver the functionality in an attractive, reliable and secure manner, irrespective of
how the system is provisioned.

The NECS Requirements Definition (NRD)
1
included some non-functional requirements but focussed principally
on functional requirements. In 2009 two consultancies were commissioned to explore stakeholder expectations
of system performance and to define non-functional requirements. The first, undertaken by Saratoga
Professional Services, included stakeholder consultations. The second, undertaken by Ajilon, focused on
applying the software engineering quality characteristics of Australian Standard AS9126:2005
2,3
.

From these reports six principal system performance characteristics were identified as the key non-functional
requirements for NECS:

Security (the ability of the system to protect information and data from unauthorised access)
Reliability (the ability of the system to maintain a level of performance)
Useability (the ability of the system to be easily understood, learned and used)
Efficiency (the ability of the system to deliver performance for resources consumed)
Maintainability (the ability of the system to be conveniently and efficiently modified)
Portability (the ability of the system to be readily transferred to another operating environment).

These characteristics each have a number of features or sub-characteristics, each with a metric to assess system
performance. In some instances the performance metrics are quantifiable (eg must achieve XX%) and in others
they rest on qualitative compliance (eg must comply with XX).

Key Issues: While all of the proposed requirements are important in provisioning a system that will attract and
retain stakeholder use and confidence, the nature of NECS makes some of the requirements more critical than
others. Principal among these are:

1. Security
NECS is intended to handle transactions involving the exchange and mortgaging of property worth in the
vicinity of $1 billion per day. Significant numbers of people will have legitimate access to it via the Internet
using systems of various levels of sophistication and intrusion protection.

It is critical therefore that the system is as secure as possible from unauthorised access. This means not only
that there must be rigorous access controls in the application but also that the core architecture of the system
contain robust features and tools to prevent unauthorised access. NFRs 1 to 4 are intended to provide these
protections. They are to be additional to both the security features defined in the functional requirements and
the compliance with the information security requirements of Australian Standard AS27001:2006.

2. Reliability
NECS is intended to become the preferred means of completing the majority of property transactions. To
achieve this position will require many industry and government stakeholders to invest significant sums in

1
NRD v6 030908 6.6 & 6.7.
2
The Saratoga and Ajilon reports are available at http://www.necs.gov.au/ and AS9126 is available for purchase at http://infostore.saiglobal.com/store/.
3
Although AS9126 is configured for use in evaluating the quality of developed and implemented software, its principles, characteristics and metrics are equally
applicable as requirements for a yet-to-be-provisioned system.




3
readying their existing systems and procedures to use NECS effectively. Those stakeholders will become
dependent on NECS and they will not be in a position to readily revert to paper conveyancing procedures in
large volume.

It is critical therefore that the system is as reliable as possible. This means it must be configured to minimise
downtime and unavailability. Particularly important will be:

redundancy of all key hardware and software components
monitoring and warning of potential failures
self-correcting and automatic re-start capabilities wherever possible
prevention of accidently or maliciously incorrect operations
re-starting at any time without partial updates
restoring to a pre-failure point without partial updates.

NFRs 5 to 12 are intended to ensure a system that can sustain an availability of at least 99.99% for 24/6 with a
mean recovery time of 4 minutes and restart and restore at any time without losing any transactions. For an
industry system such as NECS that is to provide essential ongoing infrastructure for a large number of diverse
users, these levels of performance are critical to securing user investment commitments and take-up.

3. Useability
NECS is intended to be used by a wide variety of industry participants with varying knowledge of computer
applications and of conveyancing procedures. The systems functional requirements must therefore be
implemented in a manner that makes it simple and attractive to use with the minimum of prior learning
required. Particularly important in this regard will be:

ready workflow understandability without the need to follow a manual
an independent adjunct system for context-sensitive help
intuitiveness in the presentation of content and navigation
prediction in the use of default values and re-use of data
presentation consistency, with keyboard shortcuts and customising options
ability to undo actions and to restore to a previous point at any time
suitable for users with disabilities.

NFRs 13 to 25 are intended to address these requirements. While primarily relevant to web browser users,
the principle of context-sensitive simplicity will need to carry through to the number, purpose and content of
messages made available for web services use.

Proposals: The non-functional requirements proposed for adoption in the NRD are set out in the table below.
In this table:

Characteristic refers to the key system performance area identified as important by stakeholders
AS9126 Metric refers to the measure in the Standard selected as appropriate in the NECS context
Quality Criteria refers to the performance issue that the metric addresses
NECS Requirement is the performance required of NECS to satisfy the quality criteria.

Characteristic AS9126 Metric Quality Criteria NECS Requirement Ref.
Security Access
Auditability
How complete is the audit
trail concerning user access
to the system and data?
The core architecture of the system
must provide the ability to record
access to the system to allow for
recalling access history for audit
purposes.

NFR-01
Access
Controllability
How controllable is access to
the system?
The core architecture of the system
must provide control over the access to
the system.

NFR-02
Data Corruption
Prevention
What is the frequency of data
corruption events?
The core architecture of the system
must have methods for ensuring data
and data streams are delivered intact
and not corrupted through errors or
purposely altered in transit.

NFR-03
Interface
Standard
Compliance
How compliant are the
interfaces with applicable
regulations, standards and
conventions?
The core architecture of the system
must provide standard interface
capabilities which are published.
NFR-04




4
Characteristic AS9126 Metric Quality Criteria NECS Requirement Ref.
Reliability Breakdown
Avoidance
How often does the software
cause breakdown of the total
production environment?

The system must have redundancy at
all levels to avoid service breakdown.
NFR-05
Failure
Avoidance
How many fault patterns were
brought under control to
avoid critical and serious
failures?
The core architecture of the system
must provide monitoring functions to
alert to any potential problem. The
system must also have a level of self-
correction with automatic restarting as a
minimum.

NFR-06
Incorrect
Operation
Avoidance
How many functions are
implemented with incorrect
operations avoidance
capability?
The core architecture of the system
must provide features to avoid
accidental or malicious incorrect
operation.

NFR-07
Operational
Availability
How available is the system
for use?

The system must provide service from
Sunday Midnight through to Saturday
Midnight (ie 24/6).

NFR-08
Mean Down Time What is the average time the
system stays unavailable
when a failure occurs?

The system must be available 99.99%
(four nines) of the service time
NFR-09
Mean Recovery
Time
What is the average time the
system takes to completely
recovery from a failure?
The system must recover from a fault
within 4 minutes to achieve the four
nines level of service.

NFR-10
Restartability How capable is the system of
restarting without impacting
user operations?

The system must be able to restart to
the stage it was when it went down.
This includes all confirmed, complete
transactions. No partial transactions or
restores are to be possible.

NFR-11
Restorability How capable is the system of
restoring itself after abnormal
event or at request?
The system must be able to restore to
the point in time that the system went
down. Restoring to a previous night
backup is inadequate. The system must
restore to the point it failed with all
transactions complete. Partial updates
must not be allowed.

NFR-12
Useability Demonstration
Accessibility
What proportion of the
demonstrations/ tutorials can
the user access at any time?
The system must include an
independent adjunct system to run with
the main application to provide access
to, manage and publish context
sensitive help text.

NFR-13
Function
Understandability
What proportion of the
systems functions is the user
able to readily understand?
The system must be understandable
without the need to follow a manual or
receive extensive instruction. The
actions required in using the system
effectively must be clear and backed up
by comprehensive context sensitive
help text.

NFR-14
Function
Learnability
How long does the user take
to learn to use a function of
the system?
The system must be intuitive and use
web conventions found in commonly
used public news, search and e-
commerce websites. The system must
be able to be used effectively by
someone with only basic computer
skills.

NFR-15
Documentation
Effectiveness
What proportion of tasks can
be completed correctly after
using the user documentation
and/or help system?
The systems help text must be context-
sensitive and provide details and
examples of each particular area to
assist the user in progressing in their
task.
NFR-16




5
Characteristic AS9126 Metric Quality Criteria NECS Requirement Ref.
Operational
Consistency
How consistent are the
components of the user
interface?

The system must have a consistent
look, feel and navigation across the
application.
NFR-17
Error Correction Can users easily correct
errors they make in using the
system?
The system must initially prevent users
from making errors and provide
constructive guidance on how to
address any errors made.

NFR-18
Default Value
Availability
Can users easily select data
field values for convenient
operation?

The system must wherever possible
and appropriate provide default values
for data fields.
NFR-19
Message
Understandability
Can users easily understand
messages from the system?

The system must provide messages
that are clear and unambiguous and
linked to detailed context-sensitive help
text.

NFR-20
Operational Error
Recoverability
Can users easily recover
from errors they make in
using the system?

The system must provide controlled
response in the event of an operational
error.
NFR-21
Undoability How frequently does the user
successfully correct input
errors?

The system must provide the user with
an option to undo their last acting in
using the system.
NFR-22
Customisability Can users easily customise
operation procedures for their
convenience in using the
system?

The system must provide users with the
ability to customise their experience of
the system.
NFR-23
Operation
Procedure
Reduction
Can users easily reduce
operating procedures for their
convenience?

The system must provide features to
improve operation procedure, such as
customised workflow and keyboard
short cuts.

NFR-24
Physical
Accessibility
What proportion of functions
can be accessed by users
with physical handicaps?

The system must comply with the W3C
Accessibility Guidelines
4
.
NFR-25
Efficiency Response Times How long does it take before
the system response to a
specified operation?

The system must provide an average
response time of less than 3 seconds
across all operational functions.
NFR-26
System
Throughput
How many tasks can be
successfully performed
simultaneously?

The system must provide the average
response time with 100 concurrent
users on a single server.
NFR-27
Device Utilisation Is device utilisation causing
operating inefficiencies?
The systems device utilisation must be
within manufacturer guidelines and
provide for at least 30% load growth.

NFR-28
Memory
Utilisation
Is a memory limitation
affecting the efficient fulfilling
of a function?

The systems memory utilisation must
be within manufacturer guidelines and
provide for at least 30% load growth.
NFR-29
Maintainability Audit Trail
Capability
Can maintainers easily find
the specific operation which
caused a failure?
The core architecture of the system
must have audit capabilities for use in
error tracing and issue management in
the all key components of the system
including hardware, operating system,
application server, database and
application system.

NFR-30
Diagnostic
Function Support
How capable are the
diagnostic functions in
supporting causal analysis?
The audit capabilities of the systems
core architecture must produce human
readable logs to assist in tracing errors
NFR-31

4
See http://www.w3.org/TR/WAI-WEBCONTENT/




6
Characteristic AS9126 Metric Quality Criteria NECS Requirement Ref.
and issues arising in the system.

Failure Analysis
Capability
Can maintainers easily find
the cause of a failure?
The core architecture of the system
must have tools which can be used to
assist in diagnosing errors and issues.
This must include software debugging
capabilities.

NFR-32
Status Monitoring
Capability
Can maintainers easily find
the cause of failure by getting
monitored data during
operation?

The core architecture of the system
must have automated status monitoring
capabilities with alerts to SMS and
email as a minimum.
NFR-33
Change Cycle
Efficiency
Can system problems be
solved within an acceptable
time scale?
The system must support a change
cycle of 3 months or less including all
development, testing and deployment
whilst maintaining operational
performance levels required.

NFR-34
Software Change
Control Capability
Can maintainers easily
change the software to
resolve problems?
The source code of the system must be
provided with change control
capabilities to manage maintenance
and enhancement with multiple
developers.

NFR-35
Modification
Impact
Localisation
Can maintainers easily
mitigate failures caused by
maintenance side-effects?
The system must be designed to allow
changes to be applied in a small area of
the application thus minimising the
impact of changes being deployed.

NFR-36
Portability Data Structures
Adaptability
Can maintainers easily adapt
data sets to a new operating
environment?
The database of the system and other
data stores must be able to be easily
moved to another hardware platform
without loss of data integrity. This must
be achieved without any changes to
user systems.

NFR-37
Hardware
Environment
Adaptability
Can maintainers easily adapt
the software to a new
hardware environment?

The system must be able to be moved
to alternative hardware platforms either
locally or in a completely different
location without loss of data and without
any changes needed to user systems.

NFR-38
Organisational
Environment
Adaptability
Can maintainers easily adapt
the software to a new
organisational environment?

When the system is moved to
alternative hardware and locations, it
must maintain the interfaces with other
systems internally with no code
changes and all configuration changes
able to be made in one location.

NFR-39
Porting
Friendliness
Can maintainers easily adapt
the software to an alternative
environment?

The system must be able to be moved
to alternative hardware with no coding
changes and no change to any systems
that interface with it.

NFR-40
Available Co-
existence
How often do users
encounter any constraints or
unexpected failures when
operating concurrently with
other software?

The system must be able to exist in a
virtualised environment with multiple
operating environments on a single
hardware server running other systems.
NFR-41
Additional
(not specifically
provided for in
AS9126)
Web Browser
Versions
How many users can readily
access the system by web
browser?

The system must support browsers
used by at least 90% of the user
population
5
.
NFR-42
Software
Technology
How readily can experienced
people be obtained to
The system must be written in
mainstream coding languages requiring
NFR-43

5
See http://www.w3schools.com/browsers/browsers_stats.asp




7
Characteristic AS9126 Metric Quality Criteria NECS Requirement Ref.
develop and maintain the
system?

skills readily available in the local
market place.
Multi
Environments
Can development, testing
and production be carried out
at the same time?
The system must provide separate
environments for development, system
testing, user acceptance testing,
performance testing and production.

NFR-44

Recommendation: It is recommended that these non-functional requirements be endorsed for use in defining
NECS.

Feedback: A template for securing industry feedback is attached and provided separately for ready completion
and return.
_____________




8
NPT FEEDBACK FORM Non-Functional Requirements

This template is intended as a ready means for industry participants to document their feedback. Please provide
your name, industry involvement and contact details for validation purposes.




1. What is your general view on the performance requirements expected of NECS?













2. How will your business or practice be affected by each of the performance requirements?












3. Do you believe the performance requirements are in the best interests of all parties?












4. What is your preference for the performance requirements of NECS?













PLEASE RETURN YOUR FORM TO ........................................................................ BY ........................................
(Replace with your feedback)
(Replace with your feedback)

(Replace with your feedback)

(Replace with name, industry involvement and contact details)
(Replace with your feedback)