Summer is on the Way (Spring 2024)

Vernal (Spring) Equinox 2024-03-20

Summer’s on the way for those in the Northern Hemisphere.  The Vernal (Spring) Equinox is marking the first day astronomical spring. Explained further on

Why not consider a spring clean, remove all those dusty files full of project requirements version 1 to version 9. Why? Will you really be able to find what you are looking for without a way of searching? Consider whether you can sensibly access the details of those designs sitting rolled up in mailing tubes. Do you have the means to edit them electronically any more. Does anyone know where the file is kept?

NOTE: If you live in the Southern Hemisphere you don’t have to wait until spring you could have an Autumn clean !

sunrise picture

Cradle can help save your day!

With all the data for your project in one convenient tool, everything from the requirements through the project plan, the design and the test results conveniently linked together. Isn’t that much nicer than a set of files on shelves?

From under £300 (Current Requirements Management Desktop price March 2024) you could bring order where there was chaos. See the comparison chart for details of which tool suits best and the shop for current price details.

Cradle Modules – SWE

Cradle-SWE Module

The Cradle SWE module provides reverse engineering and code generation to maintain consistency between a detailed system design and its software implementation.

Cradle SWE Module
Cradle Software Engineering SWE Module

Software Engineering

There are many contexts for software engineering, each using its own methods and languages. This module is intended for groups using functional methods to build software in C, Ada or Pascal.

Detailed software designs are represented using Structure Charts (STCs) with 3SL extensions to support:

  • Hierarchical descriptions of software into systems
  • Programs
  • Subsystems
  • Modules and source files
  • Representation of functions
  • Representation of basic data types

Software designs are described with diagrams, data definitions and module specifications that hold the pseudo code, descriptions or source code. This software design is cross referenced to architecture, design/analysis models, to requirements/test cases, and to all other data.

The initial design can be code generated to:

  • C, Ada and Pascal type definition header files (built from the model’s data definitions)
  • Source files that contain the call hierarchy from the STCs
  • Call arguments and local variable declarations
  • Content of the STC’s module specifications’ pseudo code or detailed design material.

Once algorithmic content is added to the generated code, the resulting completed source files can be reverse engineered back into the Cradle database, to update its design diagrams, and both the data definitions and module specifications of these diagrams’ symbols.

Reverse Engineering

Reverse engineering merges the actual source code into the design definitions and specifications. Each source file is subdivided into the individual routines. The component parts are then stored into separate frames in the module specification and data definition items in the database. Every line in each source file is stored in a frame of one of these items in the database.

The Code Generator can be run on the results of the reverse engineering to reconstruct the source files, either as they were, or including any changes made in the design model. In this case, the source code is generated using call interfaces built from the (possibly modified) STCs and the routines’ bodies are created from either the STC call hierarchy or the source code from the previous reverse engineer operation.

The process can start by reverse engineering legacy source code into an initial design model, recovering designs in situations where only the implementation currently exists.

As reverse engineering loads all source files into the database, the source files could be deleted, and instead configuration managed through the Cradle Configuration Management System as part of the design.

The diagrams, specifications and data definitions can contain any number of attributes, including URLs to reference the source code in a source code control system, such as Git or Subversion.

Format of Generated Code

The format of all generated code can be tailored to match your coding standards. Data definitions can be marked to be standard data types and generated into the source code. Header files can be produced from the composition specifications inside the data definitions to create record and variant structure declarations.


The reverse engineering tool supports any compiler programs and conditional compilation directives. It can distinguish application code, application libraries and standard library or operating system / runtime routines, and render the design diagrams accordingly. This uses any combination of regular expressions, and Cradle-supplied or user-defined library routine lists.

Reverse engineering can process one or more source files in one run, creating a hierarchy of design diagrams to represent the code structure beyond individual source files.

Full Traceability

