Requirements and Specifications - PowerPoint PPT Presentation

Loading...

PPT – Requirements and Specifications PowerPoint presentation | free to download - id: 585621-Y2YzZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Requirements and Specifications

Description:

Title: PowerPoint Presentation Author: mcatlett Last modified by: Steve Thebaut Created Date: 2/8/2005 8:34:14 PM Document presentation format: On-screen Show (4:3) – PowerPoint PPT presentation

Number of Views:63
Avg rating:3.0/5.0
Slides: 40
Provided by: mcat
Learn more at: http://cise.ufl.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com