Requirements Management with Use Cases

Specification of Functional Enhancements and Fault Corrections for Improved Requirements Management in a Sustainment Environment

Linton SmithDMS SME, DMS D/SDE

Alex FawcettDMS 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

Design Approval Certificate

Engineering Agency Competency(Compliance assurance)

Evidence (Verification of SOR Requirements)

ADF Oversight

Airworthiness Requirements

Specification of Technical Requirements

Functional/Performance Requirements

– How to Manage Changes to Requirements...

– How to maintain SSA competency:

– Vs obsolete tools – Vs inconsistent data– Vs documentation

issues

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

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

...In A Sustainment Environment?

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.

SORDesign

Certificate& DRI

Sustainment Challenges – Work Scope

– Sustainment is heavily dependent on the finances available.

Pick TwoPick Two

Right

On Budget$$

On Time

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

Lost Knowledge

OEM Training Sub-Contractor Trainee SSA

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 CaseUse CaseModelling !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

S/S V&V ViewpointS/S Reqts Test Cases

S/S V&V ViewpointS/S Reqts Test Cases

S/S TE ViewpointS/S AD/DD Test Cases

S/S TE ViewpointS/S AD/DD Test Cases

S/S S/W E ViewpointS/S DesignS/S Functional ReqtsS/S Analytical UC

S/S S/W E ViewpointS/S DesignS/S Functional ReqtsS/S Analytical UC

S/S User ViewpointS/S ContextS/S Scenario UCS/S CONOPS/Analytical

S/S User ViewpointS/S ContextS/S Scenario UCS/S CONOPS/Analytical

Use Cases in the System Lifecycle

RA AD SIT FQT

RARARA

ADADAD/DDSITSITIT

FQTFQTFQT

User ViewpointSystem ContextScenario UCCONOPS style

SE ViewpointSystem DesignFunctional ReqtsAnalytical UC

S/S User ViewpointS/S ContextS/S Scenario UCS/S CONOPS/Analytical

S/S S/W E ViewpointS/S DesignS/S Functional ReqtsS/S Analytical UC

S/S TE ViewpointS/S AD/DD Test Cases

S/S V&V ViewpointS/S Reqts Test Cases

TE ViewpointAD Test Cases

V&V ViewpointReqts Test Cases

SystemLevel

Sub-SystemsLevel

SystemDevelopmentUse Cases

Sub-SystemsDevelopmentUse 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

Use Cases

Fault AnalysisDocument Update

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.