Using the reverse engineering tool creates full traceability across the entire system lifecycle, from user needs to system requirements to analysis, architecture and design models, to test procedures, specifications and test cases, to the source code. Cradle’s transitive cross reference view facilities allow users to directly see the user requirements and acceptance criteria associated with each source code module, and vice versa.

Feature Summary

Feature Summary - SWE
Feature Summary – SWE

Please contact 3SL for further information about adding a Cradle SWE module to your existing system.

Cradle Modules – WEBP

Cradle-WEBP Module

The Cradle WEBP module publishes sections of Cradle databases as fully hyperlinked, standalone, websites that can be viewed independently of Cradle.

Cradle WEBP Module
Cradle Web Publisher WEBP Module

In general, users will access a Cradle database through a Cradle web UI or a  non-web UI such as WorkBench.

There are situations where direct access is not possible, particularly if the users are remote from the database and do not have any external electronic access, of if the data is classified and cannot be sent across a public network, such as the Internet, even if the connections are secured.

In such cases, database information is normally published into one or more documents that are provided to the external users. This works well, except that documents are linear, a sequence of pages, and it is not always easy to explore their contents. This is particularly true for analysis and design models where there are many connections between the models’ components, and also when following cross references between items.

Website Pages

The Web Publisher tool generates a static website containing some or all of the items in a database. This website contains three types of page:

  • A top-level page
  • Pages containing lists of each item type that has been published
  • Individual pages for each item

The pages for individual items contains lists of links to related items of each type, grouped by the type of cross reference.

Diagrams are published as SVG so they can be zoomed, panned and scrolled. All diagram symbols are hyperlinked to lower-level diagrams and to the symbols’ descriptions in specifications and data definitions.

Website Links

So the pages for individual items are connected by hyperlinks in the same way that the database items are connected by cross references.

Users can follow these hyperlinks to explore the information in any way that is convenient to them.

Website Distribution

By being static, the website is fully independent of Cradle. By being read-only, the websites can be distributed on CD or DVD, In effect, the website is a self-contained snapshot of the parts of the database that you have chosen to publish.


User-defined criteria specify the item types, and items of these types, to be published from the database. The form and content of the website’s main page can be controlled with a user-defined template. The tables for each item type have user-defined columns and contain any attributes. The pages for items have individual user-defined templates so that the layout and attributes to be published can be controlled.

Collectively these templates are called a theme. Several themes are provided with Web Publisher. You can create your own themes to include your company or project logos and branding.

Items in a Cradle database can contain any number of attributes of a wide variety of types, including URLs. So any item in Cradle can contain URLs that link it to other resources, either on the Internet, or intranet, or data in another environment.

You can include these URL attributes in your templates for the Web Publisher. By doing so, the pages published by the Web Publisher will contain these URLs so that a user browsing the published website can follow the URLs to access the related information, wherever it may be.


Websites are published into a user-defined top-level file and a directory containing all other pages. It is easy to link the generated site into a larger set of information, including any site-specific modifications to the hyperlink URLs.

Different baselines, or work-in-progress, can be published to separate websites, for comparison between approved and current activities.

Feature Summary

Feature Summary - WEBP
Feature Summary – WEBP

Please contact 3SL for further information about adding a Cradle WEBP module to your existing system.

Cradle Modules – WEBA

 Cradle WEBA Module

The Cradle WEBA module provides the means to create custom web UIs that allow users to access Cradle databases from web browsers in a manner that is appropriate to their needs and use cases.

Web Access
Web Access

Cradle provides WorkBench as the means to access databases and provides many choices to create a customised environment, including start pages and the phase hierarchy. However, WorkBench is not suitable for all users:

  • Users may not want to install Cradle
  • Users may be remote from the Cradle system and WorkBench may not provide acceptable performance (despite server-side processing)
  • Users may not allow Cradle to communicate through their firewall
  • WorkBench provides more functionality than needed and, therefore, appears too complex

Why use Web UIs?

