milestone_1posani.ppt
EXAMINING THE
SOFTWARE SPECIFICATION
Milestone #1
TESTING THE SPECIFICATION
You do not need to have code to start testing.
Testing the specification can save on time and cost later on.
Also, mistakes in specifications account for about 55% of all bugs.
The specification is typically a written document using prose and pictures to describe the functional and non-functional aspects of the software.
REQUIREMENTS SPECIFICATION:
AN OVERVIEW
Basic goal: To understand the problem as perceived by the user.
Activities of specification are problem oriented.
Focus on what, not how (this is design)
Don’t cloud the specification with unnecessary detail.
Don’t pre-constrain design in the specification.
After specification is done, do software design:
solution oriented
how to implement the what
REQUIREMENTS SPECIFICATION:
AN OVERVIEW
Key to specification is good communication between customer and developers.
Work from specification document as guide.
REQUIREMENTS SPECIFICATION
Basically, it’s the process of determining and establishing the precise expectations of the customer about the proposed software system.
TWO KINDS OF REQUIREMENTS
Functional: The precise tasks or functions the system is to perform.
e.g., details of a flight reservation system
Non-functional: Usually, a constraint of some kind on the system or its construction
e.g., expected performance and memory requirements, process model used, implementation language and platform, compatibility with other tools, deadlines, …
THE PURPOSE OF SPECIFICATION
Raw user requirements are often:
vague
contradictory
impractical or impossible to implement
overly concrete
just plain wrong
The purpose of specification is to get a usable set of requirements from which the system may be designed and implemented, with minimal “surprises”.
SPECIFICATION PROCESS
Requirements
Analysis
Requirements
Definition
Requirements
Specification
Software
Specification
included in
produces
leads to
System
Models
Requirements
Definition
Requirements
Specification
Requirements
Document
Software
Specification
THE SPECIFICATION DOCUMENT
The official statement of what is required of the system developers.
Includes system models, requirements definition, and requirements specification.
Not a design document.
States functional and non-functional requirements.
Serves as a reference document for maintenance.
SPECIFICATION STRUCTURE
Introduction (describe need for system)
Functional Requirements
Non-Functional Requirements
System Evolution (describe anticipated changes)
Glossary (technical and/or new jargon)
Appendices
Index
TO SUMMARIZE …
Specification focuses on determining what the customer wants, and not how it will be implemented.
Specification is hard to get correct; it requires good communication skills.
Requirements may change over time.
Requirements specification requires iteration.
The customer often doesn’t have good grasp of what he wants.
Bugs created in the requirements stage are very expensive to fix later.
SPECIFICATION REVIEWS
Involve people examining the specification with the aim of discovering anomalies and defects.
Reviewers reuse domain knowledge so they are likely to have seen the types of error that commonly arise.
Does not require the execution of a system so may be used before implementation.
Effective technique for discovering errors.
*
STATIC AND DYNAMIC TESTING TECHNIQUES
Reviews and testing are complementary and not opposing verification techniques.
Both should be used during the V & V process.
Reviews can check conformance with a specification but not conformance with the customer’s real requirements.
Reviews cannot check non-functional characteristics such as performance, usability, etc.
*
REVIEW PRE-CONDITIONS
A precise specification must be available.
Team members must be familiar with the
organization standards.
Management must accept that reviews will
increase costs early in the software process.
Management must not use reviews for staff appraisal.
*
LIMITATIONS OF CONVENTIONAL
REVIEW APPROACHES
Too much information to go through, and not enough time to do it thoroughly.
Unfamiliarity of individual reviewers with the overall goals of the design.
No single part of the specification gets a thorough and complete evaluation.
Burden is on reviewer to initiate action.
One-on-one interaction between individual reviewers and specification team is limited.
BETTER METHOD:
STATIC AND DYNAMIC TESTING TECHNIQUES
Change from “general” review to a set of more focused reviews.
Use questionnaires to engage the reviewer in using the specification.
More opportunities for one-on-one discussion between reviewer and specification team.
STATIC AND DYNAMIC TESTING TECHNIQUES
STEP 1: PREPARE THE SPECIFICATION FOR REVIEW
Think about what criteria reviewers will use:
Well-structured
Simple
Adequate
Flexible
Practical
Easy to implement
Standardized
ACTIVE SPECIFICATION REVIEW PROCESS
STEP 2: PREPARE THE DOCUMENTATION FOR REVIEW
Make assumptions explicit
System can record the order pertaining to a patient.
It is possible to obtain all the orders for a patient.
System can determine and change the status of an order.
The order always contains at least one item.
The status of an order is always in one of the two states i.e active or cancelled.
Incorrect Usage Assumptions
Cannot add or remove items once the order is placed.
Once an order is cancelled, the status cannot be set to active again.
An item is always added with respect to an order.
ACTIVE SPECIFICATION REVIEW PROCESS
STEP 3: IDENTIFY THE SPECIALIZED REVIEWS
Focus the reviewer’s attention on specific properties of the specification (e.g., data access).
Data access sufficiency.
E.g., provides all data required by the other features of the system.
Assumption Sufficiency.
E.g., contains all of the assumptions needed to access the feature’s data.
ACTIVE SPECIFICATION REVIEW PROCESS
STEP 4: IDENTIFY THE REVIEWERS NEEDED
People with different perspectives and expertise are needed as reviewers
Programmers and analysts who worked on the other features of the order processing system.
Programmers and analysts familiar with hospital information systems in general.
STATIC AND DYNAMIC TESTING TECHNIQUES
STEP 5: DESIGN THE QUESTIONNAIRES
Make reviewers take an active role
Make reviewers use the documentation
Phrase questions in an active way
E.g., “Write down the exceptions that can occur” rather than “Are exceptions defined for every program?”