Using DOORS to Manage Requirements for the US Army's …galactic-solutions.com/downloads/iRE12_Using_DOORS_to_Manage... · Using DOORS to Manage Requirements for the US Army's Next

© 2009 IBM Corporation

Requirements Engineering Session iRE12

1Approved for Release, Distribution A, PM FCS 28 April 2009, case 09-044

Using DOORS to Manage Requirements for the US Army's Next Generation of Manned Ground

VehiclesMichael Sutherland

Requirements Management, General Dynamics Land Systems [email protected]

Requirements Engineering Session iRE12

© 2009 IBM Corporation Approved for Release, Distribution A, PM FCS 28 April 2009, case 09-044Approved for public release; distribution is unlimited.

http://www.ibm.com/software/rational

IBM Rational Software Conference 2009

Requirements Engineering Session iRE12Using DOORS to Manage Requirements for the US Army's Next Generation of Manned Ground Vehicles - Michael Sutherland – [email protected]

2Approved for Release, Distribution A, PM FCS 28 April 2009, case 09-044Approved for public release; distribution is unlimited.

AgendaIntroduction to IBM® Rational® DOORS® and Future Combat Systems

1. Incorporating new versions of Lead System Integrator customer requirements modules into contractor DOORS databases.

2. Managing and synchronizing multiple contractor DOORS databases, including mastership and linking by attribute.

3. Managing the Manned Ground Vehicle product family in DOORS.4. Generating requirements development metrics out of DOORS.5. Delivering published Word requirements specifications, trace reports,

and corresponding DOORS linked modules to the customer.6. Incorporating Requirements Analysis, Compliance, Verification, and Test

Plans into DOORS.7. Incorporating IBM Rational Rose UML Functional Architecture into

DOORS.8. Incorporating IBM Telelogic Rhapsody models into DOORS.9. Incorporating Vitech CORE interface specifications into DOORS.



3Approved for Release, Distribution A, PM FCS 28 April 2009, case 09-044Approved for public release; distribution is unlimited.

Introduction to IBM® Rational® DOORS® and Future Combat Systems




IBM® Rational® DOORS®IBM® Rational® DOORS®, the market and technology leader in requirements management, increases the quality of systems engineering, business-critical IT and software development projects by improving requirements communication and collaboration.

DOORS enhances quality by increasing the visibility of business objectives, customer needs, technical specifications, and regulations.

With powerful capabilities for capturing, linking, analyzing and managing changes to requirements and their traceability, this multi-platform system ensures conformance to requirements and compliance with regulations and standards.http://www.telelogic.com/products/doors/doors/index.cfm

http://www-01.ibm.com/software/awdtools/doors/




Future Combat Systems

The Boeing Company and Science Applications International Corporation (SAIC), are the FCS Lead System Integrators (LSI).

General Dynamics Land Systems Inc. (GDLS) and BAE Systems were selected by the FCS LSI to form an integrated design team for the Manned Ground Vehicle (MGV) portion of the FCS program.

https://www.fcs.army.mil/




Future Combat System – Manned Ground Vehicles

https://www.fcs.army.mil/mgvfocus/index.html

The MGV family, which consists of eight vehicle variants is based on a common chassis and is the central link to the FCS network. Unique capabilities are added to the common chassis to achieve the full and distinct functionality of each variant.

GDLS has responsibility for three variants and the common chassis.




GDLS Variant – Reconnaissance and Surveillance Vehicle (RSV)

https://www.fcs.army.mil/mgvfocus/XM1201.html




GDLS Variant - Mounted Combat System (MCS)





GDLS Variant – Command and Control Vehicle (C2V)





BAE Systems - Variants

https://www.fcs.army.mil/systems/index.html

BAE Systems is responsible for additional variants (highlighted in red)

NLOS-M, NLOS-C, MV-T, MV-E, FRMV, ICV




Incorporating new versions of Lead System Integrator customer

requirements modules into contractor DOORS databases.




Prime Item Development Specification (PIDS)

The “PIDS” are the Requirements from the LSI for the MGVs

Periodically updated with additions, deletions, and modifications and reissued to the MGV team

Delivered in a DOORS module .dma file




Identify Differences in PIDS Versions

Use DXL script to identifyAdditions (New Requirements)Deletions (Deleted Requirements)Modifications (Changed Requirement Text)