So there are at least three reasons why a project may wish to create web UIs:

  • IT restrictions in the use of WorkBench
  • Performance needs of remote users
  • Provide simple UIs tailored to the needs of specific user groups

Cradle allows web UIs to create, manipulate or view database information. Each web UI is created to meet the needs of a group of users, either to offer a wide range of UI controls to provide a flexible and powerful UI so users can perform many tasks, or a simple UI that allows users to perform perhaps one or two tasks very quickly and easily.

All web UIs are zero thickness, with no client-side code. There are no browser add-ins or plug-ins needed.

Creating Web UIs

Any number of web UIs can be created. Each is associated with a project-specific user type. Each Cradle login account is also associated with a user type. When a user connects to the Cradle Web Server (CWS) and logs in, the CWS serves the web UI defined for the user’s user type, or a default web UI.

Therefore, the CWS can serve many, potentially very different, web UIs to its users, based on their user types.

Users login to a web UI with the same username and password used with non-web tools. Web-based users have the same access rights to items and Cradle operations as users of non-web tools such as WorkBench and utilities.

Web UIs are created from templates and building blocks provided in the Cradle WEBA module. The module also includes two example web UIs:

  • A web UI using all blocks to offer a powerful and flexible environment for engineers
  • A basic UI providing controls over page layout, item creation, viewing and reporting

Using the Cradle WEBA Module

In the example web UIs, users can create, view, edit and delete items and they can manipulate and follow cross references:

Users can navigate through the database using the phase hierarchy, the master tree, or using a table-based browse mechanism,

Items edited in web UIs are locked in the same way as non-web UIs and the API, to prevent simultaneous update by other web or non-web users.

Tables of items shown in web UIs will load into Word and Excel as hyperlinked documents.

Web users can create and use the same queries as non-web UI users. All query processing is server-side in the CWS to optimise the performance for each user.

Views created in WorkBench can be used in web UIs. Items can be edited in table views. Items can be shown in user-defined forms. Binary data can be modified and uploaded in a web UI. Rich text can be shown in web UIs.

Diagrams are shown in SVG. Diagrams can be zoomed and panned. Hyperlinks in each diagram symbol allow users to navigate to child diagrams and from symbols to their descriptions in data definitions and specifications.

Change histories are also fully supported, together with all collaboration facilities, including discussions and alerts.

Authentication to web UIs can use LDAP and support single sign-on. Access to web UIs can be limited to specific proxy servers, network interfaces and remote hosts.

Cradle provides cradle:// protocol URLs that allow direct access to items and query results by external tools.

Feature Summary

Feature Summary - WEBA
Feature Summary – WEBA

Please contact 3SL for further information about adding a Cradle WEBA module to your existing system.

Cradle Modules – PERF

Cradle-PERF Module

The Cradle PERF module applies user-defined calculations to an architecture model, to compare the performance of alternative architectures and apportion performance budgets to subsystem, component and equipment designs.

Performance Modelling PERF Module
Performance Modelling PERF Module

Simulation is an activity to reproduce a system’s behaviour in an artificial environment to test the system in a variety of scenarios. Simulation is used where testing the real system is either dangerous, impracticable or too time-consuming or expensive. The most fundamental behavioural characteristics of systems are set early in the design process, as alternative architecture topologies are assessed and performance budgets are set. But as there is no behaviour allocated to the components, it is not possible to build a simulation.

Performance Assessment

Performance assessment solves this problem. It is used before behaviour is known and allocated and so before simulation can be used. It can be used:

  • To confirm if a proposed architecture is viable
  • To compare performance characteristics of candidate architectures
  • To define budgets for lower design levels (apportionment)
  • To aggregate actual values

Performance assessment is expressed in user defined characteristics, typically concerned with timing, data error or precision, such as:

  • Bandwidth
  • Utilisation
  • Size
  • Cost
  • Data rate
  • Staleness
  • Weight
  • Power

