IT’S ALL ABOUT THE INTERFACES Jeffrey Eyster Indianapolis, IN.

Slides:



Advertisements
Similar presentations
Use Case Diagrams Damian Gordon.
Advertisements

Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
S Y S T E M S E N G I N E E R I N G.
SWE 316: Software Design and Architecture Objectives Lecture # 01 Prologue: The Software Process SWE 316: Software Design & Architecture  To review software.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 3 - Software Systems and Requirements.
UML and Systems Analysis MIS3502: Application Integration and Evaluation David Schuff
Requirements and Design
Sequence Diagrams. Introduction A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and.
Information System Design IT60105
Lecture 9 Object-Oriented Analysis
Chapter 12 ATM Case Study, Part 1: Object-Oriented Design with the UML
Interaction Diagrams Activity Diagram State Machine Diagram
UI Standards & Tools Khushroo Shaikh.
Unit 211 Requirements Phase The objective of this section is to introduce software system requirements and to explain different ways of expressing these.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Introduction to Software Engineering Dr. Basem Alkazemi
Inception What needs to be done? Describe the vision and business case for this project. Determine if the project is feasible. Determine if the enterprise.
1 Software Requirements Specification Lecture 14.
Senior Design – Acceptance Test Plan Review The goal is to: define the criteria for approving the application. Tightly coupled to the Requirements document.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
System Design Chapter 8. Objectives  Understand the verification and validation of the analysis models.  Understand the transition from analysis to.
The Software Development Life Cycle: An Overview
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Rational Unified Process (Part 1) CS3300 Fall 2015.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
Case Study :. Introduction The ATM network will consist of a large number of ATM machines distributed over a wide geographical area. The network must.
Developing Use Cases in a Group Carolyn L. Cukierman Face-to-Face Technology Conference March 27, 2000.
1 Systems Engineering Process Review Mark E. Sampson EMIS 8340 Systems Engineering Tool—applying tools to engineering systems.
1 12 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 12 Designing Systems Interfaces, Controls, and Security.
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
SFWR ENG 3KO4 Software Development Fall 2009 Instructor: Dr. Kamran Sartipi Software Requirement Specification (SRS) for the Automated Banking Machine.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
Topics Covered: Software testing Software testing Levels of testing Levels of testing  Unit testing Unit testing Unit testing  Integration testing Integration.
Computerization of a bank  Automatic Teller Machines  Net Banking  Phone Banking  Savings/ Current/ Fixed Deposit/ Recurring Deposit  Loans against.
Formal Methods in SE Software Verification Using Formal Methods By: Qaisar Javaid, Assistant Professor Formal Methods1.
Requirements specification Why is this the first major stage of software development? –Need to understand what customer wants first Goal of requirements.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts.
Version 02U-1 Computer Security: Art and Science1 Correctness by Construction: Developing a Commercial Secure System by Anthony Hall Roderick Chapman.
Software Requirements Specification Document (SRS)
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
ISO 9001:2015 Subject: Quality Management System Clause 8 - Operation
Chapter 3: Software Design –Use case Diagram Nouf Alghanmi.
Basic Concepts of Software Architecture. What is Software Architecture? Definition: – A software system’s architecture is the set of principal design.
Software Engineering USE CASE DIAGRAM.
Testing throughout Lifecycle Ljudmilla Karu. Verification and validation (V&V) Verification is defined as the process of evaluating a system or component.
Verification Matrix Process
CMPE 135: Object-Oriented Analysis and Design August 31 Class Meeting
PREPARED BY G.VIJAYA KUMAR ASST.PROFESSOR
DFD(Data Flow Diagram)
Chapter 11 Designing Inputs, Outputs, and Controls.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Structured Analysis and Design Technique
ATM OO Design and Implementation Case Study
Requirements Analysis Scenes
SECURITY FEATURES OF ATM
System Design.
Electronic Banking Electronic Fund Transfer (EFT)
Requirements Elicitation and Elaboration
SAD ::: Spring 2018 Sabbir Muhammad Saleh
Software Requirements Specification Document
Using Use Case Diagrams
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
PPT4: Requirement analysis
Presentation transcript:

IT’S ALL ABOUT THE INTERFACES Jeffrey Eyster Indianapolis, IN

System Under Consideration Consider current banking transaction systems System includes internet transactions, telephone transactions, dedicated transaction machines, external transaction machines, and tellers System is very complex System requires considerable emphasis on security and data integrity

Banking System Context

Notional Banking System

System Design Issues Where will most problems be found with this system? Where will you spend most of your time fixing things with this system? Where should you spend more time making sure the definitions are complete for this system?INTERFACES

Defining Interfaces Interface requirements need to be defined with the same rigor as other system requirements Treat these the same as performance requirements The interface definition must satisfy the same criteria for requirements Complete Consistent Unambiguous Verifiable

Elements of the Interface Requirement Physical Construct Functional Behavior

Requirement Definition This is the “shall” of the definition The ATM System shall perform valid transactions of customers and non- customers. What does this requirement statement imply?

Physical Construct This is the definition of the physical elements of the interface. The ATM System shall extract information about the user and transmit this information to the main bank system to verify the user can perform transactions. What other physical elements are necessary for the ATM System?

Functional Behavior This is the functional definition of the desired behavior of the interface The ATM System shall verify the user has a valid card and identification number prior to initiating any transaction. What other functional behaviors are desireable about this interface? What functional behaviors should the interface NOT have?

Tools To Identify and Manage Interfaces Thorough understanding of the system and its context Be sure you understand what aspects are included and what are excluded Ensure everyone on the design team understands the system context CREATE THE SYSTEM CONTEXT DIAGRAM

Tools To Identify and Manage Interfaces (cont’d) Document the elements of the interface Text is fine to capture the requirement, but how many words does it take to describe the functional behavior and physical elements? Use graphics CREATE THE N-SQUARED DIAGRAM CREATE THE FUNCTIONAL BLOCK DIAGRAM CREATE THE SCHEMATIC BLOCK DIAGRAM

N-Squared Diagram

Functional Block Diagram

Schematic Block Diagram User Display Entry Panel Receipt Dispenser Cash Dispenser Deposit Collector Computer Home Bank

Verification and Validation Verification determines if the requirements have been satisfied Did I build it right? Validation determines if the design meets the intended purpose Did I build the right thing?

V&V for Interfaces Verify each interface meets the requirement by one of the verification methods (Inspection, Analysis, Demonstration, or Test) Requirement Functional Behavior Physical Construct

Summary It is essential to understand the interfaces of the system Most problems occur at the interface It isn’t the software’s fault that it didn’t work in the microprocessor It isn’t the microprocessor’s fault the software didn’t work The fault is the interface between the software and the microprocessor Time spent completely defining the interface is time well spent Pay me now or pay me later (but you will pay