Tracing CS4310 Fall 2012. What is Requirements Traceability? The ability to describe and follow the life of a requirement throughout the system lifecycle,

Slides:



Advertisements
Similar presentations
Traceability Requirements Management2 Traceability Systems Engineering STD.
Advertisements

Configuration Management
Requirements Specification and Management
More CMM Part Two : Details.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Traceability James D. Palmer Presented by: Megan Heffernan.
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Software Requirements
1 Software Requirement Analysis Deployment Package for the Basic Profile Version 0.1, January 11th 2008.
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
Unit 211 Requirements Phase The objective of this section is to introduce software system requirements and to explain different ways of expressing these.
Unit 191 Introduction to Software Engineering The objective of this section is to introduce the subject of software engineering. When you have read this.
SE 555 Software Requirements & Specification Requirements Management.
Information Systems Development Lecture 2: the idea of the Life Cycle.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
SE 555 Software Requirements & Specification Requirements Validation.
1 Software Requirements Specification Lecture 14.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
NASA Space Launch System (SLS) Independent Verification and Validation (IV&V) Analysis Processes within Enterprise Architecture (EA) September 11, 2013.
Software Configuration Management
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
Engineering Systems of.
Chapter 4 Requirements Engineering
S/W Project Management
RUP Requirements RUP Artifacts and Deliverables
Software Requirements Specification (SRS) Complete description of external behavior of software system Complete description of external behavior.
Requirements Analysis
ITEC 370 Lecture 5 Requirements. Review Requirements –What did you learn? –Why are requirements part of the process? –What is the difference between a.
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Software Configuration Management (SCM)
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
Feasibility Study.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
Requirements Verification & Validation Requirements Engineering & Project Management.
IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS LECTURER : NOUF ALMUJALLY 22 – 10 – 2011 College Of Computer Science and Information, Information Systems.
[ §5 : 1 ] 5. Summary of Requirements Products 5.1 Requirements Definition Document 5.2 Software Requirements Specification.
John D. McGregor Session 2 Preparing for Requirements V & V
Approaching a Problem Where do we start? How do we proceed?
KS3 Phase4 Client Server Monitoring System October 1, 2008 by Stephen, Seema, Kam, Shpetim.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
Develop Project Charter
Requirements Specification. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification”
Chapter 4 Software Requirements
 Dr. Syed Noman Hasany.  Review of known methodologies  Analysis of software requirements  Real-time software  Software cost, quality, testing and.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Requirements Engineering
Architectural Compentency.  Business Success  How do you measure success ◦ backwards looking – derived from history? ◦ is it forward looking? – ability.
Software Requirements Specification (SRS)
Software Requirements Specification Document (SRS)
Software Engineering Lecture 10: System Engineering.
Describing MCM Mission Package Software Interoperability with Architectural Descriptions.
CS 4311 Software Design and Implementation Spring 2012.
CS 4311 Software Design and Implementation Spring 2013.
2009 copyright Leslie Munday University Requirements Management and Traceability For IIBA By Leslie Munday.
 System Requirement Specification and System Planning.
An Overview of Requirements Engineering Tools and Methodologies*
Scope Planning.
Chapter 11: Software Configuration Management
IEEE Std 1074: Standard for Software Lifecycle
Systems Analysis and Design
Trace requirements. What do we mean by the term “Trace”? Why should we trace? 2 Requirements Life Cycle Management Trace Requirements.
Defining the Activities
Software Requirements analysis & specifications
Test Planning Mike O’Dell (some edits by Vassilis Athitsos)
Chapter 11: Software Configuration Management
Lecture # 7 System Requirements
Presentation transcript:

Tracing CS4310 Fall 2012

What is Requirements Traceability? The ability to describe and follow the life of a requirement throughout the system lifecycle, in both forward and backward directions.

DoD Std 21267A The document in question contains or implements all applicable stipulations of the predecessor document A given term, acronym, or abbreviation means the same thing in all documents A given item or concept is referred to by the same name or description in the documents All material in the successor document has its basis in the predecessor document, that is no untraceable material has been introduced The two documents do not contradict one another

Artifacts Pairs: What artifacts can be used for tracing, 3 minutes. Think of the following stages: Elicitation Specification Construction

Artifacts Elicitation –Interview report –Requirement specification –Memos, conversations, Specification –SRS Construction –Design models –Code –Test plan

Tracing An SRS is traceable if it is written to facilitate referencing individual requirements.

Tracing An SRS is traceable if it is written to facilitate referencing individual requirements. Take some feature of design and map it through the SRS to the source of the requirement.

Tracing An SRS is traceable if it is written to facilitate referencing individual requirements. Take some feature of design and map it through the SRS to the source of the requirement. How: careful and complete numbering of the sections and elements of the SRS.

Tracing An SRS is traceable if it is written to facilitate referencing individual requirements. Take some feature of design and map it through the SRS to the source of the requirement. How: careful and complete numbering of the sections and elements of the SRS. An SRS is traced if a flow up path can be identified between a requirement in the SRS and system level requirements in a statement of need or some other artifact ( , meeting notes, etc).

Tracing For any feature of the deliverable, –Trace to its initial source –Trace to its ultimate implementation

Types of tracing Pairs: Name four types of tracing

Types of tracing A. Forward from requirements B. Backward to requirements C. Forward to requirements D. Backward from requirements SRS C. A. D. B. ELICITATION ARTIFACTS CONSTRUCTION ARTIFACTS

Benefits V&V Align business needs with software being developed Reduce risk by capturing knowledge vital to project success Determine impact of change to requirements Support process improvement Conflict detection and resolution

Tracing helps QA/QC everything must be verified goals of verification –results may not be binary –verification may be objective or subjective

When? Continuously. –Initially Interview, prototype –Elaboration Architecture –Construction Unit testing, verification –Maintenance

Secrets Trace continuously Understand why traceability is important Have a strategy

Problems It’s hard to do: manual links Benefits frequently not seen until later Difficult to measure return on investment

Requirements Management Requirements management is the set of activities that help the project team to identify, control, and track requirements and changes to requirements at any time as the project proceeds. Requirements management begins with the identification of requirements.

Requirements Management- Identification Each requirement is assigned a unique identify that might take the form: – artifact-identifier: code that identifies the artifact. –e.g., FR for Feasibility Report, SRS for Software Requirements Specification, IR for Interview Report, M for Memoranda dated 11/10/2005. internal-identifier: code that references a section, a requirements number, or some other part of the document. –The internal identifier should allow someone to locate the information easily.

Traceability Tables Possible types of traceability tables include: –Features traceability table –Source traceability table –Dependency traceability table –Subsystem traceability table –Interface traceability table

Traceability Tables Features traceability table: -Shows how requirements relate to important customer observable system/product features. Source traceability table: -Identifies the source of each requirement. Dependency traceability table: -Indicates how requirements are related to one another.

Traceability Tables Subsystem traceability table: -Categorizes requirements by the subsystem(s) that they govern. Interface traceability table: -Shows how requirements related to both internal and external system interfaces.

Source Traceability SRS Requirements IRProtoMemo 1……Artifact n req1 req2xx … xx x x …xxx reqnx Sources