Requirements and Specifications

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?

• Requirement
• 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

• 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?

5
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?

6
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?

7
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?

8
Roles of Requirements in Testing and Verification
(contd)

• Bottom Line testing and verification only make
  sense when requirements in some form are
  available to work with.

9
Exercise

• Consider the following pseudocode program
• Sum 0
• J 1
• while JltN do
• Sum Sum XJ
• J J1
• end_while
• What does it do? Is it correct?

10
Requirement/Specification Types

• Functional versus Non-Functional
• Formal versus Informal
• Structured versus Unstructured
• State-model based versus Operational
• Graphical versus Textual

11
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

(contd)
12
A Sampling of Requirement Representations (contd)

• 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.

13
Requirements Sources at Different Levels

• Typical System-Level Sources
• Objectives document
• User manuals (e.g., MAN Pages)
• Installation documents
• Service manuals
• Requirements definition/specification

(contd)
14
Requirements Sources at Different Levels (contd)

• Typical Unit-Level Sources
• Module/function/procedure specifications
• Pseudocode
• Logic specifications
• Object class/method specifications

(contd)
15
Requirements Sources at Different Levels (contd)

• Typical Intermediate- (e.g., Product/ Component)
  Level Sources
• Product/component specification
• Functional specification
• Object use-include relations, sequence/collaborati
  on diagrams, package specification

16
(Some) Key Attributes

• Completeness
• Consistency
• Unambiguousness
• Verifiability/Testability
• Correctness (?)

17
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.

18
Consistency

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

19
Unambiguousness

• Possible Definition
• Requirements are not subject to multiple
  interpretations.
• Gause Weinbergs heuristics for identifying
  potential ambiguity
• Mary Had a Little Lamb (emphasize different
  words)
• Mary Conned the Trader (substitute synonyms)

with mint sauce
20
Mary had a little lamb Heuristic
Mary had a little lamb.
Mary had a little lamb.
21
Mary had a little lamb Heuristic
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
22
Mary had a little lamb Heuristic
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
23
Mary had a little lamb Heuristic
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
Mary had a little lamb.
24
Mary conned the trader Heuristic
Mary had a little lamb.
25
Mary conned the trader Heuristic
Mary had a little lamb.
26
Mary conned the trader Heuristic
Mary owned a petite lamb.
Mary had a little lamb.
27
Mary conned the trader Heuristic
Mary owned a petite lamb.
Mary consumed a small amount of lamb.
Mary had a little lamb.
28
Mary conned the trader Heuristic
Mary owned a petite lamb.
Mary consumed a small amount of lamb.
Mary had a little lamb.
Mary conned the trader.
29
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.
30
Verifiability/Testability

• Possible Definition
• Objective criteria exist for determining whether
  or not requirements will have been satisfied.

31
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 programs REQUIREMENTS are correct?

(contd)
32
What about CORRECTNESS? (contd)

• 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.

33
What about CORRECTNESS? (contd)

• 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
34
What about CORRECTNESS? (contd)

• 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
35
What about CORRECTNESS? (contd)

• 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.

(contd)
36
What about CORRECTNESS? (contd)

• 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.

(contd)
37
What about CORRECTNESS? (contd)

• 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).

38

• What role can/should testers play in
  assessing/verifying the degree to which
  requirements are
• complete,
• consistent,
• unambiguous,
• verifiable,
• correct?

39
Requirements and Specifications
Software Testing and Verification Lecture 3

• Prepared by
• Stephen M. Thebaut, Ph.D.
• University of Florida