Lecture 18Specifications.ppt

Lecture 18:Specifications What is a Specification Purpose Audience Different specs for different project types Criteria for good specifications clarity, consistency, completeness measurable traceable operational vs. definitional specs Standards for specifications IEEE standard for SRS What is a Specification? A specification is an agreement… …between the producer of a service… …and the consumer of that service Software must be specified precisely… …if there is a danger of misunderstanding (or forgetting) the consumer’s needs …if more than one person’s needs are represented …if more than one person will be developing the software Uses of specifications Statement of user needs communicates understanding of those needs to everyone involved acts as a check that the real needs have been captured must be understandable by the owners of those needs! Statement of implementation constraints a point of reference for the developers can be used to justify development goals and resources Documentation of a product a point of reference for product maintainers must be updated when the product is updated baseline for change requests A legal contract a point of reference for verification and certification must be possible to determine whether the specification was met must be updated whenever changes are negotiated Choosing appropriate Spec types Consider two different projects: A) Small project, 1 programmer, 6 months programmer talks to customer, then writes up a 5memo B) Large project, 50 programmers, 2 years team of analysts model the requirements, then document them in a 500SRS Desiderata for Specifications Valid (or “correct”) expresses actual requirements Complete Specifies all the things the system must do ...and all the things it must not do! Responses to all classes of input Structural completeness, and no TBDs!! Consistent doesn’t contradict itself (i.e. is satisfiable) Uses all terms consistently Note: timing and logic are especially prone to inconsistency Nece