Lecture 5 Safety Analysis FHA, HAZOP
|
|
- Morgan Young
- 5 years ago
- Views:
Transcription
1 Lecture 5 Safety Analysis FHA, HAZOP
2 Introduction While designing a safety-critical system usually several safety analysis techniques are applied The idea is to achieve completeness of safety requirements, spot defects in the design and amend it as early as possible in the development process Each safety technique gives a different perspective on system behaviour Potentially each of them brings a new insight on system behaviour
3 Today Functional Hazard Assessment (FHA) Hazard and Operability Study (HAZOP)
4 Functional Hazard Assessment (FHA) The FHA allows us to identify hazards at a functional level and correspondingly derive safety requirements. The FHA process consists of five steps: Identification of all functions associated with the level under study. Identification and description of failure conditions associated with these functions. Determination of the effects of the failure condition. Classification of failure effects on the system. Assignment of requirements to the failure conditions to be considered at the lower level.
5 Identification of failure conditions An identification of failure conditions can be done systematically by applying the following guidewords: - Loss of function - Function provided when not required - Incorrect operation of function.
6 Issues to be addressed How to describe functionality so that it will be easy to use in FHA? What is the proper level for the analysis? Often FHA results in derivation of new functional requirements? How to integrate them into already existing requirements?
7 Use case model We identify users of the system and the tasks which they must undertake with the system Actor (= User in UML notation ) is a user in a particular role. is external to the system. interacts and places demands on the system. A use case is a task which an actor needs to perform with the help of the system
8 Use cases as input for FHA use cases clearly define system s functions use case diagrams explicitly show interdependencies between use cases by means of associations
9
10 Documenting details of use cases Borrow copy of book A BookBorrower presents a book. The system check that the potential borrower is a member of the library, and that s/he does not already have the maximum permitted number of books on loan. This maximum is 6 unless the member is a staff member, in which case it is 12. If both checks succeed, the system records that this library member has this copy of the book on loan. Otherwise it refuses the loan. Note: description is in third-person, active-voice English
11 Use case: Borrow copy of book Actors: Book borrower (BB) Purpose: Capture book borrowing Overview: BB arrives at the checkpoint.the system check that the potential borrower is a member of the library, and that s/he does not already have the maximum permitted number of books on loan. If both checks succeed then loan is allowed, otherwise it is refused. Type: primary and essential Cross References (other resources which are needed to implement the use case. e.g. some system functions)
12 Example
13 Use case diagram
14 Use case Aspirate Brief description This use case defines system s reaction on the operator s command aspirate l units of liquid from plate p. It includes positioning of the operating head over the required plate, pumping the liquid in the pipette and reporting success or failure of the execution Includes use cases Move to X position, Move to Y position, Move to Z position, Pump Preconditions Operator chooses command Aspirate l units from plate p, the system is fault free Postconditions The amount of liquid in the pipette is increased by l units, the head is positioned over the plate p and success is reported. Otherwise failure is reported
15 Typical flow of events 1. Verify that p is a valid plate ID. If the verification fails then A_Failure1 in alternative cause of events, else calculate X, Y- coordinates of plate p. 2. Execute use cases Move to X position, Move to Y position. 3. If execution of use cases Move to X position, Move to Y position failed then A_Failure 2 in alternative flow of events else if execution of use cases Move to X position and Move to Y position succeeded then execute use case Move to Z position. 4. If use case Move to Z position failed then A_Failure 3 in alternative flow of events else if execution of the use case Move to Z position succeeded then execute use case Pump 5. Alternative flow of events A_ Failure1: Prompt message Incorrect plate ID p. Cease automatic execution mode. A_Failure2: If the execution of the use case Move to X position failed then cease automatic mode of execution, revert to the operator s control, prompt message Moving to X position has failed.
16 Use case Move to X position Brief description This use case defines reaction on the command Move to X position. As a result of the execution of the use case either the operating head is brought to X position and success is reported or failure is reported. Includes none Preconditions None Postconditions The operating head is placed at the position X or failure is reported Typical flow of events Check that xmin X xmax, if not X_Failure1 in alternative flow of events Check current x-position. If current x-position equals X then report success of execution. Otherwise move operating head to X position. Check current x-position. If current x-position equals X then report success of execution else X_Failure2 in alternative flow of events Alternative flow of events X_Failure1. Prompt message Input parameter X is outside of valid range X_Failure2. Prompt message Loss of precision of X movement
17 Conducting FHA Each element of use case description Pre-conditions, Guard-conditions, System responses Post-conditions Is identifies and recorded in the analysis table For each element we apply the guide words
18 Example of FHA Example from domain of engine control. Deceleration is a core aircraft function. Control of reverse thrust is a part of it. It is decomposed and allocated to sub-systems of aircraft As a result identification of failure of a single function (reverse thrust direction) result in discovery a new functional requirement
19 System level use case diagram
20 Decelerate on landing scenario
21 System level scenario
22 Example of extracting new functional requirements Element Airframe status =on ground (precondition) Guideword Commission Deviation On ground detected when not true Possible Causes System failure, invalid airframe data; data transmission failure Use Case Effect Reverse thrust implemented when precondition not satisfied Real World Effect Thrust reverser deployed when not on ground; loss of controlled flight Severity Catastrophic Integrity Constraints Assign on ground detection reliability; validate airframe data; specify data sampling rate New Safety Requirements Disallow thrust reverser when airframe not on ground; detect inadvertent deploy
23 Example of extracting integrity constraints (guide word omission) Element Thrust reverser state = in transit (guard condition) Guideword Omission Deviation Thrust reverser state= in transit not detected when true Possible Causes System failure, invalid thrust reverser data; data transmission failure Use Case Effect Engine thrust demand not commanded to thrust limit when guard condition satisfied Real World Effect Engine thrust exceeds thrust limit; structural damage to thrust reverser; loss of controlled deceleration on landing Severity Catastrophic Integrity Constraints Assign thrust reverser state detection reliability; validate thrust reverser data; specify data sampling rate
24 Example of extracting integrity constraints (guide word value) Element Thrust reverser state = in transit (guard condition) Guideword Value Deviation Thrust reverser state= in transit detected as thrust reverser = deployed Possible Causes System failure, invalid thrust reverser data; data transmission failure Use Case Effect Engine thrust demand not commanded to thrust limit when guard condition satisfied Real World Effect Engine thrust exceeds thrust limit; structural damage to thrust reverser; loss of controlled deceleration on landing Severity Catastrophic Integrity Constraints Assign thrust reverser state detection reliability; validate thrust reverser data; specify data sampling rate
25 FHA: conclusions FHA provides a systematic way to identify hazards caused by incorrect provision of system functions FHA can be applied at different levels of design, e.g., you can try to apply FHA to overall use cases, e.g., to investigate what happens when use case provided incorrectly, or when not expected, or not provided when expected
26 Hazard and operability studies (HAZOP) Why: to identify all possible derivations from the design s expected operations and all hazards associated with these deviations How: apply a list of guide words to designed functions and identify invoked deviations. Next determine the consequences of such deviations Information analyzed: The design intention of the plant, potential deviations from the design intention, the causes of these deviations from the design intention, the consequences of such deviations
27 A flowchart of the HAZOP study process
28 Possible guide words interpretation
29 Examples of HAZOP use (hardware oriented)
30 + Evaluation of HAZOP A simple, systematic approach which is easy to apply Encourages cross-disciplinary communication and allows to find the problems overlooked by functional teams working alone - Time consuming and labor-intensive approach Relies heavily on personal judgment Depends on the level of expertise of the teammembers
31 Example: HAZOP, use cases and security requirements The idea is similar to example of FHA: an application of guide words to use cases to derive security requirements The idea is to study use, abuse and misuse (of use cases) for analysis of security requirements Tailor HAZOP guide words to security perspective
32 HAZOP, use cases, security Actor: anything (anybody) that needs to exchange information with the system Deviations from intent (e.g., it should not allowed to process and approve payment) may result in threats Consider potential or resources
33 HAZOP: Actors Guidewords in security Action/Intent NO : The action/intent does not take place. MORE : More action is achieved. This may be one of the following: Sequential Repeat - the same actions take place repeatedly. Parallel Repeat - the same actions take place concurrently. Extreme intent - some scalar attribute of the action is affected (e.g. extreme parameter values are used in service invocations). LESS : Less action is achieved than intended. AS WELL AS : Parallel action - as well as the intended or normal action, some unexpected supplementary actions occur or are intended. OTHER THAN : The action achieves an incorrect result. Alternatively, the actor may use facilities for purposes other than those intended, i.e. abuse of privilege.
34 HAZOP: Actors Guidewords in security (cont.) Capability NO : Lack of the capability to perform the action. MORE : More general capability, allowing more to be achieved than intended. LESS : Less general capability, allowing less to be achieved than is required. PART OF : The actor has only part of, or is missing a specific part of the capability. AS WELL AS : As well as the specific capabilities required, the actor has other specific capabilities.
35 Associations Associations of actors with use case model the roles that interact with the system through the functionality modelled in the use case. Interactions may represent the exchange of information or invocation of system operations. We need a clear idea of which actors should be able to access which use case for what purpose Covert channels can be thought of as unintended associations.
36 HAZOP: Association Guidewords in security NO : Association does not/can not take place. MORE : Superfluous - Interface permits greater functionality to a particular actor than is required. Association is not constrained as required. Further divisions are: In-parallel with - More functionality is provided/occurs simultaneously with the permitted ones. In-sequence with - More functionality provided/occurs before or after the permitted ones. LESS : Interface permits less functionality to a particular actor than is required. Association is over-constrained. AS WELL AS : Associations to a particular use case take place with other actors as well. REVERSE : Interaction takes place in the reverse direction. OTHER THAN : Wrong association is defined. Swapping roles - swapping of associations between actors or individuals.
37 Use cases Use cases represent tasks that the system must achieve on behalf of the associated actors. Use case documentation includes pre-conditions, post-conditions and sequence of actions. We can address the causes and effects of variation by considering the deviations on each step in the use case. Consider also deviations from pre- and post conditions
38 Use Case Elements Guidewords State (defined in a pre-condition or a post-condition) NO : The state or condition does not take place or is not detected. AS WELL AS : Additional conditions apply. This may mean that more stringent checks are made, or else a more restrictive state results than is strictly required. Errors of commission might be considered here. PART OF : Only a subset of the required conditions apply. This might result from incomplete checks, incomplete implementation, or because the consequences of system behaviour are not fully understood. OTHER THAN : An incorrect condition applies. Perhaps the wrong data is used.
39 Use Case Elements Guidewords Action NO : No action takes place. MORE : More action is achieved. This may be one of the following: Repeat - the same actions take place repeatedly. Superfluous - the system does additional actions to those intended or required. LESS : Less is achieved than intended. For example, an action is incomplete, or an action takes place for a shorter time than required, or an action stopped earlier than expected. OTHER THAN : An incorrect action takes place.
40 Use Case Elements Guidewords Sequence of Actions (scenarios) LESS : Less is achieved than intended. For example, Drop - miss one or more parts of action. Additionally, a sequence of action takes place for a shorter time than required. AS WELL AS : The sequence does the intended actions plus others. REVERSE : The sequence of actions take place in reverse order (and other outof-order concepts). EARLY : The action sequence or its components takes place before it is expected (timing). LATE : The action sequence or its components takes place after it is expected (timing). BEFORE : The action sequence or its components happens before another action that is expected to precede it. AFTER : The action sequence or its components happens after another action that is expected to come after it. OTHER THAN : An incorrect action sequence takes place.
41 Analysis The team systematically investigates each use case element to identify deviation from requirements. Each deviant is further investigated for possible causes and effects.
42 Analysis The process has the following steps: 1. From a use case, identify and record: intent/action and capability of actors; associations between actors and use cases; components from use case description: pre-condition, main flow of events, alternative flow of events (i.e. normal but perhaps less likely and exceptional/ error), post-condition. 2. Apply HAZOP guidewords with the appropriate interpretation, to each element identified in step 1, to suggest deviations. 3. Evaluate whether the identified deviations violate, or could violate, any security properties. Investigate possible causes of the deviations. 4. Identify consequences that may arise from the deviations (extract affected assets from the identified consequences). 5. Categorise the deviations identified, and generalise each group. 6. Provide recommendations on the identified problems/threats.
Software Design Models, Tools & Processes. Lecture 2: Inception Phase Cecilia Mascolo
Software Design Models, Tools & Processes Lecture 2: Inception Phase Cecilia Mascolo Inception Phase This is the phase when most of the system requirements are identified. Discover and reach agreement
More informationHuman Error Taxonomy
Human Error Taxonomy The Human Error Taxonomy (HET) provides a structure for requirement errors made during the software development process. The HET can be employed during software inspection to help
More informationCyber Security of ETCS
1 Addressing the challenges Cyber Security of ETCS Simon Tonks 2 Background The UK rail network is currently being upgraded to use new signalling technology (ERTMS) The ROSCOs are delivering the First
More informationOCR Interchange Service Agreement
Oxford Cambridge and RSA OCR Interchange Service Agreement This agreement sets out the rights and obligations of the customer ( You ) and Oxford Cambridge and RSA Examinations ( We, Us, Our ) in connection
More informationBusiness Requirements Document (BRD) Template
Business Requirements Document (BRD) Template Following is a template for a business requirements document (BRD). The document includes many best practices in use today. Don t be limited by the template,
More informationVerification and Test with Model-Based Design
Verification and Test with Model-Based Design Flight Software Workshop 2015 Jay Abraham 2015 The MathWorks, Inc. 1 The software development process Develop, iterate and specify requirements Create high
More informationPart 5. Verification and Validation
Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this
More informationCIP Cyber Security Configuration Management and Vulnerability Assessments
Standard Development Timeline This section is maintained by the drafting team during the development of the standard and will be removed when the standard becomes effective. Development Steps Completed
More informationLecture 6: Requirements Engineering
Lecture 6: Requirements Engineering Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More informationDeriving safety requirements according to ISO for complex systems: How to avoid getting lost?
Deriving safety requirements according to ISO 26262 for complex systems: How to avoid getting lost? Thomas Frese, Ford-Werke GmbH, Köln; Denis Hatebur, ITESYS GmbH, Dortmund; Hans-Jörg Aryus, SystemA GmbH,
More informationCS3205: Task Analysis and Techniques
CS3205: Task Analysis and Techniques CS3205: Task Analysis and Techniques Readings (same as before): 1) ID-Book Chapter Establishing Requirements, Ch. 10 (Ch. 9 in course ebook) 2) Chapter 2 from Task-Centered
More informationInformation Security Policy
April 2016 Table of Contents PURPOSE AND SCOPE 5 I. CONFIDENTIAL INFORMATION 5 II. SCOPE 6 ORGANIZATION OF INFORMATION SECURITY 6 I. RESPONSIBILITY FOR INFORMATION SECURITY 6 II. COMMUNICATIONS REGARDING
More informationSAFETY AND SECURITY CHECKING IN THE DESIGN OF INTERNET BASED CONTROL SYSTEMS. Lili Yang and Shuang-Hua Yang
SAFETY AND SECURITY CHECKING IN THE DESIGN OF INTERNET BASED CONTROL SYSTEMS Lili Yang and Shuang-Hua Yang Computer Science Department, Loughborough University, Loughborough, Leicestershire LE11 3TU UK
More informationEuropean Aviation Safety Agency
European Aviation Safety Agency EASA Management Board Decision 12-2007 Amending the products certification procedure MB meeting 04-2007 (11 September 2007) DECISION OF THE MANAGEMENT BOARD AMENDING DECISION
More informationIssues in Programming Language Design for Embedded RT Systems
CSE 237B Fall 2009 Issues in Programming Language Design for Embedded RT Systems Reliability and Fault Tolerance Exceptions and Exception Handling Rajesh Gupta University of California, San Diego ES Characteristics
More informationThe essential guide to creating a School Bring Your Own Device Policy. (BYOD)
The essential guide to creating a School Bring Your Own Device Policy. (BYOD) Contents Introduction.... 3 Considerations when creating a BYOD policy.... 3 General Guidelines for use (Acceptable Use Policy)....
More informationCYSE 411/AIT 681 Secure Software Engineering. Topic #6. Seven Software Security Touchpoints (III) Instructor: Dr. Kun Sun
CYSE 411/AIT 681 Secure Software Engineering Topic #6. Seven Software Security Touchpoints (III) Instructor: Dr. Kun Sun Reading This lecture [McGraw]: Ch. 7-9 2 Seven Touchpoints 1. Code review 2. Architectural
More information4. Risk-Based Security Testing. Reading. CYSE 411/AIT 681 Secure Software Engineering. Seven Touchpoints. Application of Touchpoints
Reading This lecture [McGraw]: Ch. 7-9 CYSE 411/AIT 681 Secure Software Engineering Topic #6. Seven Software Security Touchpoints (III) Instructor: Dr. Kun Sun 2 Seven Touchpoints Application of Touchpoints
More information2. Introduction to UML & Discussion of Related S.E.
2. Introduction to UML & Discussion of Related S.E. 2. Introduction to UML...1 2.1 Context of UML...2 2.1.1 A classical view of specification & design, & how they are related...2 2.1.2 Examples of requirement
More informationSoftware Testing and Maintenance
Software Testing and Maintenance Testing Strategies Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal structure/ design/ implementation of the item
More informationStandard CIP Cyber Security Security Management Controls
A. Introduction 1. Title: Cyber Security Security Management Controls 2. Number: CIP-003-4 3. Purpose: Standard CIP-003-4 requires that Responsible Entities have minimum security management controls in
More informationSOLUTION BRIEF CA TEST DATA MANAGER FOR HPE ALM. CA Test Data Manager for HPE ALM
SOLUTION BRIEF CA TEST DATA MANAGER FOR HPE ALM CA Test Data Manager for HPE ALM Generate all the data needed to deliver fully tested software, and export it directly into Hewlett Packard Enterprise Application
More informationLecture 8: Goals and Scenarios. Pohl K., Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010, 814p.
Lecture 8: Goals and Scenarios Pohl K., Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010, 814p. 2 Documenting Goals 3 Documenting Goals 1. Each goal must have a unique
More information7 The Protection of Certification Marks under the Trademark Act (*)
7 The Protection of Certification Marks under the Trademark Act (*) In this research, I examined the certification and verification business practices of certification bodies, the use of certification
More informationLesson 06. Requirement Engineering Processes
Lesson 06 Requirement Engineering Processes W.C.Uduwela Department of Mathematics and Computer Science Objectives To describe the principal requirements engineering activities and their relationships To
More informationSubsystem Hazard Analysis (SSHA)
Subsystem Hazard Analysis (SSHA) c "!$#%! Examine subsystems to determine how their Normal performance Operational degradation Functional failure Unintended function Inadvertent function (proper function
More informationEvidence-based Development coupling structured argumentation with requirements development.
Evidence-based Development coupling structured argumentation with requirements development Jeremy.Dick@integrate.biz integrate 2012 based on paper Paper: EVIDENCE-BASED DEVELOPMENT COUPLING STRUCTURED
More informationSafety SPL/2010 SPL/20 1
Safety 1 system designing for concurrent execution environments system: collection of objects and their interactions system properties: Safety - nothing bad ever happens Liveness - anything ever happens
More informationRestricted Use Case Modeling Approach
RUCM TAO YUE tao@simula.no Simula Research Laboratory Restricted Use Case Modeling Approach User Manual April 2010 Preface Use case modeling is commonly applied to document requirements. Restricted Use
More informationPOLICY 8200 NETWORK SECURITY
POLICY 8200 NETWORK SECURITY Policy Category: Information Technology Area of Administrative Responsibility: Information Technology Services Board of Trustees Approval Date: April 17, 2018 Effective Date:
More informationCIP Cyber Security Personnel & Training
A. Introduction 1. Title: Cyber Security Personnel & Training 2. Number: CIP-004-6 3. Purpose: To minimize the risk against compromise that could lead to misoperation or instability in the Bulk Electric
More informationCIP Cyber Security Personnel & Training
A. Introduction 1. Title: Cyber Security Personnel & Training 2. Number: CIP-004-5.1 3. Purpose: To minimize the risk against compromise that could lead to misoperation or instability in the BES from individuals
More informationA. Introduction 1. Title: 2. Number: 3. Purpose: 4. Applicability: 4.1. Functional Entities: Balancing Authority Distribution Provider
The Background, VRF/VSLs, and Guidelines and Technical Basis Sections have been removed for this informal posting. The Project 2016-02 is seeking comments around the concept of the Requirement/Measure
More informationSystem Models. 2.1 Introduction 2.2 Architectural Models 2.3 Fundamental Models. Nicola Dragoni Embedded Systems Engineering DTU Informatics
System Models Nicola Dragoni Embedded Systems Engineering DTU Informatics 2.1 Introduction 2.2 Architectural Models 2.3 Fundamental Models Architectural vs Fundamental Models Systems that are intended
More informationEmergency Support Function #12 Energy Annex. ESF Coordinator: Support Agencies:
Emergency Support Function #12 Energy Annex ESF Coordinator: Department of Energy Primary Agency: Department of Energy Support Agencies: Department of Agriculture Department of Commerce Department of Defense
More informationDepartment of Public Health O F S A N F R A N C I S C O
PAGE 1 of 7 Category: Information Technology Security and HIPAA DPH Unit of Origin: Department of Public Health Policy Owner: Phillip McDown, CISSP Phone: 255-3577 CISSPCISSP/C Distribution: DPH-wide Other:
More information0. Database Systems 1.1 Introduction to DBMS Information is one of the most valuable resources in this information age! How do we effectively and efficiently manage this information? - How does Wal-Mart
More informationClient Computing Security Standard (CCSS)
Client Computing Security Standard (CCSS) 1. Background The purpose of the Client Computing Security Standard (CCSS) is to (a) help protect each user s device from harm, (b) to protect other users devices
More informationStandard CIP 005 2a Cyber Security Electronic Security Perimeter(s)
A. Introduction 1. Title: Cyber Security Electronic Security Perimeter(s) 2. Number: CIP-005-2a 3. Purpose: Standard CIP-005-2 requires the identification and protection of the Electronic Security Perimeter(s)
More informationLecture 8 Requirements Engineering
Lecture 8 Requirements Engineering Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 18, 2008 Lecture Overview
More informationPRC Coordination of Protection Systems for Performance During Faults
PRC-027-1 Coordination of Protection Systems for Performance During Faults A. Introduction 1. Title: Coordination of Protection Systems for Performance During Faults 2. Number: PRC-027-1 3. Purpose: To
More informationThis Policy applies to all staff and other authorised users in St Therese School.
St. Therese School Computer and Internet Policy STAFF Policy Statement All staff and other authorised users of St Therese information and communications technology are to use the technology only in a way
More informationUnderstanding Software Engineering
McBreen.book Page 3 Wednesday, August 1, 2001 10:08 PM Chapter 1 Understanding Software Engineering In order to understand software engineering, we first need to look at the projects that were reported
More informationSE351a: Software Project & Process Management. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa
SE351a: Software Project & Process Management W4.1: Requirements Engineering 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa SE351 Roadmap Introduction to Software Project Management Project Management
More informationCIP Cyber Security Configuration Change Management and Vulnerability Assessments
CIP-010-2 3 Cyber Security Configuration Change Management and Vulnerability Assessments A. Introduction 1. Title: Cyber Security Configuration Change Management and Vulnerability Assessments 2. Number:
More informationNatural Language Specification
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Dr. Jörg Dörr Natural Language Specification Most Requirements are Described in Natural Language Free Text (Prose) In Word In Excel (Tabular) In RM-Tools In Sys-ML
More informationThe software lifecycle and its documents
The software lifecycle and its documents Supplementary material for Software Architecture course B. Meyer, May 2006 Lifecycle models Origin: Royce, 1970, Waterfall model Scope: describe the set of processes
More informationCIP Cyber Security Systems Security Management
A. Introduction 1. Title: Cyber Security System Security Management 2. Number: CIP-007-5 3. Purpose: To manage system security by specifying select technical, operational, and procedural requirements in
More informationSoftware specification and modelling. Requirements engineering
Software specification and modelling Requirements engineering Requirements engineering (RE) Requirements engineering is the process of establishing the services that a customer requires from a system and
More informationVerification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1
Verification and Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification vs validation Verification: "Are we building the product right?. The software should
More informationLOGGING AND AUDIT TRAILS
LOGGING AND AUDIT TRAILS Policy LOGGING AND AUDIT TRAILS - POLICY TMP-POL-LAT V3.00-EN, 26/06/2009 TABLE OF CONTENTS 1 INTRODUCTION... 3 1.1 Document Purpose... 3 1.2 Target Audience...3 1.3 Business Context...4
More informationThirty one Problems in the Semantics of UML 1.3 Dynamics
Thirty one Problems in the Semantics of UML 1.3 Dynamics G. Reggio R.J. Wieringa September 14, 1999 1 Introduction In this discussion paper we list a number of problems we found with the current dynamic
More informationState-Based Testing Part B Error Identification. Generating test cases for complex behaviour
State-Based Testing Part B Error Identification Generating test cases for complex behaviour Reference: Robert V. Binder Testing Object-Oriented Systems: Models, Patterns, and Tools Addison-Wesley, 2000,
More informationOBSERVATIONS ON INTERNATIONAL OUTGOING TELEPHONE CALLS FOR QUALITY OF SERVICE
INTERNATIONAL TELECOMMUNICATION UNION CCITT E.422 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE (11/1988) SERIES E: OVERALL NETWORK OPERATION, TELEPHONE SERVICE, SERVICE OPERATION AND
More informationHigher-order Testing. Stuart Anderson. Stuart Anderson Higher-order Testing c 2011
Higher-order Testing Stuart Anderson Defining Higher Order Tests 1 The V-Model V-Model Stages Meyers version of the V-model has a number of stages that relate to distinct testing phases all of which are
More informationUSTGlobal INNOVATION INFORMATION TECHNOLOGY. Using a Test Design Tool to become a Digital Organization
USTGlobal INNOVATION INFORMATION TECHNOLOGY Using a Test Design Tool to become a Digital Organization Overview: Automating test design reduces efforts and increases quality Automated testing resolves most
More informationPEFC N 04 Requirements for certification bodies and accreditation bodies
PEFC N 04 Requirements for certification and accreditation Organisation Articles of Association for PEFC Norway Forest certification PEFC N 01 Norwegian PEFC certification system for sustainable forestry
More informationTARGET2-SECURITIES INFORMATION SECURITY REQUIREMENTS
Target2-Securities Project Team TARGET2-SECURITIES INFORMATION SECURITY REQUIREMENTS Reference: T2S-07-0270 Date: 09 October 2007 Version: 0.1 Status: Draft Target2-Securities - User s TABLE OF CONTENTS
More informationEmpAnADa Project. Christian Lange. June 4 th, Eindhoven University of Technology, The Netherlands.
EmpAnADa Project C.F.J.Lange@tue.nl June 4 th, 2004 Eindhoven University of Technology, The Netherlands Outline EmpAnADa introduction Part I Completeness and consistency in detail Part II Background UML
More informationAn Architecture for Semantic Enterprise Application Integration Standards
An Architecture for Semantic Enterprise Application Integration Standards Nenad Anicic 1, 2, Nenad Ivezic 1, Albert Jones 1 1 National Institute of Standards and Technology, 100 Bureau Drive Gaithersburg,
More informationStandard Development Timeline
Standard Development Timeline This section is maintained by the drafting team during the development of the standard and will be removed when the standard becomes effective. Description of Current Draft
More informationLecture Notes on Arrays
Lecture Notes on Arrays 15-122: Principles of Imperative Computation July 2, 2013 1 Introduction So far we have seen how to process primitive data like integers in imperative programs. That is useful,
More informationUML for Real-Time Overview
Abstract UML for Real-Time Overview Andrew Lyons April 1998 This paper explains how the Unified Modeling Language (UML), and powerful modeling constructs originally developed for the modeling of complex
More informationGDPR AMC SAAS AND HOSTED MODULES. UK version. AMC Consult A/S June 26, 2018 Version 1.10
GDPR AMC SAAS AND HOSTED MODULES UK version AMC Consult A/S June 26, 2018 Version 1.10 INDEX 1 Signatures...3 2 General...4 3 Definitions...5 4 Scoping...6 4.1 In scope...6 5 Responsibilities of the data
More informationBYOD Information Session: A Guide to Being Successful with BYOD
BYOD Information Session: A Guide to Being Successful with BYOD Goal The goal of this BYOD presentation is to inform you about the Bring Your Own Device (BYOD) Policy. Our BYOD or Bring Your Own Device
More informationAn Approach to Software Component Specification
Page 1 of 5 An Approach to Software Component Specification Jun Han Peninsula School of Computing and Information Technology Monash University, Melbourne, Australia Abstract. Current models for software
More informationEuropean Responsible Care Forum. Security & Safe Maintenance
European Responsible Care Forum Security & Safe Maintenance Brussels, Thursday 7 April 2011 Mike Zeegers - Director Europe Agenda: History IMPROVE PROJECT To enhance Secure infrastructure Objective of
More informationCIP Cyber Security Security Management Controls. Standard Development Timeline
Standard Development Timeline This section is maintained by the drafting team during the development of the standard and will be removed when the standard becomes effective. Development Steps Completed
More informationREVISION HISTORY DATE AMENDMENT DESCRIPTION OF AMENDMENT
REVISION HISTORY DATE AMENDMENT DESCRIPTION OF AMENDMENT SERVICE DESCRIPTION Page 1 of 17 SERVICE DESCRIPTION 2-11: WHOLESALE DSL SERVICE 1. THE SERVICE The Wholesale DSL service is a service which enables
More informationChapter 1 Introduction
Chapter 1 Introduction Secure system development is not a trivial task. It comprises a number of activities, which need to be combined, analysed, and executed to produce a secure software system. In this
More informationInformatics 1 - Computation & Logic: Tutorial 5
Informatics - Computation & Logic: Tutorial 5 Computation: Introduction to Finite State Machines Week 7: 3 October - 4 November 206 Please attempt the entire worksheet in advance of the tutorial, and bring
More informationDistributed Systems COMP 212. Lecture 19 Othon Michail
Distributed Systems COMP 212 Lecture 19 Othon Michail Fault Tolerance 2/31 What is a Distributed System? 3/31 Distributed vs Single-machine Systems A key difference: partial failures One component fails
More informationSafety-Critical Software Development
Safety-Critical Software Development Prof. Chris Johnson, School of Computing Science, University of Glasgow. johnson@dcs.gla.ac.uk http://www.dcs.gla.ac.uk/~johnson Introduction Why is software different?
More informationBCN Telecom, Inc. Customer Proprietary Network Information Certification Accompanying Statement
BCN Telecom, Inc. Customer Proprietary Network Information Certification Accompanying Statement BCN TELECOM, INC. ( BCN" or "Company") has established practices and procedures adequate to ensure compliance
More informationStandard CIP 005 4a Cyber Security Electronic Security Perimeter(s)
A. Introduction 1. Title: Cyber Security Electronic Security Perimeter(s) 2. Number: CIP-005-4a 3. Purpose: Standard CIP-005-4a requires the identification and protection of the Electronic Security Perimeter(s)
More informationChapter 6 Architectural Design. Chapter 6 Architectural design
Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process for identifying
More informationWHAT IS SOFTWARE ARCHITECTURE?
WHAT IS SOFTWARE ARCHITECTURE? Chapter Outline What Software Architecture Is and What It Isn t Architectural Structures and Views Architectural Patterns What Makes a Good Architecture? Summary 1 What is
More informationProgram Correctness and Efficiency. Chapter 2
Program Correctness and Efficiency Chapter 2 Chapter Objectives To understand the differences between the three categories of program errors To understand the effect of an uncaught exception and why you
More informationModeling Crisis Management System With the Restricted Use Case Modeling Approach
Modeling Crisis Management System With the Restricted Use Case Modeling Approach Gong Zhang 1, Tao Yue 2, and Shaukat Ali 3 1 School of Computer Science and Engineering, Beihang University, Beijing, China
More informationSoftware Design Models, Tools & Processes. Lecture 6: Transition Phase Cecilia Mascolo
Software Design Models, Tools & Processes Lecture 6: Transition Phase Cecilia Mascolo UML Component diagram Component documentation Your own classes should be documented the same way library classes are.
More informationSoftware testing. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 1
Software testing Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles
More informationMODEL COMPLAINTS SYSTEM AND POLICY THE OMBUDSMAN'S GUIDE TO DEVELOPING A COMPLAINT HANDLING SYSTEM
MODEL COMPLAINTS SYSTEM AND POLICY THE OMBUDSMAN'S GUIDE TO DEVELOPING A COMPLAINT HANDLING SYSTEM Published by the Office of the Ombudsman 18 Lower Leeson Street Dublin 2 Telephone: 01 639 5600 Lo-call:
More informationStandard CIP 004 3a Cyber Security Personnel and Training
A. Introduction 1. Title: Cyber Security Personnel & Training 2. Number: CIP-004-3a 3. Purpose: Standard CIP-004-3 requires that personnel having authorized cyber or authorized unescorted physical access
More informationThe testing process. Component testing. System testing
Software testing Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating system
More informationAdvisory Circular (AC)
Advisory Circular (AC) Certification Plans File No. 5009-6-500 AC No. 500-015 RDIMS No. 528332-V4 Issue No. 01 Issuing Branch Aircraft Certification Effective Date 2004-12-01 1.0 INTRODUCTION... 2 1.1
More informationSOLUTION BRIEF RSA ARCHER IT & SECURITY RISK MANAGEMENT
RSA ARCHER IT & SECURITY RISK MANAGEMENT INTRODUCTION Organizations battle growing security challenges by building layer upon layer of defenses: firewalls, antivirus, intrusion prevention systems, intrusion
More informationFundamentals: Software Engineering. Objectives. Last lectures. Unit 2: Light Introduction to Requirements Engineering
Fundamentals: Software Engineering Dr. Rami Bahsoon School of Computer Science University of Birmingham r.bahsoon@cs.bham.ac.uk Unit 2: Light Introduction to Requirements Engineering Dr R Bahsoon 1 Objectives
More informationStandard CIP Cyber Security Electronic Security Perimeter(s)
A. Introduction 1. Title: Cyber Security Electronic Security Perimeter(s) 2. Number: CIP-005-2 3. Purpose: Standard CIP-005-2 requires the identification and protection of the Electronic Security Perimeter(s)
More informationStandard Development Timeline
Standard Development Timeline This section is maintained by the drafting team during the development of the standard and will be removed when the standard is adopted by the NERC Board of Trustees (Board).
More informationTerms of Service. USER means the individual that creates and/or has access to manage or maintain
Terms of Service Tiggee LLC doing business as DNS Made Easy, (hereafter DNS Made Easy or Tiggee ), provides the service ( SERVICE or DNS Made Easy service ) subject to the terms and conditions set forth
More informationOIML-CS PD-05 Edition 2
PROCEDURAL DOCUMENT OIML-CS PD-05 Edition 2 Processing an application for an OIML Type Evaluation Report and OIML Certificate OIML-CS PD-05 Edition 2 ORGANISATION INTERNATIONALE DE MÉTROLOGIE LÉGALE INTERNATIONAL
More informationChapter 6 Architectural Design. Lecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered ² Architectural design decisions ² Architectural views ² Architectural patterns ² Application architectures 2 Software architecture ² The design
More informationTerms and Conditions of Mobile Phone Service (Pre-Paid) Between Operator and Subscriber
Terms and Conditions of Mobile Phone Service (Pre-Paid) Between Operator and Subscriber Section 1 General 1.1 This Terms and Conditions of Mobile Phone Service shall be effective between Advanced Wireless
More information11.0 Random Assignment
11.0 Random Assignment Random assignment is the procedure by which enrolled youth will be assigned to either the Usual Services or ASPIRE Services groups. Random assignment is performed in a computer system,
More informationAPI documentation from the perspective of WHO-PQP
API documentation from the perspective of WHO-PQP Antony Fake PhD WHO Medicines Prequalification Programme 1 API documentation 3.2.S.3.2 from Impurities, the perspective of WHO PQP Malaysia, Mumbai, 29
More informationThomson Virtual Difficulty Indication This document has been classed as: Level 1 Beginner
Table of Contents 1 Introduction... 3 2 Membership Policy... 3 3 Flight Policy... 4 4 Communications and Privacy Policy... 5 5 Code of Conduct Policy... 5 6 Disciplinary Proceedings Policy... 6 7 Forum
More informationSoftware Development Chapter 1
Software Development Chapter 1 1. Introduction Software Applications are increasingly used to tackle problems that concern everyday life : Automatic Bank tellers Airline reservation systems Air traffic
More informationTerms and Conditions of Mobile Phone Service (Post-Paid) Between Operator and Subscriber
Terms and Conditions of Mobile Phone Service (Post-Paid) Between Operator and Subscriber Section 1 General 1.1 This Terms and Conditions of Mobile Phone Service shall be effective between Advanced Wireless
More informationCIP Cyber Security Configuration Change Management and Vulnerability Assessments
CIP 010 1 Cyber Security Configuration Change Management and Vulnerability Assessments A. Introduction 1. Title: Cyber Security Configuration Change Management and Vulnerability Assessments 2. Number:
More informationIntegrating Cyber Security and Safety Systems Engineering Disciplines with a common Code of Practice
Integrating Cyber Security and Safety Systems Engineering Disciplines with a common Code of Practice Dr Richard Piggin 16 November 2017 - Atkins Limited 1 Introduction Background Motivation Safety Engineering
More information