Using Doors® And Taug2® To Support A Simplified


Published on

In order to become a market leader, it is imperative that all stakeholders (customers, financial sponsors, developers and testers) be aware of the customer’s needs as captured in the requirements of the products and/or services that are to be produced. This is especially so within both large and small globally distributed companies since the product development organizations often are separated by geography, time and communications. An efficient way to eliminate these potential issues is to develop a common and intuitive requirements management process, which can be deployed across the product development lifecycle. The object of developing a Common Simplified Requirements Management Process is to improve customer satisfaction, eliminate escaping defects and reduce the cost of the development lifecycle. This paper describes the problems of using localised procedures and how these problems can be eliminated by implementing a common requirements management process that is intuitive, scalable and deployed across the System Development Lifecycle. This process has been supported by the industry leading DOORS tool and more recently by the TauG2 tool. An auxiliary benefit of deploying this process is that the process was developed in compliance with standardized methods of documenting and tracing requirements as expected by TL9000 and CMM/CMMI. The net benefits of this simplified requirements process include: increased customer satisfaction due to systems being developed in accordance with the customer’s needs as captured in the requirements, compliance with industry acknowledged process standards and improved cost of quality by eliminating duplication of process maintenance since a common process has been deployed across the development organization.

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • From John Mills Pitch
  • DOORS provides capabilities that are essential for a successful project. All important requirements and related information can be stored in a central database. This database can be accessed in a variety of ways, making this information available to everyone who needs access to it. The information can remain in the database throughout the life of the product, from initial requirements development through the design and implementation phases, to testing and fielding of the final product. Information about the useful life, its potential for reuse, and final disposal can also be stored. By linking the tests to the requirements, you can be sure that the final product meets its requirements. (Day 1) Page -
  • Products are increasing in complexity, to the point that no individual has the ability to comprehend the whole or the technical depth to understand all of its parts. Technologies come and go at a rapid pace, increasing the number of solution options to be evaluated for any product or release. Meanwhile, increased competition has made it essential that product development cycle times be slashed. Development budgets are under significant pressure, highlighting the need for effective strategies for reuse of requirements, technologies, components, decisions, tests, etc. The ability to design the “right thing, right the first time” is paramount. This implies that the “Voice of the Customer” be clearly heard and understood by all parties that participate in product deliveries. Finally, customers are process-savvy. They expect, and often require in writing, that developers follow a comprehensive product development process that yields 100% verification that their requirements have been implemented successfully. Requirements management tools are designed to help you meet these challenges. T-du5v3comb.ppt (Day 1) Page -
  • Using Doors® And Taug2® To Support A Simplified

    2. 2. Overview <ul><li>Problem Statement/Project Objectives </li></ul><ul><li>Simplified Requirements Decomposition Process </li></ul><ul><li>Schema to support Requirements Decomposition Process </li></ul><ul><li>Metrics/Financial Results </li></ul>
    3. 3. Requirements and Defects     Source: &quot;Software Engineering&quot;, Ramamoorthy, et al., IEEE Computer Society &quot;Fixing a problem in the requirements phase costs 1% as much as fixing the resulting [implementation]” Source: IEEE Spectrum, August 1992
    4. 4. Requirements Engineering Considerations <ul><li>Complete definition is vital to project success. </li></ul><ul><li>Software projects typically show 43% of problems due to requirements problems. </li></ul>Late Customer Changes Incomplete Wrong Missing Unclear Inconsistent
    5. 5. Requirements and Success <ul><li>“ Quality is conformance to requirements” – Philip Crosby </li></ul><ul><li>Requirements must be communicated to everyone associated with the project </li></ul><ul><li>Requirements documents act as drivers and provide a control mechanism for the entire lifecycle </li></ul><ul><li>Testing must be based on requirements to ensure the product is doing what the user asked </li></ul>
    6. 6. Requirements Engineering Challenges <ul><li>Product complexity is rapidly increasing </li></ul><ul><ul><li>Scope is beyond the mind of any individual </li></ul></ul><ul><ul><li>Complex interactions require inputs from many disciplines </li></ul></ul><ul><ul><li>Increased technology turnover - more solution possibilities </li></ul></ul><ul><ul><li>Employee turnover drives a need to record rationale for decisions </li></ul></ul><ul><li>Competition demands </li></ul><ul><ul><li>Reduced development cycle times </li></ul></ul><ul><ul><li>Reduced development costs - increased reuse </li></ul></ul><ul><ul><li>Effective flowdown of the Voice of the Customer </li></ul></ul><ul><li>Customers expect </li></ul><ul><ul><li>A documented, capable, and controlled development process (SEI, CMM) </li></ul></ul><ul><ul><li>Requirements are managed and inconsistencies with project plans and work products are identified (CMMI-SE/IPPD/SS, v1.1 PA146.IG101) </li></ul></ul><ul><ul><li>Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements (CMMI-SE/IPPD/SS, v1.1 PA157.IG101) </li></ul></ul><ul><ul><li>100% traceability and verification coverage </li></ul></ul>
    7. 7. Requirement Definitions <ul><li>“ A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document.” </li></ul><ul><ul><li>IEEE-STD-729-1983 </li></ul></ul><ul><li>A verifiable shall statement satisfying Functionality, Usability, Reliability, Performance, Safety (FURPS) </li></ul><ul><li>An unambiguous statement of need that is autonomous, verifiable and traceable. </li></ul>
    8. 8. Problem Statement <ul><li>Little or no configuration management of requirements </li></ul><ul><li>Each organization has customized tools to support their process resulting in duplication of effort. </li></ul><ul><li>Requirements churn is causing duplication of effort during design and implementation </li></ul><ul><li>Resources must be duplicated in order to maintain and administer disparate schemas and tools </li></ul><ul><li>Much of the requirements work is not done until later in the product development lifecycle </li></ul><ul><li>Defining Market Requirements is undisciplined </li></ul>
    9. 9. Problem Statement <ul><li>Integrating model driven design is an afterthought </li></ul><ul><li>Process and methods of writing requirements is archaic resulting in vague and ambiguous statements of need. </li></ul><ul><li>Very difficult to almost impossible to gather common metrics because of different schemas </li></ul><ul><li>Even when common tools are used they are not commonly implemented </li></ul><ul><li>Inadequate System Level Testing due to lack of System Level Requirements results in Customer Reported Defects </li></ul>
    10. 10. Project Objective <ul><li>Reduction of Defects attributable to requirements </li></ul><ul><li>Earlier Detection of Defects during the development lifecycle </li></ul><ul><li>Better Impact/Traceability Analysis and Metrics within and across projects </li></ul><ul><li>Facilitation of Test Automation </li></ul><ul><li>Reduced requirements churn through common process and earlier requirements definition </li></ul><ul><li>Improved Test Coverage at the System and Sub-System Levels </li></ul><ul><li>Facilitation of Auto Code through model driven requirements </li></ul>
    11. 11. Project Objective <ul><li>Less Time Fixing Defects </li></ul><ul><li>Focused Development of “Most Important Requirements” the vital few instead of the massive many </li></ul><ul><li>Improved Design Decisions </li></ul><ul><li>Common Process, Templates and Metrics Available for New Project Adoption </li></ul><ul><li>Common schema enables easier integration of DOORS with other tools like Change Management, Tau G2, and Test Systems </li></ul><ul><li>A reduction in Customer Report Defects </li></ul>
    12. 12. Develop and Validate Concept/ Impact Statement Concept Doc Validate Market Level Requirements Impact Statements Approved Requirements Change Request C A N-> N R R Base-lined Market Requirement/ Solution Doc Product Roadmaps Receive Internal Roadmaps (RMTR,Cost,ROAM) Release Plan Model Gen Allocate Reqt X Approved Requirements Change Request from RM Requirements Decomposition (Pg 1 of 2) Development System Engineering Test Program Management Product Management/ Customer Deployment Quality Assurance C A N-> N R R Document Requirements Decomposition Plan Project Specific RD Plan C A N-> N R R I - Input C - Create Q - Quality R - Review A - Approve N - Notify To Project Management plan C N-> N RA R
    13. 13. Create Current Level Requirements Describe Proposed Architecture Decomposition Complete * Requirements in DOORS Architecture Description Modeled Requirements Specify External Interfaces External Interface Specification Allocated Requirements Previous Level Allocated Requirements Model/Generate/Allocate Requirements Decompose ~ 4 times Requirements Decomposition (Pg 2 of 2) Model Gen Allocate Reqt X Allocate Requirements Yes No C N-> N N-> N RA RA R R C N-> N N-> N RA RA R R C N-> N N-> N RA RA R R C N-> N N-> N RA RA R R * Decision is based on the defined Project Specific RD Plan Development System Engineering Test Program Management Product Management/ Customer Deployment Quality Assurance Design Process I - Input C - Create Q - Quality R - Review A - Approve N - Notify
    14. 14. Requirement Hierarchy Simplified Market Requirements ( Input into our process ) Level 1: System Level Level 2: Architecture Domain Level 3: Architecture Element Level 4: Functional MRS (Marketing Requirements Set) Product Strategy Doc Customer Rqmt Doc Feature Description/Impact statement L1RS (Level 1 Requirements Set) The System Shall… Requirements, Models, AD, EIS and Verification L2RS (Level 2 Requirements Set) The RAN/CORE Shall… Requirements, Models, AD, EIS and Verification L3RS (Level 3 Requirements Set) The BTS/NodeB Shall… Requirements, Models, AD, EIS and Verification L4RS (Level 4 Requirements Set) The Functional Area Shall… Requirements, Models, AD, EIS and Verification
    15. 15. Requirements Templates TL9000 7.3.2, 7.3.2.C.2, 7.3.2.H.1
    16. 16. Modelling Requirements
    17. 17. Modelling Requirements
    18. 18. Requirements Decomposition across development lifecycle <ul><li>Finalize Handover Criteria Document </li></ul><ul><li>Complete Handover </li></ul><ul><li>Conduct After Action Review (M2) </li></ul>11 10 9 8 7 6 5 4 Solution Lockdown Project Initiation Requirements Baselined Requirements Allocated System Test Readiness Controlled Introduction (Handover) Contract Book Design Readiness <ul><li>Assign PM </li></ul><ul><li>Complete Project Charter </li></ul><ul><li>Baseline Market Level Requirements L0RS </li></ul><ul><li>Develop WBS-Lev 4 </li></ul><ul><li>Project Specific Requirements Decomposition Plan </li></ul><ul><li>Baseline L1RS </li></ul><ul><li>Baseline L2RS </li></ul><ul><li>BaselineL3RS </li></ul><ul><li>Develop Test Strategy </li></ul><ul><li>Develop Contract Book </li></ul><ul><li>Finalize PMP </li></ul><ul><li>Baseline L4RS </li></ul><ul><li>Final Design Review </li></ul><ul><li>Test Plans </li></ul>Key L0RS – Level 0 Req. Set L1RS – Level 1 Req. Set L2RS – Level 2 Req. Set L3RS – Level 3 Req. Set L4RS – Level 4 Req. Set PMP – Project Management Plan WBS – Work Breakdown Schedule
    19. 19. Project Schema
    20. 20. Project Schema
    21. 21. 4EIS Interface Specification 4EIS-Module in DOORS 4TR 4TR Modules in DOORS 4AD Architecture Description 4AD-Module in DOORS Analysis Links Interface Links DOORS Hyper-Links Hyper-Links Requirements Links 3TR DOORS 4VER-TPLAN (ITC/SST) 4VER-TDS (ITC/SST) 4VER-TC 4VER-TP Verification Links Verification Links 5EIS Interface Specification 5EIS-Module in DOORS 5TR 5TR-Modules In DOORS 5AD Architecture Description 5AD-Module in DOORS Analysis Links Interface Links DOORS Hyper-Links Hyper-Links 5VER 5VER-Modules in DOORS Verification Links Requirements Links 6EIS Interface Specification 5EIS-Module in DOORS 6TR 6TR-Modules In DOORS 6AD Architecture Description 6AD-Module in DOORS Analysis Links Interface Links DOORS Hyper-Links Hyper-Links 6VER 6VER-Modules in DOORS Verification Links Verification Links Hyper Links Hyper Links 6HLD 6HLD-Modules in DOORS 6LLD 6LLD-Modules in DOORS Design Links Design Links Hyper Links Hyper Links VerScope Links VerScope Links CM Tools Document Repository Document Repository Document Repository Document Repository
    22. 22. Schema Automation
    23. 23. Project Metrics <ul><li>Requirements Completeness at Handover </li></ul><ul><ul><li>Percent of Requirements with Issues </li></ul></ul><ul><ul><li>Percent of Requirements missing Parent Links </li></ul></ul><ul><ul><li>Percent Requirements missing Mandatory Attributes </li></ul></ul><ul><ul><li>Percent of Requirements missing Mandatory Attributes </li></ul></ul><ul><ul><li>Percentage of Requirements missing Allocation </li></ul></ul><ul><li>Requirements Churn at Baseline </li></ul><ul><ul><li>Baseline Requirements </li></ul></ul><ul><ul><li>Requirements Added </li></ul></ul><ul><ul><li>Requirements Changed (Required attributes only) </li></ul></ul><ul><ul><li>Requirements Deleted </li></ul></ul>
    24. 24. Financial Results <ul><li>Total to date Cost Savings of $64M </li></ul><ul><li>Reduced Cycle Time Contributes $2M/Month Across Development Lifecycle </li></ul><ul><li>Reduced Defects Contributes $230,000/Month across the development lifecycle </li></ul><ul><li>Requirements Decomposition Productivity Improvements Contributes $80,000/Month </li></ul>
    25. 25. Forward Looking Challenges <ul><li>Churn metrics can be generated from the model specification </li></ul><ul><li>Manage the alignment of the different DOORS and TauG2 configuration management systems </li></ul><ul><li>Manage the integration of DOORS and TauG2 via Citrix servers as the data must be made available to geographically dispersed teams. </li></ul>
    26. 26. Summary <ul><li>An efficient way to eliminate potential issues, associated with stakeholders that are not aware of customer’s needs as captured in requirements, is to develop a common and intuitive requirements management process. This presentation has shown that by deploying a Simplified Requirements Management Process, within the product development lifecycle, a business will improve their customer satisfaction, eliminate escaping defects and reduce the cost of the development lifecycle. </li></ul>
    27. 27. References <ul><li>“ Systems Engineering Handbook,” International Council on Systems Engineering (INCOSE), Ver 2.0, July 2000 </li></ul><ul><li>“ Processes for Engineering a System,” ANSI/EIA 632, January, 1999 </li></ul><ul><li>“ Introduction to Object Oriented Systems Engineering, Part 1,” Haig F. Krikorian, IT Pro, IEEE Computer Society publication, May/June 2003 </li></ul><ul><li>PRC220- “Cellular Networks Requirements Decomposition Process” PRC210- “Cellular Networks Requirements Management Process” </li></ul><ul><li>ENG7799- “Motorola University Requirements Engineering,” Bill Barr, December 2000 </li></ul><ul><li>ANSI/PMI 99-001-2004, Project Management Body of Knowledge, </li></ul><ul><li>“ Applying UML to Systems Engineering-some lessons learned,” Murray Cantor, </li></ul><ul><li>IEEE Std 829-1998, IEEE Standard for Software Test Documentation </li></ul>