Traceability Requirements Management2 Traceability Systems Engineering STD.

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

Configuration management
Configuration Management
Software Quality Assurance Plan
Presentation by Prabhjot Singh
Traceability James D. Palmer Presented by: Megan Heffernan.
Tracing CS4310 Fall What is Requirements Traceability? The ability to describe and follow the life of a requirement throughout the system lifecycle,
Building Enterprise Applications Using Visual Studio ®.NET Enterprise Architect.
What do Computer Scientists and Engineers do? CS101 Regular Lecture, Week 10.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
WKES 3202 SOFTWARE REQUIREMENTS ENGINEERING SEMESTER 1 SESSION 2004/2005.
Copyright © 2006 Software Quality Research Laboratory DANSE Software Quality Assurance Tom Swain Software Quality Research Laboratory University of Tennessee.
SE 555 Software Requirements & Specification Requirements Management.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Overview of RE techniques RE Techniques Basic Introduction.
Requirements Analysis Concepts & Principles
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
CS 290C: Formal Models for Web Software Lecture 6: Model Driven Development for Web Software with WebML Instructor: Tevfik Bultan.
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Course Instructor: Aisha Azeem
Project Documentation and its use in Testing JTALKS.
Configuration Management
Software Configuration Management
Requirements Engineering
SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY Requirements Traceability Virve Leino QURE Project Software.
Chapter 6– Artifacts of the process
Software Engineering 1 The Life Cicle of Software Lesson 5.
Requirements Expression and Modelling
Project Workflow. How do you do it? -Discussion-
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
Software Requirements Engineering CSE 305 Lecture-2.
Configuration Management (CM)
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
1 Introduction to Software Engineering Lecture 1.
KS3 Phase4 Client Server Monitoring System October 1, 2008 by Stephen, Seema, Kam, Shpetim.
Information Systems Engineering. Lecture Outline Information Systems Architecture Information System Architecture components Information Engineering Phases.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
ANKITHA CHOWDARY GARAPATI
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
 Dr. Syed Noman Hasany.  Review of known methodologies  Analysis of software requirements  Real-time software  Software cost, quality, testing and.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Requirements Engineering
Assoc. Prof. Dr. Ahmet Turan ÖZCERİT.  The concept of Data, Information and Knowledge  The fundamental terms:  Database and database system  Database.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
Software Requirements Specification Document (SRS)
Requirements Analysis
Software Engineering Lecture 10: System Engineering.
Software Test Plan Why do you need a test plan? –Provides a road map –Provides a feasibility check of: Resources/Cost Schedule Goal What is a test plan?
2009 copyright Leslie Munday University Requirements Management and Traceability For IIBA By Leslie Munday.
Design Evaluation Overview Introduction Model for Interface Design Evaluation Types of Evaluation –Conceptual Design –Usability –Learning Outcome.
1 Software Requirements Descriptions and specifications of a system.
 System Requirement Specification and System Planning.
Building Enterprise Applications Using Visual Studio®
Chapter 11: Software Configuration Management
Software Requirements
Trace requirements. What do we mean by the term “Trace”? Why should we trace? 2 Requirements Life Cycle Management Trace Requirements.
HCI in the software process
Engineering Processes
HCI in the software process
Chapter 11: Software Configuration Management
Introduction to Systems Analysis and Design Stefano Moshi Memorial University College System Analysis & Design BIT
HCI in the software process
Engineering Processes
Human Computer Interaction Lecture 14 HCI in Software Process
Presentation transcript:

Traceability Requirements Management2 Traceability Systems Engineering STD

Contents Terminologies Techniques A model of traceability Tools : case study (RTM, Slate, DOORS : what will be available at HPI !!)

What specific to Traceability in Req. Management ? Traceability increase software quality throughout the life of the project Most important issue in RM Many facets of Soft.Eng. Can be improved through RT Standard 2167A (US DoD)

A recent event : Mad cow and Hamburger !! ?

Terminologies Part of requirement management process Technique to provide relationship between requirement design and final implementation How and why system development products satisfy stakeholders requirements Ability to discover the history of every feature of a system A quality factor Many standards (2167-A then 498) require the development of traceability documents