Works well because each new PIDS are delivered in a DOORS module

Additions are identified by finding Object Identifiers in new PIDS that were not in the previous PIDSDeletions are identified by finding Object Identifiers in the previous PIDS that are not in the new PIDSModifications are identified by matching Object Identifiers and using diff() function




diff() function

DXL has a built in function called diff() that can compare text strings and show the differences

See also: http://en.wikipedia.org/wiki/Diff




diff() - Example

A view in each module (previous and new) is required to see entire set of Additions, Deletions, and Modifications




Redlining and Allocation

MGV Chief Engineers use the output of the diff() effort to assist with Redlining and AllocationRedlining

Redlining is a double-check of the diff() effort to determine if requirements of similar intent were deleted and added with new Object Identifiers. Requirements represented by Graphics and Tables also need to be scrutinized.Redlining determines if modified Requirements have had a Major change of intent, or just a Minor Change (rewording, grammar, spelling, whitespace, etc.)Redlining identifies requirements that the MGV team has identified issues with (unfeasible, conflicting, redundant, etc.)

AllocationAllocation evaluates which MGV Systems are impacted by each PIDS requirement




Copy Subsystem Links

The knowledge gained by the diff(), Redlining, and Allocation effort is used to copy Subsystem links from previous PIDS to new PIDS.

Links are copied only if a requirement with similar intent is found.If a requirement has a parent to the previous PIDS, but not to the new PIDS, the engineers must reevaluate the link parentage of the requirement.




Updating to new Customer Requirements

The sequence of activities has proven effective in reducing the work necessary to adapt to updated customer requirements.

Automations provide value, but are only an aid to the engineers.Having the customer issue requirements in a DOORS .dma file, instead of or in addition to Word .doc or Adobe .pdf files, is an essential part of the process.Without DOORS, the following options are normally attempted

The Word “Compare and Merge Documents” functionality can sometime help, but will fail if the documents have been substantially changed or re-arranged.Adobe .pdf files can be converted into text and compared in a similar manner. Third-party tools are available to convert .pdf to .txt.




Managing and synchronizing multiple contractor DOORS

databases, including mastership and linking by attribute.




MGV Team Databases

GDLS manages master databaseBAE divisions (BAE-AS and BAE-GS) can read and write real-time to the GDLS master database

A dedicated encrypted communication line is used.BAE uses their local DOORS license pools.Performance is sometimes slow but usable, as the BAE sites are geographically distant from GDLS.

BAE divisions manage separate local databases.Modules that are 100% BAE responsibility are “mastered” in their local BAE databasesDOORS module archives (.dma) files are periodically sent to GDLS and restored as read-only in the master database.

The LSI Customer and MGV Subcontractors are also accessing master database using their own licenses and an encrypted VPN

An encrypted VPN connection is used.Customer accessing master database in read-only mode




MGV Mastership Scheme

This scheme works well as long as each module is writeable in only one database, and set to read-only in the other databases.

All parties must agree and adhere to the mastership scheme, as there is no automatic way to enforce the rules.Temporary re-masterships can be performed, but are discouraged.

DOORS .dma Module Archives are used to transfer the full data set (all attributes, views, object hierarchy, Absolute Numbers, OLE objects, DOORS native tables)




MGV Module Transfers

Other data transfer methods were considered and rejectedPartition and Rejoin was rejected.

The attribute definitions of the imported partition in the “Away” cannot be edited. The access rights to the objects contained in the “Away” partition cannot be changed to enable Sharable Edit.

Excel .csv was rejected.The DOORS generated .csv file does not handle the Object Hierarchy, OLE objects, or DOORS native tables.

Citrix/Remote Desktop Connection solutions were rejected due to cost.Telelogic Requirements Exchange Format (RIF) was not available at the time this process was developed.

GDLS plans to evaluate RIF as it becomes available and matures




Archives and Links

DOORS .dma Module Archives do not transfer linksDOORS .dpa Project Archives can transfer links if the Source Module, Target Module, and Link Module for the links are all contained in the .dpa.There was no way to structure our project to take full advantage of Project Archives.

An enhanced “Link by Attribute” tool was developedDOORS standard “Linking by attribute” tool has the following limitations

Can only link one Module per attribute

Does not record Module name or path

Does not record Link Module name

Does not record Link Attributes