They can be subdivided, for example to study best case, worst case and typical conditions. They are held as user-defined formulae in the specifications and data definitions of the symbols in the architecture models’ diagrams.

Performance Characteristics

Any number of performance characteristics can be defined and associated with each diagram symbol. Each has its own formula. These are defined using a function library and user-defined calculation routines. This library contains logical, arithmetic, logarithmic, exponential, ladder, table lookup and interpolation routines, amongst others.

System performance requirements are applied as constraints to these characteristics by linking the items in the database and defining ranges of values for the performance characteristics that should not, or may not, be exceeded.


Analyses are run on state models that are sets of interconnected diagrams at appropriate levels in the architecture.

A state model can have external loads applied to it to represent different usage scenarios. An analysis can contain many such environmental loads. The environmental loads are defined as values of any of the performance characteristics at the external input(s) to the model.

Each analysis applies the environmental load and calculates performance characteristics for all of the symbols in the state model’s diagrams using the formulae and constraints in each symbol. The results are therefore quantitative. They are stored inside the symbols’ descriptions.

The results can be reported in the same manner as other information in a Cradle database. They can also be graphed. The graphs will typically show the values of specified characteristics along a path through the model, termed a thread. Each graph will show any constraints applied from the system requirements and the effect of the constrains on the analysis results. The data in such graphs can be exported to CSV.

Any number of thread analyses can occur.

The results will show that an architecture is viable if none of its constraints are violated.

Since the performance data is built into the architecture model, any changes to the model’s topology (such as a change to the architecture) will be automatically reflected in changes to the performance results. This allows easy comparison between alternative architectures.

The analysis results are the characteristics of a viable architecture. Hence, they are the constraints or budgets for the next level of design. So the analysis of each level produces performance constraints for the next level. This process can continue through the design levels until the system behaviour is sufficiently defined for simulation to be practicable.

Feature Summary

Feature Summary - PERF
Feature Summary – PERF

Please contact 3SL for further information about adding a Cradle PERF module to your existing system.

Cradle Modules – SYS

Cradle-SYS Module

The Cradle SYS module provides an analysis, process, architecture and design modelling environment that, being linked into the systems engineering lifecycle, provides full traceability and coverage for all model information. You can use SysML, UML, ADARTS, SASD, eFFBD, IDEF, BPM and other notations to achieve your MBSE goals.

Systems Modelling Module
Systems Modelling Module


A model is an abstraction of an aspect of a system being developed.  Therefore, models should not be separate from the needs, goals and objectives that the model seeks to satisfy, nor from the tests that validate the system’s compliance. Hence Cradle integrates modelling into all requirements and other systems engineering data, so every component of every model is traced to the highest level user need and to the lowest level test result.

This applies to agile and phase-based processes. An agile process has no less need for models simply because its iterations are short. To neglect rigorous design in agile projects will ultimately compromise the system if a clear design is not modelled at the outset and maintained through each iteration.


Each Cradle database provides analysis and design domains. Each domain can contain any number of models, optionally organised in hierarchies. Models can be used to represent concepts such as:

  • Alternative missions in a CONOPS
  • Products within a range
  • Regional variants of a product
  • Comparative analysis of architectures

Each model contains any number of diagrams from a wide variety of notations.  Each diagram contains symbols, and each symbol is described by a data definition or specification.

All diagrams, specifications and data definitions in a model can be cross  referenced to each other and to information in all parts of the lifecycle. So user requirements can be linked to use cases, that are linked to system requirements, that link to a logical model of system behaviour, that can be allocated to a logical architecture, which in turn can be allocated to multiple physical architecture models for assessment.

A System Breakdown Structure (SBS) is useful as an abstraction of the system composition, and as a single structure to which all the requirements can be linked. The alternative system architectures and designs can be explored, each in its own model, all models linked to the SBS. This simplifies traceability for the requirements and the performance constraints, without restricting the modelling activities.

Models can link to a Product Breakdown Structure (PBS) to allow linking to a PLM environment.

