requirements volatility topic using anchor point milestones l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Requirements Volatility Topic: Using Anchor Point Milestones PowerPoint Presentation
Download Presentation
Requirements Volatility Topic: Using Anchor Point Milestones

Loading in 2 Seconds...

play fullscreen
1 / 36

Requirements Volatility Topic: Using Anchor Point Milestones - PowerPoint PPT Presentation


  • 122 Views
  • Uploaded on

Requirements Volatility Topic: Using Anchor Point Milestones. February 14, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems. Purpose. Frame a discussion about:

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 'Requirements Volatility Topic: Using Anchor Point Milestones' - yardan


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 volatility topic using anchor point milestones
Requirements Volatility Topic:Using Anchor Point Milestones

February 14, 2007

Tom Schroeder

FCS MGV Software Engineering Manager

BAE Systems, Ground Systems

© 2007 BAE Systems Land & Armaments L.P.

purpose
Purpose

Frame a discussion about:

  • What are the major software-intensive systems risks related to Requirements Volatility with respect to experiences using Anchor Point Milestones?
  • What are the current best practices for addressing these risks?
  • What are the top-priority research topics for addressing the risks?

© 2007 BAE Systems Land & Armaments L.P.

outline
Outline
  • Perspective - Company Background & Projects
  • Software Build 1 Lesson in Requirements
  • Idealized Software Build Life Cycle
  • Extending the Software Life Cycle to Systems and SOS Levels
  • Hard Questions to Answer about LCO’s and LCA’s
  • Sources of Requirements Volatility

© 2007 BAE Systems Land & Armaments L.P.

ground systems a summary
Ground Systems – A Summary
  • Protected Fighting Platforms for Today’s Warfighter as well as the Battlefield of Tomorrow
    • Predominant Supplier to the U.S. Army Heavy Brigades with Bradley, HERCULES, Paladin, M113
    • Mine-Protected Wheeled Vehicles
    • FCS Manned Ground Vehicles and Armed Robotic Vehicle
  • Key Technologies
    • Advanced Protection and Mobility Solutions for Soldiers, Manned Vehicles and Robots
    • Outstanding Program Management and Experienced Workforce
    • 3,250 employees, including more than 600 technologists
  • World-Class Development Processes
    • CMMI Level 5 Software and Systems Engineering Process
    • Physics-Based Models & Real-Time Simulation Capabilities
    • Rapid Prototyping of Complex Systems
  • Lean, Cost-effective Production Facilities

GS is a modern, efficient, full-spectrum developer, integrator and supplier of survivable, lethal ground combat platforms and advanced technologies

© 2007 BAE Systems Land & Armaments L.P.

fcs brigade combat team bct 18 integrated systems 1 network 1 soldier

Manned Systems

Unmanned Aerial Vehicles

Infantry Carrier

Vehicle (ICV)

Class IV

Command and

Control Vehicle (C2V)

Class III

Class II

Class I

Mounted Combat System (MCS)

Unattended Munitions

Intelligent

Munitions

Systems

NLOS LS

Unattended Ground Sensors

Reconnaissance and

Surveillance Vehicle (RSV)

Unmanned Ground Vehicles

Non-Line of Sight

Cannon (NLOS-C)

Non-Line of Sight Mortar (NLOS-M)

Small

(Manpackable) UGV

ARV Aslt

ARV RSTA

FCS Recovery and

Maintenance Vehicle (FRMV)

Medical Vehicle

Treatment (MV-T)

Armed Robotic

Vehicle (ARV)

MULE

(Countermine)

MULE

(Transport)

Medical Vehicle

Evacuation (MV-E)

ARV-A (L)

FCS Brigade Combat Team (BCT)18 Integrated Systems + 1 Network + 1 Soldier

FCS is about the 21st Century Soldier

© 2007 BAE Systems Land & Armaments L.P.

Approved for Public Release, Distribution Unlimited, TACOM 20 SEP 2006, case 06-208.

