Live trace explorer

This application claims the benefit of provisional Patent Application Ser. No. 63/399,412, filed Aug. 19, 2022, assigned to the assignee of the present application, and incorporated herein by reference.

A software or systems development process may have phases that may start with customer requirements. Once the user requirements are defined, the development process may move to a system design phase that may include high-level system design and architectural decisions. The output of this phase is a detailed system design specification. Thereafter, the development process may move to define systems components.

Each of these design phases may have corresponding test phases. For example, component testing may define testing procedures for individual test cases or components of the system are tested independently to ensure they function correctly as per the design. Integration testing may define tests for testing combinations of the individual units/components together to ensure their interactions and interfaces work as expected, and for testing the entire system as a whole to verify that it meets the specified requirements.

Requirements management is the process of gathering, analyzing, documenting, and managing the requirements for a project. Requirements traceability is the process of tracking and managing relationships between the data items or artifacts throughout the development cycle in both forwards and backwards direction. This includes tracking the requirements from their origin, through their development and specification, to their subsequent deployment and use and through periods of on-going refinement and iteration in any of these phases. Forward traceability is the ability to track a requirement to its downstream data items or artifacts, such as design documents, test cases, and code. And backward traceability is the ability to track a requirement to its upstream items, such as business needs, customer requirements, and use cases. Linking all of these items together in both directions is known as end-to-end traceability. Traceability can help to ensure that the requirements are complete and accurate, and that they are implemented correctly.

The relationships between the data items may be managed and traced using a traceability matrix. The traceability matrix is a table that lists all of the data items in a project, along with the relationships between them. There may be different types of relationships between the data items. A dependency relationship indicates that one data item cannot be implemented without the other data item. For example, a use case implementation may depend on a technical specification. A derivation relationship indicates that one data item is derived from another data item. For example, a test case may be derived from the use case. An implementation relationship indicates that one data item is implemented by another data item. For example, a software module may implement the use case. A validation relationship and a verification relationship indicate that one data item is validated or verified by another data item. For example, a user acceptance test may validate a software module.

A requirement that has the expected relationship is said to be “covered” by the related requirements or test cases. Queries can be written to determine which items do not have a required relationship, e.g., which customer requirements do not have a relationship to a system requirement, which customer requirements do not have a relationship to a validation test case, and which system requirements do not have a relationship to a verification test case.

In some advanced tools, a relationship is automatically marked in the database as “suspect” if an item related by the relationship is modified, indicating the specified relationship may not hold. An engineer can then inspect the two items related by a suspect relationship, and if they determine that the items satisfy the relationship, they would “clear” the suspect flag on the relationship.

One drawback with such tools is that most of the information pulled from the database about the data items and the relationships therein is shown in reports. This can be problematic as the database may store hundreds of thousands of data items and the data is dynamic in nature, meaning that the data is constantly changing.

Accordingly, it would be desirable to provide an improved method and system to enable users to view and navigate among all the data items and more easily determine which relationships needs to be addressed because they are suspect.

The disclosed embodiments describe methods and systems for displaying an interactive graphical user interface (GUI) for viewing and navigating among sets of hierarchical data items displayed on a client device of a user. Aspects of disclosed embodiments, include displaying in the GUI containers representing and containing respective groups of the hierarchical data items. The containers are displayed in at least two sets (e.g., in two columns or rows), where a first set comprises requirement containers representing requirement items, and the second set comprises test containers representing test case items. Annotated edges are displayed between pairs of the containers, where each of the annotated edges indicate a type of relationship between the hierarchical data items in a respective pair of the containers, and a percentage of the hierarchical data items in the pair of the containers that have the suspect relationships.

According to the method and system disclosed herein, the GUI enables a user to more easily view and navigate among sets of hierarchical data items to identify what items in a project are causing the problems, so that a user can modify those items to fix the problems.