Link by Attribute – Verbose RecordingA record is created for each incoming or outgoing link.For outgoing links, information is recorded about the target object.For incoming links, information is recorded about the source object.Link attributes are also recorded.Not all fields in the record are used.




Link by Attribute – Restoring Links

A DXL utility was written to parse the link records and recreate the links

Lists source and target module names for all recorded linksSelectively create links by module name, as each database has a unique schemaSearches database for matching module names– Allows for different module names in different databases (browse & select)– Allows for different module paths (locations) in different databases

Recreates link attributesIdentifies link creation problems

Missing Absolute NumbersSoft-deleted Objects




DOORS .dma Module Archie - Access Rights

If a Module has any specific access rights set on data items internal to the Module (Views, Attributes, Objects), those rights are transferred as “User/Group Absolute Numbers”

The “User/Group Absolute Numbers” will map to a different set of users when the module is restored in another DOORS database.The process used to work around this is as follows:

Record LinksArchive (DOORS copy and paste not used, as outgoing links would be replicated)Restore module in “temp” work area.Remove access from copy using DXL script - function “inherited()”Archive the copyDelete the copy in DOORSDistribute resulting DOORS .dma module archive




DXL distribution

DXL scripts are packaged in a .zip file and restored and mounted at remote databases

DXL CategoriesModule DXL – appears on the Module MenusProject DXL – appears on the DOORS Database Explorer MenuLayout DXL – used in ViewsAttribute DXL – used to set the values of Attributes in a Module

Periodic updates are distributedMounted on share network drive for each remote siteNo need to encrypt the dxl at this time




Classified Requirements

Classified DOORS LabPCs use dedicated (Node-locked) licensesSimilar Database and Mastership scheme to unclassified

GDLS has master classified databaseNo remote access to DOORS for BAE divisions– BAE has their own remote classified DOORS databases– BAE comes to GDLS site for reviewsClassified data (Word, Excel, .dma, etc.) is transferred via approved classified network connected to classified computers

Known riskHow to get IBM support in classified arena?




Managing the Manned Ground Vehicle Product Family in

DOORS.




Requirement Attributes

“Requirement?” – “Threshold” vs. “Design Guidance” or “Information”.

Objects marked “Threshold” are shall statements (requirements) to be implemented, validated and verified.Headings are never requirements, requirement objects never have heading text

“Variant” – Multi-pick list of the eight MGVsMany Engineers often believe they need eight separate DOORS modules to produce a unique specification for each variant.

In such cases, management intervention was needed to educate the engineers and enforce the combined module.

“Increment” – Development PhasesIncrement 0 (NLOS-C) pulled-ahead in schedule for early production (see public link below)Increment 1 for all other vehicles

http://www.globalsecurity.org/military/systems/ground/fcs-nlos-sd.htm




DOORS allows “soft-deletion” and “hard-deletion” of Objects

DOORS does not allow deletion of Objects with incoming links.The MGV team uses a life-cycle attribute “Requirement Status”.“Requirement Status” has values such as “Approved”, “Peer Approved”.“Requirement Status” also has value of “Deleted”.

Marking “Requirement Status” == “Deleted” indicates a deleted requirement.

Requirements marked “Deleted”Never published, as they are filtered out in publishing views.Never counted as valid parents for traceability.Can be left in place or are moved to a special section at the end of the module that does not get published.

Requirement Deletion




Attributes and Values – “State” of Requirement Objects

State based issuesMain focus of development are requirements marked as follows:

“Requirement?” == “Threshold”“Increment” includes “Increment 1”“Requirement Status” != “Deleted”

Link traceability reports and requirements metrics must be programmed to not only count objects and links, but also must comprehend the state of objectsExample: An “Increment 0” only requirement is not a valid parent for a “Increment 1” child.Some reports also need to comprehend the “Variant” of each Requirement.

Leads to significant development and maintenance of custom DXL scripts, as the DOORS “out-of-the-box” report functionality does not comprehend the state of each requirement




FilteringGaps

In previous reviews of published specifications, users identified gaps in hierarchy (outline structure) as a defect to be addressed.

Example: Heading 3.1.2 followed by Heading 3.1.4, with no Heading 3.1.3The solution is to use a publishing filter that accepts heading 3.1.3, and to modify the publishing tool to insert N/A below any empty headings.

Menu filtersPublishing filters contain logic that cannot be saved in a DOORS view.