software build 1 objectives
Software Build 1 Objectives
  • Build initial prototype vehicles for one vehicle type (“variant”), the Non-Line of Sight Cannon (NLOS-C)
  • Develop “threshold path” common components and software for a common chassis.
    • Hybrid Electric Drive Powertrain, Driving functions, Vehicle Management
    • Power Distribution, Remote Interface Units, Servo Control Units
    • Embedded Training
  • Develop “threshold path” mission equipment and software for the weapon and mission control functions
  • Develop low-cost software and hardware “surrogates” to stand-in for functionality that is not yet available, such as the sustainment system, the displays and user interface system, etc.
  • Develop and improve processes for software development and integration
  • Reduce risk for objective vehicles and software development

© 2007 BAE Systems Land & Armaments L.P.

a software build 1 lesson in requirements

System / Subsystem Activity

Sys/Subsys Requirements Focus

Sys/Subsys Design Focus

DR1 (SFR)

DR2 (PDR)

RBR

Software Activity

Inception (Rqmts Focus)

Elaboration (Design Focus)

LCO

LCA

Software Activity

RBR Recovery

LCO / DR2 Issues

LCA

Completion

LCO

LCA

Inception (Rqmts Focus)

During this period most effort was needed to develop SRSs and IRSs

Elaboration (Design Focus) During this period, time for software architecture work was too short, resulting in an LCA slip

A Software Build 1 Lesson in Requirements
  • Systems Engineering selected a waterfall life cycle. Software Engineering selected an iterative life cycle.
  • Software Engineering introduced a new event, Requirements Baseline Review (RBR) as a handoff to receive the requirements allocated to Software from Systems & Subsystems. RBR was not in the IMP, so it lacked completion criteria.
  • At RBR, Software evaluated allocated Subsystem requirements. Quality issues resulted in an intense three-month systems/software “RBR Recovery” effort, but LCO wasn’t allowed to slip. Requirements rework was finally resolved during the first half of LCA, but it pushed the LCA milestone out, reducing time for construction iterations.

© 2007 BAE Systems Land & Armaments L.P.

build 1 common sw schedule
An adjustment of iteration durations was preferable to inserting an iteration.

Turns out that systems and subsystems engineering has provided every subsequent software iteration with necessary updates, aka beneficial “Requirements Volatility.”

Build 1 Common SW Schedule

© 2007 BAE Systems Land & Armaments L.P.

build 1 lco and lca statistics
Build 1 LCO and LCA Statistics
  • LCO October 3-21, 2005
  • Participation by 68 Reviewers
    • 10 IPT Areas Reviewed
    • 55 Artifacts Reviewed
    • 2059 Comments Received
  • 60% of All Comments from SRS/IRS
    • Most HIGH priority comments were submitted against the SRS/IRS
  • LCA Stage 1 February 16-27, 2006
  • LCA Stage 2 March 27–April 21, 2006
  • Participation by 83 Reviewers
    • 11 IPT Areas Reviewed
    • 68 Artifacts Reviewed
    • 2499 Comments Received

© 2007 BAE Systems Land & Armaments L.P.

a software build 1 lesson in requirements10
A Software Build 1 Lesson in Requirements
  • Why was LCO held steady?
    • Award Fee tied to “successful LCO”
    • Needed to hold schedule for some Subsystem software teams
    • Systems/subsystems engineering functions would need support future software iterations, although not explicitly in their plans to do so
  • Why was LCA moved 6 weeks instead of adding a new cycle?
    • Award Fee tied to “successful LCA”
    • First part of LCA period dedicated to addressing requirements issue work plans resulting from both RBR and LCO
    • Needed time to make software design progress to meet LCA criteria, and customer willing to grant extension provided time made up in construction iterations
    • An iteration no-go decision was not a viable option for the software teams
      • Technologies in use were relatively mature, risks were manageable, and vehicle schedules too important to move

© 2007 BAE Systems Land & Armaments L.P.

idealized software build life cycle
Idealized Software Build Life Cycle

Start

Year 1

Year 2

DI 1.1

SW

SIT

