Transcript Requirements Management with Use Cases Specification of

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
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.
Content
–
–
–
–
Design Acceptance in a Sustainment Environment
Sustainment Challenges
Requirements for a Sustainment RM&E Approach
A Proposal for a RM&E Solution
Design Acceptance in a Sustainment Environment
Engineering Agency Competency
(Compliance assurance)
Specification of Technical Requirements
Airworthiness
Requirements
Functional/Performance
Requirements
Evidence
(Verification of SOR Requirements)
– How to maintain SSA
competency:
– Vs obsolete tools
– Vs inconsistent data
– Vs documentation
issues
– How to Manage Changes to
Requirements...
...In A Sustainment Environment?
How to trace design changes
from requirement through
to test...
ADF Oversight
Design Approval Certificate
– How to ensure SSA EMS goals
are met...
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
DA: Competency
– SSA must have active AEO delegation
– be competent to perform the work
– Which really means:
– Certified to ISO 9001:2000
– 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.
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...
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.
SOR
Design
Certificate
& DRI
Sustainment Challenges – Work Scope
– Sustainment is heavily dependent on the finances available.
Right 
On Time

Pick Two
On Budget
$$
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
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
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
Sustainment Challenge – Develop & Maintain SSA Expertise
–
–
–
–
Developers lack experience with tools
Tool Disparity complicates development of expertise
Tool Complexity
Long Project Lifecycles
Sustainment Challenge – Obsolescence...
Sustainment Challenge – Applying OEM RM&E
– Past DMS sustainment projects have:
– applied OEM RM&E 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
OEM RM&E 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.”
OEM RM&E Issues - Poorly Documented RM&E 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 RM&E 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
Conclusion on OEM RM&E
– 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 RM&E 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."
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.
Requirements for an RM&E Approach
– A single methodology is required
– That provides
– Transferable Expertise
– Transferable Technology
– A Future Proofed Solution to RM&E Issues
“All animals are to be skinned the same way...”
The Approach - Transferable Expertise
– Streamline the lifecycle activities for the different systems
– Developers need only be trained in RM&E once
– Developers build a base set of reuseable skills
The Approach - Transferable Technology
– Toolset Supported Methodology
– Applicable across multiple systems
– Amortisable Development and Training Costs
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.
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”
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 !
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
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
Use Cases in the System Lifecycle
System
Development
Use Cases
System
Level
Sub-Systems
Level
Sub-Systems
Development
Use Cases
User Viewpoint
System Context
Scenario UC
CONOPS style
RA
SE Viewpoint
System Design
Functional Reqts
Analytical UC
TE Viewpoint
AD Test Cases
AD
RA
RA
RA
S/S User Viewpoint
S/S User Viewpoint
Context
S/SS/S
User
Viewpoint
S/S Context
Scenario UC
S/SS/S
Context
S/S Scenario UC
CONOPS/Analytical
S/SS/S
Scenario
UC
S/S CONOPS/Analytical
S/S CONOPS/Analytical
AD
AD
AD/DD
V&V Viewpoint
Reqts Test Cases
SIT
SIT
SIT
IT
S/S S/W E Viewpoint
S/S TE Viewpoint
S/S S/W E Viewpoint
Design
S/S TE Viewpoint
S/SS/S
S/W
E Viewpoint
S/S
Test
S/S Design
TEAD/DD
Viewpoint
Functional Reqts S/S
S/S AD/DD Test
S/SS/S
Design
S/S Functional Reqts S/SCases
AD/DD Test
Analytical
UC
Cases
S/SS/S
Functional
Reqts
S/S Analytical UC
Cases
S/S Analytical UC
FQT
FQT
FQT
FQT
S/S V&V Viewpoint
S/S V&V Viewpoint
Reqts
Test
S/SS/S
V&V
Viewpoint
S/S Reqts Test
S/SCases
Reqts Test
Cases
Cases
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
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
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.
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.
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
Document
Update
Fault Analysis
Use Cases
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
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
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.
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.