Requirements Management with Use Cases Specification of Functional Enhancements and Fault Corrections for Improved Requirements Management in a Sustainment Environment Linton Smith DMS SME, DMS D/SDE Alex Fawcett DMS Systems Engineer

1
Requirements Management with Use
CasesSpecification of Functional Enhancements
and Fault Corrections for Improved Requirements
Management in a Sustainment EnvironmentLinton
SmithDMS SME, DMS D/SDEAlex FawcettDMS
Systems Engineer
2
Abstract

• Sustainment of Software Intensive Systems under
  the Technical Airworthiness Framework presents
  unique challenges.
• The Software Support Agency (SSA) is required to
  perform sustainment activities such that Design
  Acceptance activities may be satisfactorily
  completed by the DAR while the SSA maintains
  appropriate levels of traceability to design
  changes and quality of requirements
  specifications. These challenges are further
  complicated by the need for rapid and efficient
  transfer of technology and expertise by the SSA
  to different systems with widely varying support
  facilities and which have varying quality of
  requirements baselines and toolsets.
• These are challenges that are specific to
  maintenance environments. They are not
  necessarily present when specifying a new system
  acquisition. As such, the specification methods
  used on new acquisitions are not always
  appropriate in the software sustainment
  environment. Furthermore, engineering must
  produce modified system products in a change
  focussed environment which is scope limited to
  the requested changes.
• BAE Systems, as an AEO and SSA for the AP-3C
  Mission and Weapon System software, is
  confronting challenges such as these by
  addressing the means and methods used to specify
  functional enhancements and fault corrections to
  the various elements of the AP-3C Weapon System
  under the current ITTF Software Support Contract
  and soon, the Mission System Support Contract.
• This paper will review some of the issues that
  can affect the sustainment of software systems. 
  The paper will present Use-Cases as a means for
  capturing the specification of defect corrections
  and functional enhancements and their application
  to successive system engineering activities.

3
Content

• Design Acceptance in a Sustainment Environment
• Sustainment Challenges
• Requirements for a Sustainment RME Approach
• A Proposal for a RME Solution

4
Design Acceptance in a Sustainment Environment

• How to maintain SSA competency
• Vs obsolete tools
• Vs inconsistent data
• Vs documentation issues

Engineering Agency Competency (Compliance
assurance)
...In A Sustainment Environment?

• How to Manage Changes to Requirements...

How to trace design changes from requirement
through to test...

• How to ensure SSA EMS goals are met...

Design Approval Certificate
5
DA Specification - Acquisition vs Sustainment

• New Product Style
• Developer is OEM
• Specification is for complete product
• Updates managed as engineering deltas to
  Acquisition Specification (CCP/ECP)
• Design is a complete Product.
• traceable to the specification of requirements
• is derived from the updated specs, tested and
  delivered
• What are the OEMs liabilities
• takes ownership of PBL
• lock, stock, and two smoking barrels
• is liable for ALL aspects of the product
• includes latent defects

• Changed Product Style
• Developer is SSA
• Specification is for product changes
• Updates managed as engineering deltas to the
  Product
• Design is a set of changes to be applied to the
  Product
• traceable to the change specification
• is derived from change specs, tested and
  delivered
• What are the SSAs liabilities
• owns the changes only
• Only liable for defects in resultant product
• within the changes
• And as a direct result of the changes

6
DA Competency

• SSA must have active AEO delegation
• be competent to perform the work
• Which really means
• Certified to ISO 90012000
• EMS commensurate with CMMI Level 2
• Standards based
• ISO 15288, EIA 632, ISO/IEC 12207, etc
• For AP-3C SSA this means
• Understands and can apply the GFD Systems
  Engineering and SW Development Environments to
  the requested tasks.

7
DA Verification

• Traceability of User Requirements to Design
  Changes
• Implies the need for Requirements Management and
  Engineering process within the SSA EMS.
• Trace Customer requirements to
• design artefacts
• the modifications of the product baseline.
• Without a verifiable traceability,
• you might get more or less than bargained for...