SwLCO

Inception

Phase

DI 1.2

SW

SIT

DI 1.3

SW

SIT

SwLCA

Elaboration

Phase

DI 1.4

SW

SIT

DI 1.5

SW

SIT

Construction

Phase

Acronyms and Abbreviations

DI b.c Development Increment, Build b, Increment c

IOC Initial Operational Capability

LCA Life Cycle Architecture Milestone

LCO Life Cycle Objectives Milestone

SI Software Item

SIT Software Subsys/Sys Integration & Test

SW Software Engineering (incl. SI-Level Int & Test)

SwLCA Software LCA

SwLCO Software LCO

TRR Test Readiness Review (SI Level)

DI 1.6

SW

SIT

TRR

IOC

DI 1.7

SW

SIT

SW

SIT

Transition

Phase

DI 1.8

© 2007 BAE Systems Land & Armaments L.P.

idealized systems and software integrated build life cycle

SyLCO

SyLCA

Idealized Systems and Software Integrated Build Life Cycle

Start

Year 1

Year 2

By adding Systems & Subsystems requirements and design engineering stages synchronized with Software development increments, upstream work products can be worked iteratively to support Software.

Software can provide valuable implementation feedback to Systems & Subsystems teams, with pre-planned learning adjustments.

DI 2.1

S/SS

SW

SIT

SwLCO

Inception

Phase

DI 2.2

S/SS

SW

SIT

Consider introduction of Systems LCO and LCA events. Software support would be a subset of Systems Engineering total scope.

DI 2.3

S/SS

SW

SIT

SwLCA

Elaboration

Phase

DI 2.4

S/SS

SW

SIT

DI 2.5

S/SS

SW

SIT

Acronyms and Abbreviations

DI b.c Development Increment, Build b, Increment c

IOC Initial Operational Capability

LCA Life Cycle Architecture Milestone

LCO Life Cycle Objectives Milestone

S/SS Systems/Subsystems (IPT) Engineering

SI Software Item

SIT Software Subsys/Sys Integration & Test

SW Software Engineering (incl. SI-Level Int & Test)

SwLCA Software LCA

SwLCO Software LCO

SyLCA Systems/Subsystems LCA

SyLCO Systems/Subsystems LCO

TRR Test Readiness Review (SI Level)

Construction

Phase

DI 2.6

S/SS

SW

SIT

TRR

IOC

DI 2.7

S/SS

SW

SIT

S/SS

SW

SIT

Transition

Phase

DI 2.8

© 2007 BAE Systems Land & Armaments L.P.

systems lifecycle

Many IPTs

SystemRqmts

System Design

Subsystem Rqmts

Subsystem Design

Software Rqmts

Software Design

Software Code!

Systems Lifecycle

© 2007 BAE Systems Land & Armaments L.P.

systems lifecycle14

SystemRqmts

System Design

Subsystem Rqmts

Subsystem Design

Software Rqmts

Software Design

Software Code!

Systems Lifecycle

© 2007 BAE Systems Land & Armaments L.P.

systems lifecycle15

to the worldof integration

SystemRqmts

System Design

Subsystem Rqmts

Subsystem Design

Software Rqmts

Software Design

Software Code!

SRSIRS

SDDIDD

CodeSVD

PIDS

SSDD

CIDSICD

SSDD

‘L3’ Rqmtsin DOORS

‘L4’ Rqmtsin DOORS

SE AL0.2Model

Sw IntegThreads

SW Item Design Model

SE AL1UML Model

SE AL2 UML Model

SW UML Model

SADD

SWARCHNotes

SDS

DDMs

DDMs

= Influences

Systems Lifecycle

Requirements are “realized” through design processes to become the next tier’s requirements which in turn are “realized” …

What is the turn-around time to change requirements with this process?

Work Products

© 2007 BAE Systems Land & Armaments L.P.

workflow integration

SW Mgmt & Env

SW Rqmts

SW Design

SW C&UT

SW I&T

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

Sys PIDS/AL1 Rq