Techniques Objectif : get all links during lifecycle of requirement Link to stakeholders Associated design Associated implementation Validation procedure Concept of operation Etc...

Techniques Cross reference schemes Keyphrase dependancy Templates Matrices Matrix sequence Hypertext Integration documents All differs in the intent of information traced and objective of tracing

Essence of traceability Of What (information) In what way (information prsentation) For whom Example : Who coded the program Who : we need the programmer What way : name, the company, the team ? For whom : to whom this information is addressed (not anybody can have any information : information abstraction and... Security)

Traceability Matrix Used to relate requirements to others software developments artifacts Spec.Si Req R1 R2 Rn Design Di S/w modules X X : relational link between a requirement and a design N/A : Non applicable (no apparent link) N/A The relation can be allocatted a type

Cross references and index schemes References made across several items (design, modules, requirements,..) in order to link two items or artifacts. Example : There should be a high-level of traceability between "Logical Architecture" and "Physical Architecture" The logical and physical architecture are tied together with a collection of cross-reference tables in the "Traceability Matrix"

Tracing languages Database query languages Used in existing powerfull RT tools (RTM use runtime version of Oracle) Regular expressions Used in formal TOOR approach TOOR -is designed for tracing requirements in system development. -It considers as objects, in the computing science sense of the word, any artifacts used during the development of a software system, e.g., an interview transcript, a video tape, a design chart, a program specification text, a system manual, etc. -It also considers the possible relations between any two objects as an object itself

Tracing Process and models Trace definition : precise semantic (formalising links between objects) Trace production : results of action (ideally : automated tracing production) Trace model : link between classes dont give exact purpose of the link Trace extraction : What are the requirement that are linked to a specific software; or what are the software modules linked to a specific requirement Traceability support : A huge amount of information to manage

TOOR. A formal approach Developped at Oxford (Goguen, Pinheiro) Object based ( see RTM tool too ) Declaration using FOOP (based on OBJ) Traceability links between any artifacts created by different documents Graphical interface Tracing are forward and backward

TOOLS : RTM Requirements Traceability Module (Chipware) Other tools : DOORS (telelogic), Slate (QSS) Essential approach A generic meta model All links are specified in the relation between between classes Document generation Can be customised to any meta-model defined by user

A model of traceability

Separation between source and other objects - -Doc - phone call -Meeting minutes - A Requirement - A Designed architecture - A software module - A manager - A user - A programmer

A model of traceability

Dependancy links issues Existence of a link and its meaning Stakeholders dependencies Requirements dependancies : a requirement is based on the assumption on satisfaction of another requirements : the software can be coded in C only if here is available compiler on operating systems imposed in another requirement Task dependencies Resource dependancies Temporal dependancies (temporal order)

Relative importance of dependancy links Attribution of weight on on link Qualitative Quantitative Example : The voltage change in one component affect another component Links can be many levels of abstraction Requirement and derived rtequirement Requirement and stackholder Not injective or surjective relation

Conclusions A model of traceability should be defined A need for a tool Two way to implement the tool Specific tool for RT A database system as Oracle.

Conclusions and recommendations State of the art and limitations All approaches require a great deal of manual effort to define the links All rely on purely syntactic information with no semantic or context capture situations where many people participate Capture changing patterns of participants

Conclusions and recommendations Informational problem Tracking useful information Inadequate prerequirement traceability Informal communication People attach great importance to personal contact and informal communication These always supplement what is recorded in database Traceability links database tells only a part of the story Finding the appropriate people

Conclusions and recommendations Involvement Who has been involved in the production of a requirement and how Responsibility Who is responsible for a specific requirement Who is currently responsible Context in defining change of responsibility Change At what point in the life of a requirement a need for a change is possible Who needs to be informed by a change

Conclusions and recommendations Loss of a knowledge What are the items regarding the loss of a project knowledge due to turnover over concerned personnel Others Verification and validation Maintenance Coverage (types of links)

Next lecture Validation and Verification Requirements management Traceability

Paper Reading and assignments Paper reading Mandatory : Traceability : IEEE Trans jan 2001 by Jark & Ramesh Other : see list paper reading assignment