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.

Slides:



Advertisements
Similar presentations
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 1.
Advertisements

What is an M and E Plan?. Organizing the Work of M and E An M and E System -- the 12 components as a whole – Sets out broad vision at national level An.
System Integration Verification and Validation
1 Software Testing and Quality Assurance Lecture 13 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
Chapter 4 Quality Assurance in Context
The Islamic University of Gaza
1 Chapter 4 The Software Team Requisite’s 6 team skills for effective requirements management.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
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 (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
SE 555 Software Requirements & Specification Requirements Management.
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.
1 Systems V & V, Quality and Standards Dr Sita Ramakrishnan School CSSE Monash University.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Recall The Team Skills Analyzing the Problem
Software Quality Assurance For Software Engineering && Architecture and Design.
Tracing Requirements 1. The Role of Traceability in Systems Development  Experience has shown that the ability to trace requirements artifacts through.
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
SEG Software Maintenance1 Software Maintenance “The modification of a software product after delivery to correct faults, to improve performance or.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
What is Business Analysis Planning & Monitoring?
Copyright © Craig Larman All Rights Reserved Requirements.
Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013.
Why use RequisitePro RequisitePro is a comprehensive tool that supports any of today's requirements management processes. The predominant requirements.
Karolina Muszyńska. Reverse engineering - looking at the solution to figure out how it works Reverse engineering - breaking something down in order to.
Chapter 2 소프트웨어공학 Software Engineering 임현승 강원대학교
Software Software is omnipresent in the lives of billions of human beings. Software is an important component of the emerging knowledge based service.
Software Quality Assurance SE Software Quality Assurance What is “quality”?
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
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.
Notes of Using RequisitePro cyt. 2 Type of user –Requirements viewers –Requirements contributors –Requirements authors –Project administrator Rational.
Traceability, Change and Quality – Chapters Requirements Text Steve Chenoweth & Chandan Rupakheti RHIT Question 1.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
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.
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.
Verification and Validation Assuring that a software system meets a user's needs.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
 Dr. Syed Noman Hasany.  Review of known methodologies  Analysis of software requirements  Real-time software  Software cost, quality, testing and.
Requirements Engineering
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with the IBM Rational Software Architect, V7.5 Module 15: Traceability and Static Analysis.
Essentials of Modeling with IBM Rational Software Architect V7.5
1 Lecture 12: Chapter 16 Software Quality Assurance Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides.
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.
Refining the Use Cases 1. How Use Cases Evolve  Early efforts typically define most of the major use cases.  The refining stages complete the process.
CI R1 LCO Review Panel Preliminary Report. General Comments –Provide clear definition of the goals of the phase (e.g. inception), the scope, etc. in order.
Traceability, Change and Quality – Chapters Requirements Text Sriram Mohan/Steve Chenoweth.
Chapter 8-1 Chapter 8 Accounting Information Systems Information Technology Auditing Dr. Hisham madi.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Your Prescription for Requirements Management 1. Assumptions The prescription for requirements management is based on the following assumptions:  The.
Software Quality Control and Quality Assurance: Introduction
Chapter 10 Software Quality Assurance& Test Plan Software Testing
The Systems Engineering Context
Recall The Team Skills Analyzing the Problem
Chapter 2 Software Engineering
Recall The Team Skills Analyzing the Problem (with 5 steps)
Software Testing and Maintenance Maintenance and Evolution Overview
Traceability – Chapter 27
Designing Scalable Architectures
Presentation transcript:

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 Definition 6. Building the Right System From Use Cases to Implementation From Use Cases to Test Cases Tracing Requirements Managing Change Assessing Requirements Quality

Chapter 27 Tracing Requirements  Role of traceability  Definition  Traceability model  Traceability matrix

The Role of Traceability in Systems Development  Definition of traceability: "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." (IEEE )  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 software implementation.

The Traceability Relationship  A traceability relationship is a relationship between two project elements.  A traceability relationship is a type of dependency relationship between elements.  A dependency relationship states that a change in one element (A) may affect another element (B), but the reverse is not necessarily true.

Traceability Link from Vision Document to Software Requirement

A Generalized Traceability Model

Traceability Matrix: User Needs versus Features

 after you've established all known need–feature relationships, you should once again examine the traceability matrix for potential indications of error.  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.  If inspection of a column fails to detect any Xs, a possibility exists that a feature has been included for which there is no defined product need.

Using Traceability Tools  Offer a simple user-guided procedure to "point and click" through the explicit relationships that may exist between two elements of the lifecycle.  Allow building large matrices required for more sophisticated projects and to examine the data automatically for many of the types of potential red flags.  Provide support for some of the implicit forms of traceability (e.g. use case to use-case realization), and provide navigational mechanisms and other methods to help assure that the implementation is correct as the application evolves.

Proceeding without Traceability Tools  Many of the matrix relationships could be easily handled with a spreadsheet.  The problem with spreadsheets, however, is maintenance, especially in extensive hierarchies of relationships.  The other alternative is to use a database.

Key Points  Requirements traceability is a proven technique that can increase the quality and reliability of software.  Traceability is mandated in certain high- assurance software development environments.  Traceability extends from user needs to product features to use cases and supplementary requirements, and from there to implementation and testing.  The value and cost of traceability varies with project context and available tooling.