1. Requirements and Specifications
Software Testing and Verification
Lecture 3
Prepared by
Stephen M. Thebaut, Ph.D.
University of Florida

2. What are Requirements and Specifications?
something required; something wanted or needed; an essential requisite...
To Specify:
to name; to state explicitly or in (sufficient) detail...

3. Roles of Requirements in Testing and Verification
How are requirements used in testing?
Serve as basis for black-box test case design.
Source of expected results for ALL test cases.
What do requirements have to do with the formal correctness assertions:
{P} S {Q} ? f = [S] ?
What if there are no requirements?

4. Roles of Requirements in Testing and Verification (cont’d)
Bottom Line: testing and verification only make sense when requirements in some form are available to work with.

5. Exercise Consider the following pseudocode program: Sum := 0 J := 1
while J<=N do
Sum := Sum + X[J]
J := J+1
end_while
What does it do? Is it correct?

6. Requirement/Specification Types
Functional versus Non-Functional
Formal versus Informal
Structured versus Unstructured
State-model based versus Operational
Graphical versus Textual

7. A Sampling of Requirement Representations
Natural language prose
Numbered paragraphs (ala DoD standards)
Functions, Attributes, and Constraints (ala Gause & Weinberg)
Structured templates (of various sorts and levels) – e.g., Volere “shell”, XP “user stories”
Decision tables
Pseudocode programs
(cont’d)

8. A Sampling of Requirement Representations (cont’d)
PDL models (PSL, RSL, etc.)
Cause-Effect models
State-Transition models
Pre- and Post-conditions
Recursive (“intended”) function definitions
Algebraic specifications
Z-based Schemas
Etc.

9. Exercise Identify each of the following requirements representations:
Sample.specs.pdf

10. Requirements Sources at Different Levels
Typical System-Level Sources
Objectives document
User manuals (e.g., “MAN Pages”)
Installation documents
Service manuals
Requirements definition/specification
(cont’d)

11. Requirements Sources at Different Levels (cont’d)
Typical Unit-Level Sources
Module/function/procedure specifications
Pseudocode
“Logic specifications”
Object class/method specifications
(cont’d)

12. Requirements Sources at Different Levels (cont’d)
Typical Intermediate- (e.g., Product/ Component) Level Sources
Product/component specification
“Functional specification”
Object use-include relations, sequence/collaboration diagrams, package specification

13. (Some) Key Attributes Completeness Consistency Unambiguousness
Verifiability/Testability
Correctness (?)

14. Completeness Possible Definition for Functional Requirements:
The desired response is specified for every possible stimulus and every system state.
Definition for Non-Functional Requirements:
Constraints and preferences for every relevant attribute of every desired function are specified.

15. Consistency Possible Definition:
There are no contradictions or conflicts in any specified functional or non-functional requirements.

16. Unambiguousness Possible Definition:
Requirements are not subject to multiple interpretations.
Gause & Weinberg’s heuristics for identifying potential ambiguity:
“Mary Had a Little Lamb” (emphasize different words)
“Mary Conned the Trader” (substitute synonyms)

17. “Mary had a little lamb” Heuristic

18. “Mary conned the trader” Heuristic
Mary owned a petite lamb.
Mary consumed a small amount of lamb.
Mary had a little lamb.
Mary was involved with a young sheep.
Mary conned the trader.

19. Verifiability/Testability
Possible Definition:
Objective criteria exist for determining whether or not requirements will have been satisfied.

20. What about CORRECTNESS?
The notion of a PROGRAM being correct (with respect to its requirements) is relatively straightforward, but what does it mean to say that a program’s REQUIREMENTS are correct?
(cont’d)

21. What about CORRECTNESS? (cont’d)
Possible Definition: The REQUIREMENTS for a (sub-) program are “correct” if the PROGRAM DESIGN which incorporates those requirements is correct with respect to its requirements.
Requirements for C C
Design for A

22. What about CORRECTNESS? (cont’d)
In other words, the correctness of a (requirements) specification would be considered with respect to a design that incorporates that specification.
For example, you might ask: “Was the decision to take this course† correct with respect to my overall plan of study?”
† A self-imposed “requirement”.
(cont’d)

23. What about CORRECTNESS? (cont’d)
Based on our definition, the answer would be “yes” if your plan of study (a design that incorporates this course) satisfies your educational goals (i.e., the requirements for your plan).

24. Role of testers in Requirements Engineering?
What role can/should testers play in assessing/verifying the degree to which requirements are:
complete,
consistent,
unambiguous,
verifiable,
correct?

25. Requirements and Specifications
Software Testing and Verification
Lecture 3
Prepared by
Stephen M. Thebaut, Ph.D.
University of Florida