DXL accept() and reject() functionality.Publishing filters are written as DXL scripts and placed on the Module user menu.

Allows for complete flexibility in filtering.The filter can be changed once, and the changes will be available for all Modules without updating a View for each Module.

Publishing filters allow users to preview data set before export (WYSIWYG).




Other common DXL automations

Distribution and modification of Views, Attribute Definition, Attribute Types

Application and interrogation of Access Rights

User and Group creation and manipulation

Link manipulation

History reporting

CPS (Change Proposal System) views and reporting




Generating requirements development metrics out of

DOORS.




Metrics (Subsystem CIDS to Customer PIDS)

Custom DXL script interrogates modules and exports results directly to Excel

Details available in the proceedings of the “Telelogic Americas' 2002 Users Group Conference”

DOORS DXL - Adventures in Microsoft OLE Automation




Metrics Script (Subsystem CIDS to Customer PIDS)

Subsystems and Components exported in Rows




Metrics Script (CIDS to PIDS) - Detail

Data Values Exported in Columns




Metrics Script (PIDS to CIDS)

Each Customer CIDS Requirement is allocated to one or more subsystems

Each Subsystem CIDS module must have one ore more valid requirements linked to each allocated PIDS requirement




Metrics Scripts - Views

Modules have views that use the same logic as the Metrics generation scripts

Views show the problem objects that are preventing a Subsystem from being 100% on their metrics

PIDS Customer Requirements ViewsSubsystem has Allocation but no valid linked Child RequirementsSubsystem has linked Child Requirements but no Allocation

CIDS Derived Subsystem Requirements ViewsSubsystem Requirement has no valid PIDS parent customer requirement– Recursive across levels




Telelogic Dashboard for Metrics

http://www-01.ibm.com/software/awdtools/dashboard/

GDLS plans to evaluate the “Telelogic Dashboard” product




DOORS Login Metrics from “login_history.txt” file

The “login_history.txt” file is parsed to generate login metricsNumber of unique user logins per day.Number of new users per month.




DOORS Floating License Usage MetricsGDLS does not own a commercial “Software Asset Management” (SAM) tool to track DOORS floating license usage

DOORS manages floating licenses using the Acresso Software FLEXnet Publisher http://www.acresso.com/products/fnp/flexnet-publisher-overview.htm

Previously owned by Macrovision and GLOBEtrotterPreviously known as “Flexible License Manager” or “FlexLM”FlexLM includes a “lmutil” function– lmutil lmstat -a -c 19353@LICENSE_SERVER_NAME

– Lists number of licenses checked out at that instant– Executed as a scheduled task (Unix “cron job”) every 10 minutes– Used to accumulate data on checked out licensesResulting log file is parsed to determine daily peak license usage




DOORS Floating License Denial MetricsThe FlexLM license server daemon process generates a debug log file

The FlexLM manual, Appendix D, states “The debug log file should not be used for usage reporting.”They never say why this should not be done.

The FlexLM license server records license usage16:14:49 (lmgrd) TIMESTAMP 3/17/2009

18:02:10 (telelogic) IN: "DOORS" USERNAME@MACHINE [telelogic]

18:06:04 (telelogic) OUT: "DOORS" USERNAME@MACHINE [telelogic]

The FlexLM license server also logs denials14:00:13 (telelogic) DENIED: "DOORS" USERNAME@MACHINE [telelogic] (Licensed number of users already reached. (-4,342:131 "Connection reset by peer"))

The FlexLM log is parsed to determine daily denials




Delivering published Word requirements specifications, trace

reports, and corresponding DOORS linked modules to the

customer.




Publishing to Word

GDLS uses a modified version of the standard DOORS Word exporter, with the following enhancements:

Attributes– Append “Object Identifier” to exported Requirement Text– Append “Variant” list for non-common Requirements– Append “Requirement Status” to Requirements for internal reviewsHierarchy– Add “N/A” to empty headingsGraphics and Tables– Center images on page– Center tables on page– Resize images to fit on page

Use DOORS standard functions for .dot templates and “Paragraph Style”




Telelogic Publishing Engine

GDLS plans on evaluating the “Telelogic Publishing Engine”

Replacement for:DocExpress (supported publishing tool)WEXP (unsupported publishing tool)

http://www-01.ibm.com/software/awdtools/pubengine/




Trace Reports