The disclosed embodiments relate to an interactive graphical user interface for viewing and navigating among sets of hierarchical data items. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the disclosed embodiments and the generic principles and features described herein will be readily apparent. The disclosed embodiments are mainly described in terms of particular methods and systems provided in particular implementations. However, the methods and systems will operate effectively in other implementations. Phrases such as “implementation” and “embodiment” may refer to the same or different embodiments. The embodiments will be described with respect to systems and/or devices having certain components. However, the systems and/or devices may include more or less components than those shown, and variations in the arrangement and type of the components may be made without departing from the scope of the invention. The disclosed embodiments will also be described in the context of particular methods having certain steps. However, the method and system operate effectively for other methods having different and/or additional steps and steps in different orders that are not inconsistent with the exemplary embodiments. Thus, the disclosed embodiments are not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.

The disclosed embodiments provide a live trace explorer engine for improving requirements management with live traceability across a development project to aid in building the next generation of complex products. Live traceability refers to the tracking and display of dynamic requirements information in substantially real-time. The live trace explorer engine converts static requirement documents into interactive requirements management across engineering teams and activities by creating and displaying an interactive diagram of a project in development as defined in a database, and uses a stored data item hierarchy and relationships between the data items to provide a high-level overview of the problem areas of the system.

The live trace explorer engine displays to a user a visual representation, called the live trace explorer, of the relationships between development phases and testing phases of a project and associated hierarchical data items. The live trace explorer comprises a first set of one or more requirement containers representing a plurality of development phases or streams of a project, and a second set of one or more test containers representing a plurality of test phases or streams for the project, where the requirement containers have a related test container. Each of the requirement containers contain a grouping of one or more of the hierarchical data items that belong to the represented development phase. Each of the test containers include a grouping of the hierarchical data items that belong to the represented test phase. A first set of edges link adjacent requirement containers together, and a second set of edges link the requirement containers to the related test containers. The edges are displayed with an indication of a percentage of relationships assigned to the edge that are suspect, and/or a total number of suspect relationships assigned to that edge. The live trace explorer further displays filter controls and navigation controls. The filter controls enable a user to filter which of the groupings of the hierarchical data items are displayed. A navigation control is displayed within each of the containers to enable the user to navigate to the hierarchical data items within a selected container, including navigating to the hierarchical data items that have a suspect relationship.

The live trace explorer engine enables the user to identify where gaps in misalignment exist across requirements levels and related test cases for early detection and correction to avoid rework and costly delays. The live trace explorer engine ensures that design changes are identified early and addressed quickly across all user groups to streamline compliance. Accordingly, the live trace explorer improves the ability of the computer to display information and interact with the user, which improves the functioning of the basic display function of a computer system.

1 FIG. 100 102 104 106 108 110 106 108 106 104 is a block diagram illustrating an exemplary systemin which a live trace explorer engine may be implemented according to one example implementation. The live trace explorer engineis run on a server clusterof a service providerthat provides software services to one or more client devicesover a network. In one example implementation, the service providermay provide requirements and traceability management services, content management services, quality management services, or a combination thereof, to users of client devices. The service providermay be implemented, for example, as a software-as-a-service (SAAS), a platform-as-a-service (PAAS), or an infrastructure-as-a-service (IAAS). In one implementation, the server clustermay be implemented as a single-tenant or a multi-tenant cloud architecture.

104 104 104 102 104 The server clusterrepresents a group of server computers working simultaneously. Compute resources utilized by the server clustermay comprise, memory, databases, storage, analytics, networking, software and intelligence. For example, the server clustermay include computer-readable media and storage devices (e.g., flash memory, hard drive, optical disk drive, magnetic disk drive, and the like) containing computer instructions that implement the functionality of the live trace explorer enginewhen executed by a processor. The server clusterfurther includes network communication interfaces for network communication.

108 102 108 108 108 108 108 108 108 Users of the client devices(also referred to as “clients”) access and interact with the live trace explorer enginevia a browserA, which is a computer program for displaying and navigating between web pages. The browserA may be a standalone application or a component of an application. The client devicesinclude a display deviceB on which the browser is displayed, a memoryC, and a processorD. The client devicesmay further include other typical hardware components (not shown) such as input devices (e.g., keyboard, pointing device, microphone, etc.), output devices (e.g., speakers and the like), and wired or wireless network communication interfaces for communication.

