Abstract

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

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

3. Content Design Acceptance in a Sustainment Environment Sustainment Challenges Requirements for a Sustainment RM&E Approach A Proposal for a RM&E Solution

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

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

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

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

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

9. Sustainment Challenges – Work Scope Sustainment is heavily dependent on the finances available. Right  On Time Pick Two On Budget$$

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

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

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

13. Sustainment Challenge – Develop & Maintain SSA Expertise Developers lack experience with tools Tool Disparity complicates development of expertise Tool Complexity Long Project Lifecycles

14. Sustainment Challenge – Obsolescence...

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

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

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

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

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

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

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

22. The Approach - Transferable Technology Toolset Supported Methodology Applicable across multiple systems Amortisable Development and Training Costs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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