1 / 94

Getting the most out of DOORS for requirements management

Getting the most out of DOORS for requirements management. Software Technology Center, BLAT Vassilka Kirova & Darshak Kothari. October, 2004. Outline. Overview of DOORS Introduction Key concepts and elements Using DOORS DOORS & Artifact Flow Through Demo. DOORS - Introduction.

joshuaelliott
Télécharger la présentation

Getting the most out of DOORS for requirements management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Getting the most out of DOORS for requirements management Software Technology Center, BLAT Vassilka Kirova & Darshak Kothari October, 2004

  2. Outline • Overview of DOORS • Introduction • Key concepts and elements • Using DOORS • DOORS & Artifact Flow Through • Demo

  3. DOORS - Introduction

  4. DOORS ERS Architecture

  5. Effectively generating High Quality Requirements: Elicitation Analysis Modeling & Specification Verification & Validation Requirements Engineering & DOORS • correct • consistent • complete • modifiable • traceable • verifiable • non-ambiguous • understandable • annotated Requirements Engineering Requirements Management Requirements Development Change Control Version Control Tracing & Impact Analysis Status Tracking Best Practices, Methods,Tools and Processes for Requirements Engineering

  6. Key challenges • Communicate requirements to all project stakeholders to “keep everyone on the same page” • Control changes to requirements, assess impact of proposed changes, and communicate approved changes • Analyze requirements coverage to ensure customer satisfaction or compliance to regulations/contracts • Validate requirements early in system/software lifecycle to avoid costly redesign later • Design and implement system/software directly from a validated requirements-based model to ensure the right system is built • Communicate design to all project stakeholders

  7. Impact of Requirements Problems? As much as a 200:1 cost savings results from finding errors in the requirements stage versus finding errors in the maintenance stage of the software life-cycle. Barry Boehm- ‘76, 88 56% of all bugs can be traced to errors made during the requirements stage 

  8. Functional requirements User requirements A Simple Project Model Design specifications Satisfies Satisfies Constrains Tests Tests Tests Standards Acceptance tests Functional tests Unit tests

  9. DOORS - Key Concepts & Elements

  10. DOORS Database Explorer - Database View Database Projects Documents Folders • DOORS Database Explorer: • Allows you to organize your data in the same way that you might organize it in MS Windows Explorer –> explorer type navigation

  11. The DOORS Explorer – Project View • Only shows projects which you can access

  12. Using Projects and Folders • Use a Folder to: • Creating structure and organization • Use a Project to: • Organize data related for a specific project or product

  13. Documents in DOORS are referred to as “Formal Modules” or simply “Modules” • A module is a container for information (requirements, graphics, etc.) • Typically structured as a document • May be structured as a data file

  14. Default Document Display • On the Left: Module Explorer allows you to navigate and see the structure • Right hand pane shows Heading and Text in a Document-Centric Format – the way you’re used to

  15. Objects • Documents (or Formal Modules) are collections of Objects • Objects may be used for • Requirement text • Headings • Graphics • Any other information

  16. Objects Have Properties Detailed information about an object • General – Heading, Short Text, Object Text values for the object • Access – View or set access rights • History – log of changes to the object • Attributes – attribute values for the object • Links – relationships to other objects Right click on the object and select Properties

  17. D B E A G C F H Object Structure Terminology Structure as a “Family”: parent object A has children objects B and C child objects D and E have B as their parent siblings objects G and H have the same parent Structure as a “Tree”: leafobjects D, E, G, and H have no children non-leafobjects A, B, C, and F are parent objects

  18. What is an Attribute? • Attributes are additional defined characteristics of a requirement; they provide essential information in addition to requirement text Source Who specified this requirement? Priority What is the priority of this requirement? Verifiability Is the requirement verifiable? Accepted Has this requirement been accepted by the developers? Review Review status of this requirement Safety Is this a safety-critical requirement? Comments Any comments on the requirement to clarify its meaning Questions Any questions that must be clarified with the source • You can define attributes that will support your process and make your database more productive for you What Attributes should you use?

  19. Attribute Have: Attribute Name Type Access Definition Change Characteristics Default Value Attributes can be assigned to: Documents (Modules), Objects (Requirements), and links

  20. Object Attributes Attributes allow additional information to be associated with each requirement Attributes can also be defined for Documents (Modules) and Links

  21. Filters • Filters allow you to reduce the information in the display to an essential set that interest you • Filters support your analysis of the requirements

  22. Filters are used to: • Limit the display to visualize specific information • High Risk Requirements • Requirements in Build 3.0 • Requirements assigned to a specific individual • Requirements that failed test • Set a specific value of an attribute to many objects at once. • You may want to set all requirements that have the word “safe” in them to “Priority = High” Filters are saved when you save the View Views are Dynamic Reports of your Data

  23. Views • Views define the layout of your data • Columns, filters, sorts, window position, etc. • Drop-Down list on left side of tool bar for easy access to your views • Defaults for Users or Documents can be set Saving a View View Drop-Down Menu

  24. Using Views • Views can be used to • Save filter or sorting conditions • Save a display that contains attribute • Save a display that contains traceability • Save a display that contains information of specific interest to certain users (e.g., managers, test engineers, reviewers, coders) • Save window positions to facilitate linking

  25. Links in DOORS • A relationship between two requirements (objects) is established using a ‘link’ • Links can be followed in either direction • Bi-directional 1 to 1, 1 to n, n to 1, & n to n are supported “From” (Source) “To” (Target)

  26. Using DOORS

  27. View requirements in context Familiarity of document view; power of a database

  28. Edit and baseline

  29. Sharable Mode Operation: Defining Shareable Sections • Shareable Edit is based on Sections • Sections are defined in the Exclusive Edit mode

  30. Prioritizing, categorizing, or assigning requirements • Annotate requirements with an “unlimited” set of user-defined attributes • Standard NOS template Analyze requirements through multiple views

  31. Tracking changes Change History Previous Baseline Current Version 

  32. Including all stakeholders in the review process • Web browser interface • Global access • Easy to use • Common user interface • No training required • Support for: • Distributed teams • Requirements reviews • Managers

  33. Notify users (e-mail, suspect links) ? Link Changes from all users including DOORSNet TM “Native” requirements change control Discuss required changes User submits “Change Proposal” Anyone on the team can participate Accepted E-mail On Hold Changes reviewed on-line or in formal “CCB” In Review Rejected

  34. Discuss required changes Notify users (e-mail, suspect links) Read-only user submits “Change Proposal” Notify users (e-mail) Change Proposal System Accepted Changes from all users Changes reviewed on-line On Hold In Review Rejected Assess and discuss impact of changes Integrated Change Management - CPS

  35. Linking & Traceability For Traceability Automation see AFT Drag-and-drop to link within a document . . . . . . or from document to document. …or across projects.

  36. Design specifications Functional requirements Unit tests Standards Functional tests Establish traceability from tests to requirements User requirements Satisfies Satisfies Constrains Tests Tests Tests Acceptance tests

  37. Use traceability to perform analysis • Coverage analysis • Impact analysis • Derivation analysis

  38. Design specifications Functional requirements Unit tests Standards Functional tests Coverage Analysis User requirements % Complete … ? Satisfies Satisfies Constrains Tests Tests Tests Acceptance tests

  39. Design specifications Functional requirements Unit tests Standards Functional tests Coverage Analysis “Gold plating” ? User requirements Satisfies Satisfies Constrains Tests Tests Tests Acceptance tests

  40. Design specifications Functional requirements Unit tests Standards Functional tests Analyzing Impact What if … ? User requirements Satisfies Satisfies Constrains Tests Tests Tests Acceptance tests

  41. Understand the impact of change before you introduce it • Navigation via link indicators • Explorer-style link navigation • Traceability matrix view

  42. Design specifications Functional requirements Unit tests Standards Functional tests Derivation analysis Why is … ? User requirements Satisfies Satisfies Constrains Tests Tests Tests Acceptance tests

  43. User Reqts Technical Reqts Design Test Cases Impact/derivation analysis

  44. End-to-end visual validation in a single view User Reqts Spec Functional Spec Design Spec Test Cases “We need to demonstrate compliance with our customer’s requirements”

  45. Ensure all requirements have been satisfied • Standard views and reports show “missing” links • Filters quickly identify unmet requirements Increases customer confidence

  46. OLE Support DOORS provides OLE support on Windows • You can embed an OLE object • Use edit-in-place to make changes after embedded • You can link an OLE object • Changes are made to the file in its original location • Embed or link in a DOORS object: • Table, Spreadsheet, Equation, Chart/graph • Picture, Audio clip, Video clip • The choice is only limited by what is installed on your system

  47. OLE Link or Embedding • Select insertion point in module • Insert / OLE object • Create New • Select type • Create from File • Browse to select • ‘Link’ or embedd • Double-click • Launches source application • Maintain as any DOORS object • Move, Copy • Attributes • Link

  48. Export from Word to DOORS • Initiate from Word • Export to current Project or Folder in DOORS

  49. Incorporating existing documentation MS-Word MS-Word RTF Automated import OLE ASCII Spreadsheet Interleaf FrameMaker Migrating existing project information to DOORS

  50. Word PowerPoint Excel Outlook Microsoft Publishing and Report Generation Printer Automated report generation from any view HTML RTF MS-Word ASCII Spreadsheet Interleaf FrameMaker Publish reports with the required content and format

More Related