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_at_unf.edu

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

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?

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

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.

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 deliverable had 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.

7
3. Needs, Features, Use Cases, Traceability

• More and more developers open subscribe to a
  requirements traceability approach that starts
  with
• Identifying and capturing stakeholder needs
• 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 use cases with a
  explicit traceability in each case.

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.

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

10
One model that may be used to capture
Requirements Traceability 7 is given below
2
11
4. Mappings Using Traceability Matrices

• Lets look more closely at these

12
Needs to Features Matrix Forward Trace
ID FORWARD TRACEABILITY
N1 Record Repository F1, F2, F5, F32
N2 Scheduling F6, F7, F9, F11, F12, F13, F31
N3 Tracking and Report F14, F15, F16, F17, F18, F20, F22,F32
N4 Remote Access F23
N5 Provider Access to Patient Records F 24, F25
N6 Mass Communication F26
N7 Central Control for Setting Up Authorized Access F33
N8 Protection Against Unauthorized Access F29, F30
NEED
13
Needs to Features Matrix Backward Trace
ID FEATURE BACKWARD TRACEABILITY
F1 The system will allow the user to add, delete, and update patient records N1
F2 The system will allow the user to add, delete, and update volunteer records N1
F5 The system shall enable approval of personal profile changes by the business administrator of volunteer coordinator N1
F6 The system shall enable the insertion and deletion of volunteers into the schedule N2
F7 The system shall enable the insertion of deletion of providers into the schedule N2
F9 The system shall enable the insertion of patient qualifying and examination appointments into the work schedule N2
F11 From the schedule, the user will be able to access information about a particular appointment. This in N2
F12 The system shall allow the rescheduling of appointments missed by a patient N2
F13 The system will allow the scheduling of grant timeframes and associated proposal and reporting due dates N2
F14 The system shall enable the business director to create statistical reports based on patient race. N3
F15 The system shall enable the business director to create statistical reports based on patient age. N3
F16 They system shall enable the clinical director to create statistical reports based on patient occupation. N3
F17 They system shall enable the business director to create statistical reports based on provider and volunteer hours. There reports will assign a dollar value of these hours based on provider and volunteer status N3












more
14
Needs to Features Matrix Backward Trace
ID FEATURE BACKWARD TRACEABILITY
F15 The system shall enable the business director to create statistical reports based on patient age. N3
F16 They system shall enable the clinical director to create statistical reports based on patient occupation. N3
F17 They system shall enable the business director to create statistical reports based on provider and volunteer hours. There reports will assign a dollar value of these hours based on provider and volunteer status N3
F18 The system shall enable the business director to create statistical reports based on patient diagnosis N3
F20 They system shall track the hours of individual volunteers and providers based on their status (nurse practitioner, doctor, UNF student) N3
F22 The system shall track the dates and amounts of donations N3
F23 The system shall allow remote access to VIM-Jax information resources to authorized individuals. N4
F24 The system shall allow providers the ability to search for patient records N5
F25 The system shall allow providers the ability to update patient records. This includes recording diagnosis and treatment of patients. N5
F26 The system shall allow the distribution of information to a selected group of stakeholders via email. N6
F29 The system shall authenticate users for certain parts of the application based on user ID N8
F30 The system shall not allow users to access system resources until the user has "clocked" in. N8
F31 The system shall enable the insertion of patient qualifying appointments into the work schedule N2
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.

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.

