Lecture 18: Specifications

Slides:



Advertisements
Similar presentations
Requirements Specification and Management
Advertisements

Software Requirements
CS 411W - Notes Product Development Documentation.
Characteristics of a good SRS
Introduction to Software Engineering Dr. Basem Alkazemi
Information System Design IT60105 Lecture 3 System Requirement Specification.
Software Requirements
Introduction to Software Engineering
Lecture 5: Requirements Specifications
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
1 / 26 CS 425/625 Software Engineering Software Requirements Based on Chapter 5 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6 th Ed.,
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
CS 425/625 Software Engineering Software Requirements
Software Requirements
1 Software Requirements Specification Lecture 14.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Project Documentation and its use in Testing JTALKS.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
S R S S ystem R equirements S pecification Specifying the Specifications.
Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher (2009) with material from: IEEE Standard, Daniel Amyot.
Software Requirement Specification(SRS)
Requirements Engineering
University of Toronto Department of Computer Science CSC444 Lec04- 1 Lecture 4: Software Lifecycles The Software Process Waterfall model Rapid Prototyping.
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
S/W Project Management
Software Requirements Specification (SRS) Complete description of external behavior of software system Complete description of external behavior.
Typical Software Documents with an emphasis on writing proposals.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
ECE450 – Software Engineering II
University of Toronto Department of Computer Science CSC444 Lec08 1 Lecture 8: Testing Verification and Validation testing vs. static analysis Testing.
University of Toronto Department of Computer Science CSC444 Lec05- 1 Lecture 5: Decomposition and Abstraction Decomposition When to decompose Identifying.
Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture.
소프트웨어공학 강좌 1 Chap 4. Software Requirements - Descriptions and specifications of a system - Soo-Mi Choi
Software Requirements Engineering CSE 305 Lecture-2.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Some Sub-Activities within Requirements Engineering 1.Prototyping 2.Requirements Documentation 3.Requirements Validation 4.Requirements Measurements 5.Requirements.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
Lecture 7: Requirements Engineering
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Writing requirements specifications. Why we need requirements specifications To give structure to your desires To avoid waste of resources To avoid slippage.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
1 Quality Attributes of Requirements Documents Lecture # 25.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Software Requirements Specification (SRS)
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
System Requirements Specification
Software Requirements Specification Document (SRS)
Requirements Engineering
CSC480 Software Engineering Lecture 7 September 16, 2002.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Requirement Specification SRS document is a contract between the development team and the customer How do we communicate the Requirements to others? Firm.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
 System Requirement Specification and System Planning.
Daniel Amyot, University of Ottawa Based on slides by Gunter Mussbacher (2009) and Stéphane Somé (2008) with material from these standards: IEEE ,
Software Requirements
Requirements Validation – II
Requirements Engineering (continued)
SYSTEM ANALYSIS AND DESIGN
CSC480 Software Engineering
COIT20235 Business Process Modelling
Software Requirements Specification Document
Software Requirements Specification (SRS) Template.
Requirements Document
Dr. Jiacun Wang Department of Software Engineering Monmouth University
Requirements Engineering Lecture 6
Presentation transcript:

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 Uses of specifications

Choosing appropriate Spec types Source: Adapted from Blum 1992, p154-5 Consider two different projects: A) Small project, 1 programmer, 6 months programmer talks to customer, then writes up a 5-page memo B) Large project, 50 programmers, 2 years team of analysts model the requirements, then document them in a 500-page SRS

Desiderata for Specifications Source: Adapted from the IEEE-STD-830-1993. See also van Vliet 1999, pp225-226 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 Necessary doesn’t contain anything that isn’t “required” Unambiguous every statement can be read in exactly one way define confusing terms in a glossary Verifiable a process exists to test satisfaction of each requirement “every requirement is specified behaviorally” Understandable (Clear) by non-computer specialists Modifiable Carefully organized, with minimal redundancy Traceable!

