Software Requirements Specification

CS 4310Fall 2011

Davis, A., Software Requirements. Prentice Hall, 1993.Peters, J. and W. Pedrycz, Software Engineering An Engineering Approach. John Wiley and Sons, 2000.

Requirement

A requirement is a user need or a necessary feature, function, or attribute of a system that can be sensed from a position external to that system.

Describes what and not how. Uses the word shall. Examples:

The system shall display the current location of a ship. The system shall generate a dial tone within 5 seconds after a

person picks up the receiver.

Software Requirements Specification (SRS)

SRS is a document containing a complete yet concise description of the entire external interface of the system with its environment including other software, communication ports, hardware, and human users.

Carves universe into two sets All systems satisfying user’s real needs All systems that do not satisfy user’s real needs

SRS-1

Communication among customers, users, analysts, and designers Defines external behavior of system (cannot be

ambiguous) May give design to help with understanding but

developers are not bound by design

SRS-2

Support for system testing activities Primary input to system test planning and

generation Test to check if system meets requirements

Means of controlling evolution of system Check if modification is new refinement or

existing

Structure of an SRS

IEEE Std. 830-1993 Review of template

Types of Requirements

Behavioral: define what the system does; inputs, outputs, and transformation of inputs to outputs

Nonbehavioral: define the attributes of the system as it performs its job, e.g., efficiency, reliability, security, maintainability, portability, and standards of compliance

Groupings of Requirements

Related to same class of user Related to same real-world object Related to same external

stimulus/response Related to same system feature Related to same class of function

Weakest of all groups

Attributes of a Well-Written SRS-1

Correct iff every requirement stated therein represents something required of the system to be built.

Unambiguous iff every requirement stated therein has only one interpretation.

Attributes of a Well-Written SRS-2

Complete if it possesses the following: Everything that the software is suppose to do is

included in the SRS. Definitions of responses of software of all

realizable classes of input data in all realizable classes of situations are included

All pages are numbered, all figures and tables are numbered, named, and referenced; all terms and units of measures are provided.

No sections are marked TBD

Attributes of a Well-Written SRS-3

Verifiable (SRS) iff every requirement stated therein is verifiable. A requirement is verifiable iff there exists some finite cost-effective process with which a person or machine can check that an actual as-built software product meets the requirements.

Example requirements that are not verifiable: The product shall have an easy-to-use interface. The program shall not enter an infinite loop. Avoid words such as “usually”, “generally,” or “often”

Attributes of a Well-Written SRS-4

Consistent iff no requirement stated therein is in conflict with other preceding documents and no subset of requirements stated therein conflict. Conflicting Behavior: Specify different stimuli to induce a

response or different responses to the same stimuli Conflicting Terms: Terms used in different contexts to

mean the same thing. Conflicting Characteristics: Demand the product to

exhibit contradictory traits Temporal inconsistency: Demand the product to obey

contradictory timing characteristics

Attributes of a Well-Written SRS-5

Traced if origin of requirements is clear.

Traceable if the SRS is written in a manner that facilitates the referencing of each individual requirement stated therein.

Nonbehavioral Specifications

Non-behavioral Characteristics

Portability Reliability Efficiency Human Engineering Testability Understandability Modifiability

Portability

Degree to which software running on one host computer environment can be converted to run on another.

Not necessary for all applications (embedded systems, single-use systems).

Some applications, it is essential.

Problems with specification

May be impossible to quantify: “The maximum time to port to host system X shall be …” We don’t know what the next generation will

be; The maximum time is not useful: it doesn’t

affect the design of the system.

Approaches to Specifying Portability

Source language Java: JVM ported to lots of platforms Ada: DoD certifies – no extentions, no subsets Ideally, language is a design issue, but if its effect

on portability is critical, it’s a requirement Language selection tends to be political in

organizations Host operating systems

Say which ones up front, if you know Compiler selection

Ansi Standard compilers

Reliability

This is difficult in software: “The system shall be 99.999% reliable.”

What does this mean? It could mean that the phone system may lose

a call now and again, but the entire system must not fail for more than 5 minutes a year.