Diagram Notations

Cradle has over 20 diagram notations from methods including UML, ADARTS, IDEF, SASD, SysML and data, process and architecture modelling. The notations can be combined when semantically viable. Cradle does not limit you to one method, nor constrain your choices for the notations that will best express the system for the audience of that model.

Cradle provides a consistent, interface to building diagrams. It includes time-saving features to build diagrams in time-sequenced notations, such as Process Flow Diagrams (PFDs) and extended Function Flow Block Diagrams (eFFBDs).

In hierarchical notations, Cradle has a range of features to build both child and parent diagrams that are automatically consistent.

Consistency Checking

Cradle enforces diagram syntax when editing. Completeness and I/O consistency checks are provided, both within a diagram and between diagrams to ensure conservation of data and function. Cradle can also check the consistency of diagram graphics and text descriptions. For notations that use it, Cradle provides a full Data Dictionary with a formal BNF notation to describe data composition.


In architecture models, Cradle supports data protocol descriptions across interfaces and can generate message formats (bitfields) that describe the formatting of the messages in all data exchanges.


Diagram symbols can be coloured and have embedded graphics, to ease users’ understanding of the model.

Notations and Models

Notations can be combined, such as using UML and other diagrams in the same model. Some notations can be used in many contexts. For example Sequence Diagrams (SQDs) can show a message protocol across an architecture model interface, their role in SDL before their use in UML.

All model elements can contain graphics, video, figures, tables, equations, URLs and integrate with desktop tools including Visio, Word, and Excel. Each diagram, data definition or specification is an item in the database and so can contain any number of attributes each containing, or referencing, up to 1 TByte of any type of data.

Configuration Management

Models have change histories, discussions, comments, are formally reviewed in Cradle’s CM system, and can be baselined.


Models can be printed to a variety of devices. They can be part of user-defined documents with requirements, tests and any other information. Models can be published into static, hyperlinked websites that provide links between diagrams and between symbols and the descriptions. All Cradle web UIs support viewing and navigation of models.


Models can be loaded from other tools by import or data conversion from other tools’ data formats or XML.

Feature Summary

Feature Summary - SYS
Feature Summary – SYS

Please contact 3SL for further information about adding a Cradle SYS module to your existing system.

Cradle Modules – DASH

Cradle DASH Module

The Cradle DASH module provides the means to define Key Performance Indicators (KPIs) . It also provides the means to define their presentation as dashboards in web UIs, non-web UIs and reports.

Every project uses a process to create, review and publish its objectives, operational concept, sets of requirements, architecture and design models, and other systems engineering data. These processes will include:

  • Management reporting
  • Quality checks
  • Routine audits

of the volume of work completed, and the completeness and quality of this work.

Key Performance Indicators (KPIs)

KPIs are measures of the maturity of the information managed in the process, and therefore of the process itself.

Cradle supports KPIs as a convenient means to provide an overview of the status of an entire project, or any phase.

Any number of KPIs can be defined. Each KPI is a calculation based on one or more elements of one or more metrics:

  • Product
  • Sum
  • Difference
  • Deduction
  • Proportion
  • Percentage

combined to produce a single numerical value. The component values are derived from user-defined queries, that are searches of database items, or searches of the links between these items, or both. The component metrics can:

  • Count the values or calculate the total, mean, average, range or variance of the values from the items found by the queries
  • Use values held in attributes or the results from user-defined calculation attributes
  • These calculation attributes can use other attributes of the same item (this includes other calculations) and also attributes from linked items, such as calculating the total cost from the individual costs of a parent and its children.

Any number of colour-coded range bands can be defined for each KPI so that its value can be shown in a block with an appropriate background colour.

Using colours for the KPIs allows the overall project status to be seen at a glance. Typically, anything shown in green is good, anything shown in red will need urgent attention, and anything yellow needs to be monitored carefully. It is easy to apply such traffic light conventions in a KPI’s colour bands.

