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

4. Roles of Requirements in Testing and Verification (cont’d) • Bottom Line: testing and verification only make sense when requirements in some formare 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 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.

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 designthat incorporates this course) satisfies your educational goals (i.e., the requirementsfor 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