It is always interesting to try something new and I am excited to have the opportunity to write the first post on LavaBlast Software’s blog. My name is Jason Kealey and I’m a software engineering graduate of the University of Ottawa and the President of LavaBlast Software. This blog will feature various insights which we want to share with our clients and the world in general. Since our specialty is software, we thought it would be nice to create a blog focused on software for franchisors.

We’re opening the blog just a few days before I leave for Europe for a few weeks as I am presenting a paper at the 13th System Design Language Forum. Because will be presenting concepts related to my Master’s thesis, I thought the first post here could give an overview of one of my interests. Over the last two years, I have been the lead developer of an Eclipse plug-in to create, analyze, and transform models which help software engineers describe software requirements. Today, I wish to explain in layman’s terms how my expertise can be useful to franchisors or anyone who might require LavaBlast’s software. By giving insight on my expertise, I hope to communicate to my readers how we can collaborate to create software without requiring our customers to be experts in software engineering.

Requirements

Traditionally, people have written free-form textual discussions to explain the behaviour of a system. This is good for initial discussions but does not scale because of the nature of unstructured text: ideas are not located easily and details are often sparse and scattered. It is better practice to list different functionality in a clear, structured pattern such as the following example:

  • FranchiseBlast SHALL record changes made to a product into an electronic journal.
  • FranchiseBlast SHALL only allow administrators to view the electronic journal.

By writing requirements in such a way, progress can be tracked, and priorities are easy to visualize. At LavaBlast Software, we like to use a collaboration wiki to elaborate our requirements for complex projects. A public example of such a wiki adapted for requirements management can be found on the website of the aforementioned tool: jUCMNav. By using a wiki, we collaboratively create the requirements document. No more emailing large documents and ending up with out of synch versions: everyone works on the central web-accessible location (protected by password if necessary)  and the requirements evolve. Later on, the requirements are not shelved as the developers who are implementing the system can go back and ask questions directly in the particular requirement’s discussion thread. Everyone works closely together to best define and scope the software system.

How to write good textual requirements is a topic that has been discussed by many authors. However, while the mileage that a team can obtain with a collection of textual requirements varies from project to project, more often than not these are insufficient. Structured textual requirements are good to describe features but not to describe scenarios or relationships between features. To better represent scenarios, a common tool of the requirement engineer’s arsenal is the textual use case. Textual use cases describe scenarios in which actors and a system under description interact. Such sequence of events increases the comprehension of the context in which the various features come into play. Use cases illustrate the system’s functionality and do not usually include technical jargon. By utilizing language that the domain expert and end users understand, a broader group of stakeholders can discuss the system’s behaviour (unlike more formal approaches). At LavaBlast, we often use textual Use Cases, but we find they lack the ease of use of a visual notation. They are great to explain detailed scenarios, but non-technical people don’t really want to read or discuss them. Here’s where the work done in my thesis comes into play.

Over the past decade, researchers around the world developed a graphical notation to describe software requirement by assembling concepts from other notations into a single easy-to-understand visual notation. This notation is called the User Requirements Notation (URN) which is composed of two sub-notations, the Use Case Map (UCM) notation and the Goal-Oriented Requirement Language (GRL).  The Use Case Map (UCM) notation represents the functional and operational aspects of a software system. The abstraction level of UCMs makes them an ideal notation to express user requirements as high-level scenarios. As for the Goal-Oriented Requirement Language (GRL), it describes the non-functional aspects of a software system and is well adapted to model high-level business goals. Now that the boring technicalities are out of the way, what does this notation mean to you?

 Goal-Oriented Requirement Language (GRL)

Above is a sample GRL diagram which represents various alternatives to create a secure system.  jUCMNav is a tool that makes it easy to create such diagrams and visualize the different alternatives using an automated evaluation propagation algorithm. Although one could draw such a diagram on paper or use the techniques commonly taught in management programs, the GRL notation combined with the powerful tool saves time.  Simply put, to achieve the high level goal of security, one needs to secure the terminal and the host. There are a number of ways one could achieve this; the sample GRL diagram shows a system where authentication is provided by swiping a cardkey and encryption is not used. In the end, security is achieved but is not very high. Although I do not wish to go into detailed explanations here, with a simple 10 minute tutorial, stakeholders can understand the notation and visualize the impact of certain solutions on their business goals.
Typically, at LavaBlast, we build the models ourselves to reveal the tradeoffs between various alternatives and present them in meetings. The goal here is to keep trace of the motivations behind a certain decision. In a meeting, the stakeholders can discuss elements that may not be taken into consideration by the model, refine it iteratively and observe the impact on the goals (automatically, thanks to the tool). In the end, a decision is made and the GRL model records the motivations.

Use Case Map (UCM) Notation

Above is a sample Use Case Map used in the context of a web store with a warehouse. Again, with a brief 10 minute tutorial about the notation, one can understand the modeled scenarios. In this case, we see a normal order where the user submits and other and waits for it to arrive.  As an exercise, without any background in the UCM notation, you are invited to see if you can understand the above diagram. Complex details can be encapsulated inside the Stubs (diamond figures) allowing for multi-layer models. After brief discussions with franchisors the LavaBlast team can, thanks to the Use Case Map notation and jUCMNav, unify all the scenarios that were discussed and rapidly break it down into various interacting scenarios. Having a visual notation such as above helps clarify any vague issues and identifies any problems very early on in the requirements elicitation phase.

The model here identifies various issues that can arrive when products are backordered; software engineers need to know about these fringe cases to build a robust system and having such a tool helps minimize costs incurred by discovering issues late in the game. Everyone can sit down around a table and discuss the scenarios which represent what LavaBlast’s understanding of a business process and clarify any issues before any code has been written. Moreover, thanks to these scenarios, the software architecture and the development team can review the modeled scenarios at a later date to ensure they are implementing the appropriate behaviour.

For decades, software engineers have understood the value of writing things down; that’s why NASA has thousand page documents for their software systems. However, we at LavaBlast take a much lightweight approach to requirements engineering. Simple visual diagrams used in meetings combined with online collaboration for requirements elaboration are a perfect balance between traceability and pragmatism.

Conclusions

LavaBlast knows the best practices for writing good requirements and loves to have the customer participate in the process. We understand that requirements are only useful if they evolve with the system and we use Web 2.0 collaboration tools to manage our requirements. Furthermore, we’re dedicated to help people understand the software system to be built. With our agile software development processes, we focus on clear understanding and incremental development. We want our customers to have as much fun developing a software system as we do and that starts by minimizing useless repetitive paperwork and replacing hundred page documents with clear and concise figures.

Side note

LavaBlast’s CTO was the lead software architect for jUCMNav and I was the lead developer. My main responsibilities were related to the manipulation, analysis, and transformation of Use Case Map models. This open-source tool has around 200 KLoc of Java, with about a quarter automatically generated from UML class diagrams.