110 108 102 The networkover which the client devicesaccess the live trace explorer enginecomprises one or more arrangements of the type known in the art, e.g., local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), intranets, and Internet(s).

106 112 114 114 114 112 114 The service providermaintains or otherwise has access to a data source, such as an item database, containing hierarchical data items. The hierarchical data items(also referred to as “artifacts”) can be used to capture requirements at all stages of the requirements management process, from the initial gathering of requirements to the final verification of the requirements. The hierarchical data itemscan be used to communicate requirements to users, to track the progress of the requirements, and to ensure that the requirements are complete. The item databasecontaining the hierarchical data itemsmay comprise a relational database (e.g., MySQL or SQL Server) in one implementation.

112 114 114 In some implementations, the item databasemay store the hierarchical data itemsaccording to a particular format or model. For example, the V-Model, also known as the Verification and Validation Model, is a software development process model that is used to represent sets of hierarchical data items. As used herein, the term data items or artifacts refers to any type of digital information used for a development project (e.g., the design and implementation of a product, service, or system).

The V-Model emphasizes the relationship between different development phases and corresponding testing phases. For example, each stage of development is typically required to have a relationship with an associated testing phase, ensuring that defects are caught and addressed early in the process, and another relationship with the next development phase that defines the development in further detail. The V-Model also keeps track of the traceability between each development phase and its corresponding testing phase, ensuring that the final system meets the initial requirements.

An example set of hierarchical development phase requirements may start with user requirements, which are used to develop system requirements, and the system requirements may be used to further develop system components or a system architecture. Each of these requirement phases may have a related test phase. Each test phase may perform validation or verification procedures that are used together for checking that a product, service, or system meets requirements and specifications and fulfills its intended purpose. Validation is the assurance that the product, service, or system meets the needs of the customers. Verification is the evaluation of whether or not the product, service, or system complies with a regulation, requirement, specification, or other imposed condition.

114 In further detail, the stored hierarchical data itemsmay be organized as an ordered tree, where nodes of the tree may represent the various types of data items, and edges between the nodes may represent various types of relationships between those items. There is a single data item that is the root of the tree, and each of the data items has an ordered list of zero or more child data items. Each of the data items, except for the root item, has one parent data item. A data item is a descendant of another data item if the data item is a child of the other data item or if it is a descendant of a child of the other data item.

Each of the data items may have an item type, indicating what kind of item is represented, e.g., a customer requirement, a system requirement, a system component, a test case, and the like.

A relationship is an ordered pair of data items, where one data item in the pair is the source item of the relationship, and the second item is the target data item of the relationship. Each relationship has a relationship type, indicating the kind of relationship represented. In one implementation, the relationship types may include satisfied-by, verified-by, validated-by.

The type of data item defines which types of relationships the data item must have for the data item to be considered “covered” by the target data item. For example, a relationship for a customer requirement data item could defined to be covered if the customer requirement data item is the source of a satisfied-by relationship with a child requirement data item as well as the source of at least one validated-by relationship with a related test case. A system requirement data item could be defined to be covered if system requirement data item is the source of at least one verified-by relationship a related test case. The system requirement could also include a satisfied-by relationship with a child system component data item.

114 114 Conventional requirements management tools may enable users to view information pertaining to the hierarchal data items, including a status of the relationships defined between the hierarchal data items. However, if an engineer changes, adds, or deletes, a data item, any relationships defined for that data item is automatically changed from good/present to suspect/missing. The engineer must then inspect the two data items related by a suspect/missing relationship, and if they determine that the items satisfy the relationship, the engineer can “clear” the suspect/missing flag to change the status to good/present.

