Control Systems Design Part: FS Slovak University of Technology Faculty of Material Science and Technology in Trnava 2007.

Slides:



Advertisements
Similar presentations
EIDE System Requirements and Specification Documents
Advertisements

© by cellconsult.com Application Testing & Test Management.
Introduction to Databases
Software Engineering 1. Software development – the grand view 2. Requirements engineering.
Chapter 7 Other Requirements Good Fast Cheap Pick any two. 1CS John Cole.
System integrity The term system integrity has the following meanings: That condition of a system where in its specified operational and technical parameters.
Network Management Overview IACT 918 July 2004 Gene Awyzio SITACS University of Wollongong.
Introduction to Databases
Conquering Complex and Changing Systems Object-Oriented Software Engineering TJSS System Design Lecture 12 Päivi Ovaska.
WKES 3202 SOFTWARE REQUIREMENTS ENGINEERING SEMESTER 1 SESSION 2004/2005.
1 ITC242 – Introduction to Data Communications Week 12 Topic 18 Chapter 19 Network Management.
Introduction to Databases
11 3 / 12 CHAPTER Databases MIS105 Lec14 Irfan Ahmed Ilyas.
Software Requirements
Introduction to Databases Transparencies
 2006 Pearson Education, Inc. All rights reserved Introduction to Classes and Objects.
1 A Student Guide to Object- Orientated Development Chapter 9 Design.
Testing - an Overview September 10, What is it, Why do it? Testing is a set of activities aimed at validating that an attribute or capability.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 1.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
IV&V Facility Model-based Design Verification IVV Annual Workshop September, 2009 Tom Hempler.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Introduction to Databases
Key Management in Cryptography
Introduction to Databases Transparencies 1. ©Pearson Education 2009 Objectives Common uses of database systems. Meaning of the term database. Meaning.
Database Systems: Design, Implementation, and Management Ninth Edition
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
Database Systems COMSATS INSTITUTE OF INFORMATION TECHNOLOGY, VEHARI.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
Chapter 4 – Requirements Engineering 1Chapter 4 Requirements engineering.
Software Requirements Engineering CSE 305 Lecture-2.
1 Welcome: To the second learning sequence “ Data Base (DB) and Data Base Management System (DBMS) “ Recap : In the previous learning sequence, we discussed.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
Information: Policy, Strategy and Systems Module Overview
Lecture 7: Requirements Engineering
12.1 Introduction Checklists are used as a technique to give status information in a formalized manner about all aspects of the test process. This chapter.
Chapter(1) Introduction and conceptual modeling. Basic definitions Data : know facts that can be recorded and have an implicit. Database: a collection.
Lecture # 3 & 4 Chapter # 2 Database System Concepts and Architecture Muhammad Emran Database Systems 1.
Chapter 1 Introduction to Databases. 1-2 Chapter Outline   Common uses of database systems   Meaning of basic terms   Database Applications  
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Requirements Engineering Overview Senior Design Don Evans.
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
1 Introduction to Databases. 2 Examples of Database Applications u Purchases from the supermarket u Purchases using your credit card u Booking a holiday.
1 Chapter 1 Introduction to Databases Transparencies.
1 Quality Attributes of Requirements Documents Lecture # 25.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Control Systems Design Part URS Slovak University of Technology Faculty of Material Science and Technology in Trnava 2007.
Software Requirements
Introduction to Databases Transparencies © Pearson Education Limited 1995, 2005.
CSC480 Software Engineering Lecture 7 September 16, 2002.
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
IIS 645 Database Management Systems DDr. Khorsheed Today’s Topics 1. Course Overview 22. Introduction to Database management 33. Components of Database.
I&C Lab Seminar Procedure for the Software Requirements Specification for Safety Critical Systems Seo Ryong Koo Korea Advanced Institute Science.
“ Database (DB) and Database Management System (DBMS) “
SYSTEM ANALYSIS AND DESIGN
Introduction to Databases
Introduction to Databases
Introduction to Databases
Database (DB) and Database Management System (DBMS)
Introduction to Databases
EIDE System Requirements and Specification Documents
Robin Dale RLG OAIS Functionality Robin Dale RLG
Terms: Data: Database: Database Management System: INTRODUCTION
Design.
Presentation transcript:

Control Systems Design Part: FS Slovak University of Technology Faculty of Material Science and Technology in Trnava 2007

Functional Specification Purpose General guidelines Ambiguity, duplication and contradiction has to be avoided All limitation should be explicitly defined Consistent and intuitive naming has to be used Each function and facility has to be testable Each specification should be traceable (traceability matrix)

Functional Specification Introduction Author of the document, his authority and for what purpose the document has been produced The contractual.status of the document Relationship to other documents

Functional Specification Overview Key objectives and benefits Reference to relevant standards and regulations High level description The main interfaces from the system to other systems or the environment

Functional Specification Overview - continued Assumptions: it defines any design or implementation assumptions or limitations as use of standard packages, program libraries, operating systems, hardware... Non-conformance with User Requirements Specification; any divergence between the Functional Specification and the User Requirements Specification has to be noted.

Functional Specification Functions The objective of the function or facility, and the details of its use, including interface with other parts of the system. Critical calculation and algorithms has to highlighted. Performance, response and accuracy Safety and security: action in case of HW/SW failures, I/O variables checking, redundancy, access restrictions, self diagnostic, data recovery, time-outs...  Functions which are configurable and any limits within which the configuration can take place  Traceability to specified requirements in User Requirements Specification

Functional Specification Functions - continued Functions which are configurable and any limits within which the configuration can take place Traceability to specified requirements in User Requirements Specification

Functional Specification Data Data definition in a hierarchical manner with complex objects being built up from simpler objects. Critical parameters has to be highlighted. Data access (which subsystems need read or write, access to each data item, access method, speed and update time, read/write interlocks) Data capacity, retention time, and details about data archiving Data integrity and security

Functional Specification Interfaces Interface with users is defined by terms as operator, administrator, system manager. Topics to consider include facilities available, types of peripherals, general format of displays and reports, error handling and reporting Interface with other systems; nature of the interaction, and the methods and rules governing the interaction

Functional Specification Interfaces - topics Data transmitted and received Data type, format, ranges, and meaning of values Timing Rate of data transfer Communications protocol – initiation and order of execution Any data haring, creation, duplication, storage, or destruction

Functional Specification Interfaces - topics continued Mechanism for invocation and interruption Communication through parameters, common data areas, or messages Direct access to internal data Error handling, recovery, and reporting Security

Functional Specification Non-functional Attributes Availability – reliability, redundancy, error checking, stand-by operation Maintainability – expansion and enhancement possibilities, spare capacity, likely changes in environment, lifetime.

Functional Specification Glossary Section This Section contains definitions or explanations of any terms that may be unfamiliar to the readership of the document