8
DA Certification

• The AEO Design Certificate is the final artefact
  of the engineering process that generates the
  deliverable product.
• It is a document covering the product description
  documentation
• i.e Design Record Index
• For it to be valid and effective, the DC must be
  physically traceable to the SOR.
• Good traceability is equated with clear and
  unambiguous records
• Traceability Table or Matrix
• Links artefacts with sufficient detail
• Eg Test Cases in the test plan linked to
  requirements in the SOR.

Traceability
Design Certificate DRI
SOR
Records
9
Sustainment Challenges Work Scope

• Sustainment is heavily dependent on the finances
  available.

Right ?
On Time ?
Pick Two
On Budget?
10
Sustainment Challenges Work Scope

• Sustainment effort is only expended where it is
  most needed
• to provide an overall balanced capability.
• Management shifts focus and s to where the need
  is greatest

11
Sustainment Challenges TCO Today or Tomorrow?

• The focus is NOT on Total Cost of Ownership
• Opportunities for minimising TCO are being missed
  or ignored
• SSA is only tasked to produce deltas to the
  product baseline
• No opportunity for Futureproofing

12
Sustainment Challenges Tool Support Issues

• Dwindling support for obsolete COTS tools
• Multiple disparate tools across Multiple Systems
  Multiple learning curves
• The tools installed in the AP-3C SE Environment
  are obsolete
• Non-standard UI idioms
• Expertise is not a readily available commodity
• In Use of Tools
• In support of Tools

13
Sustainment Challenge Develop Maintain SSA
Expertise

• Developers lack experience with tools
• Tool Disparity complicates development of
  expertise
• Tool Complexity
• Long Project Lifecycles

14
Sustainment Challenge Obsolescence...
15
Sustainment Challenge Applying OEM RME

• Past DMS sustainment projects have
• applied OEM RME methodology, or
• attempted to manage changes only
• All have degraded the requirements and design
  data to some degree
• Sustainment activities accelerate the natural
  degradation of design data
• If left unchecked, the end result is a system
  that is too expensive to maintain
• "A Stitch, in time, saves nine!"
• old proverb

16
OEM RME Issues - Quality and Consistency of GFD

• The design data and requirements, as delivered,
  do not always totally agree or are ambiguous.
• Has a direct effect on cost to repair
• You don't know what you don't know...
• ... until you find out.

17
OEM RME Issues - Poorly Documented RME Methods

• OEM Documentation tends to be sparse
• Quality of transferred knowledge
• Does published information communicate the
  intent?
• Tacit Knowledge is, by definition, rarely, if
  ever, passed on to the SSA.
• Information re-discovery relies on Maintainer
  epiphanies. Feodoroff, 2006
• A part of a broader issue that affects all SSAs
• "Maintainer's Lament". Feodoroff, 2006
• i.e. poor Software Transition
• OEM RME methods were not well covered in
  official training delivered to SSA by PA5276
  training contractor.
• 2x lost tacit knowledge

OEM
Training Sub-Contractor
Trainee SSA
Lost Knowledge
18
Conclusion on OEM RME

• We are not able to avoid the eventual
  obsolescence of a system
• What little time and money is available for
  sustainment needs to be spent wisely
• The RME methodology used during acquisition may
  not be suitable for the sustainment phase for a
  variety of reasons
• The Design Data is a liability through
  inconsistency, ambiguity, incompleteness.
• "Fit the tool to the process...
• ...Not the process to the tool."

19
The Challenge A Summary

• Right now in the AP-3C Sustainment environment
• the developers must become experts
• On different systems
• With different support environments
• Quickly with little or no prior experience to
  rely on
• Juniors particularly
• even though the basic tasks that make up the
  systems' lifecycles are essentially the same.
• Sustainment activities at the ITTF are heavily
  constrained by time and cost.
• There is no leeway to include activities to
  perform groundwork for future development
  activities unless explicitly tasked to do so.

20
Requirements for an RME Approach

