Dynamic Object-Oriented Requirements System (DOORS)

Editor's Notes

• #4: So, just what do we mean by “Requirements Management”? There are any number of definitions of requirements management. This one seems to cover all the bases.
• #5: So what is a requirement? Requirements concern anything that affects the quality of a product or service. This can include such things as performance, the design, and the manufacturing of a product. Requirements come in many forms under many different synonyms: Objectives, goals, aims, regulations, rules, constraints, needs, features, functions, criteria, etc… And requirements come from a great variety of sources. That can include customers, customer support, development, contractual obligations, etc. This adds significantly to the complexity of the requirements management challenge. With so many types of requirements we end up with complex products having 1000’s of requirements
• #6: Requirements describe what customers and other stakeholders want from a product or service. For example, if you are planning to buy a new car for your family, you might make a list of the things that you need from the car. Your list might include the following features: must be able to carry at least five people, must have fuel consumption of over 35 mpg, must cost no more than X, etc… Less important features that you would like, such as a particular color, would be further down your list. At the end of the exercise, you have a list of user requirements , which specify the kind of car you want to buy. The exercise of listing requirements for buying a car is fairly straightforward; however, the designers of that car need more. The designers need system requirements , which describe the features the car must provide. From these they can prepare detailed design documents. Each part of the design must be tested; therefore, tests are specified in a separate document. Well-defined requirements ensure that your customers get what they want and show you the type of product you have to build, or the type of service you have to provide
• #7: Use DOORS for requirements definition and requirements management to improve quality by optimizing communication and collaboration, and by promoting compliance and verification.
• #9: Use DOORS for requirements definition and requirements management to improve quality. How ? By optimizing communication and collaboration, and by promoting compliance and verification.
• #10: DOORS Web Access is a powerful tool that enables access to module data stored in a DOORS Database. It provides access to views, discussions, edit, and link requirements using a zero-footprint web browser application. You log in to the web client with your Rational DOORS user name and password, and then select the package that you want to use. The package that you select determines what you can do with the data.
• #12: Citrix Presentation Server V4.0 on Windows 2000 or Windows 2003 Server Enterprise Edition, using the Citrix ICA client v 9.00.32649 on Windows 2000 or Windows XP.
• #13: There are two different types of DOORS client: Standard Client Installs DOORS client application files on a local machine. This installation type relies on a user accessing networked DOORS data. This has its own copy of the DOORS application files. When you run DOORS, you run your local copy of the DOORS executable file (DOORS.exe), which makes use of local copies of DOORS eXtension Language (DXL) support files, e.g. for importing and exporting data. You access the DOORS database using the DOORS database server, and get your floating license from the FLEXlm license server. Workstation Client This is the same as the standard client except it doesn’t have its own copy of the DOORS application files. It accesses these files from a central location on another computer. The standard client has a shortcut that points to and runs DOORS.exe on the remote server. The advantage of keeping the files in a central location is that it’s easier to manage them. For example, when you upgrade DOORS, you just have to upgrade the application files on one computer.
• #14: When you start Rational® DOORS®, the registry determines which configuration settings to use. If you start Rational DOORS from the command line or from a shortcut, you can use switches to override the registry settings. You can also use the switches to add functionality to Rational DOORS.
• #16: When you start Rational® DOORS®, the registry determines which configuration settings to use. If you start Rational DOORS from the command line or from a shortcut, you can use switches to override the registry settings. You can also use the switches to add functionality to Rational DOORS.
• #17: projects are different from folders in the several ways: You can see a list of every project in the database in the Project view in the database explorer. Projects can be partitioned and archived Projects can contain RIF definitions Projects can contain change proposal systems.
• #18: The DOORS toolset allows users to select or create & select requirements rendered through a UI that follows a data access methodology of row & column layout, scrollable page loading, and find tools that provides an intuitive approach to navigation providing easy access to content.
• #19: The database hierarchy can be as broad and as deep as you require. DOORS is designed to cater for organisations running multiple projects / programmes, and it is normal practice for a number of projects within an organization to share a database. Projects can wall themselves off from each other using DOORS access permissions.
• #20: A DOORS ‘Formal Module’ may be considered equivalent to a project document, which you might previously have stored as a Word document, for instance. There are other types of Module, but we do not need to be aware of them at this point.
• #21: The administrator user account is a special account that bypasses all access rights checks. There is only one administrator user for each DOORS database.
• #22: The user type controls what operations users can perform, for example, whether they can create projects or archive data.
• #24: DOORS provides a comprehensive desktop client environment for systems engineers and business analysts to edit and manage requirements and their traceability, DOORS Web Access provides other stakeholders—business managers, marketing and suppliers—who need visibility of the requirements and the traceability relationships, with simple Web browser access to the central DOORS repository. Through DOORS Web Access, users access requirements with their existing Web browser: Requirements descriptions (including rich text, OLE objects, and tables), requirements attributes (standard and user-defined), and traceability links can all be viewed via the Web.
• #26: Open Services for Lifecycle Collaboration Collaborative/Application Lifecycle Management (C/ALM) Benefits Integration between products No requirement for custom integrations Integrations will deepen over time and to include other products Features Cross-repository artifact linking Cross-repository navigation Common Look & Feel – delegate UIs Open standard support – built around OSLC interfaces
• #27: The Rational DOORS eXtension Language (DXL) is an easy-to-learn scripting language that you can use to control and extend Rational DOORS functions. Automate routine or complex tasks, such as calculating attribute values. Respond to events by triggering custom programs. Add your own options to DOORS menus. DXL syntax is like C and C++.
• #30: Today, organizations are more concerned than ever with requirements management. There are annual conferences that are devoted to the subject, such as the IEEE Requirements Engineering conference. Most engineering companies, and many in the commercial sector, now have a requirements management function. So what has brought about the evolution of requirements management? There are several, and some of them include: Complexity – projects these days are much more complex then they used to be. Think of all of the software in cars, banks, medical devices, etc. In addition to complexity, organizations today are more often than not, global organizations. This can be due to several factors, out-sourcing, mergers, acquisitions, and partnerships. The need to effectively communicate and to create products that meet the requirements is a much more difficult challenge in a global environment. Competition in marketplace today is also driving the need for requirements management. Organizations are being driven to deliver better products much more quickly and cheaply, or their competitors will. And finally, compliance is becoming increasingly more critical to an organizations success. The culture of compliance is developing in all industries. Companies are now obligated to provide evidence that they comply with these regulations.
• #31: Requirements management is the discipline of gathering, expressing, organizing, tracing, analyzing, reviewing, agreeing, and validating requirement statement. It also requires the management of the documents that contain them, so that the right product or service is delivered. Because of this, requirements management processes span the entire development lifecycle – from inception, to the end of development when final testing is carried out. Requirements management is particularly important because it has a vertical phase component, gathering and analyzing the requirements, and a lifecycle component in which those requirements are linked and traced throughout the rest of the project. This is rather unique amongst the tools our customers use. Most other tools are either vertical, within one or two phases, or lifecycle, providing a constant service. It is also the only tool to act as the “glue” connecting all the other phases together. A requirements tool is probably the most important tool our customers will have.
• #32: Requirements define what is needed by the users and help us make sure we develop what they asked for. Requirements are the method used to communicate goals to everyone on the project team and allow us to control the development process. Requirements ensure that we build the right product, help prevent over design (also known as; creeping elegance or gold-plating) and to control outsourcing. Requirements help keep all members of the team involved in the development driving in the same direction, working towards the same, precisely defined goals.
• #33: The benefits of requirements management are clear. Customers are more satisfied as their business needs are met. They know what to test the deliverables against. DOORS allows customers to do concise impact analysis by seeing the dependencies and relationships between requirements. What will happen if I change this one requirement? Team members have a consistent idea of what the solution is for through improved communication. Managers can now take a global view of a project or product. The quality of deliverables is much greater, and our customers can demonstrate compliance with regulatory agencies such as the FDA’s 21 CFR Part 11 or Sarbanes-Oxley.
• #34: These are some of the symptoms of a broken requirements management process. The symptoms can range from unclear project status to no formal development process. Often it seems the objectives of a project change. Often, change is costly and time consuming for customers. Communications can be unclear between departments. Gold plating leads to higher development costs. Often QA departments don’t know what to test because they don’t understand the original intent or need. Without that understanding, QA departments aren’t sure when their tests are complete. This can lead to test cycles that are too long and too expensive. All of these types of problems can be resolved using a comprehensive requirement management process and tool.
• #35: To manage complexity, development is undertaken in levels, with requirements playing a role at each level. In order to effectively manage these various levels, there are several key concepts that are at the core of requirements management. Communication is accomplished through the sharing of requirements across an organization and across levels of development. Collaboration is via the creation of traceability to those requirements from any other activity or deliverable made to satisfy those requirements. These traceability links are critical to manage the requirements at various levels or phases within the lifecycle. Validation is through the linking of actual test cases that show how the requirement was proven, whether by test, observation, measurement, etc. This validation can be done with or without a formal test tool.
• #36: The key components of traceability lie in four areas. First, we need to identify how the requirements were satisfied. In other words, which design, system, and implementation requirements fulfill the customer requirement. Secondly, we need to understand how the requirements were tested, and therefore satisfy the original requirements. Traceability also enables the organization to see immediately the impact of changing a requirement, and the subsequent impact that it would have on other requirements. This helps organizations make intelligent decisions about changes to the requirements. And finally, what is the impact of a test failure? Does it have legal implications, product quality implications, or is it a failure that is acceptable? Traceability enables the traversal of related requirements. For example, from the original customer requirements through system requirements, and system requirements into design and implementation. Many of the concerns of requirements management exist to enable traceability. It is through traceability that we hope to understand and document
• #37: Without a formal requirements management solution you probably keep track of requirements in regular documents, perhaps using Word. And you may relate requirements using unique ids, or even using a spreadsheet. However you do it, there is a logical relationship between the requirements and other phases of the project, ultimately leading to test cases. This is true whether you are building software, hardware, systems or anything else. The way your data is related can be considered a traceability model. Define this model formally and enforce it and you can now achieve process improvement. DOORS supports that process improvement by allowing you to enforce a traceability model so that all users must relate data in the same way and nobody can cut corners. Traceability/compliance matrices produced by hand are most often considered out of date on or shortly after the date they are completed. Compare this with pressing a single button within DOORS or better still have the information in a live view in the normal document interface
• #38: These four concepts are clearly illustrated in what is referred to as the V-Model in systems engineering. Traceability enables the traversal of related requirements. For example, from the original customer requirements through system requirements, and system requirements into design and implementation. It also demonstrates clearly how the various requirements are validated through acceptance, system, subsystem, and component testing.
• #39: This is another example of requirements tracing. We can trace the individual software specification to the individual system requirement, and in turn to the customer requirement. We can clearly see which requirements have been satisfied, and perhaps more importantly, which requirements have not been satisfied.
• #40: Once established, tracing can be used to carry out impact analysis. Suppose a customer requirement was subject to change? Then the links that satisfy that requirement could be used to identify the related system requirements, and in turn, the related software requirements that would be subject to change as a result.
• #42: So what happens if an organization does not address the requirements management issue? The analysts at Standish issued a report in 2003, “Extreme Chaos”. When asked what contributes to project success, 50% of the reasons given for success were related directly to requirements in one way or another. That’s exactly half the reasons for success directly related to one single discipline; requirements management. A discipline, that based on these numbers, our customers cannot afford to do half-heartedly. Meta Group concurred with Standish. Plainly stated, the Domino Effect of missing User and System requirements may be missing functions, design elements, and missed test cases. The total effect from these missing items can result in higher maintenance costs to put them in once the system is fielded or complete operational failure because the cost is prohibitive or the window of opportunity is closed. Think of a car manufacturer who must recall all cars in order to add a safety part or the financial package that fails to make a crucial calculation because it was not known to be needed. Information Week also agrees that requirements management is critical. Requirements management is becoming the key discipline for improvement. Analysts, journalists and the industry alike, are all waking up to the realization that requirements are the foundation of everything else you do on a project. Manage your requirements properly throughout the life of the project and your goals and achievements are never in doubt.