Requirements Engineering and Management

Transcription

1 Requirements Engineering and Management June 14, 2012 : Dist A. Approved for public release.

2 Report Documentation Page Form Approved OMB No Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 14 JUN REPORT TYPE Briefing Charts 3. DATES COVERED to TITLE AND SUBTITLE Requirements Engineering and Management 5a. CONTRACT NUMBER 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) Andrew Yee 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) U.S. Army TARDEC,6501 E.11 Mile Rd,Warren,MI, SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) U.S. Army TARDEC, 6501 E.11 Mile Rd, Warren, MI, PERFORMING ORGANIZATION REPORT NUMBER # SPONSOR/MONITOR S ACRONYM(S) TARDEC 11. SPONSOR/MONITOR S REPORT NUMBER(S) # DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited 13. SUPPLEMENTARY NOTES TARDEC systems engineering (SE) workshop, ABSTRACT A collection of activities undertaken by many people on a project in order to gather, document, store, analyze, track, and implement requirements, while controlling change and communicating with stakeholders. 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF a. REPORT unclassified b. ABSTRACT unclassified c. THIS PAGE unclassified ABSTRACT Public Release 18. NUMBER OF PAGES 13 19a. NAME OF RESPONSIBLE PERSON Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

3 Requirements Engineering and Management What is Requirements Engineering and Management? A collection of activities undertaken by many people on a project in order to gather, document, store, analyze, track, and implement requirements, while controlling change and communicating with stakeholders. Why do we need Requirements Engineering and Management? People involved on the project are: Continually kept apprised of requirement status Understand the impact of changing requirements specifically, to schedules, functionality, and costs.

4 Requirements Engineering and Management Ensures that the voice of the customer is heard throughout the entire development process Not restricted to a single phase in the lifecycle Key task is traceability of the requirements Different techniques, approaches and tools may be used Success depends on the commitment of the whole project team

5 DEPARTMENT OF DEFENSE SYSTEMS ENGINEERING PROCESS MODEL 2009 Technical Planning Requirements Management Configuration Management Technical Management Process Technical Assessment Decision Analysis Risk Management Interface Management Technical Data Management Stakeholder Requirements Definition Requirements Analysis Technical Process Validation Verification Transition Architecture Design Integration Implementation

6 What are Requirements? Requirements Define: What the users want to achieve. What the system must do to satisfy user needs. What each component must do, and how components will interact. Requirements: Have only one shall statement Have only one action verb Do not have stacked (multiple) shall statements in a list

7 What should a Requirement Be? Unambiguous - The reader of a requirement statement should be able to draw only one interpretation of it. Verifiable There is a value or test to measure the requirement against to insure the intent of the requirement is being met. The verification methods can be an inspection, demonstration, analysis, or a test to determine whether each requirement is properly implemented in the product. Traceable - You should be able to link each requirement to its source, which could be a higher-level system requirement, a use case, or a voice-of-thecustomer statement

8 What should a Requirement Be? (Cont.) Correct - Must accurately describe the functionality to be delivered. Feasible - Must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. Necessary - Should document something the customers really need or something that is required for conformance to an external requirement, an external interface, or a standard.

9 How TARDEC Manages Requirements DOORS (Dynamic Object-Oriented Requirements System) Made for Requirements Engineering and Management Traceability (requirement, derived requirements, decisions, test reports, etc.) Allocations History/Change Management Baselining Access Control Single Access Point for Requirements Able to Export/Import Information into Other Formats

10 DOORS Training Modules DOORS training is available through TARDEC SEG. Contact any SEG group member for more information. DOORS Extension Language (DXL) 4 hour hands-on + homework

11 Benefits of Requirements Engineering and Management using DOORS Traceability From Highest Level Requirements To Implementations Established Via Links In DOORS Database Building Traceability Improves The Quality Of Requirement Analysis, Ultimately Producing Better Work Products Impact Assessments Of Proposed Changes DOORS Analysis Tools Let You See Which Other Requirements Will Be Affected By A Change Controlled Access To Project Information A Shared Database Ensures That All Users Are Working With Current Data A Central Repository Allows Controlled Access To Essential Information Change Control DOORS Complements Configuration Management

12 Leveraging DOORS at TARDEC Ground Systems Integration Domain (GSID) 1. Support Systems Engineering Analysis 2. Align Capability, Platform and Technology Road maps 3. Inform S& T Portfolio Decisions S& T and ACAT Programs 1. Maintain continuous traceability between plans, decisions, requirements, designs and tests 2. Frame and inform decisions (trade studies) 3. Guide modeling, simulation and prototyping 4. Manage baselines FOCs + WFOs Capability f Gaps + 1-N 5. Adapt quickly to changes and lessons learned r 'l , Knowledge Reuse 1. Develop and refine patterns and templates (decisions, requirements, plans) 2. Jump-start programsi accelerate solutions 3. Identify opportunities for common solution Patterns A lot more than just requirements.. TECHNOLDGY DRNEN. WARRGHTER FOOJSED.

13 DOORS Information Model Issues can be linked to any other data Sources Capabilities Voice of Customer System

14 Requirements Traceability Information Quest i ~ons tr,acea bil ity c,an a1nswer SOVtl How will we N-Sq uared Diagram Legend W hat i s our scope acrom pi i sh our & charter? charter? Is our pbn Node A A-to-8 adequate? interaction H o w wil wort fl ow WBS 8-to-A NodeB down t o od.ers? W hat's our plan? nle ractbn Who's responsible? Is plln adequate? Read the interacton s cbckvlise How will we DECISIO NS Why does this Where di d this. an al yze or Top N de c:i si ons? component e» st? requi'ement imp1em ent this S ta tu s? Rationa le? W hat ro le does i orginate? deeision? C onsequences? play? Chang e impact? ARCHITE CTURE Components in our soluti on? In terfac es? What deosions du A Jioeated REQ UIREMENTS Requiremen5 per t!hi s req't driv.e? r equirements? Success=? ~.est? Budget a locati:>.n? Budget fl'ow-d own? Clear? Complete? Verlicato n Change i 111>ac1? Source? m v er ag,e? Requir erne nts m el.? P riority gaps to fix? TEST S Test ev en:.slcases? Test enablers? Resutslfindn gs? TECHNOI.DGY DRNEN. WARRGHTER FOCUSED.