Inserting Requirements Traceability into the Capstone Sequence

1. Inserting Requirements Traceability into the Capstone Sequence Bob Roggio Professor School of Computing University of North Florida Jacksonville, FL 32224 broggio@unf.edu 1

2. Outline • 1. Introduction to Requirements Traceability (RT) • 2. The Volunteers in Medicine (VIM) Project • 3. Needs, Features, Use Cases, and Traceability • 4. Mappings Using Traceability Matrices • 5. Assessment of Inserting Requirements Traceability into the Capstone Sequence 2

3. 1. Introduction to Requirements Traceability The Controversy • The Good: • Most practitioners agree that tracing requirements is a good thing and can lead to improved products, more satisfied customers, higher reliability, etc. But: • The Questions: • Is the cost, effort worth the value? • How much RT is enough? • Best mechanisms? Does RT delay time to market? • The Constant: • If we undertake RT: must be: • low in cost, high in value, and easy to implement. • As Faculty: • We know capstone sequences culminate programs • Where, if included, would we insert RT? Costs? 3

4. Requirements Traceability - Definition • “…the ability to describe and follow the life of a requirement, in both a forward and backward direction from elicitation of stakeholder needs through to deployment of the application.” [2] 4

5. 2. The Volunteers in Medicine Project (VIM) • Volunteers in Medicine (VIM) – Jacksonville, FL • Provide Health Care to the Working Uninsured • Almost all volunteers; four paid employees. • Doctors, Nurses, Nurse Practitioners, a host of volunteer clerks and various other jobs at this Clinic. • Needs: scheduling patients/volunteers • Records, appointments, qualification for treatment…. • Statistical record keeping for external funding, etc. etc. • Funding: a variety of local, state, federal programs: based on statistics provided, philanthropy, etc. 5

6. Capstone Sequence – VIM • Two semester sequence; Eleven deliverables. • Real World Issues • creeping requirements, • missing / incorrectly understood requirements • the more the customer sees the more they want… • Each deliverablehad at least a single RT activity / artifact produced or previous artifact serious reviewed. • Introduced an SQA manager as a specific development team role. • Used the RUP, Rational Rose, Visual Modeling; • Use-Cases drove the project, MVC layered architecture; Various technologies. • Deployed / Installed Aug 2006. 6

7. 3. Needs, Features, Use Cases, Traceability • More and more developers open subscribe to a requirements traceability approach that starts with • Identifying and capturing stakeholderneeds • Very abstract; high level. Often contain statements not directly traceable to computer-based features. • Mapping these needs into features and then • Mapping these features into usecases with a explicit traceability in each case. 7

8. Sample Statement of Need • “The system will allow students to register for courses, and change their registration, as simply and rapidly as possible. It will help students achieve their personal goals of obtaining their degree in the shortest reasonable time while taking courses that they find most interesting and fulfilling.”[1] p. 107 (italics are mine) • Pretty darn ‘high-level’ and abstract • Yet very meaningful to the Stakeholder. 8

9. Deliverable 1 - Overview Main Emphasis: • Critical to capture Needs and Features in the Product Vision Document – up front. • Additional documents in Deliverable 1 include Business Rules Document, Risks Lists, Business Model, etc. •  Develop a traceability matrix mapping Needs to Features 9

10. One model that may be used to capture Requirements Traceability [7] is given below: [2] 10

11. 4. Mappings Using Traceability Matrices • Let’s look more closely at these… 11

12. Needs to Features Matrix – ForwardTrace NEED 12

13. Needs to Features Matrix – BackwardTrace 13 more

14. Needs to Features Matrix – Backward Trace 14

15. Deliverable 2 - Overview Main Emphasis: • Essentially Deliverable focused on the Domain Model. But: •  Teams iterated the Needs to Features traceability matrices. Really took a close look at these matrices. In particular: • Needs not mapped to any Features (functional requirements) became clearly evident. Shouted for scrutiny. • Features not mapped back to Needs were suspect and resulted in further investigation. • Some features appeared to satisfy more than one need. Examined and deemed okay. • A very worthwhile activity. 15

16. Deliverable 3 - Overview Main emphasis: • Development of Façade Use Cases and • Development of initial User Interface (UI) Prototype. But: •  Development of “Features to Use-Case” Traceability Matrices • Forward and Rearward Traceability Matrices. 16