Dashboard in WorkBench
Dashboard in WorkBench


A collection of KPIs is held in a dashboard. Any number of dashboards can be defined, either personal to you, shared with other members of your team, or shared with everyone in the project, or available to all projects.

Each dashboard presents its KPIs as a column with the KPI shown either as a name and colour-coded number:

Dashboard in table view
Dashboard in table view

or as a dial:

Dashboard in dial view
Dashboard in dial view

The size and display styles of the dials can be controlled for each KPI.

The dashboard can be published as a report, either as a table or as a set of dials. As for all reports, output can be to a file, a printer or the UI. Such dashboard reports are fully supported in web UIs, and non-web UIs.

Dashboard Output
Dashboard output to a report

The value shown in each KPI is a link. Selecting this value will display the list of items that have been used to create the KPI’s value.

Dashboards are shown in a separate sidebar in both web UIs and non-web UIs. One dashboard can be set as the default and can be shown automatically when the UI starts.

Dashboard showing dashboard sidebar
Dashboard showing dashboard sidebar

Custom web UIs could be created to show a collection of dashboards, for example to provide a simple overview of the project and more detailed analyses of the status of each work area.

Dashboards can be published to RTF, HTML and CSV files.

Feature Summary

Feature Summary - DASH
Feature Summary – DASH

Please contact 3SL for further information about adding a Cradle DASH licence to your existing system.

Cradle Modules – MET

Cradle MET Module

The Cradle MET module provides the means to define metrics on the:

  • Needs
  • Requirements
  • User stories
  • Features
  • Models
  • Tests

It also defines metrics on all other systems engineering data in your project. Metrics are ran to monitor your progress.

Metric example
Metric example

Each project uses a process to create, review and publish its: objectives, operational concept, sets of requirements, architecture and design models, and other systems engineering data. These processes include management reporting, quality checks and routine audits of the volume of work that has been completed, and the completeness and quality of this work.

Metrics are a means to measure characteristics of your project data by collecting information about the materials created at each stage in the process. For agile projects, these characteristics will be analysed at the start and end of each iteration or sprint, and in phase based processes, the analyses are likely to be weekly or monthly as part of normal project management activities.

Metrics are user-defined sets of calculations that can be run from the user-defined phase hierarchy and start pages, from the metrics tool’s own UI, as a report, or from a command-line utility.

You can collect metrics on any of your project data. This includes requirements, use cases, functions, architecture components, models, interfaces, issues, risks, features, test specifications, test results, verifications and any other information generated by the systems engineering process.

Metric Elements

Each metric contains any number of elements, each of which is the combination of a query that finds the information in the database to be analysed, and an analysis to be performed on this set of items found by the query.

Metric Details dialog
Metric Details dialog

Each metric element can use a simple query, or a complex query that nests one query inside another. The items found by the query can be counted, or the metric can perform a coverage analysis of the values of all of their category codes, or it can perform a calculation on the values of one or more attributes, including those attributes that are the results of other user-defined calculations. The results of these operations can be grouped in up to two levels based on the values of other attributes. You can also calculate weighted totals and means of a set of values. This can be used to calculate compliance of responses to a RTF or ITT. Basic calculations can be performed which are based on the results of other metric elements.

Pivot Tables

Metrics can also include pivot tables, which are a special tabular display using two of the items’ attributes’ values as rows and columns where the cells show the number of items from those found by the query that have each pair of values for these attributes.

If a pivot table is shown in the UI, the cells in the pivot table become links. Selecting a link displays the items that have that pair of attribute values. Thus, users can decompose the totals shown in the pivot table’s cells into lists of items with corresponding attribute values.

Running Metrics

The results of running a metric can be shown in Cradle web UIs and in the WorkBench UI. They can also be generated to RTF, HTML and CSV files and loaded directly into a variety of tools including web browsers, Word and Excel.

Metric Output
Metric displayed in WorkBench