DOORS provides industry leading traceability reporting

Some complex reports push the limits of the DOORS display technologyTrace columns contain much more content than can be represented in the length of a page or screenExample: 5226 PIDS Customer Requirements generate 50395 CIDS Derived Subsystem Requirements– Many individual PIDS generate over 20 derived subsystem

requirements each– Trace report is generated to Excel .csv– Output similar to the DOORS Analysis -> Traceability Explorer




Example Trace Report

PIDS (Customer Requirement)

CIDS (Derived Subsystem Requirements 1-N)

Each PIDS requirement is in a unique row, followed by the N derived subsystem requirements

Total report is 55621 rows

Excel filtering and pivot table functionality is used for analysis




Extended Team Peer Reviews (ETPRs)

Reviewers need to comprehend a significant subset of attributes for each requirement

ETPR View available in DOORSETPR View also published to Word and Excel from same baseline using same publishing filter

ETPR Word extract has OLEs and DOORS Native TablesETPR Word extract append “Requirement Status”ETPR Excel extract has Attributes:




Customer (LSI) Database

Data formats delivered to the LSI customerWord .docExcel .xlsDOORS .dma Module Archives

FilteringAll formats (including .dma) filtered before delivery

Example: Unapproved or deleted requirements are not deliveredDOORS .dma Module Archive Process– Record parent requirement (PIDS) links in text attribute, baseline module, archive

without baselines (“cleans history”), restore module in work area, delete all views, delete extra attributes and objects not in filter set, archive, deliver .dma

– Modules will then have same content as Word and Excel extracts– LSI restores and links subsystem CIDS modules to their PIDS requirements




Incorporating Requirements Analysis, Compliance, Verification,

and Test Plans into DOORS.




Environmental Requirements

Certain Environmental Requirements are common across all IPTs

These requirements were gathered and placed into a common “Environmental Requirements for Subsystems” module

The Environmental specification is referenced by each Subsystem specification by document number and version.

An “Applicability Table” is added to Environmental module.

DXL script uses “Subsystem” pick-list attribute values for each Requirement to generate Table.




Specification Standard and VerificationMIL-STD-961D

This standard establishes the formats, contents, and procedures for the preparation of performance specifications, detail specifications, program-unique specifications, and associated documents, prepared either by Government activities or under contract.

Requirements in “Section 3” of the outline

MIL-STD-961D NOTICE 1 - VCRI (Verification Cross-Reference Index)FIGURE A-3. Sample requirements/verification cross-reference matrix for detail specification

http://www.everyspec.com/MIL-STD/MIL-STD+(0900+-+1099)/download.php?spec=MIL_STD_961D_NOT_1.1149.pdf

Verification Plan (text)




VCRI (Verification Cross-Reference Index)

Since every “Section 3” Requirement has a row in the Section 4.3 VCRI, the VCRI information for each requirement is stored as additional attributes of the Section 3 Requirement object

Verification Attributes: “Verification Method”“Verification Class”“Verification Plan”

The Section 4.3 VCRI and Section 4.3 “Verification Plan” are each exported to Word from a Layout DXL view and manually pasted into the specification at the time of publicationEliminates making additions, modifications, and deletions to VCRI rows when requirements are added, deleted, modified, or shifted in the hierarchy.Allows for easy generation of Verification completion metrics to determine if the engineers have documented the Verification for each requirement.




SWaP-C

SWaP-C (Size, Weight, Power, and Cooling)Allocation and estimate data for each subsystem and component of the product.

SWaP-C data is referenced in many specifications (SSDDs, ICDs, etc.)Placing this data in single DOORS module, and using “Dynamic Linked Cells” to reference the data, allows each specification to be automatically kept up to date and synchronized with the master SWaP-C data table.The SWaP-C data table is composed of rows and columns.

Rows are the subsystems and components which are represented as DOORS objects.Columns are the SWaP-C data which is represented as DOORS attributes.




SWaP-C Data Table Module

The SWaP-C data table Module is composed of rows and columns.

Rows are the subsystems and components which are represented as DOORS objects.Columns are the SWaP-C data which is represented as DOORS attributes.

Row (DOORS Object)“Cell”

Column (DOORS Attribute)




Dynamic Linked Cells

Details available in the proceedings of the “Innovation 2006 Telelogic User Group Conference”

Dynamic Linked Cells:An Implementation of "Virtual Objects" in DOORS




