1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement.

Slides:



Advertisements
Similar presentations
Requirements Elicitation and Use Case Diagrams
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Introduction To System Analysis and Design
Systems Analysis and Design in a Changing World, Fourth Edition
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Introduction to Software Engineering
© 2005 Prentice Hall3-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Software Requirements
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Ch5: Software Specification. 1 Overview  Use of specifications  Specification qualities  Classification of specification styles  Verification of specifications.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
Object-Oriented Analysis and Design
Chapter 7: The Object-Oriented Approach to Requirements
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
Chapter 5: Specification Yuanfang Cai CS751 Jan 29, 2003.
Chapter 4 – Requirements Engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Systems Analysis and Design in a Changing World, Fifth Edition
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September,
Ch. 51 Specification. Ch. 52 Outline Discussion of the term "specification" Types of specifications –operational Data Flow Diagrams (Some) UML diagrams.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 Object-oriented and Structured System Models.
Approaching a Problem Where do we start? How do we proceed?
Chapter 7 System models.
Pertemuan 19 PEMODELAN SISTEM Matakuliah: D0174/ Pemodelan Sistem dan Simulasi Tahun: Tahun 2009.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 Specification Some slides for Chapter 5 Of Ghezzi, Jazayeri, and Mandrioli.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Slide 1 Use Case Diagrams.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Ch. 51 Specification. Ch. 52 Outline Discussion of the term "specification" Types of specifications –operational Data Flow Diagrams (Some) UML diagrams.
Requirements Specification. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification”
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Systems Analysis and Design in a Changing World, Fourth Edition
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Requirements Analysis
UML - Development Process 1 Software Development Process Using UML.
Capturing Requirements. Questions to Ask about Requirements 1)Are the requirements correct? 2)Consistent? 3)Unambiguous? 4)Complete? 5)Feasible? 6)Relevant?
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
CS 501: Software Engineering Fall 1999 Lecture 15 Object-Oriented Design I.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
1 Software Requirements Descriptions and specifications of a system.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VII. System Specification (I)
Systems Analysis and Design in a Changing World, Fourth Edition
UML Diagrams By Daniel Damaris Novarianto S..
Chapter 4 – Requirements Engineering
Software Requirements
Chapter 5 – Requirements Engineering
Requirements Engineering (continued)
Structured Analysis and Dataflow Diagrams
Unified Modeling Language
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4th edition, Prentice Hall, Hans Van Vliet, Software Engineering:
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement (contract) between –producer and consumer of a service –implementer and user All desirable qualities must be specified

2 Uses of specification Statement of user requirements –major failures occur because of misunderstandings between the producer and the user –User requirements are often not clearly understood by developer. If this is the case, a careful analysis involving frequent interaction with the user, should be devoted to clarifying and documenting a clear statement of requirements, in order to uncover and avoid possible misunderstandings.

3 Uses of specification (cont.) Statement of the interface between the machine and the controlled environment –serious undesirable effects can result due to misunderstandings between software engineers and domain experts about the phenomena affecting the control function to be implemented by software

4 Uses of specification (cont.) Statement of requirements for implementation –design process is a chain of specification (i.e., definition)–implementation–verification steps requirements specification refers to definition of external behavior design specification refers to definition of the software architecture

5 Uses of specification (cont.) A reference point during maintenance -corrective maintenance only changes implementation -adaptive maintenance occur because of requirements changes Eg. Modification of functionality of the product - in perfective maintenance sometimes functional requirements do not change.

6 Specification qualities Precise, clear, unambiguous Consistent Complete –internal completeness –external completeness Incremental

7 Clear, unambiguous, understandable Example: specification fragment for a word-processor Selecting is the process of designating areas of the document that you want to work on. Most editing and formatting actions require two steps: first you select what you want to work on, such as text or graphics; then you initiate the appropriate action.

8 Precise, unambiguous, clear Another example (from a real safety- critical system) The message must be triplicated. The three copies must be forwarded through three different physical channels. The receiver accepts the message on the basis of a two-out-of-three voting policy. can a message be accepted as soon as we receive 2 out of 3 identical copies of message or do we need to wait for receipt of the 3 rd ?

9 Complete Internal completeness –the specification must define any new concept or terminology that it uses glossary helpful for this purpose –the specification must document all the needed requirements difficulty: when should one stop?

10 Incremental Referring to the specification process –start from a sketchy document and progressively add details Referring to the specification document –document is structured and can be understood in increments

11 Classification of specification styles Informal, semi-formal, formal Operational –Behavior specification in terms of some abstract machine Descriptive –Behavior described in terms of properties

12 Example 1 Specification of a geometric figure E: E can be drawn as follows: 1.Select two points P1 and P2 on a plane 2.Get a string of a certain length and fix its ends to P1 and P2 3.Position a pencil as shown in next figure 4.Move the pen clockwise, keeping the string tightly stretched, until you reach the point where you started drawing this is an operational specification

13

14 A descriptive specification Geometric figure E is describe by the following equation ax 2 + by 2 + c = 0 where a, b, and c are suitable constants

15 Another example “Let a be an array of n elements. The result of its sorting is an array b of n elements such that the first element of b is the minimum of a (if several elements of a have the same value, any one of them is acceptable); the second element of b is the minimum of the array of n-1 elements obtained from a by removing its minimum element; and so on until all n elements of a have been removed.” “The result of sorting array a is an array b which is a permutation of a and is sorted.” OP DES

16 How to verify a specification? “Observe” dynamic behavior of specified system (simulation, prototyping, “testing” specs) Analyze properties of the specified system Analogy with traditional engineering –physical model of a bridge –mathematical model of a bridge

17 Data Flow Diagrams (DFDs) A semi-formal operational specification System viewed as collection of data manipulated by “functions” Data can be persistent –they are stored in data repositories Data can flow –they are represented by data flows DFDs have a graphical notation

18 Graphical notation –bubbles represent functions –arcs represent data flows –open boxes represent persistent store –closed boxes represent I/O interaction

19 A library example

20 Patient monitoring systems The purpose is to monitor the patients’ vital factors--blood, pressure, temperature, …--reading them at specified frequencies from analog devices and storing readings in a DB. If readings fall outside the range specified for patient or device fails an alarm must be sent to a nurse. The system also provides reports.

21 UML use-case diagrams Define functions on basis of actors and actions borrow book return book library update librarian customer

22 UML sequence diagrams Describe how objects interact by exchanging messages Provide a dynamic view

23 UML collaboration diagrams Give object interactions and their order Equivalent to sequence diagrams

24 Finite state machines (FSMs) Can specify control flow aspects Defined as a finite set of states, Q; a finite set of inputs, I; a transition function d : Q x I  Q (d can be a partial function)

25 A finite-state machine (FSM) or simply a state machine, is a mathematical model of computation used to design both computer programs and sequential logic circuits. It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called a transition. A particular FSM is defined by a list of its states, and the triggering condition for each transition.model of computationcomputer programssequential logicabstract machinestates