files: 74

This data as json

rowid	image	timestamp	memento	first_capture	last_capture	current_status	text	mime	status	url	urlkey	digest	length	file_path
74		20120507034749	https://web.archive.org/web/20120507034749/http://www.defence.gov.au/dgta/Documents/DAVENG/Software%20Symposium%20documents/2008/Presentations/Requirements%20Management%20with%20Use%20Cases%20(Smith).ppt	2012-05-07	2012-05-07	404	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 Sustainment of Software Intensive Systems under the Technical Airworthiness Framework presents unique challenges. The Software Support Agency (SSA) is required to perform sustainment activities such that Design Acceptance activities may be satisfactorily completed by the DAR while the SSA maintains appropriate levels of traceability to design changes and quality of requirements specifications. These challenges are further complicated by the need for rapid and efficient transfer of technology and expertise by the SSA to different systems with widely varying support facilities and which have varying quality of requirements baselines and toolsets. These are challenges that are specific to maintenance environments. They are not necessarily present when specifying a new system acquisition. As such, the specification methods used on new acquisitions are not always appropriate in the software sustainment environment. Furthermore, engineering must produce modified system products in a change focussed environment which is scope limited to the requested changes. BAE Systems, as an AEO and SSA for the AP-3C Mission and Weapon System software, is confronting challenges such as these by addressing the means and methods used to specify functional enhancements and fault corrections to the various elements of the AP-3C Weapon System under the current ITTF Software Support Contract and soon, the Mission System Support Contract. This paper will review some of the issues that can affect the sustainment of software systems. The paper will present Use-Cases as a means for capturing the specification of defect corrections and functional enhancements and their application to successive system engineering activities. Content – Design Acceptance in a Sustainment Environment – Sustainment Challenges – Requirements for a Sustainment RM&E Approach – A Proposal for a RM&E Solution Design Acceptance in a Sustainment Environment Design Approval Certificate Engineering Agency Competency (Compliance assurance) Evidence (Verification of SOR Requirements) ADF Oversight Airworthiness Requirements Specification of Technical Requirements Functional/Performance Requirements – How to Manage Changes to Requirements... – How to maintain SSA competency: – Vs obsolete tools – Vs inconsistent data – Vs documentation issues How to trace design changes from requirement through to test... – How to ensure SSA EMS goals are met... ...In A Sustainment Environment? DA: Specification - Acquisition vs Sustainment – New Product Style – Developer is OEM – Specification is for complete product – Updates managed as engineering deltas to Acquisition Specification (CCP/ECP) – Design is a complete Product. – traceable to the specification of requirements – is derived from the updated specs, tested and delivered – What are the OEMs liabilities: – takes “ownership” of PBL – “lock, stock, and two smoking barrels” – is liable for ALL aspects of the product – includes latent defects – Changed Product Style – Developer is SSA – Specification is for product changes – Updates managed as engineering deltas to the Product – Design is a set of changes to be applied to the Product – traceable to the change specification – is derived from change specs, tested and delivered – What are the SSAs liabilities: – “owns” the changes only – Only liable for defects in resultant product – within the changes – And as a direct result of the changes DA: Competency – SSA must have active AEO delegation – be competent to perform the work – Which really means: – Certified to ISO 9001:2000 – EMS commensurate with CMMI Level 2 – Standards based – ISO 15288, EIA 632, ISO/IEC 12207, etc – For AP-3C SSA this means: – Understands and can apply the GFD Systems Engineering and SW Development Environments to the requested tasks. DA: Verification – Traceability of User Requirements to Design Changes – Implies the need for Requirements Management and Engineering process within the SSA EMS. – Trace Customer requirements to – design artefacts – the modifications of the product baseline. – Without a verifiable traceability, – you might get more or less than bargained for... DA: Certification – The AEO Design Certificate is the final artefact of the engineering process that generates the deliverable product. – It is a document covering the product description documentation – i.e Design Record Index – For it to be valid and effective, the DC must be physically traceable to the SOR. – Good traceability is equated with clear and unambiguous records – Traceability Table or Matrix – Links artefacts with sufficient detail – Eg Test Cases in the test plan linked to requirements in the SOR. SOR Design Certificate & DRI Sustainment Challenges – Work Scope – Sustainment is heavily dependent on the finances available. Pick Two Pick Two Right  On Budget $$ On Time  Sustainment Challenges – Work Scope – Sustainment effort is only expended where it is most needed – to provide an overall balanced capability. – Management shifts focus and $$s to where the need is greatest Sustainment Challenges – TCO: Today or Tomorrow? – The focus is NOT on Total Cost of Ownership – Opportunities for minimising TCO are being missed or ignored – SSA is only tasked to produce deltas to the product baseline – No opportunity for Futureproofing Sustainment Challenges – Tool Support Issues – Dwindling support for obsolete COTS tools – Multiple disparate tools across Multiple Systems = Multiple learning curves – The tools installed in the AP-3C SE Environment are obsolete – Non-standard UI idioms – Expertise is not a readily available commodity – In Use of Tools – In support of Tools Sustainment Challenge – Develop & Maintain SSA Expertise – Developers lack experience with tools – Tool Disparity complicates development of expertise – Tool Complexity – Long Project Lifecycles Sustainment Challenge – Obsolescence... Sustainment Challenge – Applying OEM RM&E – Past DMS sustainment projects have: – applied OEM RM&E methodology, or – attempted to manage changes only – All have “degraded” the requirements and design data to some degree – Sustainment activities accelerate the natural degradation of design data – If left unchecked, the end result is a system that is too expensive to maintain "A Stitch, in time, saves nine!" old proverb OEM RM&E Issues - Quality and Consistency of GFD – The design data and requirements, as delivered, do not always totally agree or are ambiguous. – Has a direct effect on cost to repair “You don't know what you don't know... ... until you find out.” OEM RM&E Issues - Poorly Documented RM&E Methods – OEM Documentation tends to be sparse – Quality of transferred knowledge – Does published information communicate the intent? – Tacit Knowledge is, by definition, rarely, if ever, passed on to the SSA. – Information re-discovery relies on Maintainer epiphanies. [Feodoroff, 2006] – A part of a broader issue that affects all SSAs – "Maintainer's Lament". [Feodoroff, 2006] – i.e. poor Software Transition – OEM RM&E methods were not well covered in official training delivered to SSA by PA5276 training contractor. – 2x lost tacit knowledge Lost Knowledge OEM Training Sub-Contractor Trainee SSA Conclusion on OEM RM&E – We are not able to avoid the eventual obsolescence of a system – What little time and money is available for sustainment needs to be spent wisely – The RM&E methodology used during acquisition may not be suitable for the sustainment phase for a variety of reasons – The Design Data is a liability through inconsistency, ambiguity, incompleteness. "Fit the tool to the process... ...Not the process to the tool." The Challenge – A Summary – Right now in the AP-3C Sustainment environment: – the developers must become experts – On different systems – With different support environments – Quickly with little or no prior experience to rely on – Juniors particularly – even though the basic tasks that make up the systems' lifecycles are essentially the same. – Sustainment activities at the ITTF are heavily constrained by time and cost. – There is no leeway to include activities to perform groundwork for future development activities unless explicitly tasked to do so. Requirements for an RM&E Approach – A single methodology is required – That provides – Transferable Expertise – Transferable Technology – A Future Proofed Solution to RM&E Issues “All animals are to be skinned the same way...” The Approach - Transferable Expertise – Streamline the lifecycle activities for the different systems – Developers need only be trained in RM&E once – Developers build a base set of reuseable skills The Approach - Transferable Technology – Toolset Supported Methodology – Applicable across multiple systems – Amortisable Development and Training Costs The Approach – Need for Future-Proofed Solution – The current work focus is the completion of current planned DMS work. – In Jan 09 the focus shifts to the OMS. – DMS SW development will be scaled back. The Approach – Need for Future-Proofed Solution – What use will DMS specific skills be on OMS? – Different Tools – ReQuire/StP vs System Architect vs RTM – Different SW Architectures – Embedded vs General Purpose – Different Sizes – Single SW System vs System of Systems – Different purposes – Airborne Mission vs Ground Simulator – Both are SW Systems – With Users – With System level behaviour – With Design level behaviour – Needing to be tested “The more things change, the more they stay the same” The Solution – System Independent – Applicable across multiple systems – Complementary data – Enhances existing Requirements & design data – Traceable artefacts – Provides effective traceability throughout a sustainment project – Ease of Use – Easily learnt skills – De Facto Standard – Wide Support – Broad scope applicability – Useful throughout development lifecycle Use Case Use Case Modelling ! Modelling ! The Solution – Use Case Maps – Describe specific behaviours of a system wrt interactions with the environment – Capture behaviour descriptions from system level down to implementation level – Provide support for whole lifecycle – Identification of CONOPS, System Requirements & Functional Requirements – Daniels & Bahill, 2004., Alexander & Zink, 2002. – Identification of Safety Requirements – Wu & Kelly, 2006, Alexander, 2003. – Recording operation of design – Buhr & Casselman, 1996. – Identification of test cases – Ahlowalia, 2002. – Identification of SW Modification Impacts – Shiri, et al. 2007 – Can be used to fill in the gaps in understanding of system operation and design Benefits of Use Cases – Easy to learn & Low Cost. [Cockburn, 2001] – Learn Once - Use Many – Proven and mature technology [Google - ~63M pages in english] – Acquirer - Supplier alignment S/S V&V Viewpoint S/S Reqts Test Cases S/S V&V Viewpoint S/S Reqts Test Cases S/S TE Viewpoint S/S AD/DD Test Cases S/S TE Viewpoint S/S AD/DD Test Cases S/S S/W E Viewpoint S/S Design S/S Functional Reqts S/S Analytical UC S/S S/W E Viewpoint S/S Design S/S Functional Reqts S/S Analytical UC S/S User Viewpoint S/S Context S/S Scenario UC S/S CONOPS/Analytical S/S User Viewpoint S/S Context S/S Scenario UC S/S CONOPS/Analytical Use Cases in the System Lifecycle RA AD SIT FQT RA RA RA AD AD AD/DD SIT SIT IT FQT FQT FQT User Viewpoint System Context Scenario UC CONOPS style SE Viewpoint System Design Functional Reqts Analytical UC 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 TE Viewpoint AD Test Cases V&V Viewpoint Reqts Test Cases System Level Sub-Systems Level System Development Use Cases Sub-Systems Development Use Cases Use Cases as Specification – Identification of sustainment activities: – in particular for Fault Corrections. – Fault corrections are rarely requirements changes – Don't treat them as such – incorrectly treated as requirements in the system requirements database results in assorted difficulties – Use cases can specify the expected behaviour – that is not being exhibited by an aberrant system. – Identify System Capability – Identify Change Impacts – Traceable to SOR Use Cases as Design – Use Cases are hierarchical – Upper levels specify operational viewpoint – Black Box view of system behaviour – Lower levels specify behaviour with greater specifics – Incorporate design decisions – White Box view of system behaviour – Support traditional structured design with model based design approach – Provide descriptions of module interactions & macro behaviour – Clear text and graphical descriptions – enhance readability & general system comprehension – increase understanding of extant design documentation – shortens ramp-up time of new engineers to project Use Case as Test Case – Use Case = Test Case – Use cases can be used to develop the Test Cases – Ahlowalia describes a method for extracting Test Cases from the Use Cases using “Path Analysis Technique” [Ahlowalia 2002]. – Use Cases used to identify normal vs aberrant behaviour – basis of test cases to prove implementation of solution – Use Cases used to identify normal use and mis-use processing – basis of test cases to perform tests of error handling. Use Cases and Traceability – Use Cases are specific documented artefacts. – They can and should be uniquely identified – recorded as part of a system's development. – They can provide the glue that links requirements (in System Level UCs) with the Design (in Design UCs) and the Test Cases – Traditional traceability can be extended to include Use Cases in traceability tables. Use Case as User Manual – Use Cases are descriptions of a system's interactions with actors and the environment – They provide input to development of User documentation – For SDRs can be used to capture intended operation – Test Cases from the Use Cases verify the User Documentation User Man Use Cases Fault Analysis Document Update What Next? - More Investigation – UCM Capabilities – as a requirement gathering tool – User Requirement Notation (URN) – Goal-oriented Requirement Language (GRL) – as a design capture tool – as a test case generation tool – as a User Documentation assessment tool – Feasability of UCM application – Deployment Planning – BAES Management buy-in – CoA buy-in – Logisitics – Training development – Process development – Tool Selection and Support – Pilot Trials – Build ground-swell of support In Summary – Use Cases support all phases of the System Engineering Lifecycle. – They are easy to learn – They provide support for identification of requirements – Functional, Safety, etc – They are applicable to any system – That interacts with external entities – That produces observable outputs – Defacto Standard via UML – with broad industry support and application References I – Ahlowalia, Naresh: Testing from Use Cases using Path Analysis Technique, International Conference on Software Testing Analysis & Review, November 2002. – Alexander, Ian, & Zink, Thomas: An Introduction to System Engineering with Use Cases, Institute of Electrical Engineers Computing and Control Engineering Journal, December 2002. – Alexander, Ian: Misuse Cases: Use Cases with Hostile Intent, IEEE Software, January/February 2003. – Buhr, R.J.A & Casselman, R.S.: Use Case Maps for Object Oriented Systems, Prentiss-Hall, 1996. – Cockburn, Alistair: Writing Effective Use Cases, Addison-Wesley, 2001. – Jacobson, Ivar, et al: Object Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992. – Shiri, Maryam; Hassine, J & Rilling, J: A Requirement Level Modification Analysis Support Framework, Third International IEEE Workshop on Software Evolvability, October 2007. – Wu, Weihang & Kelly, Tim: Deriving Safety Requirements as Part of System Architecture Definition, Proceedings of 24th International System Safety Conference, August 2006. References II – Feodoroff, Ray: Software Maintenance and Support of Missions Systems Assets - Specification, Assessment and Qualification of Enabling Products, 2nd ADF Software Symposium, May 2006.	application/vnd.ms-powerpoint	200	http://www.defence.gov.au/dgta/Documents/DAVENG/Software%20Symposium%20documents/2008/Presentations/Requirements%20Management%20with%20Use%20Cases%20(Smith).ppt	au,gov,defence)/dgta/documents/daveng/software%20symposium%20documents/2008/presentations/requirements%20management%20with%20use%20cases%20(smith).ppt	BTOBSV2BM4UXHKJ54PEHYTRACLG6JF6Z	1343247	domains/defence-gov-au/powerpoints/original/au-gov-defence-dgta-documents-daveng-software-20symposium-20documents-2008-presentations-requirements-20management-20with-20use-20cases-20-smith-ppt-20120507034749.ppt