• A single methodology is required
• That provides
• Transferable Expertise
• Transferable Technology
• A Future Proofed Solution to RME Issues
• All animals are to be skinned the same way...

21
The Approach - Transferable Expertise

• Streamline the lifecycle activities for the
  different systems
• Developers need only be trained in RME once
• Developers build a base set of reuseable skills

22
The Approach - Transferable Technology

• Toolset Supported Methodology
• Applicable across multiple systems
• Amortisable Development and Training Costs

23
The Approach Need for Future-Proofed Solution

• The current work focus is the completion of
  current planned DMS work.
• In Jan 09 the focus shifts to the OMS.
• DMS SW development will be scaled back.

24
The Approach Need for Future-Proofed Solution

• What use will DMS specific skills be on OMS?
• Different Tools
• ReQuire/StP vs System Architect vs RTM
• Different SW Architectures
• Embedded vs General Purpose
• Different Sizes
• Single SW System vs System of Systems
• Different purposes
• Airborne Mission vs Ground Simulator
• Both are SW Systems
• With Users
• With System level behaviour
• With Design level behaviour
• Needing to be tested
• The more things change, the more they stay the
  same

25
The Solution

• System Independent
• Applicable across multiple systems
• Complementary data
• Enhances existing Requirements design data
• Traceable artefacts
• Provides effective traceability throughout a
  sustainment project
• Ease of Use
• Easily learnt skills
• De Facto Standard
• Wide Support
• Broad scope applicability
• Useful throughout development lifecycle

• Use Case
• Modelling !

26
The Solution

• Use Case Maps
• Describe specific behaviours of a system wrt
  interactions with the environment
• Capture behaviour descriptions from system level
  down to implementation level
• Provide support for whole lifecycle
• Identification of CONOPS, System Requirements
  Functional Requirements
• Daniels Bahill, 2004., Alexander Zink, 2002.
• Identification of Safety Requirements
• Wu Kelly, 2006, Alexander, 2003.
• Recording operation of design
• Buhr Casselman, 1996.
• Identification of test cases
• Ahlowalia, 2002.
• Identification of SW Modification Impacts
• Shiri, et al. 2007
• Can be used to fill in the gaps in understanding
  of system operation and design

27
Benefits of Use Cases

• Easy to learn Low Cost. Cockburn, 2001
• Learn Once - Use Many
• Proven and mature technology Google - 63M pages
  in english
• Acquirer - Supplier alignment

28
Use Cases in the System Lifecycle
User Viewpoint System Context Scenario UC CONOPS
style
TE Viewpoint AD Test Cases
VV Viewpoint Reqts Test Cases
SE Viewpoint System Design Functional
Reqts Analytical UC
System Development Use Cases
RA
AD
SIT
FQT
System Level
RA
AD
SIT
FQT
RA
AD
SIT
FQT
Sub-Systems Level
AD/DD
IT
FQT
RA
S/S VV Viewpoint S/S Reqts Test Cases
S/S TE Viewpoint S/S AD/DD Test Cases
S/S S/W E Viewpoint S/S Design S/S Functional
Reqts S/S Analytical UC
S/S User Viewpoint S/S Context S/S Scenario
UC S/S CONOPS/Analytical
S/S VV Viewpoint S/S Reqts Test Cases
S/S TE Viewpoint S/S AD/DD Test Cases
S/S S/W E Viewpoint S/S Design S/S Functional
Reqts S/S Analytical UC
S/S User Viewpoint S/S Context S/S Scenario
UC S/S CONOPS/Analytical
Sub-Systems Development Use Cases
S/S TE Viewpoint S/S AD/DD Test Cases
S/S VV Viewpoint S/S Reqts Test Cases
S/S User Viewpoint S/S Context S/S Scenario
UC S/S CONOPS/Analytical
S/S S/W E Viewpoint S/S Design S/S Functional
Reqts S/S Analytical UC
29
Use Cases as Specification

• Identification of sustainment activities
• in particular for Fault Corrections.
• Fault corrections are rarely requirements changes
• Don't treat them as such
• incorrectly treated as requirements in the system
  requirements database results in assorted
  difficulties