17
Use Case Index Part 1
USE CASE NO TITLE ACTORS LEVEL MATURITY DESCRIPTION LAST MOD
UC-01 Schedule Patients Clinical Director, Volunteer, Relational Data Base Management System (RDBMS) Facade This use case is started by the Clinical Director or a Volunteer, and it allows them to schedule patient appointments. 10/21/05
UC-02 Schedule Volunteers Volunteer Coordinator, RDBMS Facade This use case is started by the Volunteer Coordinator who wishes to schedule volunteer work hours. 10/21/05
UC-03 Schedule Qualification Consultation Clinical Director, Volunteer, RDBMS Facade The Clinical Director or a Volunteer schedules a qualification consultation appointment. 10/21/05
UC-04 Maintain Patient Records Office Coordinator, Volunteer Coordinator, Volunteer, RDBMS Facade The Office Coordinator, Volunteer Coordinator or a Volunteer creates, updates, and deletes patient records. 10/22/05
UC-05 Maintain Volunteer Records Volunteer Coordinator, RDBMS Facade The Volunteer Coordinator edits volunteer records. 10/21/05
more
N.B. VerbObject
(There are a few errors in here)
18
Use Case Index Part 2
USE CASE NO TITLE ACTORS LEVEL MATURITY DESCRIPTION LAST MOD
UC-06 Research Statistics Business Administrator, RDBMS Façade The Business Administrator looks up, compiles and prints out organizational statistics. 10/21/05
UC-07 Send Group Email Business Administrator, RDBMS Facade The Business Administrator undertakes a mass email all the volunteers in the database. 10/21/05
UC-08 Authorize User All Users of the System, RDBMS Façade This use case is started by any user of the system and it allows them to gain access on site or remotely, and check authentication. 10/22/05
UC-09 Perform Administrative Tasks Business Administrator, RDBMS Façade The Business Administrator creates and deletes users, and resets user passwords. 10/22/05
19
Identification of Use-Cases. Forward Traceability
of Features to Use-Cases
ID FEATURE FORWARD TRACEABILITY
F1 The system will allow the user to add, delete, and and update patient records UC-04
F2 The system will allow the user to add, delete, and update volunteer records UC-05
F5 The system shall enable approval of personal profile changes by the business administrator and volunteer coordinator UC-04, UC-05
F6 The system shall enable the insertion or deletion of volunteers into the schedule UC-02
F7 The system shall enable the insertion or deletion or providers into the schedule UC-02
F9 The system shall enable the insertion of patient examination appointments into the work schedule UC-01
F11 From the schedule, the user will be able to access information about a particular appointment. UC-01




more
20
Identification of Use-Cases. Forward Traceability
of Features to Use-Cases
ID FEATURE FORWARD TRACEABILITY
F23 The system shall allow remote access to VIM-Jax information resources to authorized individuals. UC-09
F24 The system shall allow providers the ability to search for patient records UC-04
F25 The system shall allow providers the ability to update patient records. This includes recording diagnosis and treatment of patients. UC-04
F26 The system shall allow the distribution of information to a selected group of stakeholders via email. UC-07
F29 The system shall authenticate users for certain parts of the application based on user ID UC-08
F30 The system shall not allow users to access system resources until the user has "clocked" in. UC-08
F31 The system shall enable the insertion of patient qualifying appointments into the work schedule UC-03
F32 Maintain chronic medical conditions treatment. UC-04
F33 The system will allow an authorized user system administration capabilities such as creating and deleting users and reset forgotten user passwords. UC-09
more
21
Backward Traceability of Use-Cases to Features
ID USECASE DESCRIPTIONS USECASE DESCRIPTIONS BACKWARD TRACEABILITY
UC-01 This use-case is started by the Clinical Director or a Volunteer and it allows them to schedule patient appointments. This use-case is started by the Clinical Director or a Volunteer and it allows them to schedule patient appointments. F9, F11, F12
UC-02 This use-case is started by the Clinical Director or Volunteer Coordinator to schedule volunteer work hours. This use-case is started by the Clinical Director or Volunteer Coordinator to schedule volunteer work hours. F6, F7
UC-03 This use-case is started by the Clinical Director or a Volunteer to schedule a qualification consultation appointment. F31 F31
UC-04 This use-case is started by either, the Office Coordinator, Volunteer Coordinator or a Volunteer to create, update, and delete patient records. F1, F5, F24, F25, F32 F1, F5, F24, F25, F32
UC-05 This use-case is started by the Volunteer Coordinator and it allows her to edit volunteer records. F2, F5 F2, F5
UC-06 This use-case is triggered by the Business Administrator to look up, compile and print out organizational statistics. F13, F14, F15, F16, F17, F18, F19, F20 F13, F14, F15, F16, F17, F18, F19, F20
UC-07 This use-case is started by the Business Administrator and it allows him to mass email all the volunteers in the database. F26 F26
UC-08 This use-case is started by any user of the system and it allows them to gain access on site or remotely, and check authentication. F29, F30 F29, F30