Restrictiveness vs. Generality Specificand Sets A specification describes a set of acceptable behaviours The set of all implementations that meet a specification are its specificand set There are always an infinite number of possible implementations E.g. Restrictiveness: a specification should rule out any implementation that is unacceptable to its users Generality: a specification should be general enough so that few of the acceptable implementations are excluded. In particular the more desirable (e.g. elegant, efficient) implementations should not be excluded. Examine every condition in the spec and ask if it’s really needed This specification is trivial, but its specificand set is still infinite! procedure foo(x: int) returns y:int effects: x = y

Ambiguity Is this ambiguous? Can test by trying to translate it: if you get different answers from different people, then it is ambiguous. “The system shall report to the operator all faults that originate in critical functions or that occur during execution of a critical sequence and for which there is no fault recovery response.”

Consistency and Completeness an inconsistent specification contradicts itself and therefore cannot be satisfied inconsistency may depend on context: In practice, inconsistency is hard to test for. Completeness internally complete: all terms are defined no TBDs Complete with respect to the requirements i.e. describes all services needed by the users In practice, completeness is nearly impossible to achieve aim for balance between generality and restrictiveness The text should be kept in lines of equal length specified by the user. Spaces should be inserted between words to keep the line lengths equal. A line break should only occur at the end of a word

Operational vs. Definitional An Operational Specification… describes an abstraction in terms of its intended behaviour by describing how it might work e.g. A Declarative Specification… describes an abstraction in terms of the desired properties of the implementation by describing some properties it must obey Declarative specifications are better More general (less implementation bias) Easier to verify procedure search(list a, int x) returns int effects: examines each element of a in turn and returns the index of the first one that is equal to x. signals: NOT_IN if it reaches the end of the list without finding x. procedure search(list a, int x) returns int effects: returns i such that a[i]=x; signals: NOT_IN if there is no such i.

Modifiability and Traceability well-structured, indexed, cross-referenced, etc. redundancy reduces modifiability avoid or clearly mark as such An SRS is not modifiable if it is not traceable... Traceability Backwards: each requirement traces to a source e.g. a requirement in the system spec; a stakeholder; etc Forwards: each requirement traces to parts of the design that satisfy that requirement Note: traceability links are two-way; hence other documents must trace into the SRS Every requirement must have a unique label. Useful Annotations E.g. relative necessity and relative stability

IEEE Standard for SRS 1 Introduction 2 Overall Description Source: Adapted from IEEE-STD-830-1993 See also, van Vliet 1999, pp226-231 Identifies the product, & application domain 1 Introduction Purpose Scope Definitions, acronyms, abbreviations Reference documents Overview 2 Overall Description Product perspective Product functions User characteristics Constraints Assumptions and Dependencies 3 Specific Requirements Appendices Index Describes contents and structure of the remainder of the SRS Describes all external interfaces: system, user, hardware, software; also operations, site adaptation, and hardware constraints Summary of major functions Anything that will limit the developer’s options (e.g. regulations, reliability, criticality, hardware limitations, parallelism, etc) All the requirements go in here (I.e. this is the body of the document). IEEE STD provides 8 different templates for this section

IEEE STD Section 3 (example) Source: Adapted from IEEE-STD-830-1993. See also, Blum 1992, p160 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communication Interfaces 3.2 Functional Requirements this section organized by mode, user class, feature, etc. For example: 3.2.1 Mode 1 3.2.1.1 Functional Requirement 1.1 … 3.2.2 Mode 2 ... 3.2.2 Mode n 3.3 Performance Requirements Remember to state this in measurable terms! 3.4 Design Constraints 3.4.1 Standards compliance 3.4.2 Hardware limitations etc. 3.5 Software System Attributes 3.5.1 Reliability 3.5.2 Availability 3.5.3 Security 3.5.4 Maintainability 3.5.5 Portability 3.6 Other Requirements

References van Vliet, H. “Software Engineering: Principles and Practice (2nd Edition)” Wiley, 1999. Section 9.2 covers most of the material in this lecture, and gives a good introduction to the IEEE standards. IEEE-STD-830-1993 Is the current IEEE standard that covers software specifications. It is available electronically through the IEEE electronic library (access via U of T library website for the campus-wide subscription) Blum, B. “Software Engineering: A Holistic View”. Oxford University Press, 1992 Provides some additional insights into how to write good specifications.