Sys PIDS/AL1 Rq

Sys Design

Sys Design

Sys Spec/Alloc

Sys Spec/Alloc

SSys AL2 Rq

SSys AL2 Rq

SSys Design

SSys Spec/Alloc

SW Mgmt & Env

SW Mgmt & Env

SW Rqmts

SW Rqmts

SW Design

SW Design

SW C&UT

SW C&UT

SW I&T

SW I&T

CMN SW I&T Env

CMN SW Int

CMN SW Test

CMN SW Test

VNT SW I&T Env

VNT SW I&T Env

VNT SW Int

VNT SW Int

VNT SW Test

VNT SW Test

© 2007 BAE Systems Land & Armaments L.P.

workflow integration17

CMN SW I&T Env

CMN SW Int

CMN SW Test

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

Sys PIDS/AL1 Rq

Sys PIDS/AL1 Rq

Sys Design

Sys Design

Sys Spec/Alloc

Sys Spec/Alloc

SSys AL2 Rq

SSys AL2 Rq

SSys Design

SSys Spec/Alloc

SW Mgmt & Env

SW Mgmt & Env

SW Mgmt & Env

SW Rqmts

SW Rqmts

SW Rqmts

SW Design

SW Design

SW Design

SW C&UT

SW C&UT

SW C&UT

SW I&T

SW I&T

SW I&T

CMN SW I&T Env

CMN SW Int

CMN SW Test

CMN SW Test

VNT SW I&T Env

VNT SW I&T Env

VNT SW Int

VNT SW Int

VNT SW Test

VNT SW Test

© 2007 BAE Systems Land & Armaments L.P.

workflow integration18

VNT SW I&T Env

VNT SW Int

VNT SW Test

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

Sys PIDS/AL1 Rq

Sys Design

Sys Spec/Alloc

SW Mgmt & Env

SW Rqmts

SW Design

SW C&UT

SW I&T

CMN SW I&T Env

CMN SW Int

CMN SW Test

© 2007 BAE Systems Land & Armaments L.P.

workflow integration19

Sys PIDS/AL1 Rq

Sys Design

Sys Spec/Alloc

SSys AL2 Rq

SSys Design

SSys Spec/Alloc

SW Mgmt & Env

Improvement

Improvement

Improvement

Improvement

SW Mgmt & Env

SW Mgmt & Env

SW Mgmt & Env

SW Rqmts

Improvement

Improvement

Improvement

Improvement

SW Rqmts

SW Rqmts

SW Rqmts

SW Design

Improvement

Improvement

Improvement

Improvement

SW Design

SW Design

SW Design

SW C&UT

Improvement

Improvement

Improvement

Improvement

SW C&UT

SW C&UT

SW C&UT

SW I&T

Improvement

Improvement

Improvement

Improvement

SW I&T

SW I&T

SW I&T

CMN SW I&T Env

Improvement

Improvement

Improvement

Improvement

CMN SW I&T Env

CMN SW I&T Env

CMN SW I&T Env

CMN SW Int

Improvement

Improvement

Improvement

Improvement

CMN SW Int

CMN SW Int

CMN SW Int

CMN SW Test

Improvement

Improvement

Improvement

Improvement

CMN SW Test

CMN SW Test

CMN SW Test

VNT SW I&T Env

Improvement

Improvement

Improvement

Improvement

VNT SW I&T Env

VNT SW I&T Env

VNT SW I&T Env

VNT SW Int

Improvement

Improvement

Improvement

Improvement

VNT SW Int

VNT SW Int

VNT SW Int

VNT SW Test

Improvement

Improvement

Improvement

Improvement

VNT SW Test

VNT SW Test

VNT SW Test

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

Sys PIDS/AL1 Rq

Sys Design

Sys Spec/Alloc

SSys AL2 Rq

SW Mgmt & Env

SW Rqmts

SW Design

SW C&UT

SW I&T

CMN SW I&T Env

CMN SW Int

CMN SW Test

VNT SW I&T Env

VNT SW Int

VNT SW Test