As described further above, one drawback with such tools is that most of the information pulled from the database about the data items and relationships are shown in reports. This can be problematic as the database may store hundreds of thousands of data items and the data is dynamic in nature meaning that the data is constantly changing. The unintended result of this process is that critical functions such as requirements management and traceability, validation, verification, and compliance may include information gaps, defects, missed requirements, and significant manual effort to correct.

102 108 108 114 According to the disclosed embodiments, the live trace explorer engineis an application that creates and displays on client devicean interactive graphical user interface (GUI) showing a diagram of the data item hierarchy and data item relationships to provide a high-level overview of the problem areas of the system. A user of client devicecan then interact with the diagram to navigate among the hierarchical data itemsand more easily determine which relationships are causing the problems, so that those items can be modified and fixed more efficiently compared to past methods.

102 102 102 1028 102 In one embodiment, the live trace explorer enginemay comprise a number of software components such as software servers or services that are packaged together in one or more software applications. For example, the live trace explorer enginemay include a presentation layerA, a service layer, and a data access layerC.

104 108 102 102 112 102 114 102 108 In operation, the server clusteraccepts API query requests from the client devices, forwards the request to the live trace explorer engineand the data access layerC fulfills the queries using the item database. The service layerB visualizes the hierarchical data itemsand associated relationships returned from the query, and the presentation layerA returns the visualization as one or more webpages in a response to the requesting client device.

102 4 102 102 3 FIG. In further detail, the presentation layerA may provide a model view controller framework that formats and presents information to the user in an interactive graphical user interface (GUI). In one embodiment, the presentation layer may be written in JavaScript, HTML 5, CSS, and/or Angular. The presentation layerA includes rest APIs for front-end server communication and may further include a graphical subsystem for implementing a lightweight browser-based user interface that displays the hierarchical data items as described with respect to. The presentation layerA also handles user input, such as clicks, taps, and keystrokes.

102 102 1028 102 102 The service layerB may be responsible for implementing core functionality of the live trace explorer engine. The service layermay be written in a language that is efficient and scalable, such as Java or C #. The service layerB may further provide security related features for the live trace explorer engine.

102 114 112 102 102 The data access layerC may implement a runtime for fulfilling client queries with the sets of hierarchical data itemsfrom one or more data sources, such as item database. The data access layerC may be written in a language that is efficient and can handle large amounts of data, such as an object-relational mapping tool for the Java programming language (e.g., Hibernate ORM™). Hibernate ORM provides a framework for mapping an object-oriented domain model to a relational database. In an alternative implementation, the data access layerC may be written in SQL.

102 104 102 108 102 102 In the embodiment shown, the live trace explorer engineis implemented as software components executed by the server cluster. However, in another embodiment, the live trace explorer enginemay be implemented as an application that is downloaded and run on the client devices. Although the live trace explorer engineis shown as a monolithic application, the functionality of the live trace explorer enginemay be implemented as a number of separate modules/components.

2 FIG. 200 102 112 202 is a flow diagramillustrating operations of the live trace explorer engine according to one implementation. In operation, the live trace explorer enginemonitors hierarchical data items from a data source (e.g., item database) that capture requirements from a development phase and a test phase of a project (block). The project can be representative of any product, system, or service that is for use by customers. The hierarchical data comprises a hierarchy of requirement data items and test case items, where the requirement data items are validated or verified based on sets of relationships between the hierarchical data items.

102 204 102 108 Responsive to detecting which ones of the hierarchical data items have changed, the live trace explorer enginedetermines which ones of the relationships are suspect based on the changes (block). In one example implementation, live trace explorer enginemay determine which hierarchical data items have changed based on monitoring database update operations (e.g., add, change, and delete) performed on the hierarchical data items by users, which may be different or the same as users of the client devices.

102 206 The live trace explorer enginecombines the hierarchical data items into groups based on data item types, where the data item types may include, for example, a customer requirement, a system requirement, a system component, and a test case (block).

