Introduction to Software Specifications and Data Flow Diagrams. Neelam Gupta The University of Arizona

Similar documents
CS350 Lecture 2 Requirements Engineering. Doo-Hwan Bae

Requirement Analysis

Ch 4: Requirements Engineering. What are requirements?

Requirements Engineering Process

Requirements Analysis. SE 555 Software Requirements & Specification

Business Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3)

Chapter : Analysis Modeling

Database Systems: Design, Implementation, and Management Tenth Edition. Chapter 9 Database Design

SE351a: Software Project & Process Management. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

The software lifecycle and its documents

UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION

Requirements Engineering. Contents. Functional requirements. What is a requirement?

Chapter 4. Capturing the Requirements. 4th Edition. Shari L. Pfleeger Joanne M. Atlee

Techniques for the unambiguous specification of software

Lecture 6: Requirements Engineering

Requirements engineering

Quality Software Requirements By J. Chris Gibson

Methods for requirements engineering

Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1

Unit 1 Introduction to Software Engineering

Lesson 06. Requirement Engineering Processes

Designing and documenting the behavior of software

Recommended Practice for Software Requirements Specifications (IEEE)

Lecture 9 Requirements Engineering II

Chapter 4 Objectives

Requirements. Requirements. Types of Requirement. What Is a Requirement?

Human Error Taxonomy

CompuScholar, Inc. Alignment to Nevada "Computer Science" Course Standards

Requirements Validation and Negotiation

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Summary of Contents LIST OF FIGURES LIST OF TABLES

Fundamentals of STEP Implementation

Administrivia. Wednesday: Requirements and Specification. CS169 Lecture 4. We assign teams and you start on Monday. Determining Stakeholders and Needs

PROGRAM SPECIFICATION INTRODUCTION

Lecture 8 Requirements Engineering

Requirements Engineering. Establishing what the customer requires from a software system. Requirements Engineering. What is a Requirement?

Requirements Modelling and Software Systems Implementation Using Formal Languages

Requirements Validation and Negotiation (cont d)

System Analysis and Design

Introduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p.

Software Engineering Unit 4- Requirement Analysis and Specification

The IDN Variant TLD Program: Updated Program Plan 23 August 2012

Formal Foundations of Software Engineering

Software specification and modelling. Requirements engineering

T52-Software Engineering

Architectural Design

Programming Practices By Joe Feliu in conjunction with Harris Kern s Enterprise Computing Institute

Requirements Validation and Negotiation

Architectural Design. Topics covered. Architectural Design. Software architecture. Recall the design process

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements

Introduction to Formal Methods

Specification of Behavioural Requirements within Compositional Multi-Agent System Design

EE249 Discussion Petri Nets: Properties, Analysis and Applications - T. Murata. Chang-Ching Wu 10/9/2007

Darshan Institute of Engineering & Technology for Diploma Studies

06. Analysis Modeling

Security Engineering for Software

Requirements Engineering process

CS SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS

copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc.

CS504-Softwere Engineering -1 Solved Objective Midterm Papers For Preparation of Midterm Exam

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING

Fundamentals: Software Engineering. Objectives. Last lectures. Unit 2: Light Introduction to Requirements Engineering

Benefits and Challenges of Architecture Frameworks

SE351a: Software Project & Process Management. 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

Integration With the Business Modeler

System Models. Minsoo Ryu. Hanyang University. Real-Time Computing and Communications Lab., Hanyang University

Introduction to Modeling

Architectural Design

REQUIREMENTS. Michael Weintraub Spring, 2016

System Analysis & design

Modeling Issues Modeling Enterprises. Modeling

Topic Formal Methods. ICS 121 Lecture Notes. What are Formal Methods? What are Formal Methods? Formal Specification in Software Development

Q Body of techniques supported by. R precise mathematics. R powerful analysis tools. Q Rigorous, effective mechanisms for system.

Delimited. Interfaced. Readable. Modifiable. Verifiable. Prioritized* Endorsed

Chapter 1 Introduction

Identify the guidelines for system development. Discuss the purpose of the activities performed in the analysis phase

SE 1: Software Requirements Specification and Analysis

5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered

"Charting the Course... Certified Information Systems Auditor (CISA) Course Summary

INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2

Security Risk Management Domain Model

Requirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18

ICS 52: Introduction to Software Engineering

Chapter 6 Architectural Design. Chapter 6 Architectural design

ISO/IEC INTERNATIONAL STANDARD. Software and system engineering High-level Petri nets Part 1: Concepts, definitions and graphical notation

IDEF3 Process Modeling

Requirements Analysis

COURSE: DATA STRUCTURES USING C & C++ CODE: 05BMCAR17161 CREDITS: 05

1 Executive Overview The Benefits and Objectives of BPDM

Software Design Models, Tools & Processes. Lecture 2: Inception Phase Cecilia Mascolo

UNIT III DESIGN CONCEPTS AND PRINCIPLES

1: Specifying Requirements with Use Case Diagrams

Requirements Engineering. Version October 2016

Computation Independent Model (CIM): Platform Independent Model (PIM): Platform Specific Model (PSM): Implementation Specific Model (ISM):

Natural Language Specification

Sofware Requirements Engineeing

Software Architecture

CIS 890: Safety Critical Systems

What is Software Architecture

1.1 Software Life Cycle

Transcription:

Introduction to Software Specifications and Data Flow Diagrams Neelam Gupta The University of Arizona

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

Uses of specification Statement of user requirements major failures occur because of misunderstandings between the producer and the user "The hardest single part of building a softwarem system is deciding precisely what to build" (F. Brooks) Statement of requirements for implementation requirements specification refers to definition of external behavior design specification must be verified against it design specification refers to definition of the software architecture code must be verified against it