Analysis Module and Requirement Compliance

A single module stores references to analysis documents that support Requirements Compliance

Actual Analysis Documents are stored on Web, referenced by URL

Each analysis document is linked to by many Requirements

Requirements pull detail of each analysis into module using Layout DXL




Software Test Modules

Software Requirements Specifications (SRS) documents are maintained in DOORS

Subsystem/Software Test Plans (STP) modules link to Software Requirements

Software Test Descriptions (STD) modules link to the Software Test Plans

Software Test Report (STR) modules link Test Results to the Software Test Descriptions




Incorporating IBM Rational Rose UML Functional Architecture into

DOORS.




Rational Rose

http://www-01.ibm.com/software/awdtools/developer/rose/enterprise/index.html

The Rational Rose Enterprise tool is used by the MGV team to perform Functional Analysis using the Unified Modeling Language (UML)




Generating Requirements from UML

New Subsystem Requirements are derived from Operational Contracts, documented in DOORS, and traced back to the Operations in the UML surrogate Module.

An Operation may generate multiple Subsystem requirements, and a single Subsystem requirement may be generated from multiple Operational Contracts.

Operation(Parameters)




Traceability between UML and DOORS

Traceability must be established:

Between Use Cases and the System Requirements they were derived fromBetween Subsystem Requirements and the Operations they were derived from




UML – Surrogate ModuleMakes the model more widely available for consumption.

Daily synchronizations allow for timely communication of changes.

Filtering and sorting allow for custom views.




Rose Link - EvaluationTelelogic has developed a product called “DOORS - Rose Link” to accomplish requirements traceability between the two tool sets.

GDLS evaluated Rose Link v2.8, and found that even though it is a very capable integration, it did not fit well into the FCS MGV System Requirements Analysis process for the following reasons:

No graphical representations of UML diagrams were made available in DOORS.Some UML elements and diagram types were not represented in DOORS in any form.Knowledge of the complex UML Browser hierarchy structure was not represented in the DOORS Module Explorer view.Knowledge of the relationships between UML elements was not well represented.




DOORS and UML – Further Detail

Because of the critical importance of establishing traceability throughout the System Requirements Analysis process, GDLS developed a custom integration between DOORS and Rose.

Details available in the proceedings of the “Telelogic 2004 User Group Conference”

Developing Complex Systems Using DOORS and UML




Incorporating IBM Telelogic Rhapsody models into DOORS.




Telelogic Rhapsody

http://www-01.ibm.com/software/awdtools/rhapsody/

The Rhapsody tool is used by the MGV team to develop SysML and UML models and perform simulations

Telelogic provided DOORS-Rhapsody integration is used to take Functional Architecture Elements from Rhapsody elements and push them into surrogate DOORS module




Incorporating Vitech CORE interface specifications into

DOORS.




Vitech CORE

http://www.vitechcorp.com/products/index.html

The CORE tool is used by the MGV team to manage interfaces between Subsystems




Interface Control Documents (ICDs)Engineers enter interface data into the CORE tool.The ICD is then populated with data tables generated from CORETables contain DOORS “Object Identifiers” in “Subsystem RID#" column




CORE tables

Exported from CORE to a Word .doc, then exported from Word into DOORS Module

Use standard DOORS Word “Export to DOORS” functionalityTables imported to bottom of module, manually move up to correct section

Tables contain DOORS “Object Identifiers”.– “Object Identifier” = Module “Prefix” + Object “Absolute Number”– “XXXX-####” = “XXXX-” + “####”

First cell in each DOORS Table Row is linked to the corresponding parent Object(s) via DXL script.

– Since the Module Prefix for each Module is stored inside the DOORS module as a Module level attribute, a lookup table is generated and used to determine which Module corresponds to each Module Prefix.




CORE Table Linking

Subsystem Requirement Linking IssuesNo Module for PrefixNo Object foundSoft-deleted ObjectObject marked DeletedObject not Increment 1

Report generated for each error




Summary of DOORS Support Tasks




Conclusion

All aspects of DOORS support need to be considered

There are no “spare time” tasks.

Addition of complexity creates ripple effectUnforeseen consequences of innovation.

All enhancements must be supportedIncluding user created enhancements.

Plan for unplanned workOverestimate support manpower.







© Copyright IBM Corporation 2009. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.