The Specification Phase

Size: px

Start display at page:

Download "The Specification Phase"

Malcolm Bernard Perry
5 years ago
Views:

1 The Specification Phase CS427: Elements of Software Engineering Lecture am, 30 Jan 2012 CS427 The Specification Phase 1/16

2 Outline 1 Recall... The Requirements Phase 2 Phase 2: Specifications 3 Requirements V Specs 4 Turning Reqs into Specs System Errors 5 Homework 6 Using Formalism 7 Other Methods 8 Logic CS427 The Specification Phase 2/16

3 Recall... The Requirements Phase Last week we looked at the 1st phase of the Software Lifecycle: Requirements Exercise (4.1) Read Section 7.2 of the text book for an example of a dialog between a customer and developer. CS427 The Specification Phase 3/16

4 Phase 2: Specifications The second phase of the Software Life Cycle is the Specification phase Information in this lecture is taken from Hamlet and Maybee Sections, and Chapter 9, Chapter 10, particularly Sections 10.2 and The Specifications Phase is also called the Complete Problem Description. Its main input is the requirements document. Its main output, the Specification Document, is written in technical language. Its intended audience are the developers themselves, most particularly, the designers. CS427 The Specification Phase 4/16

5 Phase 2: Specifications By being technical, the Specifications (Specs) should be precise and unambiguous. One of the most common sources of ambiguity in the Requirements is that certain words mean different things to non experts and experts. CS427 The Specification Phase 5/16

6 Phase 2: Specifications Another facet of the Specs is that, when it is being decided what a piece of software should do, and how it should behave, there are important issues which may not find a place in the Requirements document. For example, there are some issues which the user might simply not care about, or will leave to the discretion of the developer (some times they are called Trusting Users). These often include the exact nature of error messages, etc. CS427 The Specification Phase 6/16

7 Phase 2: Specifications Recall the list of Good Requirements given in the last section. Of these, the most important may be (iv) Completeness. Often the Requirements are not complete; and so the Specs are used to fill the gaps. Note that the other Good Requirements should apply to the Specs, except for... Exercise (4.2) Review the list of good requirements and decide which one(s) do not apply to the Specs, and say why. CS427 The Specification Phase 7/16

8 Requirements V Specs It can be a problem to differentiate the Requirements from the Specs. This might help: Of what use are the Specifications to... The User? None. The user sees only the Requirements document. When the software is completed, the user uses the requirements as a checklist to verify that the software does what was promised. The Designer? The designer will use the specs to decide what subsystems the software will need, and will only check the requirements if there is no Specs document. The testers? They will primarily use the Requirements to choose their test cases. They may consult the Specs to verify that the software is generated the expected output. (Specifications as a Test Oracle...) Not every model for software development separates Requirements and Specifications into two separate phase. However, in this course we do. We should think of the Specs as being a superset of the Requirements. If the Specs and the Reqs not agree, then it is the Specs that are wrong. CS427 The Specification Phase 8/16

9 Turning Reqs into Specs The Specs document often begins with the Requirements document which is then sharpened to become the Specifications. No attention is payed to whether the Specs are understandable to the user. Two of the most common issues to be dealt with are When the user doesn t care. System errors. Identifying and filling in these gaps is an important part of writing the Specs Document. Example: CS427 The Specification Phase 9/16

10 Turning Reqs into Specs System Errors The user is usually concerned with how the software works when the system on which it is running is functioning normally. However it is not uncommon that the software attempts to send output to the printer, but a printer is not available. a memory request is made (malloc()) but not enough is available. It must be decided What message if given when the resource is not available. What happens next? E.g., CS427 The Specification Phase 10/16

11 Homework Exercise Write a short essay (<= 1 page) on one of the following Agile Methods CASE/UML (SK) Formal Methods Cowboy Coding Extreme Programming (XP) CS427 The Specification Phase 11/16

12 Using Formalism Suppose you are asked to write a program to compile students exam results. In the Requirements might be written: In the Specs this might be written more formally as This is an example of a formal specification. This is extended in the next section where we will employ First Order Predicate Logic as a specification tool. CS427 The Specification Phase 12/16

13 Other Methods Other methods that can be used in the Specs documents: Finite State Machines. FSMs are an excellent tool for specifying software. This is because they determine the output when your system is in a particular state, and given is particular input. Object Oriented Design. In this system we view the system as consisting of entities called Objects and ways of manipulating them called Methods. Data Flow Diagrams. These three methods are as much part of the software design as the specifications. CS427 The Specification Phase 13/16

14 Logic Natural language is the appropriate medium for stating software requirements, but is inappropriate for Specs. In this section, we will try to show how natural language can lead to ambiguities which can be circumvented using logic. This is a hugely important area of software development, and one of the most difficult. It is a reason why mathematicians are employed as software engineers Recall from Semester I of CS304 that we have Constants. In CS304 we usually just had 0 and 1. In the examples that follow we ll use the integers:..., -2, -1, 0, 1, 2,... Variables. May have the value of a constant. An important type is a Boolean Variable. Usually we use lower case letters a, x,... Logical Connectives: also called gates : AND, OR, NOT, IMPLIES, EQUIVALENCE. CS427 The Specification Phase 14/16

15 Logic The important logical equivalences are: a b a b. (a b) ( a) ( b) In Semester 2 of CS304, we ve had: Functions. Functions are just express as function names followed by an argument list. E.g, P(x, y), W (x). Predicates: Functions that map to truth values. They usually contain binary relational predicates, such as =,, etc. Quantifiers: the Universal quantifier FOR ALL the existential quantifier THERE EXISTS. CS427 The Specification Phase 15/16

16 Logic Not all WFFs have a True or False value, e.g., x = y. However, they can be made to take a value by applying one or more quantifier: and x y(x = y), x y(x = y). The quantifiers can be related using xp(x) x ( P(x) ). Examples: CS427 The Specification Phase 16/16

CSI30. Chapter 1. The Foundations: Logic and Proofs Rules of inference with quantifiers Logic and bit operations Specification consistency

CSI30. Chapter 1. The Foundations: Logic and Proofs Rules of inference with quantifiers Logic and bit operations Specification consistency Chapter 1. The Foundations: Logic and Proofs 1.13 Rules of inference with quantifiers Logic and bit operations Specification consistency 1.13 Rules of inference with quantifiers universal instantiation