• Use cases can specify the expected behaviour
• that is not being exhibited by an aberrant
  system.
• Identify System Capability
• Identify Change Impacts
• Traceable to SOR

30
Use Cases as Design

• Use Cases are hierarchical
• Upper levels specify operational viewpoint
• Black Box view of system behaviour
• Lower levels specify behaviour with greater
  specifics
• Incorporate design decisions
• White Box view of system behaviour
• Support traditional structured design with model
  based design approach
• Provide descriptions of module interactions
  macro behaviour
• Clear text and graphical descriptions
• enhance readability general system
  comprehension
• increase understanding of extant design
  documentation
• shortens ramp-up time of new engineers to project

31
Use Case as Test Case

• Use Case Test Case
• Use cases can be used to develop the Test Cases
• Ahlowalia describes a method for extracting Test
  Cases from the Use Cases using Path Analysis
  Technique Ahlowalia 2002.
• Use Cases used to identify normal vs aberrant
  behaviour
• basis of test cases to prove implementation of
  solution
• Use Cases used to identify normal use and mis-use
  processing
• basis of test cases to perform tests of error
  handling.

32
Use Cases and Traceability

• Use Cases are specific documented artefacts.
• They can and should be uniquely identified
• recorded as part of a system's development.
• They can provide the glue that links requirements
  (in System Level UCs) with the Design (in Design
  UCs) and the Test Cases
• Traditional traceability can be extended to
  include Use Cases in traceability tables.

33
Use Case as User Manual

• Use Cases are descriptions of a system's
  interactions with actors and the environment
• They provide input to development of User
  documentation
• For SDRs can be used to capture intended
  operation
• Test Cases from the Use Cases verify the User
  Documentation

User Man
Fault Analysis
Document Update
Use Cases
34
What Next? - More Investigation

• UCM Capabilities
• as a requirement gathering tool
• User Requirement Notation (URN)
• Goal-oriented Requirement Language (GRL)
• as a design capture tool
• as a test case generation tool
• as a User Documentation assessment tool
• Feasability of UCM application
• Deployment Planning
• BAES Management buy-in
• CoA buy-in
• Logisitics
• Training development
• Process development
• Tool Selection and Support
• Pilot Trials
• Build ground-swell of support

35
In Summary

• Use Cases support all phases of the System
  Engineering Lifecycle.
• They are easy to learn
• They provide support for identification of
  requirements
• Functional, Safety, etc
• They are applicable to any system
• That interacts with external entities
• That produces observable outputs
• Defacto Standard via UML
• with broad industry support and application

36
References I

• Ahlowalia, Naresh Testing from Use Cases using
  Path Analysis Technique, International Conference
  on Software Testing Analysis Review, November
  2002.
• Alexander, Ian, Zink, Thomas An Introduction
  to System Engineering with Use Cases, Institute
  of Electrical Engineers Computing and Control
  Engineering Journal, December 2002.
• Alexander, Ian Misuse Cases Use Cases with
  Hostile Intent, IEEE Software, January/February
  2003.
• Buhr, R.J.A Casselman, R.S. Use Case Maps for
  Object Oriented Systems, Prentiss-Hall, 1996.
• Cockburn, Alistair Writing Effective Use Cases,
  Addison-Wesley, 2001.
• Jacobson, Ivar, et al Object Oriented Software
  Engineering A Use Case Driven Approach,
  Addison-Wesley, 1992.
• Shiri, Maryam Hassine, J Rilling, J A
  Requirement Level Modification Analysis Support
  Framework, Third International IEEE Workshop on
  Software Evolvability, October 2007.
• Wu, Weihang Kelly, Tim Deriving Safety
  Requirements as Part of System Architecture
  Definition, Proceedings of 24th International
  System Safety Conference, August 2006.

37
References II

• Feodoroff, Ray Software Maintenance and Support
  of Missions Systems Assets - Specification,
  Assessment and Qualification of Enabling
  Products, 2nd ADF Software Symposium, May 2006.