Modeling Functional Requirements to Support Traceability Analysis
|
|
- Arline Booth
- 7 years ago
- Views:
Transcription
1 Modeling Functional Requirements to Support Traceability Analysis Nihal Kececi*, Juan Garbajosa*, Pierre Bourque** Universidad Politécnica de Madrid (UPM) Technical University of Madrid E.U. Informatica. Ctra. de Valencia, Km. 7. E-80 Madrid. Spain ** Département de génie logiciel et des TI École de technologie supérieure 00, rue Notre-Dame Ouest Montréal (Québec), Canada HC K pierre.bourque@etsmtl.ca Abstract Traceability analysis is a technique that enables the verification of software requirements within the software life cycle. Within a context where there is a lack of common understanding of what must be traced, a number of methods have been proposed to implement software requirements traceability analysis, many of these methods dealing with software requirements expressed in natural language. This paper provides a graphical model to visualize software functional requirements that facilitates identifying functional traceability links. An application of the proposed model is illustrated through a case study taken from a process control system. Keywords: Functional traceability, requirements verification, traceability analysis. I. INTRODUCTION Requirements specifications for software consist of a number of abstraction levels, derived through successive decompositions of the software under development or being maintained. One of the major challenges within large-scale software engineering is the management of these requirements notably because software requirements are generated, used and changed throughout the software life cycle by a number of different technical and commercial groups. The SWEBOK Guide defines verification as an attempt to ensure that the product [software] is built correctly, in the sense that the output products of an activity [within the software life cycle] meet the specifications imposed on them in previous activities []. Validation deals with ensuring that the product fulfills its intended purpose. This paper deals with traceability analysis within the context of software verification rather than within the context of software validation. The completeness of the verification of software requirements is fundamental to effective requirements management. The complete software requirements verification process shows whether a software component behaves in accordance with its previously stated software requirement specifications. The importance of software requirements cannot be overstated since all subsequent phases of the software life cycle are dependent upon these software requirements. Developing and managing software requirement specifications represent an especially difficult challenge. Experience has shown that some of the reasons why errors tend to occur in the software requirements phase are as follows: () misunderstanding or misinterpretation of software requirements, () incomplete and inconsistent software requirements, and () software requirements written in natural language that are ambiguous, inconsistent, and incomplete. The result of the software requirements elicitation and specification process is often a long document that is difficult to read and is even more difficult to design and code from. Also, when changes are needed, processes are often not in place to determine how other software requirements are affected by particular changes. Software requirements traceability analysis is therefore an essential activity to support the verification of software requirements as well as to manage changes. The ability to trace the logical and physical links between software artifacts including different levels of requirements is essential and critical to the development of complex software. In this section we discuss the importance of software requirements in the software life cycle, the verification of software requirements, and the role of software requirements traceability analysis within the software verification process. Section reviews current verification methods for software. Definitions of the terms used in this paper are introduced in section. A modeling method for graphical software requirements analysis is discussed in section, and a case study is presented in section. Conclusion and lessons learned are discussed in Section 6.
2 II. SOFTWARE REQUIREMENTS VERIFICATION METHODS To deal with inconsistent and incomplete software requirements, many approaches to the verification of software requirements have been developed over the last years. According to a survey and assessment of verification methods of conventional software [], software requirements and design verification methods consist of four major categories and various subcategories. These major categories are described as follows and are summarized in Table. TABLE CATEGORIES OF SOFTWARE VERIFICATION METHODS Category Formal Methods Semi-formal Methods Review and Analysis Traceability Analysis Description Mathematical Verification of Software Requirements: Translates software requirements into mathematical form to analyze various properties. Requirements Language Analysis: Express software requirements in a special requirements language and analysis of results for completeness, consistency, feasibility, testability, etc. Review and analysis by trained personnel of the adequacy of software requirement specifications using a detailed preestablished set of criteria and procedures. Identification of individual software requirements entities and tracing of these to design entities and from the design entities to implementation entities. A. Formal Methods: Formal methods involve mathematical and logical representations for expressing relationships among data and for expressing the processes which interact with them. Mathematical representations produced early in the software life cycle, from the stakeholder requirements definition document, the software requirements specifications, and the software design documents may then be subjected to formal deductive reasoning to detect anomalies or defects regarding, for example, correctness, contradiction, completeness, and consistency. While formal descriptions are valuable, the state of the art has not evolved to a point, yet, where they can be very widely applied. In particular, the number of people who could be trusted to make formal descriptions of non-trivial software is quite limited. B. Semi-Formal Methods: Semi-formal methods are less difficult to apply than formal methods. They often involve notations with rigorous constraints on notably the selection and sequencing of operators to achieve the goal of analyzing software requirement specifications within well defined boundaries. One major advantage is often their graphical mode, a characteristic that facilitates simulation or animation of software requirement specifications and designs. But formalization itself cannot guarantee defect detection, nor can it prove that the software requirement specifications are correct. C. Review and Analysis: A commonly applied method of software verification is the review and analysis of the stakeholder requirements definition documents and the software requirement specifications. Such a review and analysis is carried out by trained personnel to investigate their adequacy using a detailed pre-established set of criteria and procedures. A group of reviewers is constituted with a mandate to look for errors, mistaken assumptions, lack of clarity and deviations from standard practices. Reviews may be constituted on completion of the stakeholder requirements definition document, the software requirement specifications, the baseline specifications for a new release, etc. D. Traceability Analysis: Traceability analysis notably establishes the relationships between software requirement specifications and software design, matching elements of one to those of the other. Once the matching has been completed, all that remains is either a set of unmapped software requirement specifications, or a set of unmotivated or unintended functions that were inserted in the software design artifacts. Traceability analysis may also be applied between different levels of software requirements such as between the stakeholder requirements definition document and the software requirement specifications. Within the context of a lack of common understanding of what must be traced, many methods have been proposed for diverse applications of software requirements traceability analysis and many of them deal with software requirements expressed in natural language [, ]. II. KEY CONCEPTS AND DEFINITIONS Functions are discrete actions that must be performed. Functional analysis begins by identifying top-level system functions and decomposing these into a hierarchy of subfunctions to form a functional architecture. The objective is to break the system down into sub-functions which can be performed by people, hardware, and software, and which, when combined with other sub-functions, will achieve the performance of the higher-level system function. The purpose of functional requirements traceability analysis at the system level is to determine if all the functional requirements have been mapped to detailed system specifications and if these, in turn, have all been allocated to the functional components of the software architecture if these system specifications are allocated to software. The Software Functional Specification (sometimes called a Functional Architecture) contains a high-level diagram of the logical software architecture including interfaces to other systems and software. The software is divided into functional
3 components, which are further described in the software design descriptions produced in the next phase. The Functional Specification describes how the software requirement specifications will be met in terms of the software s logical architecture. To avoid confusion, many of the terms used in this paper are defined below. Function: () A function is a module that performs a specific action, is invoked by the appearance of its name in an expression, may receive an input value, and returns a single value []. When a function is decomposed, sub-functions can be identified Even though this definition is technical in nature, it is deemed to be useful because of its emphasis on the discrete nature of a function. Functional Characteristics: Inputs, outputs, process (algorithms), and interfaces of a function are defined as functional characteristics in this paper []. Functional Requirement: A requirement that specifies a function that a system [software] or system [software] component must be able to perform []. Functional Specification: A document that specifies the functions that a system [software] or component must perform []. Functional User Requirements (FUR): The term Functional User Requirements is a sub-set of the user requirements. The FUR represent the user practices and procedures that the software must perform to fulfill the user s needs. FUR exclude Quality Requirements and any Technical Requirements [6]. Traceability: Definitions or descriptions of traceability that can be found in software engineering standards include: o The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor successor or master-subordinate relationship to one another; for example, the degree to which the requirements and design of a given software component match []. o A Software Requirements Specification (SRS) is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation. Forward and backward traceability are also recommended [7]. o Traceability [ ] means that the document in question is in agreement with a predecessor document to which it has a hierarchical relationship. Traceability has five elements: o the document in question contains or implements all applicable stipulations of the predecessor document, o A given term, acronym, or abbreviation means the same thing in all documents, o A given item or concept is referred to by the same name or description in the documents, o All material in the successor document has its basis in the predecessor document, that is, no untraceable material has been introduced, and o The two documents do not contradict one another [8]. III. MODELING METHOD FOR GRAPHICAL REQUIREMENTS ANALYSIS Graphical Requirement Analysis (GRA) is a method for translating functional requirements expressed in a text format to a graphical format. It is also proposed as a traceability analysis method for system and software requirements The GRA modeling core concept was derived from a system engineering technique called the Master Logic Diagram (MLD) [9,0,]. This technique has been used to model complexity for system diagnostic purposes. GRA includes, as well, a mapping to the COSMIC-FFP method [6] for measuring software functional size though this topic is not discussed in this paper. As shown in Fig., the GRA modeling method adopts the following graphical language notation: Module : A rectangle in the centre represents a module or Functional User Requirement in a multilevel hierarchy. External I/O: The rectangles on the top and on the left represent external input and output sets. User inputs, sensor outputs, system variables, and outputs of another module are examples of such external input and outputs. Internal I/O: The numbered circles represent the output of a sub-module which will be an input to another sub-module within a time sequence, as shown in Fig. Sub-module: These are illustrated with decision logic symbols in Fig.. Sub-modules can be mathematical operators, decision algorithms, etc. Boundary: This is identified by the entry and exit points of a Functional User Requirement or module. The terms of module and function are used interchangeably.
4 A module A sub-module Internal I/O OUTPUT 6 The description of the Vessel Water Level Controller function was taken from the System Requirement Specifications, and is as follows: The level controller provides the dynamic level position inside a given component along with the current feed water line and steam line mass flow rates. The output consists of the mass flow rate of the FILL component, which provides the inlet flow of the feed-water system. Step : Identifying the external I/O User/operator inputs Sensor outputs Outputs of another function/module Any hardware action INPUT INPUT INPUT INPUT n Fig.. Graphical Requirements Analysis (GRA) Notations A general strategy for functional decomposition is to define a Functional User Requirement (FUR) as a mapping from inputs to outputs. Ideally, traceability analysis proceeds in a top-down fashion, first identifying the functions associated with the software as a whole. Each level of detail in the hierarchy provides detail about the processing steps necessary to accomplish the more abstract function defined one level above. The decomposition process is repeated until some lowest level of sub-functions is reached. On the left side, the external input sets are linked to sub-modules. Some external inputs may be used by multiple sub-modules. In a complete decomposition of a Functional User Requirement (FUR), the functional hierarchy specifies the sub-modules, the internal inputs needed to perform these sub-modules, and the internal outputs resulting from these sub-modules, as well as their interrelationships. Any external output of a module can be an input to another module or vice versa. IV. A CASE STUDY: An illustration of an application of the GRA method on a Vessel Water Level Controller, a functional user requirement (FUR s) in a process control system, is presented in this section. To build the GRA model, the functional characteristics (input/output/process) of the Vessel Water Level Controller which is a system level requirement, were searched through the various documents produced during the system and software development process. To achieve the Vessel Water Level Controller function, five inputs were identified in the System Requirement Specification as follows. These were traced forward from, and backward to, the User Manual to verify their correctness. X(meter) should be provided with the vessel down water level, which could be provided by type 06 signal variable. X (kg/sec) should be provided with the current time step feed water line mass flow rate. X(kg/sec) should be the current time step steam line mass flow rate. c (meter) is the user-desired vessel collapsed water level position, c (kg/sec) is the nominal steady state feed water line mass flow rate (kg/sec) Control block number 0 was identified in the User Manual as the Vessel Water Level Controller function. The control block was described as follows: Control Block no.: 0 Control Block name: Vessel water level controller Control Block Mathematical Operation: X (out) = f (X, X, X, c, c) Block Inputs: X, X, X Block Constant: c, c The External I/O of the Vessel Water Level Controller is illustrated in the GRA framework with rectangles outside the functional boundary in Fig.. Step : Identifying Sub-modules and Internal I/0 The control block function operators or sub-modules belonging to the Vessel Water Level Controller were identified from the System Design Specification (SDS). These are traced forward from, and backward to, the User Manual. To achieve the process goal of each sub-module as listed in Table ; their internal inputs/outputs were searched using a functional decomposition technique. The application of the GRA method notably identified that SUBT had an incorrect control block number. This has been replaced by ADD in Figure. For reasons of confidentiality, no reference is cited here.
5 Table : Sub-Modules of Control Block 0 Xout =f (X,X,X C,C) Previously Identified Sub-Modules Sub-Modules Identified by Using the GRA Method Control Block # Control Block Type & Name Control Block Number and Type ING (Integrate) ING 6 LAG First-order lag LAG 6 6 SUBTC (Sum SUBTC 6 constant) 9 WSUM (Weighted WSUM 9 summer) DEAD (Divide) DEAD SUBT (Subtract) ADD 9 WSUM (Weighted WSUM 9 summer) 6 SUBTC (Sum constant) SUBTC 6. X() (m) Vessel Water Level SVT The external inputs identified in step are then mapped to the internal inputs of the lowest level of sub-module obtained using a functional decomposition of the system requirement in step. As shown in Fig., the inputs of the Control Block Functions or sub-modules,, 6, and are mapped to the external inputs. After verifying the correctness of the external inputs in the GRA method, these inputs are mapped to the System Requirement Specifications; leading to either a set of unmapped requirements or to a set of unnecessary requirements. Models such as Figure are built from top to bottom (that is from the User Manual to the System Requirement Specifications, the System Design Specifications and eventually to the Software Requirement Specifications), and traceability analysis is executed from bottom to top (that is, from the Software Requirement Specifications to the System Design Specifications, the System Requirement Specifications and to the User Manual). Functional characteristics (internal I/O, external I/O, subfunctions or sub-modules) can be incorporated into a multilevel hierarchy using the GRA modeling method. Cbcon (m): Water level set-point X() (kg/sec) Current time step feed-water line mass flow rate (mfw) X() (kg/sec) Current time step steam line mass flow rate (ms) Cbcon (kg/sec): nominal steady state feed-water line mass flow rate INTERNAL I/O Water Level Int. Lev. Err (Ki+Kp)term mfw m - m S 6 m (dem) FW 7 m (act) FW 8 mfw FW 6 9 SUB-FUNCTIONS SUBTC INT WSUM DEAD 6 LAG ADD 0 Level Controller EXTERNAL (SYSTEM AND USER) INPUTS X() (m) Vessel Water Level SVT 06 Cbcon(m): Water level set-point X() (kg/sec) Current time step feed-water line mass flowrate (mfw) X() (kg/sec) Current time step steam line mass flow rate (ms) Cbcon(kg/sec): nominal steady state feed-water line mass flowrate EXTERNAL OUTPUT Xout =f (X,X,X C,C) Fig.. Analyzing Water Level Control Function using the GRA Method V. LESSONS LEARNED AND CONCLUSION This paper discussed a modeling method to support software requirements verification and to facilitate traceability analysis of software requirements. The proposed method has the following strengths: o Using a graphical presentation instead of natural language to specify software requirements at various levels of abstraction can reduce inconsistencies, incompleteness, ambiguities and better reveal requirements that are not specified. o A graphical presentation of requirements helps to visualize functional interrelationships between system
6 o requirements and software requirements as well as between stakeholder requirements and software requirements. Even though these topics are not presented in this paper, effectiveness of test cases and impact analyses are an integral part of the model. A future research opportunity to be investigated regarding automation of the GRA method is the link between the proposed method and the current research and development on model-driven software development []. An investigation of how the proposed method can benefit from a stronger integration with the COSMIC-FFP functional size measurement method should also be pursued [6]. ACKNOWLEDGEMENTS In this work Universidad Politécnica de Madrid has been partially supported by the AGMOD project, Ref. TIC00-080, funded by the Ministry of Education of Spain. REFERENCES [] Abran A. and Moore J. W. (Exec. Eds), Bourque P. and Dupuis R. (Eds) "Guide to the Software Engineering Body of Knowledge,", 00 Version, IEEE Computer Society Press and also published as ISO Technical Report 979, 00. [] Groundwater E.H., Miller L.A., Mirsky S.M. Guidelines for the Verification and Validation of Expert System Software and Conventional Software. Survey and Document of Expert System Verification and Validation Methodologies NUREG/CR-66, SAIC-9/08. Vol [] Orlena C.Z., Anthony C.W., Finkelstein. An Analysis of the Requirements Traceability Problem,, [] Jackson, J., A Key-Phrase-Based Traceability Scheme, Tools and Techniques for Maintaining Traceability during Design, IEEE Colloquium, Computing and Control Division, Digest No: 99/80 [] IEEE, Std. 60.: Standard Glossary of Software Engineering Terminology [6] ISO/IEC, ISO/IEC 976: Software Engineering - COSMIC-FFP - A Functional Size Measurement Method, International Organization for Standardization, Geneva, Switzerland. 00. [7] IEEE, Std. 80: Guide to Software Requirements Specification, 998. [8] DoD, Std-67A: U.S. Department of Defense Military Standard: Defense System Software Development, Washington, D.C [9] Modarres M.. Functional Modeling of Complex Systems Using a GTST- MLD Framework. Proceeding of the st International Workshop of Functional Modelling of Complex Technical Systems, Ispra, Italy. 99. [0] Hu Y-S, Modarres M., Applying Fuzzy-Logic-Based Hierarchy for Modelling Behaviours of Complex Dynamic System. System and Software Computing in Nuclear Engineering, Da Ruan ed., Springer- Verlage [] Kececi, N., M. Modarres, and C. Smidts. System Software Interface for Safety-Related Digital I&C Systems, European Safety and Reliability ESREL 99 Conference, TUM Munich- Garching, September -7, 999 [] Sendall, S.; Kozaczynski, W. Model transformation: the heart and soul of model-driven software development. IEEE Software, Vol. 0, No, p.- 00.
3SL. Requirements Definition and Management Using Cradle
3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification
More informationTECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs.
CH04 Capturing the Requirements Understanding what the customers and users expect the system to do * The Requirements Process * Types of Requirements * Characteristics of Requirements * How to Express
More informationMEASURING SOFTWARE FUNCTIONAL SIZE FROM BUSINESS PROCESS MODELS
International Journal of Software Engineering and Knowledge Engineering World Scientific Publishing Company MEASURING SOFTWARE FUNCTIONAL SIZE FROM BUSINESS PROCESS MODELS CARLOS MONSALVE CIDIS-FIEC, Escuela
More informationIT Process Conformance Measurement: A Sarbanes- Oxley Requirement
26 IT Process Conformance Measurement: A Sarbanes- Oxley Requirement Rafik Ouanouki 1, Dr. Alain April 2 1 RONA, Quality Assurance, 220 Chemin du Tremblay, Boucherville, Québec, Canada rafik.ouanouki@rona.ca
More informationRequirements engineering
Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and
More informationSystem Development Life Cycle Guide
TEXAS DEPARTMENT OF INFORMATION RESOURCES System Development Life Cycle Guide Version 1.1 30 MAY 2008 Version History This and other Framework Extension tools are available on Framework Web site. Release
More informationQUALITY TOOLBOX. Understanding Processes with Hierarchical Process Mapping. Robert B. Pojasek. Why Process Mapping?
QUALITY TOOLBOX Understanding Processes with Hierarchical Process Mapping In my work, I spend a lot of time talking to people about hierarchical process mapping. It strikes me as funny that whenever I
More informationSoftware Product Quality Practices Quality Measurement and Evaluation using TL9000 and ISO/IEC 9126
Software Practices Measurement and Evaluation using TL9000 and ISO/IEC 9126 Witold Suryn 1, Alain Abran 2, Pierre Bourque 3, Claude Laporte 4 Department of Electrical Engineering, École de Technologie
More informationPROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >
PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > Date of Issue: < date > Document Revision #: < version # > Project Manager: < name > Project Management Plan < Insert Project Name > Revision History Name
More information8. Master Test Plan (MTP)
8. Master Test Plan (MTP) The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across
More informationAn integrated life cycle quality model for general public market software products
An integrated life cycle quality model for general public market software products Witold Suryn 1, Alain Abran 2, Claude Laporte 3 1 Département de génie électrique, École de technologie supérieure 1100,
More informationTraceability Patterns: An Approach to Requirement-Component Traceability in Agile Software Development
Traceability Patterns: An Approach to Requirement-Component Traceability in Agile Software Development ARBI GHAZARIAN University of Toronto Department of Computer Science 10 King s College Road, Toronto,
More informationU.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN. Organization responsible for the review of instrumentation and controls
U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN NUREG-0800 BRANCH TECHNICAL POSITION 7-14 GUIDANCE ON SOFTWARE REVIEWS FOR DIGITAL COMPUTER-BASED INSTRUMENTATION AND CONTROL SYSTEMS REVIEW RESPONSIBILITIES
More informationDesign Document Version 0.0
Software Development Templates Design Document Version 0.0 Description of Project DOCUMENT NO: VERSION: CONTACT: EMAIL: Ivan Walsh DATE: 4/13/2004 Distribution is subject to copyright. Design Document
More informationDRAFT REGULATORY GUIDE
U.S. NUCLEAR REGULATORY COMMISSION August 2012 OFFICE OF NUCLEAR REGULATORY RESEARCH Division 1 DRAFT REGULATORY GUIDE Contact: K. Sturzebecher (301) 251-7494 DRAFT REGULATORY GUIDE DG-1206 (Proposed Revision
More informationCASS TEMPLATES FOR SOFTWARE REQUIREMENTS IN RELATION TO IEC 61508 PART 3 SAFETY FUNCTION ASSESSMENT Version 1.0 (5128)
CASS TEMPLATES FOR SOFTWARE REQUIREMENTS IN RELATION TO PART 3 SAFETY FUNCTION ASSESSMENT Version 1.0 (5128) Report No. T6A01 Prepared for: The CASS Scheme Ltd By: The 61508 Association All comment or
More informationEffective Business Requirements (Virtual Classroom Edition)
Developing & Confirming Effective Business Requirements (Virtual Classroom Edition) Eliminate Costly Changes and Save Time by Nailing Down the Project Requirements the First Time! Pre-Workshop Preparation
More informationRegulatory Guide 1.169 Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
Regulatory Guide 1.169Configuration Managemen... Page 1 of 10 September 1997 Regulatory Guide 1.169 Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power
More informationIssues in Information Systems Volume 15, Issue I, pp. 52-60, 2014
ORGANIZATIONALLY AGNOSTIC BUSINESS MODELING: HOW TO MAKE BUSINESS ARCHITECTURE ADAPTABLE TO ORGANIZATIONAL CHANGE Carlos E. Martinez, The MITRE Corporation, cmartinez@mitre.org Sheila A. Cane, The MITRE
More informationHow to Craft a World-Class Work Breakdown Structure
How to Craft a World-Class Work Breakdown Structure Laura Miller, PMP laura.miller2@hp.com 1 Copyright Copyright 2012 2012 Hewlett-Packard Development Development Company, Company, L.P. The L.P. information
More informationA Case Study of the Systems Engineering Process in Healthcare Informatics Quality Improvement. Systems Engineering. Ali M. Hodroj
A Case Study of the Systems Engineering Process in Healthcare Informatics Quality Improvement By Ali M. Hodroj Project Report submitted to the Faculty of the Maseeh School of Engineering and Computer Science
More informationHow To Develop Software
Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which
More informationInformation Technology Security Evaluation Criteria. ITSEC Joint Interpretation Library (ITSEC JIL)
S Information Technology Security Evaluation Criteria ITSEC Joint Interpretation Library (ITSEC JIL) Version 2.0 November 1998 This document is paginated from i to vi and from 1 to 65 ITSEC Joint Interpretation
More informationINTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM)
Guide for Integrated Software Quality Management (ISQM) GUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) SEPTEMBER 2012 (Updated July 2014 see next page) American Bureau of Shipping Incorporated
More informationPROJECT PLAN TEMPLATE
Treasury Board of Canada Secretariat Secrétariat du Conseil du Trésor du Canada Enhanced Management Framework for Information Management/Information Technology PROJECT PLAN TEMPLATE Document Revision Draft
More informationSoftware Requirements Specification
1 of 7 17.04.98 13:32 Software Requirements Specification The sub-sections : 1. What is a Software Requirements Specification 2. Why is a Software Requirement Specification Required 3. What is Contained
More information11 Tips to make the requirements definition process more effective and results more usable
1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to
More informationFUNCTIONAL ANALYSIS AND ALLOCATION
Functional Analysis Allocation CHAPTER 5 FUNCTIONAL ANALYSIS AND ALLOCATION 5.1 INTRODUCTION The purpose of this systems engineering process activity is to transform the functional, performance, interface
More informationHow To Write Software
1 Medical Device Software - Software Life Cycle Processes IEC 62304 2 Credits John F. Murray Software Compliance Expert U.S. Food and Drug Administration Marcie R. Williams Medical Device Fellow Ph.D.
More informationHow To Validate Software
General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002 This document supersedes the draft document, "General Principles of Software Validation,
More information<name of project> Software Project Management Plan
The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor
More informationCertification Authorities Software Team (CAST) Position Paper CAST-18
Certification Authorities Software Team (CAST) Position Paper CAST-18 Reverse Engineering in Certification Projects Completed June 2003 (Rev 1) NOTE: This position paper has been coordinated among the
More informationApplications in Business. Embedded Systems. FIGURE 1-17 Application Types and Decision Types
22 CHAPTER 1 Overview of Software Engineering she may determine his or her degree of confidence in the ES's results. These four application types-transaction, query, DSS, and ES-will be referenced throughout
More informationIBM Rational Rhapsody
IBM Rational Rhapsody IBM Rational Rhapsody Reference Workflow Guide Version 1.9 License Agreement No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor translated
More informationCertification Authorities Software Team (CAST) Position Paper CAST-15
Certification Authorities Software Team (CAST) Position Paper CAST-15 Merging High-Level and Low-Level Requirements Completed February 2003 NOTE: This position paper has been coordinated among the software
More informationSoftware Test Plan (STP) Template
(STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This
More informationREGULATORY GUIDE 1.170 (Draft was issued as DG-1207, dated August 2012)
Purpose U.S. NUCLEAR REGULATORY COMMISSION July 2013 Revision 1 REGULATORY GUIDE OFFICE OF NUCLEAR REGULATORY RESEARCH REGULATORY GUIDE 1.170 (Draft was issued as DG-1207, dated August 2012) Technical
More informationProject Risk Management: IV&V as Insurance for Project Success
Project Risk Management: IV&V as Insurance for Project Success Introduction Software development projects can be expensive and risky: Ever more complex mission-critical requirements lead to increasingly
More informationCompliance ow - managing the compliance of dynamic and complex processes
Loughborough University Institutional Repository Compliance ow - managing the compliance of dynamic and complex processes This item was submitted to Loughborough University's Institutional Repository by
More informationHardware safety integrity Guideline
Hardware safety integrity Comments on this report are gratefully received by Johan Hedberg at SP Swedish National Testing and Research Institute mailto:johan.hedberg@sp.se Quoting of this report is allowed
More informationThe SPES Methodology Modeling- and Analysis Techniques
The SPES Methodology Modeling- and Analysis Techniques Dr. Wolfgang Böhm Technische Universität München boehmw@in.tum.de Agenda SPES_XT Project Overview Some Basic Notions The SPES Methodology SPES_XT
More informationOverview of the System Engineering Process. Prepared by
Overview of the System Engineering Process Prepared by Ed Ryen, PE Maintenance ITS March 2008 Introduction This document provides a high level look at the Systems Engineering Process for ITS projects.
More informationSoftware Testing Interview Questions
Software Testing Interview Questions 1. What s the Software Testing? A set of activities conducted with the intent of finding errors in software. 2.What is Acceptance Testing? Testing conducted to enable
More informationThe Role of Information Technology Studies in Software Product Quality Improvement
The Role of Information Technology Studies in Software Product Quality Improvement RUDITE CEVERE, Dr.sc.comp., Professor Faculty of Information Technologies SANDRA SPROGE, Dr.sc.ing., Head of Department
More informationSoftware Requirements
Software Engineering Software Requirements Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce the concepts of user and system requirements To describe functional and
More informationSoftware Design Document (SDD) Template
(SDD) Template Software design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase.
More informationQuantification and Traceability of Requirements
Quantification and Traceability of Requirements Gyrd Norvoll Master of Science in Computer Science Submission date: May 2007 Supervisor: Tor Stålhane, IDI Norwegian University of Science and Technology
More informationR214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM
The American Association for Laboratory Accreditation Document Revised: R214: Specific Requirements: Information Technology Testing Laboratory Accreditation July 13, 2010 Program Page 1 of 26 R214 SPECIFIC
More informationSystem Requirements Specification (SRS) (Subsystem and Version #)
of the (Subsystem and Version #) () (Document Revision Number) Contract (No.) Task (No.) GSA Contract (No.) Prepared for: The United States Department of Agriculture Food & Nutrition Service (FNS)/ Information
More informationELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL
61508-3 ª IEC: 1997 1 Version 12.0 05/12/97 COMMISSION CEI ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL COMMISSION Functional safety of electrical/electronic/ programmable
More informationTeaching Requirements through Interdisciplinary Projects
Teaching Requirements through Interdisciplinary Projects Deepti Suri, Eric Durant Department of Electrical Engineering and Computer Science Milwaukee School of Engineering 1025 North Broadway Milwaukee,
More informationMapping A Knowledge Areas of The SWEBOK Standard With The CBOK in Software Engineering Field Using A Set Theory
Advances in and s Mapping A Knowledge Areas of The Standard With The in Field Using A Set Theory Kenza Meridji Department of Petra University kmeridji@uop.edu.jo Abstract The purpose of this paper is to
More informationCertification Authorities Software Team (CAST) Position Paper CAST-26
Certification Authorities Software Team (CAST) Position Paper CAST-26 VERIFICATION INDEPENDENCE COMPLETED January 2006 (Rev 0) NOTE: This position paper has been coordinated among the software specialists
More informationExample Software Development Process.
Example Software Development Process. The example software development process is shown in Figure A. The boxes represent the software development process kernels. The Software Unit Testing, Software Component
More information1. INTRODUCTION. 23'd Int. Conf. Information Technology Interfaces /TI 2007, June 19-22, 2001, Pula, Croatia
83 The Concept of Quality Information System (QIS) Ninoslav Slavek Faculty of Electrical Engineering and Computing, University of Osijek, Croatia Phone: (0385) 03 1 208 900, e-mail: ninoslav.slavek@etfos.hr
More informationSoftware Error Analysis
U.S. DEPARTMENT OF COMMERCE Technology Admistration National Institute of Standards and Technology Computer Systems Laboratory Gaithersburg, MD 20899 Software Error Analysis NIST Special Publication 500-209
More informationProject Time Management
Project Time Management Study Notes PMI, PMP, CAPM, PMBOK, PM Network and the PMI Registered Education Provider logo are registered marks of the Project Management Institute, Inc. Points to Note Please
More informationAn Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs)
An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs) Rosziati Ibrahim, Siow Yen Yen Abstract System development life cycle (SDLC) is a process uses during the development of any
More informationRequirements engineering and quality attributes
Open Learning Universiteit Unit 2 Learning Unit 2 Requirements engineering and quality attributes Contents Introduction............................................... 21 2.1 Important concepts........................................
More informationSoftware Quality Assurance Plan
For Database Applications Document ID: Version: 2.1a Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 54 Copyright 2000-2006 Digital Publications LLC.
More informationFourth generation techniques (4GT)
Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some
More informationCertification Authorities Software Team (CAST) Position Paper CAST-13
Certification Authorities Software Team (CAST) Position Paper CAST-13 Automatic Code Generation Tools Development Assurance Completed June 2002 NOTE: This position paper has been coordinated among the
More informationInterpreting the Management Process in IEEE/EIA 12207 with the Help of PMBOK
Interpreting the Management Process in IEEE/EIA 12207 with the Help of PMBOK Lewis Gray, Ph.D., PMP Abelia Fairfax, Virginia USA www.abelia.com Copyright 2002 by Abelia Corporation. All rights reserved
More informationONTOLOGY FOR MOBILE PHONE OPERATING SYSTEMS
ONTOLOGY FOR MOBILE PHONE OPERATING SYSTEMS Hasni Neji and Ridha Bouallegue Innov COM Lab, Higher School of Communications of Tunis, Sup Com University of Carthage, Tunis, Tunisia. Email: hasni.neji63@laposte.net;
More informationHow To Write A Contract For Software Quality Assurance
U.S. Department of Energy Washington, D.C. NOTICE DOE N 203.1 Approved: Expires: 06-02-01 SUBJECT: SOFTWARE QUALITY ASSURANCE 1. OBJECTIVES. To define requirements and responsibilities for software quality
More informationLecture 9: Requirements Modelling
A little refresher: What are we modelling? Lecture 9: Requirements Modelling Requirements; Systems; Systems Thinking Role of Modelling in RE Why modelling is important Limitations of modelling Brief overview
More informationAnnouncements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions
Announcements SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 Send your group
More informationChap 1. Introduction to Software Architecture
Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)
More informationCoverage Analysis and Improvement of the Role Definitions of the Bombardier Software Engineering Process
Coverage Analysis and Improvement of the Role Definitions of the Bombardier Engineering Process Pierre Bourque* Youssef Belkebir* Claude Y Laporte* pbourque@ele.etsmtl.ca belkebir_y@iquebec.com claporte@ele.etsmtl.ca
More informationSyllabus. REQB Certified Professional for Requirements Engineering. Foundation Level
Syllabus REQB Certified Professional for Requirements Engineering Version 2.1 2014 The copyright to this edition of the syllabus in all languages is held by the Global Association for Software Quality,
More informationErrata. 133 Figure 5-15 Corrected the output for 8.3 Control Quality to read verified deliverables
Errata NOTE: The following errata only pertain to the first printing of the PMBOK Guide Fifth Edition. In order to verify the print run of your book (or PDF), refer to the bottom of the copyright page
More informationSoftware Engineering. Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti
Software Engineering Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical
More informationSofware Requirements Engineeing
Sofware Requirements Engineeing Three main tasks in RE: 1 Elicit find out what the customers really want. Identify stakeholders, their goals and viewpoints. 2 Document write it down (). Understandable
More informationSTANDARD REVIEW PLAN
NUREG-0800 U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN BRANCH TECHNICAL POSITION 7-14 GUIDANCE ON SOFTWARE REVIEWS FOR DIGITAL COMPUTER-BASED INSTRUMENTATION AND CONTROL SYSTEMS REVIEW RESPONSIBILITIES
More informationJOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,
More informationSurveying and evaluating tools for managing processes for software intensive systems
Master Thesis in Software Engineering 30 Credits, Advanced Level Surveying and evaluating tools for managing processes for software intensive systems Anuradha Suryadevara IDT Mälardalen University, ABB
More informationRevision History Revision Date 3.0 14.02.10. Changes Initial version published to http://www.isasecure.org
SDLA-312 ISA Security Compliance Institute Security Development Lifecycle Assurance - Security Development Lifecycle Assessment v3.0 Lifecycle Phases Number Phase Name Description PH1 Security Management
More informationIntroducing Formal Methods. Software Engineering and Formal Methods
Introducing Formal Methods Formal Methods for Software Specification and Analysis: An Overview 1 Software Engineering and Formal Methods Every Software engineering methodology is based on a recommended
More information2 nd UML 2 Semantics Symposium: Formal Semantics for UML
2 nd UML 2 Semantics Symposium: Formal Semantics for UML Manfred Broy 1, Michelle L. Crane 2, Juergen Dingel 2, Alan Hartman 3, Bernhard Rumpe 4, and Bran Selic 5 1 Technische Universität München, Germany
More informationPROJECT MANAGEMENT METHODOLOGY SECTION 3 -- PLANNING PHASE
PROJECT MANAGEMENT METHODOLOGY SECTION 3 -- PLANNING PHASE Table of Contents Introduction...3-1 Overview...3-1 The Process and the Project Plan...3-1 Project Objectives and Scope...3-1 Work Breakdown Structure...3-1
More informationSTSG Methodologies and Support Structure
STSG Methodologies and Support Structure STSG Application Life Cycle Management STSG utilizes comprehensive lifecycle tools that are fully integrated and provide capabilities for most of the roles in its
More informationCMS Policy for Configuration Management
Chief Information Officer Centers for Medicare & Medicaid Services CMS Policy for Configuration April 2012 Document Number: CMS-CIO-POL-MGT01-01 TABLE OF CONTENTS 1. PURPOSE...1 2. BACKGROUND...1 3. CONFIGURATION
More informationProcedure for Assessment of System and Software
Doc. No: STQC IT/ Assessment/ 01, Version 1.0 Procedure for Assessment of System and Software May, 2014 STQC - IT Services STQC Directorate, Department of Electronics and Information Technology, Ministry
More informationSystem Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director
System Development and Life-Cycle Management (SDLCM) Methodology Subject Type Standard Approval CISSCO Program Director A. PURPOSE This standard specifies content and format requirements for a Physical
More informationSOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT
SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original
More informationA Test Case Generator for the Validation of High-Level Petri Nets
A Test Case Generator for the Validation of High-Level Petri Nets Jörg Desel Institut AIFB Universität Karlsruhe D 76128 Karlsruhe Germany E-mail: desel@aifb.uni-karlsruhe.de Andreas Oberweis, Torsten
More informationKarunya University Dept. of Information Technology
PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main
More informationClarifying a vision on certification of MDA tools
SCIENTIFIC PAPERS, UNIVERSITY OF LATVIA, 2010. Vol. 757 COMPUTER SCIENCE AND INFORMATION TECHNOLOGIES 23 29 P. Clarifying a vision on certification of MDA tools Antons Cernickins Riga Technical University,
More informationLecture 17: Requirements Specifications
Lecture 17: Requirements Specifications Why we need to write specifications Purpose and audience Choosing an appropriate size and formality Desiderata for Specifications Properties of good specifications
More informationAcknowledgement. Software Engineering. CS 3141: Team Software Project Introduction
CS 3141: Team Software Project Introduction Ali Ebnenasir Department of Computer Science Michigan Technological University Acknowledgement Betty H.C. Cheng Software Engineering Systematic approach for
More informationHow To Write Software
Overview of Software Engineering Principles 1 Software Engineering in a Nutshell Development of software systems whose size/ complexity warrants a team or teams of engineers multi-person construction of
More informationEnterprise Architecture Modeling PowerDesigner 16.1
Enterprise Architecture Modeling PowerDesigner 16.1 Windows DOCUMENT ID: DC00816-01-1610-01 LAST REVISED: November 2011 Copyright 2011 by Sybase, Inc. All rights reserved. This publication pertains to
More informationHOW TO CREATE USEFUL SOFTWARE PROCESS DOCUMENTATION ABSTRACT
HOW TO CREATE USEFUL SOFTWARE PROCESS DOCUMENTATION Linda Westfall The Westfall Team lwestfall@westfallteam.com 3000 Custer Road, Suite 270, PMB 383 Plano, TX 75075 ABSTRACT Whether our organization is
More informationRequirements Traceability. Mirka Palo
Requirements Traceability Mirka Palo Seminar Report Department of Computer Science University of Helsinki 30 th October 2003 Table of Contents 1 INTRODUCTION... 1 2 DEFINITION... 1 3 REASONS FOR REQUIREMENTS
More informationStandard Glossary of Terms Used in Software Testing. Version 3.01
Standard Glossary of Terms Used in Software Testing Version 3.01 Terms Used in the Expert Level Test Automation - Engineer Syllabus International Software Testing Qualifications Board Copyright International
More informationQuality Management. Lecture 12 Software quality management
Quality Management Lecture 12 Software quality management doc.dr.sc. Marko Jurčević prof.dr.sc. Roman Malarić University of Zagreb Faculty of Electrical Engineering and Computing Department of Fundamentals
More informationInvestment Analysis using the Portfolio Analysis Machine (PALMA 1 ) Tool by Richard A. Moynihan 21 July 2005
Investment Analysis using the Portfolio Analysis Machine (PALMA 1 ) Tool by Richard A. Moynihan 21 July 2005 Government Investment Analysis Guidance Current Government acquisition guidelines mandate the
More informationRequirements-driven Verification Methodology for Standards Compliance
Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS) serrie@testandverification.com Mike Bartley (TVS) mike@testandverification.com Darren Galpin (Infineon)
More informationAlgorithms, Flowcharts & Program Design. ComPro
Algorithms, Flowcharts & Program Design ComPro Definition Algorithm: o sequence of steps to be performed in order to solve a problem by the computer. Flowchart: o graphical or symbolic representation of
More informationMeasurement Information Model
mcgarry02.qxd 9/7/01 1:27 PM Page 13 2 Information Model This chapter describes one of the fundamental measurement concepts of Practical Software, the Information Model. The Information Model provides
More information