Requirements Management with Use Cases
Download
1 / 37

Abstract - PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Abstract' - vincent-mckenzie


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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


Abstract
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
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 Acceptance in a Sustainment Environment

Specification of Technical Requirements

Airworthiness Requirements

Functional/Performance Requirements

Evidence

(Verification of SOR Requirements)

ADF Oversight

  • 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


Da specification acquisition vs sustainment
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
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
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
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


Sustainment challenges work scope
Sustainment Challenges – Work Scope

Sustainment is heavily dependent on the finances available.

Right 

On Time

Pick Two

On Budget$$


Sustainment challenges work scope1
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
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
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
Sustainment Challenge – Develop & Maintain SSA Expertise

Developers lack experience with tools

Tool Disparity complicates development of expertise

Tool Complexity

Long Project Lifecycles



Sustainment challenge applying oem rm e
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
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 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
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
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
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
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
The Approach - Transferable Technology

Toolset Supported Methodology

Applicable across multiple systems

Amortisable Development and Training Costs


The approach need for future proofed solution
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 solution1
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
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 solution1
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
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
Use Cases in the System Lifecycle

User Viewpoint

System Context

Scenario UC

CONOPS style

TE Viewpoint

AD Test Cases

V&V 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 TE Viewpoint

S/S AD/DD Test Cases

S/S V&V 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

S/S TE Viewpoint

S/S AD/DD Test Cases

S/S V&V 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

Sub-Systems

Development

Use Cases

S/S TE Viewpoint

S/S AD/DD Test Cases

S/S V&V 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


Use cases as specification
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 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 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 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 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


What next more investigation
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
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
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
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.


ad