102 208 102 The live trace explorer enginedetermines or measures what percentage of the hierarchical data items in each of the groups have suspect relationships (block). The live trace explorer enginemay calculate the percentage by using the formula (suspect relationships divided by the total number of relationships)×100. For example, assuming that an example group of data items has a total of 50 relationships with 26 suspect relationships and 24 good relationships, the percentage of suspect relationships is 26/(50)×100=52%.

102 108 108 210 3 FIG. The live trace explorer enginethen displays on a displayB of client deviceof a user, an interactive graphical user interface (GUI) showing the project in development as defined by the hierarchical data items and sets of relationships between the data items (block), as shown in.

3 FIG. 102 120 108 is a diagram illustrating an example GUI displayed by the live trace explorer engine according to one implementation. The GUI displayed by the live trace explorer engineis referred to herein as live trace explorerand is displayed within browserA to provide users with requirements management and live traceability.

120 302 120 300 302 306 302 According to the disclosed embodiments, the live trace explorerdisplays containers, which refer to graphical or visual elements used to group and hold other UI elements together. The live trace exploreralso displays filter controlsthat filter what type of containersare displayed based on user interactions, and displays navigational controlsto enable the user to navigate and zoom into details about each of the containersbased on user interactions.

302 114 302 302 302 302 302 1 302 1 302 3 The containersare used to represent and contain respective groups of the hierarchical data items. According to one aspect, the containersare displayed in at least two sets. A first set comprises requirement containersA representing requirement items of a development phase or stream. A second set of the containers comprises test containersB representing test case items of a testing phase or stream. The first set of requirement containersA includes a root requirement containerA-and one or more child requirement containersA-andA-.

302 302 302 302 302 302 The two sets of requirement containersA and test containersB are displayed adjacent to one another. For the requirement containersA in the first set, there may be a corresponding test containerB in the second set. In the specific embodiment shown, the first set of requirement containersA are displayed in one column and the test containersB are displayed in a second column adjacent to the first column.

302 302 302 302 However, the two sets of containersA and test containersB may be displayed with any type of spatial orientation to one another. For example, the requirement containersA and the test containersB may be displayed along adjacent columns, adjacent rows, arcs, curves, geometric patterns (e.g., a “V” formation), or combinations thereof.

Annotated Edges

304 302 304 302 302 302 304 302 2 302 3 304 302 Annotated edgesare displayed between pairs of the containers, with each of the annotated edgesindicating a type of relationship between the hierarchical data items in a respective pair of the containers, and also indicating a percentage of the hierarchical data items in the pair of the containersthat have the suspect relationships. The requirement containersA are shown sharing an annotated edgeA with a child requirement containerA-orA-, and sharing an annotated edgeB with a related or adjacent test case containerB.

304 302 304 302 1 302 304 302 2 302 3 302 The annotated edgesA between pairs of the requirement containersA represent a satisfied-by relationship. The annotated edgesB between the root requirement containerA-and a test case containerB represent a validated-by relationship. The annotated edgesB between child requirement containersA-orA-and a test case containerB represent a verified-by relationship.

4 4 FIGS.A-C 4 FIG.A 4 FIG.B 4 FIG.C 4 FIG.C 304 302 304 304 302 302 304 304 302 304 302 302 304 302 302 are diagrams illustrating different types of annotated edgesbetween pairs of containers in further detail. In the implementation where the containersare displayed in a two column format,shows the annotated edgeA representing a satisfied-by relationship, andshows the annotated edgeB representing a verified-by relationship or a validated-by relationship.also shows an embodiment where more than one set or columns of test containersB andC are displayed with annotated edgeB therebetween.shows the annotated edgesA between pairs of the requirement containersA, the annotated edgesB between pairs of the requirement containersA and the test containersB, and the annotated edgesC between pairs of test containersB and test containersC.

304 304 402 402 In one implementation, the annotated edgesare displayed with annotations comprising additional textual and/or graphical information summarizing a status or a quality of all relationships assigned to the respective annotated edge. According to a further aspect of the disclosed embodiments, the annotated edgessummarize the status of all relationships assigned to that edge by displaying a first percentageA of the hierarchical data items that have suspect relationships, and optionally a second percentageB of the hierarchical data items that have relationships that are not suspect or otherwise good.

