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. USING DOORS® AND TAUG2® TO SUPPORT A SIMPLIFIED REQUIREMENTS MANAGEMENT PROCESS Bill Barr & John Mathews Motorola

3. Requirements and Defects Source: "Software Engineering", Ramamoorthy, et al., IEEE Computer Society "Fixing a problem in the requirements phase costs 1% as much as fixing the resulting [implementation]” Source: IEEE Spectrum, August 1992

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. 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. 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. Requirements Templates TL9000 7.3.2, 7.3.2.C.2, 7.3.2.H.1

16. Modelling Requirements

17. Modelling Requirements

19. Project Schema

20. Project Schema

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