1 / 36

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. Purpose. Frame a discussion about:

yardan
Download Presentation

Requirements Volatility Topic: Using Anchor Point Milestones

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. Many IPTs SystemRqmts System Design Subsystem Rqmts Subsystem Design Software Rqmts Software Design Software Code! Systems Lifecycle © 2007 BAE Systems Land & Armaments L.P.

  14. SystemRqmts System Design Subsystem Rqmts Subsystem Design Software Rqmts Software Design Software Code! Systems Lifecycle © 2007 BAE Systems Land & Armaments L.P.

  15. 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.

  16. 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.

  17. 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.

  18. 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.

  19. 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.

  20. 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.

  21. 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.

  22. 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.

  23. 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.

  24. 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.

  25. 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.

  26. 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.

  27. 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.

  28. 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.

  29. 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.

  30. 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.

  31. 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.

  32. 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.

  33. 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.

  34. 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.

  35. 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.

  36. 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.

More Related