402 402 402 402 304 404 404 404 404 404 404 304 406 304 304 304 4 FIG.B In one implementation, the first and second percentagesA andB may be displayed as a number value. Additionally or alternatively, the first and second percentagesA andB may be displayed by segmenting the annotated edgesinto two sections, where a length of a first sectionA represents the percentage of the relationships that are suspect, and a length of a second sectionB represents the percentage of the relationships that are not suspect or good. SectionsA andB may be further displayed in different colors, e.g., the first sectionA may be red in color to show the suspect relationships, and the second sectionB may be green in color to show the good relationships. Any color or shading combinations can be used. Alternatively or additionally, the annotated edgesmay further display a total number value of suspect relationships(as shown in) and/or the total number of all relationships (not shown). Although the annotated edgesare shown displaying textual and/or graphical information directly on or within the annotated edges, the textual and/or graphical information may be displayed adjacent to the annotated edgesin other implementations.

Annotated Containers

4 FIG.D 120 302 302 410 412 414 410 302 is a diagram illustrating that the live trace explorermay display the containerswith annotations showing a summary of informational details about the respective requirement containers. The informational details displayed in the container(s)may include a data item type label, a container details section, and a coverage section. The data item type labelindicates the types of data items grouped in the container.

302 102 412 412 412 302 302 412 4911 For each of the requirement containersA, the live trace explorer enginemay display in the container details section: i) a total numberA of all data items that are visible, ii) optionally a total number of all requirement data items that are not visible (not shown); and iii) optionally a total numberB of open conversations about the containeror the requirement data items. In this example, the containergroups product requirement data items, and the container details sectionindicates there areproduct requirement data items grouped in that container with zero open conversations.

102 414 414 4148 414 The live trace explorer enginemay display in the coverage sectiondifferent requirement data items typesA and an indication of internal relationship coverageof each of the different requirement data item typesA. A relationship is internal to a container if both the source and target of the relationship are assigned to that container.

414 4148 The relationship coverageB for the various types of data items are shown in this example as a percentage of internal relationships that are good, or alternatively the percentage of internal relationships that are suspect. Different colors may be displayed for the relationship coveragedepending on how the percentage values compare to predefined percentage thresholds. For example, for the percentage values of internal relationships that are good, any percentage values of 80% or greater may be displayed in one color (green), while any percentage values less than 80% may be displayed in another color (red).

414 Additionally or alternatively, the coverage sectionmay display i) the total number of each of the different requirement data item types, ii) a count of all visible data items based on their relationship status (missing coverage relationship, suspect coverage relationship, not covering any items), iii) a count of relationships of visible requirement data items that are not contained in an annotated edge (i.e., relationships with an item that is not visible).

302 102 412 302 306 For each of the test containersB (not shown), the live trace explorer enginemay display in the container details section: i) a total number of all visible test cases that are assigned to a test plan, ii) a total number of visible test cases whose most recent test has passed; and/or iii) a total number of visible test cases that do not have a relationship with a data item in the related requirements containerA. If user selects “full details” using navigational controlA, a percentage is displayed of visible test cases whose most recent test run has a given test run status. In one example, the test run status may include “pass”, “fail”, “blocked”, “in progress”, “not run”, or “not assigned to a test plan”.

Navigational Controls

3 FIG. 4 FIG.D 120 306 302 306 306 302 302 306 302 As shown in, the live trace explorerdisplays navigational controlswithin the containersthat enables the user to navigate to the hierarchical data items in a selected container, including the hierarchical data items that have suspect relationships. In one implementation, there are at least two types of navigational control. Referring to, navigational controlA displays full details of the containerand may comprise a hyperlink or link, which when clicked by the user, opens a new window, tab, or pane that displays the further details of the content associated with the container. Clicking the navigational controlA allows the user to toggle a containerbetween full detail view and summary view.