22
This is what we were after.
Product Features and more
7
23
Deliverable 4 - Overview

• Main Emphases
• 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)

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.

25
Deliverable 5 Overview

• Main Emphasis
• 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.

26
Use-Case Traceability to Boundary Classes
ID USECASE CLASS TYPE FORWARD TRACEABILITY
UC-01 Schedule Patients This use case is started by the Clinical Director or a Volunteer and it allows them to schedule patient appointments. BOUNDARY VolunteerHome AppointmentCalender AppointmentScheduleOptions AppointmentOptions AppointmentDetails RDBMSBoundary
UC-01 Schedule Patients This use case is started by the Clinical Director or a Volunteer and it allows them to schedule patient appointments. CONTROL SchedulePatientsControl
UC-01 Schedule Patients This use case is started by the Clinical Director or a Volunteer and it allows them to schedule patient appointments. ENTITY Appointment Providers PatientRecord Schedue
UC-02 Schedule Volunteers This use case is started by the Clinical Director or Volunteer Coordinator to schedule volunteer work hours. BOUNDARY VolunteerCoordinatorHome AppointmentScheduleOptions WorkCalendar WorkScheduleOptions WorkScheduleDetail RDBMSBoundary
UC-02 Schedule Volunteers This use case is started by the Clinical Director or Volunteer Coordinator to schedule volunteer work hours. CONTROL ScheduleVolunteerHoursControl
UC-02 Schedule Volunteers This use case is started by the Clinical Director or Volunteer Coordinator to schedule volunteer work hours. ENTITY User Schedule
more
27
Use-Case Traceability to Boundary Classes
UC-03 Schedule Qualification Consultation This use case is started by the Clinical Director or a Volunteer to schedule a qualification consultation appointment. BOUNDARY VolunteerHome AppointmentCalendar AppointmentOptions QualificationOptions QualificationDetails RDBMSBoundary
UC-03 Schedule Qualification Consultation This use case is started by the Clinical Director or a Volunteer to schedule a qualification consultation appointment. CONTROL ScheduleQualificationConsultationControl
UC-03 Schedule Qualification Consultation This use case is started by the Clinical Director or a Volunteer to schedule a qualification consultation appointment. ENTITY PatientRecord Appointment
UC-04 Maintain Patient Records This use case is started by either, the Office Coordinator, Volunteer Coordinator or a Volunteer to create, update, and delete patient records. BOUNDARY VolunteerCoordinatorHome RecordKeeping SearchForPatient PatientRecordOptions AppointmentSelection EditAppointmentDetails RDBMSBoundary
UC-04 Maintain Patient Records This use case is started by either, the Office Coordinator, Volunteer Coordinator or a Volunteer to create, update, and delete patient records. CONTROL MaintainPatientRecordsControl
UC-04 Maintain Patient Records This use case is started by either, the Office Coordinator, Volunteer Coordinator or a Volunteer to create, update, and delete patient records. ENTITY PatientRecord Appointment
UC-05 Maintain Volunteer Records This use case is started by the Volunteer Coordinator and it allows her to edit volunteer records. BOUNDARY VolunteerCoordinatorHome RecordKeeping VolunteerSearch EditVolunteerRecords RDBMSBoundary
UC-05 Maintain Volunteer Records This use case is started by the Volunteer Coordinator and it allows her to edit volunteer records. CONTROL MaintainVolunteerRecordsControl
UC-05 Maintain Volunteer Records This use case is started by the Volunteer Coordinator and it allows her to edit volunteer records. ENTITY Person User Providers Volunteer VolunteerGroup
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

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.