Access to the metrics facility can be controlled, to ensure reliable metrics are produced only in project-approve contents.

This mechanism allows projects to monitor:

  • The completeness of sets of needs or requirements
  • The completeness of their cross reference linkage
  • The volume of data generated by specific project groups.

Metrics can be generated from any project baseline(s), allowing cumulative statistics to be created as the project develops. You can view the database as it was at the time of any historic baseline, and generate metrics from that baseline.

Metrics can be referenced from within KPIs in dashboards using the Cradle DASH module.

Feature Summary

Feature Summary - MET
Feature Summary – MET

Please contact 3SL for further information about adding a Cradle MET licence to your existing system.

Cradle Modules – DOC

Cradle DOC Module

The Cradle DOC module generates documents by combining user-defined templates with items in the database. A document register and a correlation between documents and database items provides full traceability.

Document Generation
Cradle DOC Module

Projects use documents:

  • As sources of information (such as user requirements or regulations, codes and standards)
  • As confirmation of agreement (such as a CONOPS or RTM or SRD)
  • To define interfaces between project teams or organisations (such as a SDS or SSDS).

Often, a project’s progress can be expressed as the issue states of its key documents.

User Defined Reports

Cradle can generate user-defined reports that will satisfy all internal project needs for information, including:

  • Simple lists
  • Compliance tables
  • Change logs
  • Traceability
  • Coverage matrices

These outputs are produced from the report, view, query and matrix facilities of the Cradle-PDM module.

The Cradle Document Generation module exists to produce complete, high quality, documents directly from the database. It can publish documents that include cover pages, Table of Contents, List of Figures, sections with mixtures of hierarchical paragraphs, bullet lists, figures and tables.

Defining Documents

Any number of documents can be defined. Each starts as a Microsoft Word document that has all of the internal structure, page layouts, styles and formats required. The Document Publisher tool is used to insert tags into this template everywhere that data is to be reported from the database. Each tag defines both the information to be published, and the high-level formatting to be used for this information, for example if it is to be published as a hierarchy of sections, a bullet list, or as rows in a table. The tags can follow cross references in any manner required, so complex relationships can easily be included in the document. The tags are defined through a UI, so that complex scripts are not needed.

Arbitrarily complex tables, hierarchies of sections and subsections, embedded diagrams, paragraph and section numbering and self-referencing within the document are supported, all specified within these tags and their associated descriptions.

At runtime, the Document Publisher uses the tags to query the database for information that is to be loaded into Word and formatted according to the styles, contents lists and indexes of that Word template. Embedded binary data can be loaded into the document, including any other Word documents and other binary content, including figures, spreadsheet and drawings.

Document templates can include user-defined variables that are specified at runtime so that a single template can be used to produce many different documents.

Any number of these templates can be defined and each used to generate many documents. Each document publishing operation will report either the current work-in-progress information or the contents of project baselines created with Cradle’s built-in Configuration Management System.

Publishing Documents

Documents can be published from the Document Publisher tool’s UI, Start Page drop downs, from nodes in a user-defined phase hierarchy UI, or the command line. This allows Document Publisher to be run in batch mode, for example to publish standard project documents overnight.

When Document Publisher is used to publish a document from a template and the database, the resulting document can be marked as a formal document by specifying an issue, issue date and reference. In this case:

  • A copy of the published document is held in the database so it can be provided in the future
  • A record of the document is added into a formal document register, and
  • Cradle records which instances of database items were used to produce the document

This means that when anything changes in the database, you know which formal documents contain the items that have changed, so you know which formal documents need to be re-issued. The new version of these formal documents are also recorded in the register.

Comparison of the contents of different issues of project documentation and the items published within them, are fully supported.

Published documents can be provided to customers and suppliers. They can also be captured using the Document Loader tool, after an external group has made change. So cyclical processing of external documents is supported. When combined with the register of the issue states of project documents, this facility means that all document-orientated processes are supported. The tools therefore fully support all customer-supplier and supply chain management contexts.