17. Use Case Index – Part 1 more 17 N.B. Verb…Object (There are a few errors in here…)

18. Use Case Index – Part 2 18

19. Identification of Use-Cases. Forward Traceability of Features to Use-Cases more 19

20. Identification of Use-Cases. Forward Traceability of Features to Use-Cases 20 more

21. Backward Traceability of Use-Cases to Features 21

22. This is what we were after…. Product Features and more 22 [7]

23. Deliverable #4 - Overview MainEmphases: • Develop Full/Mature Use Case Specifications • Develop Activity Diagram for each Use Case •  Extend Requirements Traceability (RT) Matrix • Elaboration – next slide • Revisit and Revise: • Domain Model, • Façade Use Case Specifications and Diagrams • User Interface; • All Management Docs • Business Vision; Risks List; Business Rules; Bus Obj. Model, … • Executive Summary • Individual Work Sheets / Team Work Sheets (from PSP / TSP) 23

24. Traceability Matrix – Sample Elaboration • Extend your traceability by tracing all features forward to individual or groups of Use Cases required to capture these features. • Similarly, trace Use Cases back to features that the Use Cases address. • Ensure that every feature is accommodated in the collection of Use Cases and that there are no scenarios in use cases that do not trace back to specific features. • Address the scenarios in each use case to do an adequate trace. This is a lot of work. If you find a scenario that does not relate back to a feature, check the feature; if necessary check the Need. Something needs to be resolved… Report on this activity. 24

25. Deliverable 5 – Overview MainEmphasis: • Analysis Modeling • Structural Relationships – Class diagrams • Dynamic Relationships – Interaction diagrams and • Non-Functional Requirements: Supplementary Specification Document •  Traceability Matrix: Use Cases to Analysis Classes • Map each Use Case (such as UC1, …, UCn) to the analysis classes that will accommodate the Use Case functionality. • (Recognize that there may a number of scenarios in each use case. But they must be traceable to analysis classes that ‘realize’ them - and hence the matrix. 25

26. Use-Case Traceability to Boundary Classes more 26

27. Use-Case Traceability to Boundary Classes 27

28. Capstone Sequence – Second Semester • Deliverables 6 and 7 addressed the Detailed User Interface and a Layered Architectural Design Approach. • Deliverables 8 and 9 addressed detailed design to the subsystem level and subsystem design realizations. •  Traceability: In these last two deliverables, we attempted to map the analysis classes derived from use cases into design classes and other artifacts as appropriate. • Most analysis classes do not morph into design classes. They may morph into a subsystem or existing reusable component, etc. • Difficulties ahead: 28

29. Traceability into Use-Case Realizations • Most RT efforts seem focused on front-end activities. • Probability because widespread feelings the root causes of software failure often center •  on inadequate problem analysis and capture, and the •  failure to properly manage requirements / change • Tracing into design using traceability matrices is a daunting task, even for a small system. 29

30. Tracing Requirements into Design Classes 30 DC – design class; DS – design subsystem…

31. 5. Assessment of Inserting Requirements Traceability into Capstone Sequence • DevelopmentTeams: The development teams felt the RT effort was worth the cost certainly for front-end activities; that is, through mappings culminating with use-case specifications with all paths (alternate and exceptions) and into analysis modeling. • Teams: Teams felt that the careful mappings of requirements from needs to features to use-cases resulted in very reliable use-cases, which (as stated) were used to driveourprocess. • RT provided a levelofassurance that all work could be traced back to needs and features. • Building the system right versus building the rightsystem! 31

32. From an Industrial Viewpoint: • Failure to undertake some requirements traceabiity is a serious software development problem nowadays. • RT must become an integral part of the organization’s development process. • It has been asserted that incorporating RT into an organization’s development process often parallels organizations that are successful with software development and those that are not. • Use of traceability matrices for RT for front end development efforts in small systems is low cost, provides high value, and is easy to implement particularly for applications developed in academe’. 32

33. Continued Traceabilities with Matrices • So much more could have been done. • A matrix approach can be developed to trace non-functional requirements. • Similarly, mapping of features into test cases can similarly be accommodated… 33

34. Questions? 34