In a patient monitoring system, it may mean that if it does go down, it alerts staff. It must not make a mistake in monitoring more than one patient in 100,000.

Traditional reliability (hardware) Mean Time to Failure (MTTF)

MTTF of system is well defined in terms of MTTF of components. Redundant components improve reliability because failure of

components is independent. Hardware degrades in its environment. Bathtub curve for electronics over entire population of products.

time

failures

Burn-in

MTTF and Software

Software doesn’t degrade over time. Suppose you run a program for 10 years

without failure, then it suddenly fails. Why? Software was changed. Software was used a new way.

Bugs

Failure: Software does not do what is required (specified). Behavior is different from that needed.

Fault: A cause of a failure. Not all faults result in failure. All failures result from faults. A state in which there is a fault without a

failure is a hazard state. Error: A design or implementation flaw.

Testing

The purpose of testing is not to demonstrate correct execution of the program.

The purpose of testing is to discover faults.

Problems specifying reliability in terms of bugs Assume quality is designed in from the start:

The software testing shall require no more than two months.

Software testing shall discover no more than 10 bugs.

The software shall have no more than one bug per thousand lines of code. We want zero bugs, so this must be better

than 5 per 1000. How do we know how many there are? Wait

until software is retired, then count them.

Fault Seeding

Before testing, insert some bugs Track how many of these are found in

testing. Total bugs in system =

(#seeded * total_detected)/seeded_detected

Example

Secretly seed 10 bugs. Test team discovers 120 bugs, 6 of which

are seeds. Bugs = 10 * 120 / 6 = 200 bugs # bugs remaining = 200 – 120 = 80, 4 of

which are “known”.

Notes

Not all bugs are equal Equally difficult to find Equally difficult to repair

Seeding is harder than it looks. Intuitive Measure of testing effectiveness

Reliability

Levels of criticality Cause mild inconvenience Cause minor financial loss Cause major embarrassment Cause major financial loss Injure people Kill a few people Kill many people Destroy humankind

Example Reliability Requirement

No more than five bugs per 10K lines of executable code shall be detected during integration and system testing.

No more than ten bugs per 10K lines of executable code shall remain in the system after delivery, as calculated by the Monte Carlo seeding technique defined in Appendix III.

The system shall be 100% operational 99.9% of the calendar time during its first year of operation.

Efficiency

The utilization of scarce resources. Memory CPU Disk Communication

Easy to specify if limits are given Example: Air Traffic Control system: The

system shall trace the movements of up to fifty aircraft.

Need to say how it will degrade:

What if there are 51 aircraft? Possibilities: Software fails. Track first 50, ignore 51st. Software notifies 51st pilot to leave area.

Human Engineering: Levels of Specification The system shall have an easy-to-use

human interface. The system shall be menu driven. The system shall be menu-driven.

Appendix A shows sample menus. The system shall be menu-driven.

Appendix A shows all menus to be used.

Human Engineering: Error Messages Unless there is a sound understanding of

the types of error messages the system can generate, there is insufficient knowledge of the system’s expected normal behavior.

It is a good idea to have an appendix that specifies the text of all error messages.

Testability, Modifiability, Understandability Very difficult to quantify. These are important contributors to cost

(maintenance). One suggestion is to specify conformity to

a set of programming standards.

Programming standards specify

Naming conventions Invocation conventions

Calls, interrupts, synchronization Message formats

Component headers Format and content

In-line documentation style Use of global constructs and variables Use of named constructs Modularity standards

TEAM WORK (modified from IEEE SE Problems)

Irbis is gathering the requirements for a software-controlled furnace. After interviewing several users, Irbis obtained the following requirements: R1: Gas intlet valves shall always be open when furnace is

heating. R2: Heating shall stop when furnace temperature reaches 150°C. R3: Furnace temperature should increase gradually when heating. R4: The gas inlet valves shall be closed when the temperature

goes above 200°C.

In teams of 3, for each of the requirements: identify the requirement’s defects. Provide a fix to address the requirement’s defects. Indicate in which section of the SRS will you place the requirement

and the reasoning for your decision.