Uses of specification (cont.) A reference point during maintenance corrective maintenance only changes implementation adaptive and perfective maintenance occur because of requirements changes» requirements specification must change accordingly

Requirements Specification Requirements Specification:Written document, a graphical model, a formal mathematical model, a collection of usage scenarios, a prototype or any combination of these describing the external behavior of the system Requirements Engineering Process: involves all of the activities required to create an maintain the requirements specification document of a software system

Requirements Engineering Obtain overall requirements of product from customer including information and control needs, product function and behavior, overall product performance, design and interfacing constraints and other special needs. Allocate function and behavior to the four systems components - Software, Hardware, Data, People Goal: Specify a system that meets customers needs and expectations.

Requirements Engineering Process Requirements elicitation Requirements analysis and negotiation Requirements specification System modeling Requirements validation Requirements management

Requirements Elicitation Identify elicitation methods (interviews, focus groups, meetings) Identify people who will help specify requirements and understand their organizational bias Define technical environment Identify domain constraints Solicit participation from many people to get different points of view Create usage scenarios

Output of Requirements Elicitation A statement of need and feasibility A statement of scope for the product Description of technical environment of the system A set of usage scenarios Any prototypes developed List of people who participated in requirements elicitation

Requirements Analysis and Negotiation Categorize requirements and organize them into related subsets. Explore each requirement in relationship to others. Examine requirements for consistency, omissions, and ambiguity. Rank requirements based on the needs of customers/users. Examine if each requirement is achievable in the technical environment in which it will be used and if each requirement is testable, once implemented.

Requirements Analysis and Negotiation (cont.) Examine risks associated with each requirement. Rough estimates of development efforts made and used to assess the impact of each requirement on project cost and delivery time. Resolve conflicts in requirements by negotiating with users.

Requirements Specification Written document, a graphical model, a formal mathematical model, a collection of usage scenarios, a prototype or any combination of these describing the external behavior of the system

Specification Qualities (i) unambiguous (ii) consistent (iii) complete internal completeness external completeness (iv) incremental

Unambiguous Example: specification fragment for a wordprocessor 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. can an area be scattered?

Consistent Example: specification fragment for a wordprocessor The whole text should be kept in lines of equal length. The length is specified by the user. Unless the user gives an explicit hyphenation command, a carriage return should occur only at the end of a word. What if the length of a word exceeds the length of the line? (results in an inconsistency in the specifications)

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?

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

Specification Styles Informal specifications written in a natural language. Semi-formal specifications use a notation with precise syntax but imprecise semantics Formal specifications written using a notation that has precise syntax and semantics (meaning). Operational specifications describe the desired behavior of the system. Descriptive specifications state desired properties of the system.

An example Operational Specifications: 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. Descriptive Specifications: The result of sorting array a is an array b which is a permutation of a and is sorted.

Operational Specification 1. Data Flow Diagrams 2. Finite State Machines 3. Petri nets Descriptive Specification 1. Entity-Relationship Diagrams 2. Logic Specifications 3. Algebraic Specifications

Data Flow Diagrams (DFD) A semi-formal operational specification System: collections of data that are manipulated by functions. Data: (i) can be persistent i.e., stored in data repositories; (ii) can flow i.e., represented by data flows DFD Notation Bubbles used to represent functions Arrows used to represent data flow Open Boxes represent persistent data storage I/O Boxes represent data acquisition and production during human computer interaction

An Example of DFD The example below specifies evaluation of expression (a+b)*(c+a*d) b a a d c + * + *

Construction of DFDs 1. Start from the context diagram Input 1 Input 2 Input n information...... system Output 1 Output 2 Output m

Construction of DFD s (cont.) 2. Proceed by refinements until you reach elementary functions (preserve balancing) I A O I A1 K H A3 A2 J M A4 N P A5 R Q A6 S A7 O K B1 Ag K2 T K1 B3 B2 K3 K4 B4 M N

A DFD describing a simplified library information system Shelves Book Title & Author User Name Book request by the user List of Authors Author Deliver a book Book Book reception List of Titles Title Book Title; User Name List of books borrowed List of Topics Topic Search by topics List of titles referring to a topic Topic request by the user Display of list of titles

In order to obtain a book, the following are necessary. User request Access to bookshelves List of authors List of titles The way the book is actually obtained is not mentioned.

Refinement of Deliver a book in DFD for Library System Shelves List of Authors List of Titles Book <shelf#,book#> Author Title Title & Author; User Name Find Book position Book request by user Get a book Book Book reception Book Title; User Name List of books borrowed

Limitations of DFD 1. Semantics of the symbols used is specified only by the identifiers chosen by the user. Easy to read, but Informal semantics 2. Control aspects are not defined by the model A B C D E F The above DFD does not specify how inputs are used and how outputs are produced by the function D. D needs all or only one of of A, B and C to execute? D outputs to just one or both of E and F? D outputs same or different data to E and F?

A B The above DFD does not specify synchronization between modules (absence of control information) Does A produce a datum and waits until B has consumed it? Are A and B asynchronous activities with different speeds with a buffering mechanism between them to prevent data loss?

Conclusions DFD provide a graphical notation for capturing the flow of data and operations involved in an information system. However, they lack precise semantics A prototype to test whether specifications reflect the user s expectations cannot be derived directly from a DFD since no machine execution is possible without precise semantics for the notation. The syntax, i.e., way of composing bubbles, arrows, and boxed is defined precisely, but the semantics of DFDs is not specified precisely. (therefore DFD s provide a semiformal notation for specifying systems)

Remedies Use a complementary notation to describe aspects not captured adequately by DFDs. Augment DFD model by introducing new features. d1 Trigger d2... Σ dn Revise DFDs to make them fully formal.