IEEE Oregon Section

Requirements Satisfaction: A Tutorial in Two Parts
Jerry Conklin

 
Part II. A Tutorial Exercise

Introduction
In Part I. an aspect of the problem of requirements satisfaction is described along with some suggested techniques for requirement satisfaction assurance. In this second part of the paper an exercise is proposed as a tutorial and to collect some data bearing on the problem in question.

Sample Exercise
A tutorial exercise is defined in the following paragraphs. Let’s consider a simple example showing a set of requirements and an example of a design document (flowchart) associated with a data entry screen:

EXERCISE
Requirements (Derived requirements may be added, if you like, with DReqIDs in the form: DReqIDn  => DReqID1 [DReqID2[, …,DReqIDn] ].)

The Problem Submission Screen
  1. The system shall present a screen to the user that invites the entry of name, address, phone number and a textual description of the problem being submitted.
  2. User input shall be read when entered.
  3. The user shall be prompted to enter information in a specific format and all input shall be subject to discrepancy checking, depending on the field or subfield in question as follows:
    a.    Name
    Two subfields shall be presented; first name and, last name.
    b.    Address
    Four subfields shall be presented; street address, city, state and, zip code.
    c.    Problem Description
    A text box shall be presented for the entry of a variable amount of text with a minimum entry of 8 characters and a maximum of 1024 characters.
  4. Upon detection of a discrepancy, the user shall be prompted to make a corrected entry. Such prompting shall be very specific and informative such that the user is not presented with a puzzle but given every kind of support feasible to make entering the correct format easy.
Optional
  1. If the user fails to enter the correct information format and content for any given field three times in succession, a screen tutorial shall be offered to allow selection by mouse click.
  1. When the screen tutorial selection is made, the user shall be presented with a hypertext tutorial that permits easy drill down to increasing levels of detail.
  1. When the user exits the screen tutorial, a selection shall be offered to permit entry of an evaluation of the efficacy of the tutorial graded into five categories of helpfulness vs. useless.
Design Document

The following design is presented simply as an example of associating each design element with the requirement to which it pertains and it is suggested that team members produce their own design.
 

Figure 5. Example Design Flowchart

Various source code modules might be produced from the requirements and design documents portrayed in the preceding paragraphs, all of which might seem to satisfy the specified requirements, but which might produce different interactive results in the evocation of operations produced by the compiler generated machine code.

Challenge
A challenge to the reader: Form a team of two or more software engineers, Present each team member with the requirements specification and design documents specified above, Have each team member, working independently, code, test and, deliver to you:

I.  Team Member Deliverables
1)    Source Code and Load modules
2)    New Design Document (optional)
3)    Test Plan and Discrepancy Report
4)    Completed RTM

Then (you):

II. Team Leader Tasks & Deliverables
a.    Write Operational Test Plan
b.    Run Test Cases
c.    Produce Discrepancy Report

III.  Team Leader Defect Summary Report
d.    Generate Defect Summary Report

Then, please deliver to me the deliverables as described in the Appendix to this document.

Support
You may email me with questions or comments regarding the exercise or anything else (other than marital problems): Zootzot@Yahoo.com

In the event of a life-threatening software development problem you may call: (Cell) 541-787-0117

Overview of Multiple Exercises

If you will send the results to:

HarvestTime Software Productivity
Attention: Jerry Conklin, CEO
521 Shorthorn Gulch Road
Grants Pass, Oregon 97526

I will summarize and report an overview of all team efforts. All teams and team leaders will remain anonymous and copies of the report will be sent to all team leaders for distribution to team members.

If there is a good response to this proposal, follow-up exercises may be proposed to enlarge on the scope and depth of requirements engineering coverage. Email suggestions are invited.

Good luck! Have fun! I look forward to hearing from you.

                    Jerry Conklin

- Appendix -
Deliverables

  1. Defect Summary Report Format 
Package Defect Count Defects Fixed Count Date Produced
DM1
DL1
DM2
DL2
DMn
DLn
Total DM
Total DL

  1. Delivery Package Naming Conventions 
NAME ORIGIN
Source Modules Source code from all team members.
Load Modules Executables from  all team members.
Design Documents From all team members.
Test Plans From all team members.
Discrepancy Reports From all team members.
RTMs From all team members.
Operational Test Plans From team leader.
Operational Discrepancy Reports From team leader.
Defect Summary Report From team leader.

  1. Delivery Package Form
Self-Extracting ZIP file.

Copyright 1997-2008, The Institute of Electrical and Electronics Engineers, Inc.
Send comments about this site to Oregon Section Webmaster | KAVI® where .orgs workSM