© 2007 BAE Systems Land & Armaments L.P.

workflow integration20

Sys PIDS/AL1 Rq

Sys Design

Sys Spec/Alloc

SSys AL2 Rq

SSys Design

SSys Spec/Alloc

SW Mgmt & Env

SW Mgmt & Env

SW Mgmt & Env

SW Mgmt & Env

SW Rqmts

SW Rqmts

SW Rqmts

SW Rqmts

SW Design

SW Design

SW Design

SW Design

Improvement

Improvement

SW C&UT

SW C&UT

SW C&UT

Improvement

SW C&UT

Improvement

Improvement

SW I&T

SW I&T

SW I&T

Improvement

SW I&T

Improvement

Improvement

Improvement

CMN SW I&T Env

CMN SW I&T Env

CMN SW I&T Env

CMN SW I&T Env

Improvement

Improvement

CMN SW Int

CMN SW Int

CMN SW Int

Improvement

CMN SW Int

Improvement

Improvement

CMN SW Test

CMN SW Test

CMN SW Test

Improvement

CMN SW Test

Improvement

Improvement

Improvement

VNT SW I&T Env

VNT SW I&T Env

VNT SW I&T Env

VNT SW I&T Env

VNT SW Int

VNT SW Int

VNT SW Int

VNT SW Int

VNT SW Test

VNT SW Test

VNT SW Test

VNT SW Test

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

Sys PIDS/AL1 Rq

Sys Design

Sys Spec/Alloc

SSys AL2 Rq

SW Mgmt & Env

SW Rqmts

SW Design

SW C&UT

SW I&T

CMN SW I&T Env

CMN SW Int

CMN SW Test

VNT SW I&T Env

VNT SW Int

VNT SW Test

© 2007 BAE Systems Land & Armaments L.P.

workflow integration21

VNT SW I&T Env

VNT SW Int

VNT SW Test

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

Sys PIDS/AL1 Rq

Sys Design

Sys Spec/Alloc

SW Mgmt & Env

SW Rqmts

SW Design

SW C&UT

SW I&T

CMN SW I&T Env

CMN SW Int

CMN SW Test

© 2007 BAE Systems Land & Armaments L.P.

workflow integration22

SSys AL2 Rq

SSys Design

SSys Spec/Alloc

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

SW Mgmt & Env

SW Rqmts

SW Design

SW Design

SW C&UT

SW C&UT

SW I&T

SW I&T

CMN SW I&T Env

CMN SW I&T Env

CMN SW Int

CMN SW Int

CMN SW Test

CMN SW Test

VNT SW I&T Env

VNT SW I&T Env

VNT SW Int

VNT SW Int

VNT SW Int

VNT SW Test

VNT SW Test

VNT SW Test

© 2007 BAE Systems Land & Armaments L.P.

workflow integration23

Sys PIDS/AL1 Rq

Sys Design

Sys Spec/Alloc

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

SSys AL2 Rq

SSys Design

SSys Spec/Alloc

SW Mgmt & Env

SW Rqmts

SW Design

SW C&UT

SW I&T

CMN SW I&T Env

CMN SW Int

CMN SW Test

VNT SW I&T Env

VNT SW Int

VNT SW Test

© 2007 BAE Systems Land & Armaments L.P.

workflow integration24

Sys PIDS/AL1 Rq

Sys PIDS/AL1 Rq

Sys PIDS/AL1 Rq

Sys PIDS/AL1 Rq

Sys PIDS/AL1 Rq

Sys Design

Sys Design

Sys Design

Sys Design

Sys Design

Sys Spec/Alloc

Sys Spec/Alloc

Sys Spec/Alloc

Sys Spec/Alloc

Sys Spec/Alloc

SSys AL2 Rq

SSys AL2 Rq

SSys AL2 Rq

SSys AL2 Rq

SSys AL2 Rq

SSys Design

SSys Design

SSys Design

SSys Design

SSys Design

SSys Spec/Alloc

SSys Spec/Alloc

SSys Spec/Alloc

