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

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

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

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

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

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

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

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

16. “Mary had a little lamb” Heuristic Mary had a little lamb.

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

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

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

20. 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. C Design for A Requirements for C

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

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

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

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