1 / 79

Requirements Validation and Verification

Requirements Validation and Verification. Based on the slides by Luiz Cysneiros , Steve Easterbrook, Sotirios Liaskos , Gregor Bochmann , and Gunter Mussbacher. Overview V&V (Recap). Goals, Needs. At this point: have a specification document w/ text and models Requirements Validation:

stearn
Download Presentation

Requirements Validation and Verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Validation and Verification Based on the slides by Luiz Cysneiros, Steve Easterbrook, SotiriosLiaskos, Gregor Bochmann, and Gunter Mussbacher ITEC 4040 Requirements Management, Winter 2017

  2. Overview V&V (Recap) Goals,Needs • At this point: have a specification document w/ text and models • Requirements Validation: • “Are we building the right system?” • Do our requirements specs accurately capture the real problem – stakeholder goals, needs? • Did we account for the needs of all the stakeholders? • Checks the SRS against stakeholder goals and requirements • Requirements Verification: • “Are we building the system right?” • Does our design meet the specification? • Does our implementation meet the spec? • Does the delivered system do what we said it would do? • Are our requirements models consistent with one another? • Checks consistency of SRS artefacts and other software development products (design, implementation) against the specification RequirementsSpecification Validation Verification Design [Steve Easterbrook] System ITEC 4040 Requirements Management, Winter 2017

  3. Refresher: V&V Criteria [Adapted from M. Jackson (1995) by S. Easterbrook] Shared Phenomena Application Domain (AD) Machine Domain (MD) • Some definitions: • D – Things in the AD that are true anyway • R – Things in the AD that we wish to be made true • S – Description of the behaviours the program must have in order to meet the requirements • Two verification criteria: • The Program running on a particular Computer satisfies the Specification • The Specification, given the Domainproperties, satisfies the Requirements • Two validation criteria: • Did we discover (and understand) all the important Requirements? • Did we discover (and understand) all the relevant Domainproperties? C - computer D - domain properties P - program R - requirements ITEC 4040 Requirements Management, Winter 2017

  4. V&V Example (Review) • Example: • Requirement R: • “Reverse thrust shall only be enabled when the aircraft is moving on the runway” • Domain Properties D: • Wheel pulses on if and only if wheels turning • Wheels turning if and only if moving on runway • Specification S: • Reverse thrust enabled if and only if wheel pulses on • Verification • Does the flight software, P, running on the aircraft flight computer, C, correctly implement S? • Does S, in the context of assumptions D, satisfy R? • Validation • Are our assumptions, D, about the domain correct? Did we miss any? • Are the requirements, R, what is really needed? Did we miss any? ITEC 4040 Requirements Management, Winter 2017

  5. Formal Requirements V&V • Evaluating the satisfaction of “D and S  R” is difficult with natural language • Descriptions are verbose, informal, ambiguous, incomplete, etc. • This represents a risk for the development and organization • Verification of this “validation question” is more effective with formal methods • Based on mathematically formal syntax and semantics • Proving can be tool-supported • Depending on the modeling formalism used, different verification methods and tools may be applied • Can call this “Model-Based V&V” • In the case of the aircraft example, Logic was used to write down statements about the model – this is a particular example of modeling formalism • Normally apply formal V&V to complete requirements specifications ITEC 4040 Requirements Management, Winter 2017

  6. Methods for Requirements V&V • Validation • Prototyping • Informal Walkthrough • Formal Inspection/Walkthrough • Animation • Verification • Formal Inspection • Traceability • Testing • Model-based V&V techniques (first-order logic, behavioural models) ITEC 4040 Requirements Management, Winter 2017

  7. Note similarity with process of scientific investigation: Requirements models are theories about the world; Designs are tests of those theories Initial hypotheses Look for anomalies - what can’t the current theory explain? Design experiments to test the new theory Carry out the experiments (manipulate the variables) Create/refine a better theory Inquiry Cycle in RE Prior Knowledge (e.g. customer feedback) Observe (what is wrong withthe current system?) Intervene (replace the old system) Model (describe/explain theobserved problems) Design (invent a better system) ITEC 4040 Requirements Management, Winter 2017

  8. (what is wrong withthe model?) (what is wrong withthe prototype?) Check propertiesof the model Get users to try it Analyzethe model Build aPrototype Shortcuts in the Inquiry Cycle Prior Knowledge (e.g. customer feedback) Observe (what is wrong withthe current system?) Intervene (replace the old system) Model (describe/explain theobserved problems) Design (invent a better system) ITEC 4040 Requirements Management, Winter 2017

  9. Validation in Requirements • Early Validation: Informal Walkthrough • Use scenarios and mock-ups and/or working prototypes • Present the mock-ups while going through the scenarios • Optative (to-be) scenarios are used for requirements validation • Storyboards can be used as well • Late Validation: Formal Walkthroughs and Inspections • Read a specification document in an organized way • Try to find errors, inconsistencies, incompleteness (requirements that are missing) and redundancies (requirements that are not needed) ITEC 4040 Requirements Management, Winter 2017

  10. Scenario Validation • Can validate scenarios with users using semi-structured interviews (other techniques possible too) • Strategies • Read scenarios aloud together with users • Ask if they have anything to add or change • Ask Why ITEC 4040 Requirements Management, Winter 2017

  11. Storyboards • Purpose – gain early reaction from the users (and other stakeholders) on the concepts proposed for the product • Can help elicit and document the “Yes, but…” reactions • Identify actors, explain what happens to them and describe how it happens • Effective for projects with innovative or unknown content • Inexpensive, user-friendly, informal, (frequently) interactive, easy to create/change ITEC 4040 Requirements Management, Winter 2017

  12. Storyboards - Types • Passive storyboards • Tell a story to the user • Consist of pictures, static screens, reports, or sample application outputs • Guide the user through the story, while explaining what happens • Active storyboards • Automatically describe how the system behaves in a typical scenario of use • Can have presentations (e.g., PowerPoint), animation, simulation • Interactive storyboards • Let the user experience the system • Basic demo or interactive presentation ITEC 4040 Requirements Management, Winter 2017

  13. Storyboards - Continuum Passive Active Interactive Presentation Screen Prototype Animation Demo Pictures Simulation Interactive Presentation Reports Complexity and cost ITEC 4040 Requirements Management, Winter 2017

  14. Prototypes in Requirements • Help elicit reactions, e.g.: • Yes, but… • Now that I can see it working, it comes to me that I also need… • Etc. • Help clarify fuzzy requirements • Not well defined or understood ITEC 4040 Requirements Management, Winter 2017

  15. Prototyping “A software prototype is a partial implementation constructed primarily to enable customers, users, or developers to learn more about a problem or its solution.” [Davis, 1990] “Prototyping is the process of building a working model of the system” [Agresti, 1986] • Approaches to prototyping • Presentation Prototypes • Used for proof of concept; explaining design features; etc. • Explain, demonstrate, and inform – then they are thrown away • Exploratory Prototypes • Used to identify problems, elicit needs, clarify goals, compare design options • Informal, unstructured and thrown away • Experimental Prototypes • Explore technical feasibility; test suitability of a technology • Typically no user/customer involvement • Evolutionary (e.g., “operational prototypes”, “pilot systems”) • Development seen as continuous process of adapting the system • “Prototype” is an early deliverable, to be continually improved • MVP, agile development methods ITEC 4040 Requirements Management, Winter 2017

  16. Prototypes: Throwaway • Frequently – horizontal • Implements a large portion of the functionality • Purpose • Learn more about the problem or its solution • Discard after desired knowledge is gained • Use • Early or late • Approach • Horizontal - build only one layer (e.g., UI) • “Quick and dirty” • Advantages • Cheap, can have bugs • Learning medium for better convergence • Early delivery  early testing  less cost • Successful even if it fails! • Disadvantages • Wasted effort if requirements change rapidly • Often replaces proper documentation of the requirements • May set customers’ expectations too high • Can get developed into final product ITEC 4040 Requirements Management, Winter 2017

  17. Prototypes: Evolving • Frequently – Vertical • Implements a few functions better • Purpose • Learn more about the problem or its solution… • …and reduce risk by building parts early • Use • Incremental, evolutionary • Approach • Vertical – partialimplementation of all layers • Designed to be extended/adapted • Advantages • Supports changing requirements • Return to last increment if error is found • Cheaper = you’re not throwing the effort away • Disadvantages • Can end up with complex, unstructured system that is hard to maintain • Early architectural choice may be poor • Optimal solutions not guaranteed • Lacks control and direction ITEC 4040 Requirements Management, Winter 2017

  18. Requirements Review Types • Different types of reviews with varying degrees of formality exist (similar to JAD vs. brainstorming sessions) • Both for validation and verification! • Reading the document • A person other than the author of the document • Reading and approval (sign-off) • Encourages the reader to be more careful (and responsible) • Walkthroughs • Informal, often high-level overview • Can be led by author/expert to educate others on his/her work • Formal inspections • Very structured and detailed review, defined roles for participants, preparation is needed, exit conditions are defined • E.g., Fagan Inspection • Focused inspections • Reviewers have roles, each reviewer looks only for specific types of errors ITEC 4040 Requirements Management, Winter 2017

  19. Problem Categories in Requirements • Requirements clarification • The requirement may be poorly expressed or may have accidentally omitted information which has been collected during requirements elicitation • Missing information • Some information is missing from the requirements document • Requirements conflict • There is a significant conflict between requirements • The stakeholders involved must negotiate to resolve the conflict • Unrealistic requirement • The requirement does not appear to be implementable with the technology available or given other constraints on the system • Stakeholders must be consulted to decide how to make the requirement more realistic ITEC 4040 Requirements Management, Winter 2017

  20. Reviews, Walkthroughs, Inspections • Management reviews • E.g., preliminary design review (PDR), critical design review (CDR), … • Used to provide confidence that the design is sound • Attended by management and sponsors (customers) • Often just a “dog and pony show” • Walkthroughs • Developer technique (usually informal) • Used by development teams to improve quality of product • Focus is on finding defects • Fagan Inspections • A process management tool (always formal) • Used to improve quality of the development process • Collect defect data to analyze the quality of the process • Written output is important • Major role in training junior staff and transferring expertise • These definitions are not widely agreed! • Other terms used: • Formal Technical Reviews (FTRs) • Formal Inspections • “Formality” can vary: • Informal: • Meetings over coffee • Regular team meetings • Etc. • Formal: • Scheduled meetings • Prepared participants • Defined agenda • Specific format • Documented output ITEC 4040 Requirements Management, Winter 2017

  21. Inspections and Walkthroughs • Inspection – A formal evaluation technique in which artifacts are examined in detail by a person or group other than the author to detect errors, violations of development standards, and other problems. • Formal, initiated by the project team, planned, author is not the presenter • Frequently uses checklists • Walkthrough – A review process in which a developer leads one or more members of the development team through a segment of an artifact that he has written while the other members ask questions and make comments about technique, style, possible errors, violation of development standards, and other problems. • Semi-formal, initiated by the author, quite frequently poorly planned ITEC 4040 Requirements Management, Winter 2017

  22. Benefits of Formal Inspections[Adapted from Blum, 1992, Freedman and Weinberg, 1990, & notes from Philip Johnson] • Formal inspection works well for programming – main QA method: • For application programming: • More effective than testing • Most reviewed programs run correctly first time • Compare: 10-50 attempts for test/debug approach • Evidence from large projects • Error reduction by a factor of 5; (10 in some reported cases) • Improvement in productivity: 14% to 25% • Percentage of errors found by inspection: 58% to 82% • Cost reduction of 50%-80% for V&V (even including cost of inspection) • Effects on staff competence (i.e., organizational effects): • Increased morale, reduced turnover • Better estimation and scheduling (more knowledge about defect profiles) • Better management recognition of staff ability • These benefits also apply to requirements inspections • Many empirical studies investigated variant inspection processes • Mixed results on the relative benefits of different inspection processes ITEC 4040 Requirements Management, Winter 2017

  23. Planning Inspections[Adapted from Blum, 1992, pp369-373 & Freedman and Weinberg, 1990] • Scope • Focus on small part of a document/design, not the whole thing • Timing • Examines a product once its author has finished it • Not too soon • Product not ready - find problems the author is already aware of • Not too late • Product/Document in use – errors are now very costly to fix • Purpose • Remember the biggest gains come from fixing the process • Collect data to help you not to make the same errors next time ITEC 4040 Requirements Management, Winter 2017 • Size • “Enough people so that all the relevant expertise is available” • Min: 3 (4 if author is present) • Max: 7 (less if leader is inexperienced) • Duration • Never more than 2 hours • Concentration will decrease if longer • Outputs • All reviewers must agree on the result • Accept, re-work or re-inspect • All findings should be documented • Summary report (for management) • Detailed list of issues • Report on process improvement – e.g., given consistency issues w/ models, note that team needs to coordinate better in the future

  24. Typical Roles in Reviews • Review leader • Chairs the meeting • Ensures preparation is done • Keeps review focused • Reports the results • Recorder • Keeps track of issues raised • Reader • Walks the group through the spec piece by piece • Author • Should actively participate (e.g., as reader) • Other reviewers • Task is to find and report issues ITEC 4040 Requirements Management, Winter 2017

  25. Choosing Reviewers • Choose among • Specialists in reviewing (e.g., QA people) • People from the same team as the author • People invited for specialist expertise • People with an interest in the product • Visitors who have something to contribute • People from other parts of the organization • Exclude • Anyone responsible for reviewing the author • I.e., line manager, appraiser, etc. • Anyone with known personality clashes with other reviewers • Anyone who is not qualified to contribute • All management (?) • Anyone whose presence creates a conflict of interest ITEC 4040 Requirements Management, Winter 2017

  26. Structuring The Inspection • Checklist • Uses a checklist of questions/issues • Review structured by issue on the list • Walkthrough • One person presents the document step-by-step • Review is structured by the document • Round robin • Each reviewer in turn gets to raise an issue • Review is structured by the review team • Speed review • Each reviewer gets 3 minutes to review a chunk, then passes to the next person • Good for assessing comprehensibility! ITEC 4040 Requirements Management, Winter 2017

  27. Requirements Review Checklists [1] • Essential tool for an effective review process • Lists common problem areas and guide reviewers • May include questions on several quality aspects of the document: comprehensibility, redundancy, completeness, ambiguity, consistency, organization, standards compliance, traceability ... • There are general checklists and checklists for particular modeling and specification languages • Checklists are supposed to be developed and maintained ITEC 4040 Requirements Management, Winter 2017

  28. Requirements Review Checklists [2] • Sample of elements in a requirements review checklist • Comprehensibility – can readers of the document understand what the requirements mean? • Redundancy – is information unnecessarily repeated in the requirements document? • Completeness – does the checker know of any missing requirements or is there any information missing from individual requirement descriptions? • Ambiguity – are the requirements expressed using terms which are clearly defined? Could readers from different backgrounds make different interpretations of the requirements? • Consistency – do the descriptions of different requirements include contradictions? Are there contradictions between individual requirements and overall system requirements? ITEC 4040 Requirements Management, Winter 2017

  29. Requirements Review Checklists [3] • Sample of elements in a requirements review checklist • Organization – is the document structured in a sensible way? Are the descriptions of requirements organised so that related requirements are grouped? • Conformance to standards – does the requirements document and individual requirements conform to defined standards? Are departures from the standards justified? • Traceability – are requirements unambiguously identified? Do they include links to related requirements and to the reasons why these requirements have been included? ITEC 4040 Requirements Management, Winter 2017

  30. The Process[Adapted from Freedman and Weinberg, 1990] • Prior to the review • Schedule formal reviews into the project planning • Train all reviewers • Ensure all attendees prepare in advance • During the review • Review the product, not its author • Keep comments constructive, professional and task-focused • Stick to the agenda • Leader must prevent drift • Limit debate and rebuttal • Record issues for later discussion/resolution • Identify problems but don’t try to solve them • Take written notes • After the review • Review the review process ITEC 4040 Requirements Management, Winter 2017

  31. The Process: Opening Moments[Adapted from Wiegers 2001] • Don’t start until everyone is present • Leader announces: • “We are here to review product X for purpose Y” • Leader introduces the reviewers, and explains the recording technique • Leader briefly reviews the inspection materials (everyone has the right version of the SRS, checklists, etc.) • Check that everyone received them • Check that everyone prepared • Leader explains the type of review Note: the review should not go ahead if: • Some reviewers are missing • Some reviewers didn’t receive the materials • Some reviewers didn’t prepare ITEC 4040 Requirements Management, Winter 2017

  32. During Inspections, Avoid • Devil’s Advocates • Contradicting for the sake of argument • Debugging • Find problems don’t try to fix them (no time) • Reviewing the author and not the product • Engaging in debates and rebuttals • Record issues for later discussion • Violating rules and deviating from the agenda • Have people put, say, $1 into the party fund when they speak out of turn • Take away the chairs (stand-up review) • Timer to limit participants from talking longer than allowed ITEC 4040 Requirements Management, Winter 2017

  33. Fagan Inspection Process • Fagan inspection – structured review process • Aim – finding defects in development documents, including requirements specifications • Named after Michael Fagan, who is credited with being the inventor of formal software inspections (at IBM in the 70’s) • Every activity has entry and exit criteria (i.e., pre-/post-conditions) • The Fagan inspection process offers a way to validate whether the output complies with the exit criteria intended for that activity. ITEC 4040 Requirements Management, Winter 2017

  34. Fagan Inspection Process – Main Activities[Adapted from Blum, 1992, pp.374-375] 4) Rework • All errors/problems addressed by author • Document corrected 5) Follow-up • Moderator ensures all errors have been corrected • If more than 5% reworked, product is re-inspected by original inspection team ITEC 4040 Requirements Management, Winter 2017 0) Planning • Materials preparation, scheduling, etc. 1) Overview • Communicate and educate about product • Circulate materials, assign roles 2) Preparation • All participants perform review individually • Review materials to detect defects 3) Inspection • A reader paraphrases the design • Identify and note problems (don’t solve them)

  35. Summary: Inspections • Inspections are very effective • Code inspections are better than testing for finding defects • For Specifications, inspection is all we have (you can’t “test” a spec!) • Key ideas: • Preparation: reviewers inspect individually first • Collection meeting: reviewers meet to merge their defect lists • Log each defect, but don’t spend time trying to fix it • The meeting plays an important role: • Reviewers learn from one another when they compare their lists • Additional defects are uncovered • Defect profiles from inspection are important for process improvement • Wide choice of inspection techniques: • What roles to use in the meeting? • How to structure the meeting? • What kind of checklist to use? ITEC 4040 Requirements Management, Winter 2017

  36. Model Analysis • Verification • “Is the model well-formed?” • Are the parts of the model consistent with one another? • Are related models of different types consistent? • Validation • Animation of the model on small examples • Formal challenges • “If the model is correct, then the following property should hold...” • ‘What if’ questions • Reasoning about the consequences of particular requirements; • Reasoning about the effect of possible changes • “Will the system ever do the following...” • State exploration • E.g., use model checking to find traces that satisfy some property ITEC 4040 Requirements Management, Winter 2017

  37. Verification • Checking if a representation (e.g., an SRS) is consistent within itself • Checking whether the system that was developed meets the specifications (independent of how valid the specs are). • Methods: • Inspection (as in validation) • Traceability • Formal Verification (e.g., Model Checking) • Can also bee seen as a validation effort. • Testing, Code Inspection, etc. ITEC 4040 Requirements Management, Winter 2017

  38. Formal Analysis of Models [1] • Logic models • First order logic – can use theorem proving (expensive, slow) • Workflow (process) and state machine models • Simulations – as high-level prototype implementations • Partial analysis on certain number of test cases • Reachability analysis – determine all reachable states in a workflow or state machine model • For workflows, the formal Petri Net notation is used • Different types of consistency checks • Conformance/Refinement b/w two models – e.g., one abstract, one more concrete • Equivalence (trace, observational, etc.) ITEC 4040 Requirements Management, Winter 2017

  39. Formal Analysis of Models [2] • Model checking • Used for behavioural workflow (process) and state machine models • Uses the approach of reachability analysis • Some typical properties to be verified for a given model: • General properties • Absence of deadlocks in systems with concurrency • All states can be reached and all transitions can be traversed • Specific properties depending on a particular system; must be specified using suitable notation, such as • Logic assertions or invariants • Temporal logic (predicate logic extension with two operators: always and eventually) • Can use always to capture avoid/maintain goals; eventually – achieve goals ITEC 4040 Requirements Management, Winter 2017

  40. Inspecting Models • Basic Syntactic/Semantic Check • E.g., UML Class diagrams • Are classes represented with rectangles (e.g. not circles)? • Are they connected with associations and specializations links (e.g., not <<includes>> links)? • Are they really classes (e.g. “Student”, “Enrollment”, etc.) or something else (e.g., processes or goals – “Fulfill Order”)? • Cross Check amongst diagrams • Consistency amongst diagrams is extremely important • Basic Checks • Classes of objects in System Sequence Diagrams (SSDs) appear in Class diagram. • Actors in SSDs appear in Use Case Diagrams • Each SSD describes a use case in the Use Case Diagram. • Each actor in BPMN (or Activity Diagram) that uses the system must appear in the Use Case diagram • Each activity in the BPMN (or Activity Diagram) that involves use of the system must associate with one or more use cases in the Use Case Diagram. • State Diagrams must reflect the state of one or more objects from the Class Diagram • Use cases are in the use case diagram if and only if they appear in the SRS • Inspect NFRs: use taxonomies – they help to, e.g., ensure coverage of various relevant NFR types • The above can be used to enrich the inspection checklists ITEC 4040 Requirements Management, Winter 2017

  41. Sample Checklist for DFDs • The documentation contains • Date, numbered pages, list of topics, change and version control • Process represented by a numbered circle (or a rounded rectangle) • Identifier should begin with a verb • Maximum number of processes should be 7 +/- 2 • No black holes • No miracles • Models must be balanced ITEC 4040 Requirements Management, Winter 2017

  42. Example Basic Cross-Checks for UML • Use Case Diagrams • Does each use case have a user? • Does each user have at least one use case? • Is each use case documented? • Using sequence diagrams or equivalent • Class Diagrams • Does the class diagram capture all the classes/entities mentioned in other diagrams? • Does every class have methods to get/set its attributes? • Sequence Diagrams • Is each class in the class diagram? • Can each message be sent? • Is there an association connecting sender and receiver classes on the class diagram? • Is there a method call in the sending class for each sent message? • Is there a method call in the receiving class for each received message? • StateChart Diagrams • Does each statechart diagram capture (the states of) a single class? • Is that class in the class diagram? • Does each transition have a trigger event? • Is it clear which object initiates each event? • Is each event listed as an operation for that object’s class in the class diagram? • Does each state represent a distinct combination of attribute values? • Is it clear which combination of attribute values? • Are all those attributes shown on the class diagram? • Are there method calls in the class diagram for each transition? • …a method call that will update attribute values for the new state? • …method calls that will test any conditions on the transition? • …method calls that will carry out any actions on the transition? ITEC 4040 Requirements Management, Winter 2017

  43. Traceability • IEEE-STD-830: • Backwards traceability • Tracing the origins of each requirement • Forward traceability • Tracing the requirement to all (design/implementation) artifacts that follow the SRS • DOD-STD-2167A: • A specification is traceable if: • It contains or implements all applicable stipulations in 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 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 ITEC 4040 Requirements Management, Winter 2017

  44. problem REQUIREMENTS Req. Doc Version 1 Domain (University of Discourse) Req. Document definition Req. Doc Version 3 Req. Doc. Version 2 a e c design j g b software implementation d f i h maintenance Traceability Pre (backwards) Traceability [Luiz Cysneiros] Post (forward) traceability ITEC 4040 Requirements Management, Winter 2017

  45. Requirements Traceability • Considered part of requirements management • Checks can be done using traceability techniques • Given the requirements document, verify that all elicitation notes are covered (e.g., sources of requirements are documented) • Tracing between different levels of requirements • Checking goals against tasks, features, requirements, etc. • Involves developing a traceability matrix • Ensures that requirements have been taken into consideration (if not there should be a reason) • Ensures that everything in the specification is justified ITEC 4040 Requirements Management, Winter 2017

  46. Traceability Problem Statements: Level 1 Requirements: Level 2 Specification: Level 3 Design: Level 4 ITEC 4040 Requirements Management, Winter 2017 • Vertical traceability – capture relationships across different types of artifacts (the picture on the left) • Horizontal traceability – relationships between artifacts of the same type • E.g., Req#29 impacts Rec#3

  47. More on Traceability • Pre traceability – before adding to the requirements document • Where does it come from? Who suggested? Why? • Post traceability – After something is added to the SRS • How it’s implemented • Traceability helps link requirements and design/implementation artifacts: • Backwards traceability – find rationale for having design/implementation artifacts (WHY) • Forward traceability – see how requirements are implemented, what design/implementation artifacts are affected (HOW) ITEC 4040 Requirements Management, Winter 2017

  48. Explicit and Implicit Traceability • Explicit • Links elements otherwise not intrinsically linked • Develop/create relationships from external considerations given by team members • Specifically implemented – link, indicator, etc. • Implicit • Inherent in the nature of the artifacts • Examples: DFD Process 1.1 is linked to process 1.0 • Overall – model cross-consistency rules • Not explicitly represented ITEC 4040 Requirements Management, Winter 2017

  49. Internal and External Traceability • Internal • Relationship between artifacts of the same type • For example: scenarios • Other scenarios • Other versions of the same scenario (alternatives, exceptions) • External • Relationship between different artifacts • Example: scenarios and class diagrams • Example: requirements and Java code ITEC 4040 Requirements Management, Winter 2017

  50. Traceability Matrix or Table • Traceability info is usually maintained in a traceability matrix • No standard format • No standard content • Can include test cases, components, etc. Implemented by [www.guru99.com/traceability-matrix.html] Software Requirements Compo- nents R1 R2 R3 ... C1 X X C2 X C3 • Traceability tables can also be used ... ITEC 4040 Requirements Management, Winter 2017

More Related