SSys Spec/Alloc

SSys Spec/Alloc

SW Mgmt & Env

SW Mgmt & Env

SW Mgmt & Env

SW Mgmt & Env

SW Mgmt & Env

SW Rqmts

SW Rqmts

SW Rqmts

SW Rqmts

SW Rqmts

SW Design

SW Design

SW Design

SW Design

SW Design

SW C&UT

SW C&UT

SW C&UT

SW C&UT

SW C&UT

SW I&T

SW I&T

SW I&T

SW I&T

SW I&T

CMN SW I&T Env

CMN SW I&T Env

CMN SW I&T Env

CMN SW I&T Env

CMN SW I&T Env

CMN SW Int

CMN SW Int

CMN SW Int

CMN SW Int

CMN SW Int

CMN SW Test

CMN SW Test

CMN SW Test

CMN SW Test

CMN SW Test

VNT SW I&T Env

VNT SW I&T Env

VNT SW I&T Env

VNT SW I&T Env

VNT SW I&T Env

VNT SW Int

VNT SW Int

VNT SW Int

VNT SW Int

VNT SW Int

VNT SW Test

VNT SW Test

VNT SW Test

VNT SW Test

VNT SW Test

Workflow Integration

Construction Iteration ER1(~4 months)

Construction Iteration ER2(~4 months)

Construction Iteration ER3(~4 months)

© 2007 BAE Systems Land & Armaments L.P.

idealized system of systems build life cycle
Idealized System of Systems Build Life Cycle

Start

Year 1

Year 2

Year 3

DI 2.1

SOS

S/SS

SW

SIT

SOSIT

Very difficult to achieve!

SOSLCO

SyLCO

SwLCO

Inception

Phase

DI 2.2

SOS

S/SS

SW

SIT

SOSIT

DI 2.3

SOS

S/SS

SW

SIT

SOSIT

SOSLCA

SyLCA

SwLCA

Elaboration

Phase

DI 2.4

SOS

S/SS

SW

SIT

SOSIT

Acronyms and Abbreviations

DI b.c Development Increment, Build b, Increment c

IOC Initial Operational Capability

LCA Life Cycle Architecture Milestone

LCO Life Cycle Objectives Milestone

S/SS Systems/Subsystems (IPT) Engineering

SI Software Item

SIT Software Subsys/Sys Integration & Test

SW Software Engineering (incl. SI-Level Int & Test)

SOS Systems of Systems Engineering

SOSIOC SOS Initial Operational Capability

SOSIT SOS Software Integration & Test

SOSLCA System of Systems LCA

SOSLCO System of Systems LCO

SwLCA Software LCA

SwLCO Software LCO

SyLCA Systems/Subsystems LCA

SyLCO Systems/Subsystems LCO

TRR Test Readiness Review (SI Level)

DI 2.5

SOS

S/SS

SW

SIT

SOSIT

Construction

Phase

DI 2.6

SOS

S/SS

SW

SIT

SOSIT

TRR

IOC

SOSIOC

DI 2.7

SOS

S/SS

SW

SIT

SOSIT

SOS

S/SS

SW

SIT

SOSIT

Transition

Phase

DI 2.8

© 2007 BAE Systems Land & Armaments L.P.

problems with sos staging
Problems with SOS Staging
  • Synchronizing development to similar iterations across many organizations, each with its own development processes, is extremely difficult
    • Unsynchronized workflows increase the number “surprise” requirements changes
  • Greater numbers of participants tend to stretch out the iterations to make the same amount of progress.
    • Takes time to discover who to coordinate with, and if they have tasking to do so
    • Organizations change, people move around, responsibilities shift, POC’s change
    • Potential O(2) effect with more interactions and interfaces
  • Interface and scope negotiation across many associate teams adds activities and stretches iterations.
    • To make progress, teams are forced to make unilateral decisions
    • From SOS perspective, may be sub-optimal or not even viable system-wide
  • Coordinating compatible requirements to achieve viable functioning threads across associate contractors for small increments is difficult.
  • Incremental SOS use of tactical software can be prohibitively expensive in terms of numbers of computers, simulators, emulators, and plant models needed prior to long-lead time dedicated hardware being available.
  • Intellectual property protection, licensing, and legal involvement increases.

