From CS294-10 Visualization Sp11

Jump to: navigation, search


Group Members

  • Jessica Voytek
  • Julian Limon Nunez


Visualizing "Traceability" in Student Projects

At the UC Berkeley School of Information there is a graduate level course called Information Systems and Service Design (ISSD). One key concept students must master as part of this course is “traceability,” however, the concept of traceability in this context is different from previously studied traceability in the software development process. Traceability in ISSD is a software design tool, rather than a software development tool. It is the way in which a student group identifies and keeps track of the relationships between important observations and key insights from early to later design activities. It is a tool for making more objective decisions about system and service design.

Some visualizations for requirements have been developed both in business settings (http://www.ibm.com/developerworks/rational/library/07/0605_hovater/) and in academia (http://www.springerlink.com/index/3076m5105l25773p.pdf). However, they are based on cryptic requirement codes, do not reflect the changing nature of requirements, and are not always associated with the specific source of the requirement (a quote in an interview transcription or an observation, or a technical constraint specified in a Service Level Agreement), or the series of documents that went into their making. These cryptic codes lose touch with the reasons for which the requirement was generated.

The visualization we developed is a modified graph-based representation of traces throughout the student project design process. One ring on the graph indicates one design artifact. The rings towards the center of the graph indicate artifacts that were completed before the artifact-rings towards the edges of the graph. Each node on the graph represents a trace, the lines between the nodes represent a parent-child relationship between nodes. Nodes can have multiple parents and multiple children. We also used interaction to allow viewers to better explore the relationship between traces.

Initial problem presentation


Final Deliverables

Final Visualization:

Final Poster:

Final Paper:

Dan - Apr 06, 2011 04:05:56 pm

Visualizing non-functional traces is a very complex and interesting subject. It was hard to grasp a good story, however. I think it would be nice to create an interesting story in the beginning to get people immersed in what a trace is, and how what you are going to do can help with visualizing a trace.

Siamak Faridani - Apr 06, 2011 04:17:14 pm

The visualization reminded me of GitHub commit visualizations :) Alas I am not very familiar with the concept of traceability but it looks very interesting. You have done a great job on doing literature survey and related work.

David Wong - Apr 06, 2011 05:01:27 pm

An interesting way of visualizing traces could be through DAGs. You could make the requirement one node and the realization of that in the design another node. Depending on how you want the visualization to work, the directed edge could be from the design element to the requirements or vice versa. Having it from design decision to requirement can allow you to trace back design decisions to the underlying requirements and visualize dependencies in design decisions. Having it the other way can allow you visualize trees on how the final design decisions were created.

Matthew Can - Apr 06, 2011 05:53:44 pm

I'm interested in what kind of metadata you're collecting on the traces and if/how you intend to visualize that. An example might be the strength of a trace based on how much consensus there is for each design decision made along the trace. There might be an opportunity to create novel traceability visualizations that include such additional data.

Krishna - Apr 06, 2011 08:39:20 pm

I think we should closely work together :). As I mentioned after class, one extension of your idea could be to query the requirement graph for dependency patterns. Questions such as 'what requirements should be met to go from req 1 -> req 10' and visually depicting it would be really interesting !!

Sally Ahn - Apr 06, 2011 09:19:34 pm

This sounds like a great challenge in visualization due to the complexity of the data. Your initial sketches were great, but I think it shows the potential for confusion with the overlapping links. It seems that you will have to optimize the layout of the documents to minimize the complexity of the links between them. Also, as it was mentioned in class, I think interactivity for exploring this visualization would be an important feature as well.

Michael Cohen - Apr 06, 2011 11:56:44 pm

I have some experience writing and managing software requirements. As a potential user of your system, I'd be pleased with its focus on tracing the relationships between requirements (or inspirations for requirements) but I'd be concerned that it seems to be reducing the requirements to named graph nodes, potentially obscuring the nuance of the actual requirements as written. The problem could be addressed in a basic way with rollovers (i.e., rollover a node and get more detail about that requirement) but it would be better to be able to view the text of an entire chain (or graph, if it branches) of traces together, so I can see how the details evolved as it meandered through the documents. I would encourage you to think creatively about how to surface as much of the content as possible while maintaining a viable graph layout.

Saung Li - Apr 07, 2011 12:58:36 am

Seeing how people's work are influenced by other work is an interesting and useful problem to tackle. I do like the approach in the initial sketches, and you do acknowledge the challenge of jamming a lot of information into a finite space. If these graph-like structures become to big it may be hard to trace paths between different works, so color highlighting for selected paths and other techniques for generalized selection would be crucial.

Michael Porath - Apr 07, 2011 04:32:37 pm

As I understand the students periodically have to assess how valid their traces are. For each trace, the validity and feasability of a trace might change over time. A color coded status could show this change, even before a trace merges with another one or dies completely. It would also provide a nice overview over the status of a project for GSIs and professors.

Michael Hsueh - Apr 08, 2011 02:58:35 am

Your presentation really illustrated the difficulty in managing the density of information encoded in traceability matrices and graphs. Perhaps there is some potential in using level-of-detail techniques. You might explore using different resolutions for viewing the data, abstracting away certain parts to reduce the cognitive overhead. The key challenge is figuring out how to preserve important and cohesive information about the traces.

Karl He - Apr 09, 2011 01:28:51 am

This is the exact type of problem that should be solved by visualization. I think a lot can be done with interactivity in your project to deal with data density, e.g. highlighting edges when selecting certain nodes in order to easily see the connections.

Brandon Liu - Apr 09, 2011 10:20:16 am

It sounds like a segment of the project is evaluating the usability of the system, so you should think carefully about what you could measure in a user test.

[add comment]
Personal tools