306 414 Navigational controlB is displayed in the coverage sectionand may comprise a treeview control, shown as a folder icon and/or a tree icon, which when clicked by the user, displays a hierarchical structure of the data items contained therein. The folder icon represents a node in a tree structure, and the other nodes in the tree represent subfolders and data items contained in that folder. Users can expand and collapse nodes in the treeview control to view the subnodes. Users can select a specific node in the treeview control to view the data items the node contains. The treeview control can be used to navigate (e.g., zoom in and out) through the hierarchical structure of data items.

306 Alternatively or additionally navigational controlcan also be implemented as accordion controls that allows users to collapse and expand individual sections of the data items and/or drilldown controls allow users to navigate through the hierarchical data items by drilling down into individual nodes.

302 302 In one implementation, the containerscan encapsulate event handling logic. For instance, the containersmay be configured to capture events such mouse clicks and display child data items as needed.

Filter Controls

5 FIG. 300 120 300 302 302 is a diagram illustrating example filter controlsdisplayed on the live trace explorerthat enable a user to filter which of the groups of the hierarchical data items are displayed. In one example implementation, the filter controlsmay be displayed in a window or pane adjacent to the diagram of the sets of requirement containersA and test containersB.

300 300 300 500 502 504 500 500 Responsive to user input with the filter controls, the filter controlsmodify what information is shown the diagram. The filter controlsmay include a data item type filters, relationship type filters, and a query filterthat can be applied to the diagram. Each of the data item type filtersidentifies a set of data item types, and all data items whose type is one of the types in the item filter may be added or removed from the diagram by the user toggling the selected data item type filterson or off.

502 502 500 The relationship type filtersidentify a set of relationship types (e.g., validated-by, verified-by, and the like), and all relationships whose type is one of the types in the item filterare added or removed from the diagram by the user toggling the selected relationship type filteron or off.

504 504 504 The query filterspecifies a database query, and all data items that do not match the query are removed from the diagram. In one implementation, the query filtermay comprise a command-line user interface for the user to form the query. In another implementation, the query filtermay be a link to another window or pane in which the user can construct and execute the query.

302 302 302 302 302 302 302 302 302 Additionally or alternatively, the user may invoke filter operations by interacting with the containers. For example, the user can collapse two adjacent requirement containersA into a single containerA (e.g., by dragging and dropping), which will automatically collapse the corresponding two adjacent test case containersB. If a requirement containerA has more than one root child item, the requirement containerA is split into two adjacent requirement containersA. If there are more than two root child data items in the requirement containerA, the user may specify which set of adjacent root child data items go into which of the two requirement containersA (the leftmost root child data items are placed in the upper requirement container).

302 The user may select a set of data items and move the set from one containerin the diagram to another container in the diagram. When a data item is moved to another container, all child data items of that data item are automatically moved as well.

302 304 302 If a containercontains multiple data items, the user can select to hide a subset of the data items. This removes those data items from the detail information of the container, and removes any relationships with those data items from the annotated edgesconnected to the container. If a containercontains hidden data items, the user can select to view (unhide) one or more of the hidden data items.

Container Full Detail View

6 6 FIGS.A-D 6 FIG.A 6 FIG.A 6 FIG.B 600 306 602 604 602 604 are diagrams illustrating various implementations of displaying detailed information about a selected container.illustrates paneA displaying a full detail view of a requirements container in response the user clicking navigational controlA, which can be considered a type of zoom control. According one implementation, the product requirements full detail viewed may include view options for showing detailed content regarding coverage qualityor relationship health.shows the content details related to coverage quality, whileshows the content details related to relationship health.

602 302 600 102 Responsive to the user clicking on coverage quality, example content details associated with the containerthat may be displayed in paneA include: i) expected versus established relationships over time, ii) expected relationship details with trends, iii) owners of items having missing coverage, iv) data item review status (e.g., percentage that needs review, percentage in progress, and percentage approved), v) coverage item location (e.g., internal to the live trace explorer engineor external), and vi) open conversations between users regarding the container.