© 2007 BAE Systems Land & Armaments L.P.

hard questions to answer about lco s and lca s
Hard Questions to Answer about LCO’s and LCA’s

What level of completion of Systems Engineering work products is needed for Software to have a successful LCO?

  • A typical answer from Software: All requirements allocated to software need to be specified. Reasons:
    • If Software doesn’t keep up the pressure on Systems Engineering, the Requirements provided to Software will be incomplete. LCO could fail.
    • If Software doesn’t have a complete set of requirements, Software will be unable to complete SRS trace tables to parent requirements.
  • Obvious problem of handoff adequacy and criteria definition
    • Software can try to create a risk that all necessary requirements will not be available
      • “Cry Wolf” approach sure to fail at the Risk Review Board
    • Systems could create a risk that all the Systems work products will not be available for software
      • “Hit Me” approach never seems to emerge, either
    • What should the completeness and completion criteria be?

© 2007 BAE Systems Land & Armaments L.P.

hard questions to answer about lco s and lca s28
Hard Questions to Answer about LCO’s and LCA’s

What level of completion of Systems Engineering work products is needed for Software to have a successful LCO?

  • A typical answer from Systems: All requirements allocated to software will be specified, with traceability to upper-level models. Other documents will be made available as reference (work in progress) leading up to System PDR:
    • System Architecture which may include applicable DDM's, such as Vehicle Electronics Architecture, System/Subsystem Schematics, Specialty Engineering Reports (Security, HFE/MANPRINT, Safety, Maintainability), Sustainment and Training Design Concepts
    • Thread based performance analyses
    • Current Version of Common Subsystem and Variant Level S/SDD's
    • Vehicle External ICD’s - Interfaces to all C4ISR, Sustainment, and Training supplied subsystems.
    • Vehicle Internal ICD’s – Interfaces to MGV Subsystems
    • HW Configuration Item Specifications (HW CIDS - as available)

© 2007 BAE Systems Land & Armaments L.P.

hard questions to answer about lco s and lca s29
Hard Questions to Answer about LCO’s and LCA’s

What level of completion of Software Engineering work products is needed for Software to have a successful LCO/LCA?

  • To pass the LCO/LCA, what percent of the software requirements need to be documented? How is that measured?
    • What is the answer if there are a lot of requirements but the risks are relatively low?
    • What is the answer if there exist some risks, but feasibility analysis indicates they are manageable.
  • At what point should the requirements be baselined?
    • Defines what to measure volatility against
    • Drives how much time is spent in various SCCB’s reviewing requirements changes during development iterations

© 2007 BAE Systems Land & Armaments L.P.

requirements problems specific to software intensive systems
Requirements Problems Specific to Software Intensive Systems
  • Lines between systems engineering and software engineering activities and work products are blurred
    • System/Subsystem/Component Engineers can over-specify requirements, resulting in limited or no opportunities for software engineers to optimize the technical solution
    • Software Engineers conversely may make decisions on what should properly be the purview of systems requirements, and may result in an incomplete system solution
  • What are proper requirement sets for various domains and levels is often open to interpretation
    • Especially when multiple organizations and cultures must interact

© 2007 BAE Systems Land & Armaments L.P.

volatility concerns from using uml for requirements
Volatility Concerns from Using UML for Requirements
  • UML sequence diagrams created by Systems Engineering to develop interfaces and logical behavior requirements pose challenges
    • A sequence represents only one path through a use case
    • A full set of alternative use cases cannot be easily expressed in this form
  • Textual requirements in a DBMS serve as the “official” allocation of requirements to software
    • Some problems translating between use case steps and “shalls”
    • Complete alternative use case specification always a problem
      • In one case, factoring out alternative use cases into a use case or DDM titled “Handle Operational Problem” is a concern.
        • The Mother of all use cases/DDM’s.
  • Software teams are strongly encouraged to use full-up text-based use cases to specify behavior
    • Emphasis on handling all conditions and alternative/exception behavior
      • Can be major feasibility driver!
    • Non-behavioral requirements sections of SRS must be completed
    • Everyone has a requirement to follow Software Design Standards (Architecture Decisions) to address horizontal consistency.
    • UML is used for software design and detailed interface design