Feature Summary

Feature Summary - DOC
Feature Summary – DOC

Please contact 3SL for further information about adding a Cradle DOC module to your existing system.

Cradle Modules – REQ

Cradle-REQ Module

The Cradle REQ module provides a complete requirements capture and engineering solution with built-in CM. It can manage needs, risks, products, features, tests, validations and any other data. It is easily applied to both agile and phase-based processes.

REQ Requirements Management Module
REQ Requirements Management Module

Requirements management is part of every agile and phase process. Stakeholder needs are captured, analysed and engineered. Changes are tracked in a CM system. All needs will be linked to design, build, test and acceptance information. In agile, this is in every sprint. In phase-based processes, it is less frequent. But the techniques are the same, and the same tool needs apply that only Cradle provides:

Requirement types can be defined (user, business, system, product, functional or non-functional), user stories and use cases. Link to codes, standards, regulations, knowledge or assumptions. You define other item types to be managed, such as functions, issues, tests, risks, SBS, PBS, WBS or defects. Attributes in these items are controlled, how they will be linked to each other, and their workflows.

Item Attributes

Items have user-definable attributes, each storing or linking to up to 1 TByte of data. Attribute types are user-defined, including dates, numbers, plain and rich text, single or multi-value lists, Office and other documents, and calculations.

The text in requirements, tests, verifications and other items can be quality checked against project-specific rules.

Items can be in hierarchies, groups and many:many relationships. You can create projects using a common library. Product ranges, models, variants and builds are supported. Items can be shared and reused in any of these structures.

Capturing Items

Items can be captured from external documents by Document Loader. It reproduces the document structure in a hierarchy of items. Each item is linked to its origin in the document. Figures are loaded automatically. Tables can be captured into items, images, Word objects or rich text.

Document Loader finds differences in new versions of documents. Loading the new version will update items and their links. Coverage analysis between documents and database items are provided.

Full version management of source documents is provided. Regression to previous versions is supported, with reversal of all changes.

Requirements and other items can be loaded from Word, Excel or other tools using plug-ins, data exchange or direct interfaces.


Coverage, traceability and impact analyses are easily run, then viewed as trees, lists, tables, matrices, or in dynamic Hierarchy Diagrams with user-defined attributes. Items can be filtered, sorted, split and merged. All changes to items can be logged. Users can be alerted to changes by Cradle, email or both.


Users collaborate by adding discussions to items and adding threads to items and adding threads of comments to these discussions.


Once stable, items can be progressed through a series of formal reviews that log comments from all reviewers. You define the workflows. Once in a baseline, items can be subject to formal change control using change request (proposals) and change tasks (actions). You can view the database as it was in any previous baseline.

Multiple generations of requirements can be maintained and compared. Multiple sets of variants can be managed to reflect different products in a common family.

Items can be progressed within their lifecycles. The lifecycle of an item represents the series of stages that it can pass through between being created and reaching a final, rest, condition.

User-defined tree, table and matrix views can be defined from a point-and-click UI to show traceability, coverage and compliance. This includes RTMs, VCRMs and PVMs.

Linking Items

Cradle provides transitive cross referencing, in which it follows chains of multiple links between indirectly linked items, so you can see cross-lifecycle traceability in one step. For example, you can view user requirements to tests, where Cradle transparently follows intermediate links via system requirements, functions, architecture components and so on.

Requirements can be linked to test data, safety and other critical issues, risks or any project data. When used with the Cradle-SYS module, user stories and requirements can be linked to functional, behavioural, UML, analysis, architecture and design models organised into any number of model hierarchies in both analysis and design domains.

Publish Information

All information can be published in user-defined reports and formal documents.

Feature Summary

Feature Summary - REQ
Feature Summary – REQ

Please contact 3SL for further information about adding a Cradle REQ module to your existing system.