30
Tracing Requirements into Design Classes
F1 N1 UC-03 DS3, DC11.01, DS5, DC16.01, DC16.02, DS7, DC20.01, DC20.02, DC20.03, DC20.04, DC21.01, DC21.02, DC21.03, DC21.04, DC21.05, DC21.06, DC22.01, DC22.02, DC22.03
F2 N1 UC-03 DS3, DC11.01, DS5, DC16.01, DC16.02, DS7, DC20.01, DC20.02, DC20.03, DC20.04, DC21.01, DC21.02, DC21.03, DC21.04, DC21.05, DC21.06, DC22.01, DC22.02, DC22.03
F3 N1 UC-03 DS3, DC11.01, DS5, DC16.01, DC16.02, DS7, DC20.01, DC20.02, DC20.03, DC20.04, DC21.01, DC21.02, DC21.03, DC21.04, DC21.05, DC21.06, DC22.01, DC22.02, DC22.03
F4 N1 UC-03 DS3, DC11.01, DS5, DC16.01, DC16.02, DS7, DC20.01, DC20.02, DC20.03, DC20.04, DC21.01, DC21.02, DC21.03, DC21.04, DC21.05, DC21.06, DC22.01, DC22.02, DC22.03
F5 N1 UC-03 DS3, DC11.01, DS5, DC16.01, DC16.02, DS7, DC20.01, DC20.02, DC20.03, DC20.04, DC21.01, DC21.02, DC21.03, DC21.04, DC21.05, DC21.06, DC22.01, DC22.02, DC22.03
F6 N2 UC-01 DS2, DC6.01, DC6.02, DC6.03, DC6.04, DC6.05, DC7.01, DC7.02, DC7.03, DC7.04, DC7.05, DC7.06, DC8.01, DC8.02, DC8.03, DS5, DC15.01, DC15.02
F7 N2 UC-01 DS2, DC6.01, DC6.02, DC6.03, DC6.04, DC6.05, DC7.01, DC7.02, DC7.03, DC7.04, DC7.05, DC7.06, DC8.01, DC8.02, DC8.03, DS5, DC15.01, DC15.02
F8 N3 UC-04 DS3, DC9.01, DC9.02, DC10.01, DC10.02, DS6, DC17.01, DC17.02, DC17.03, DC18.01, DC18.02, DC18.03, DC18.04, DC18.05, DC19.01, DC19.02, DC19.03
F9 N3 UC-04 DS3, DC9.01, DC9.02, DC10.01, DC10.02, DS6, DC17.01, DC17.02, DC17.03, DC18.01, DC18.02, DC18.03, DC18.04, DC18.05, DC19.01, DC19.02, DC19.03
F10 N4 UC-02 DS1, DC1.01, DC1.02, DC1.03, DC1.04, DC1.05, DC2.01, DC2.02, DC2.03, DC3.01, DC3.02, DC3.03, DC3.04, DC3.05, DC4.01, DC4.02, DC4.03, DC5.01, DC5.02, DC5.03
F11 N4 UC-02 DS1, DC1.01, DC1.02, DC1.03, DC1.04, DC1.05, DC2.01, DC2.02, DC2.03, DC3.01, DC3.02, DC3.03, DC3.04, DC3.05, DC4.01, DC4.02, DC4.03, DC5.01, DC5.02, DC5.03
F12 N4 UC-02 DS1, DC1.01, DC1.02, DC1.03, DC1.04, DC1.05, DC2.01, DC2.02, DC2.03, DC3.01, DC3.02, DC3.03, DC3.04, DC3.05, DC4.01, DC4.02, DC4.03, DC5.01, DC5.02, DC5.03
F13 N4 UC-02 DS1, DC1.01, DC1.02, DC1.03, DC1.04, DC1.05, DC2.01, DC2.02, DC2.03, DC3.01, DC3.02, DC3.03, DC3.04, DC3.05, DC4.01, DC4.02, DC4.03, DC5.01, DC5.02, DC5.03
F14 N5 UC-05 DS5, DC13.01, DC13.02, DC14.01
F15 N5 UC-05 DS5, DC13.01, DC13.02, DC14.01
F16 N5 UC-05 DS5, DC13.01, DC13.02, DC14.01
F17 N6 UC-06 DS4, DC12.01, DC12.02, DC12.03
DC design class DS design subsystem
31
5. Assessment of Inserting Requirements
Traceability into Capstone Sequence

• Development Teams 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 drive our process.
• RT provided a level of assurance that all work
  could be traced back to needs and features.
• Building the system right versus building the
  right system!

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
  organizations development process.
• It has been asserted that incorporating RT into
  an organizations 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.

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

34
Questions?