Software Specification: Understanding the Process and Importance of Requirements - Prof. S, Assignments of Engineering

Download Software Specification: Understanding the Process and Importance of Requirements - Prof. S and more Assignments Engineering in PDF only on Docsity!

Examining the

Software Specification

[Reading assignment: Chapter 4, pp. 54-62]

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

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

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 System Models Requirements Definition Requirements Specification Requirements Document Software Specification included in produces leads to

Specification document

“requirements”

• Should be easy to change as

requirements evolve.

• Must be kept up-to-date as system

changes.

Specification should state ...

• Foreseen problems:
  • “won’t support Win-3.x apps”
• Expected evolution:
  • “will port to MacOS in next version”
• Response to unexpected events/usage:
  • “if input data in old format, will auto- convert”

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.

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.

What is a specification review?

• A process of identifying faults in the

specification of a software system.

• Review should uncover both errors

made in producing specification

documents, and errors made earlier in

the requirements engineering process.

Better method: Active specification review process

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

An example

• We have been asked to review the specification for a hospital’s order processing system.
• The order processing system allows users to order items for patients, such as tests or medications.