Nonfunctional Requirements

There are several different types of requirements ¡  Business Requirements ¡  Business Rules ¡  System Functional Requirements ¡  Non-Functional Requirements ¡  Data Requirements ¡  User Interface Requirements ¡  Enterprise Requirements

No, they're not requirements that don't work

Nonfunctional requirements describe the characteristics of the system

Functional Requirements Nonfunctional Requirement

What the system shall do What the system shall be

What the system does How well the system does it

The things it should do Measurements of how it does it

Windows Linux A computer operating system for running personal computers and enterprises

A computer operating system for running personal computers and enterprises

Very simple to use Purposely difficult to use

Expensive Free

Secretive Open

Takes huge amounts of disk space Very conservative in disk usage

Memory hog Very conservative in memory usage

Lets look at an example

Users have expectations about how well our software works ¡  How easy the software is to use, ¡  how quickly it executes, ¡  how reliable it is, and ¡  how well it behaves when unexpected

conditions arise.

Specify as precisely as possible by using numbers ¡ Max seconds it must take to perform some task ¡ Min concurrent users supported ¡ Max minutes per year a system may be down ¡ Max size of database ¡ Max millisecond response time

But what kinds of things should be measured?

Capacity ¡  Throughput – how many transactions per hour

does the system need to be able to handle? ¡  Storage – how much data does the system need

to be able to store? ¡  Predictions of growth

Flexibility ¡  If the organization intends to

increase or extend the functionality of the software after it is deployed, that should be planned from the beginning

¡  It influences choices made during the design, development, testing, and deployment of the system.

Recoverability ¡ Recovery process ¡ Recovery time scales ¡ Backup frequencies ¡ Backup generations

Auditability

¡ Audited elements – what business elements will be audited?

¡ Audited fields – which data fields will be audited?

¡ Audit file characteristics - before image, after image, user and time stamp, etc.

Reliability ¡ Reliability ¡ Mean Time Between Failures ¡ Mean Time To Recovery

Compatibility ¡  Portability specifies the ease with

which the software can be installed on all necessary platforms, and the platforms on which it is expected to run.

¡ Compatibility with shared applications – What other systems does it need to talk to?

¡ Compatibility with 3rd party applications – What other systems does it have to live with amicably?

¡ Compatibility on different operating systems – What does it have to be able to run on?

Scalability ¡  Software that is scalable has the ability to handle

a wide variety of system configuration sizes. The nonfunctional requirements should specify the ways in which the system may be expected to scale up (by increasing hardware capacity, adding machines, etc.)

¡  How many more users can it handle? ¡ Can we easily add capacity when it slows down? ¡ Can we add additional servers easily? ¡ Can we upgrade the current hardware easily?

Security/Integrity ¡  Integrity: Integrity requirements

define the security attributes of the system, restricting access to features or data to certain users and protecting the privacy of data entered into the software

¡  Login requirements - access levels, CRUD levels

¡  Password requirements - length, special characters, expiry, recycling policies

¡  Inactivity timeouts – durations, actions

Performance ¡  The performance constraints specify the timing

characteristics of the software. Certain tasks or features are more time-sensitive than others; the nonfunctional requirements should identify those software functions that have constraints on their performance.

¡  Response times - application loading, screen open and refresh times, etc

¡  Processing times – functions, calculations, imports, exports

¡ Query and Reporting times – initial loads and subsequent loads

Efficiency ¡  How well the software utilizes

scarce resources: CPU cycles, disk space, memory, bandwidth, etc.

Availability ¡ Availability: A system's availability, or "uptime," is

the amount of time that it is operational and available for use. This is specified because some systems are designed with expected downtime for activities like database upgrades and backups.

¡  Hours of operation – when is it available? Consider weekends, holidays, maintenance times, etc

¡  Locations of operation – where should it be available from, what are the connection requirements?

Robustness and Integrity ¡ A robust system is able to handle error

conditions gracefully, without failure. This includes a tolerance of invalid data, software defects, and unexpected operating conditions.

¡  Fault trapping (I/O) – how to handle electronic interface failures, etc

¡  Bad data trapping - data imports, flag-and-continue or stop the import policies, etc

¡ Data integrity – referential integrity in database tables and interfaces

¡  Image compression and decompression standards

Maintainability ¡ Conformance to architecture standards – What

are the standards it needs to conform to or have exclusions from?

¡ Conformance to design standards – What design standards must be adhered to or exclusions created?

¡ Conformance to coding standards – What coding standards must be adhered to or exclusions created?

Usability ¡  Usability: Ease-of-use

requirements address the factors that constitute the capacity of the software to be understood, learned, and used by its intended users.

¡  Look and feel standards - screen element density, layout and flow, colors, UI metaphors, keyboard shortcuts

¡  Internationalization / localization requirements – languages, spellings, keyboards, paper sizes, etc

Documentation ¡  Required documentation items and audiences

for each item

Reusability

¡  Reusability indicates the extent to which software components should be designed in such a way that they can be used in applications other than the ones for which they were initially developed.

¡ Many systems are developed with the ability to leverage common components across multiple products.

You may want to put them on cards to record them

Conclusion

¡  Scalability ¡  Security ¡  Integrity ¡  Robustness ¡  Recoverability ¡  Usability

¡ Documentation ¡ Maintainability ¡  Flexibility ¡  Reliability ¡ Auditability ¡  Performance

¡  Efficiency ¡ Capacity ¡ Availability

¡  Software can work as designed but still be unusable ¡  Nonfunctional requirements tell how the software

should do its job ¡  They should be quantified to make them precise ¡  Some of the things we require may be: