03-02SpecificationIntro-notes

03-02SpecificationIntro-notes - Recall from previous...

Info iconThis preview shows pages 1–4. Sign up to view the full content.

View Full Document Right Arrow Icon
1 CSE 435: Software Engineering B. Cheng Recall from previous lecture… Understanding customer requirements is critical to success of any software development effort Major process tasks: – Requirements elicitation/analysis – Drafting a requirements specification Review: What are the (meta-) requirements on a requirements specification? CSE 435: Software Engineering B. Cheng Software specification (1) How NOT to write a specification Topics: – Problems with natural language specifications – Case study in functional specification: Text formatting – Companion paper: “On formalism in specifications”, by B. Meyer. IEEE Software , 1985 CSE 435: Software Engineering B. Cheng Specification Defn: Statement of an agreement between producer (of a product or service) and consumer (of that product or service) or between an implementer and a user Many different kinds of specifications: – Requirements specification: agreement between end user and developer – Design specification: agreement between system architect and the implementer – Module specification: agreement between programmer using the module and programmer implementing the module
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 CSE 435: Software Engineering B. Cheng Uses of specifications Many: – Statement of user requirements – Statement of the interface between the machine and the controlled environment – Statement of the requirements for the implementation – A reference point during product maintenance For today, we focus on statements of user requirements; however techniques we will study apply generally CSE 435: Software Engineering B. Cheng Quality attributes of a specification What makes a good specification? Three major qualities: – Clarity (i.e., understandability, lack of ambiguity) – Consistency – Completeness We will now study: – Characteristics of a bad specification – Model-based techniques for designing in clarity and consistency CSE 435: Software Engineering B. Cheng 7 deadly sins of specifier Noise: text that contains no relevant information; – redundancy – remorse Silence: unspecified feature; lack of definition Overspecification: solution/program details not problem description Contradiction: incompatible specifications Ambiguity: multiple possible interpretations Forward reference: mention of a feature before it is defined Wishful thinking: a requirement that cannot be validated
Background image of page 2
3 CSE 435: Software Engineering B. Cheng Case study: Text formatter (Naur’s specification) Given a text consisting of words separated by BLANKS or by NL (new line) characters, convert it to a line-by-line form in accordance with the following rules: 1. line breaks must be made only where the given text has BLANK or NL; 2. each line is filled as far as possible, as long as 3. no line will contain more than MAXPOS characters. CSE 435: Software Engineering
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 4
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 9

03-02SpecificationIntro-notes - Recall from previous...

This preview shows document pages 1 - 4. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online