© 2007 BAE Systems Land & Armaments L.P.

measuring requirements volatility
Measuring Requirements Volatility
  • Mechanics of counting requirements changes
    • Add requirement
    • Delete requirement
    • Modify requirement
      • Modify can also be achieved by a delete followed by an add
  • What is the requirements count measurement worth? What else could be measured with more value?
    • Consider statistics of implementation risk exposure, or estimated cost to implement considering each requirement
    • Other measures: have observed ratios of SLOC/Requirements Counts from 9 to 300 for different SI’s on BAE Systems programs.
    • Have seen great volatility in requirements measurements caused by simply revising same requirements to be more understandable

© 2007 BAE Systems Land & Armaments L.P.

source of requirements volatility requirements vs design
Source of Requirements Volatility: Requirements vs. Design

Two approaches, sometimes conflicting:

  • Requirements are essential attributes of a system to meet the stakeholders needs
    • The requirements should represent an aspect of essential system behavior
    • Similar systems should have similar levels of specification
    • Avoid overconstraining the specification
  • Requirements describe whatever the stakeholders want
    • A requirement can be specified at any level of the system
    • A requirement for one system might be a design choice for a similar system, depending on who the stakeholders are

Underlying assumption:

  • The designer for a given system scope is granted authority to select and optimize design elements to meet the requirements
  • This requires negotiation and trust between the stakeholders

© 2007 BAE Systems Land & Armaments L.P.

sources of requirements volatility
Sources of Requirements Volatility
  • Actors and Goals
    • All actors were not considered
    • All goals/subgoals of the actors and system were not considered
  • Stakeholders and Interests
    • All stakeholders’ interests were not considered when the system was specified
      • The system must enforce or protect these interests
      • Frequent cause of requirements changes
  • Architecture-derived requirements
    • Aspects of the selected architecture that must be specified for correct operation and to meet quality attributes
    • Can be a strong driver of lower-level requirements
  • General causes of change
    • A stimulus or condition that the system needs to respond to needs to be changed
    • The system response to a stimulus or condition needs to change
    • An architectural decision or constraint causes a change

© 2007 BAE Systems Land & Armaments L.P.

sources of requirements volatility35
Sources of Requirements Volatility
  • The requirement was not obvious, unknown, or sometimes even unknowable at the time of specification
  • Sufficient resources to complete the baseline work were not available
  • All aspects of the requirements effort were not performed
  • Without feedback, the systems/software analyst polishes the requirements until they are perfect (this can go on forever)
  • Emergent behavior not predictable
  • Changes in forces driving the market, threat, technology, needs
  • Architectural and system quality attributes potentially drive foundational changes throughout the system
  • Middleware layers that are not transparent to functionality change
  • COTS products that bring along their own set of requirements and constraints

© 2007 BAE Systems Land & Armaments L.P.

some mechanisms for coping with requirements changes
Some Mechanisms for Coping with Requirements Changes
  • Build an architecture that is specifically designed to accommodate changes within specified limits
    • Product line architecture approach
    • Extensible design patterns
    • Will cost more up front, payoff comes later
    • Cost/benefits analysis and estimation modeling needed to justify
  • Prioritize requirements implementation as dependent variable
    • SAIV, CAIV
    • Hard to say no, but must make decisions
    • Potential research areas: decision analysis approaches, strategies, toolsets, decisions with uncertainty, decision-maker utility functions for consistency and attitude towards risk
  • Reserve budget (cost/schedule) for requirements changes as a function of project parameters. How should this be calculated?

© 2007 BAE Systems Land & Armaments L.P.