6 FIG.B 604 302 600 606 102 Referring to, responsive to the user clicking on relationship health, example content details associated with the requirements containerA that may be displayed in paneB include: i) a pull down menufor the user to select a path for which relationship health details will be shown, ii) relationship status over time (e.g., the number of suspect, valid, and missing relationships), iii) suspect item user details (i.e., who owns the items with suspect relationships), iv) created by (i.e., the creator of the items), and v) suspect item location (e.g., internal to the live trace explorer engineor external).

6 FIG.C 600 306 302 600 608 610 illustrates paneC displaying a full detail view of a test container in response the user clicking navigational controlA. Example content details associated with test containerB that may be displayed in paneC include: i) test plan distribution (e.g., which test plans are assigned to which test cases), ii) a test case run summary, which may include a pull down menufor the user to select a given test plan, and a pull down menufor the user to select a given test case within the selected test plan, and iii) test not run by assignee.

6 FIG.D 302 600 is a diagram illustrating an implementation for displaying detailed information about a selected container for enhancing coverage and correctness for the user to clear suspect data items and/or relationships. Responsive to the user clicking on suspect data item or relationship in a given container, paneD displays source level data items associated with the suspect data item or relationship. A list of requirement data items is show with associated block requirements. A user may click a check box next to a suspect data item to clear the suspect data item.

7 FIG. 700 102 300 702 is a flow diagram illustrating a processperformed by the live trace explorer engineto enable a user to clear a suspect data item or relationship. The process my begin receiving filter controlsettings from a user that control what groups of data items are displayed in a set of one or more requirement containers (block).

102 120 302 704 The live trace explorer enginedisplays in the live trace explorerequirement containersA and information about the requirement data items and all direct and indirect child data items (block).

102 302 302 302 302 706 The live trace explorer enginedisplays one or more test containersB adjacent to the set of requirement containersA, where the test containersB contain all test case data items that have a relationship to any of the requirement data items in the requirement containersA (block).

102 300 302 708 704 The live trace explorer engineoptionally receives filter controlsettings from the user that adjusts what is displayed in the containersby specifying types of data items and types of relationships that should be ignored (block). The process continues at block.

102 710 704 The live trace explorer enginereceives navigational control from a container of interest that adjusts the group of data items, which includes either zooming in and out on a child data item in the container, moving the child data item to a specified location in the group or removing the child data item from the group (block). The process continues at block. Zooming in and out of summary and detail views of the containers and data items contained by the containers provides live traceability.

102 712 Responsive to receiving user selection of a section in the container of interest containing a set of suspect data items, the live trace explorer enginedisplays the suspect data items in a detailed view that can be directly edited by the user (block).

102 714 The live trace explorer enginereceives user changes to the suspect data items in the detailed view that satisfied their relationships and user input that clears the suspect property on those relationships (block).

102 120 120 According to aspects of the disclosed implementations, the live trace explorer engineprovides information to the user in the live trace explorerelating to completeness of the relationship coverage in a given project. This includes whether each of the customer requirements covered by system requirements, whether each of the customer requirements are covered by test cases, and whether each of the system requirements are covered by test cases. The live trace explorefurther provides users with information regarding i) the quality of traceability, i.e., how many relationships are suspect, ii) which test cases do not have a passing result, iii) provides team leads to determine which areas of the project have problems based on measurements of progress and who is responsible for clearing those problems, and iv) provides systems engineers a way to drill into details of a problem area in the project and to take action on particular data items causing problems.

A live trace explorer engine has been disclosed that is implemented as method and system for providing an interactive GUI for viewing and navigating among sets of hierarchical data items. The present invention has been described in accordance with the embodiments shown, and there could be variations to the embodiments, and any variations would be within the spirit and scope of the present invention. For example, the exemplary embodiment can be implemented as a cloud based tool, a downloadable application, a non-transitory computer readable medium (NCRM) storing software program instructions, or a combination thereof. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.