Tracing Requirements 1. The Role of Traceability in Systems Development  Experience has shown that the ability to trace requirements artifacts through.

Slides:



Advertisements
Similar presentations
Design by Contract.
Advertisements

System Integration Verification and Validation
Software Quality Assurance Plan
1 SOFTWARE TESTING Przygotował: Marcin Lubawski. 2 Testing Process AnalyseDesignMaintainBuildTestInstal Software testing strategies Verification Validation.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
© ABB AB, Corporate Research - 1 5/19/2015 abb Project Breakdown Structure Creation.
Requirements Elicitation Techniques
7.1 A Bridge to Design & Construction
1 Software Requirement Analysis Deployment Package for the Basic Profile Version 0.1, January 11th 2008.
Overview Lesson 10,11 - Software Quality Assurance
The Architecture Design Process
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
Analysis Concepts and Principles
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
1 Case Study: Starting the Student Registration System Chapter 3.
Recall The Team Skills Analyzing the Problem
 QUALITY ASSURANCE:  QA is defined as a procedure or set of procedures intended to ensure that a product or service under development (before work is.
Software Process and Product Metrics
Functional Testing.
What is Business Analysis Planning & Monitoring?
1 ‘Title’ Deployment Package for Profile X Version X – Month-Day-20XX.
AICT5 – eProject Project Planning for ICT. Process Centre receives Scenario Group Work Scenario on website in October Assessment Window Individual Work.
Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013.
1 Chapter Eight Exception Handling. 2 Objectives Learn about exceptions and the Exception class How to purposely generate a SystemException Learn about.
CPIS 357 Software Quality & Testing I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
Quality Control Project Management Unit Credit Value : 4 Essential
John D. McGregor Session 2 Preparing for Requirements V & V
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
GRASP: Designing Objects with Responsibilities
Actors and Use Case Diagrams Month Day, Year. Agenda Training Plan Overview Review Detailing Requirements with Requisite Pro Concepts Setting Up XDE Integration.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
UML as a Specification Language for Embedded Systems. By, Mir Ahmed Ali, Asst. Professor, ECM department, SNIST. By, Prof. Narsiah sir, Director of School.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Software Testing Definition Software Testing Module ( ) Dr. Samer Odeh Hanna.
Project Quality Management.  Define project quality management.  Describe quality planning and its relationship to project scope management.  Discuss.
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.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Requirements Engineering
Lecture 13.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Notes Over 4.2 Finding the Product of Two Matrices Find the product. If it is not defined, state the reason. To multiply matrices, the number of columns.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
OSLC PLM Workgroup1 Towards detailed use cases and alignment to OSLC V0.1 Gray Bachelor 18 th July 2011.
Getting started with Accurately Storing Data
Change Request Management
Testability.
Requirements Elicitation Techniques
Software Verification and Validation
Architecture Concept Documents
Recall The Team Skills Analyzing the Problem
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
BASICS OF SOFTWARE TESTING Chapter 1. Topics to be covered 1. Humans and errors, 2. Testing and Debugging, 3. Software Quality- Correctness Reliability.
Recall The Team Skills Analyzing the Problem (with 5 steps)
Chapter 24 Testing Object-Oriented Applications
Chapter 19 Testing Object-Oriented Applications
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Software Verification, Validation, and Acceptance Testing
Chapter 19 Testing Object-Oriented Applications
Traceability – Chapter 27
AICT5 – eProject Project Planning for ICT
From Use Cases to Implementation
Presentation transcript:

Tracing Requirements 1

The Role of Traceability in Systems Development  Experience has shown that the ability to trace requirements artifacts through the stages of specification, architecture, design, implementation, and testing is a significant factor in assuring a quality product.  Software developed in many areas for certain customers may have mandated traceability requirements (e.g. the FDA). 2

Definition of Traceability  According to IEEE [1994] traceability is: “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.” “The degree to which each element in a software development product establishes its reason for existing; for example, the degree to which each element in a bubble chart references the requirement it satisfies.” 3

The Traceability Relationship  A traceability relationship is a dependency relationship between two project elements. A B traces Element B is in some way Dependent on element A 4

The Traceability Relationship (Cont’d)  A dependency relationship states that a change in one element (e.g., a use case) may affect another element (e.g., a test case), but the reverse is not necessarily true.  Additional meanings associated with the traces (or traced by) relationship can be inferred from the context. E.g., in the previous example, the relationship infers that the use case is “tested by” the test case. 5

A Generalized Traceability Model Stakeholder Need Product Feature Supplementary Requirements Use Case Test Cases Use-Case Realization Implementation System Definition System Test traces 6

Tracing Requirements in the System Definition Domain  This is called requirement-to- requirement traceability.  It includes: Tracing user needs to features Tracing features to use cases Tracing features to supplementary requirements 7

Tracing User Needs to Features Traceability Matrix: User Needs versus Features Feature 1Feature 2...Feature n Need 1 X Need 2 XX … XX Need m X 8

Examining the Traceability Matrix for Possible Errors  If inspection of a row fails to detect any Xs, a possibility exists that no feature is yet defined to respond to a user need. This might be acceptable, but it raises a red flag.  If inspection of a column fails to detect any Xs, possibility exists that a feature has been included for which there is no defined product need.  The traceability matrix can be helpful when changes in user needs occur. 9

Tracing Features to Use Cases  It is important to ensure that the features can be related to the use cases proposed for the system.  A matrix similar to the Needs versus Features matrix can be used. 10

Tracing User Needs to Features Traceability Matrix: Features versus Use Cases Use Case 1Use Case 2...Use Case k Feature 1 XX Feature 2 XX … X Feature n XX 11

Examining the Traceability Matrix for Errors  If inspection of a row fails to detect any Xs, a possibility exists that no use case is yet defined to respond to a feature. This is a red flag.  If inspection of a column fails to detect any Xs, a possibility exists that a use case has been included for which there is no known feature that requires it. That is, this use case may not be required. 12

Tracing Features to Supplementary Requirements Traceability Matrix: Features versus Supplementary Requirements Supplementary Requirement 1 Supplementary Requirement 2...Supplementary Requirement p Feature or Sys Req 1 XX Feature or Sys Req 2 XX … XX Feature or Sys Req j X 13

Tracing Requirements to Implementation  First we trace use cases to use case realizations as we did before.  We then follow the traceability relationship to the component parts of the use case realization, the classes (code).  We must do something similar for supplementary requirements. In this case we trace the requirements to a collaboration (which we need to name since it doesn’t come from a use case). See next slide. 14

Tracing Supplementary Requirements to Implementation Sync Clock > Requirements - The clocks shall... - Every 24 hours... - Synchronization occurs... Design Model Collaboration Participating classes 15

Tracing from Requirements to Testing  A comprehensive approach to testing is to assure that every use case is tested by one or more test cases.  In fact, each possible scenario for a use case needs to be tested by one or more test cases.  We can create a traceability matrix that maps use cases to test cases.  Requirements that are not expressed as use cases are either traced individually to scenarios and test cases or grouped into “requirements packages” that operate in the same logical fashion as use cases. 16

Traceability Matrix for Use Cases to Test Cases Use CaseScenario NumberTest Case ID Control Light Run Vacation Profile

Mechanisms for Managing Traceability Matrices  For a large project creating and managing the traceability matrices can be an overwhelming task due to the problems of correctly updating the information when changes (e.g., to requirements) occur. Mechanisms to help include: Spreadsheets Relational Data Bases Specialized Traceability Management Tools 18