Agile for Embedded Part I

I have used a number of development techniques in my career and, most recently, have taken up Agile Development as a means of rapidly building systems. However, Agile's heritage is in the development of web sites and I am currently interested in the development of embedded systems. The differences between these two require some modifications to the basic Agile techniques. I plan to publish a series of posts that describe the changes I would use.
This post is concerned with User Stories.
A User Story is a simple way of capturing the requirements of a system. It has many similarities to the Use Case as defined in UML. Both define requirements based on a consistent outside-in perspective from a User to the System.

The User Story is a single sentence in the form
As a [user role] , I can [feature] ,so that [benefit] .
Instead of the generic "user", the user role tries to identify different classes of users with different requirements. User is too generic. But Tom, Sally, Harry are too specific. When we see that Tom and Sally are customers and Harry is the administrator then the roles of Customer and Administrator emerge with separate interfaces, transactions, and requirements.
The feature  is what I want to accomplish with the system as the User Role.
And benefit; is why I want to use that feature. What value do I get from the story.

Suppose we are building Amazon.com. Then we might see user stories like:

As a Customer, I can search for something, so that I find the item I am looking for.
As a Customer, I can select an item from a results list to get more details, so I can decide if I want to buy it.
As a Merchant, I can register my business as an Amazon storefront, so I can sell my products.

So the catch with an embedded system is that the rich interaction with Users is not always present. In a "headless" system with no user interface, the embedded system depends on sensors to modify its behavior and will often send outputs to actuators. Let us imagine a thermostat as the system. I may have a simple user interface so that the homeowner can:

As a homeowner, I can change the mode of the HVAC between Off, Heat, and Cool, so that the house is maintained at the temperature I want.
As a homeowner, I can change the temperature limits, so that the house is maintained at the temperature I want.

A simple context diagram for the thermostat is shown below

The "Commands" shown on the diagram are for mode control and temp control, and map cleanly to the two user stories. But what about the "Display"? Unlike a web site where the user takes an explicit action of clicking on a link to see a new page, the display on a thermostat is always there. Or is it? That is what the Battery is doing on a diagram. Remember what the display looks like without the battery inserted? Blank. Insert the battery and the display comes on (usually showing default information) and stays on until the battery runs out of power. One could imagine a user story like

As the homeowner, I can insert a battery, so my thermostat will turn on and maintain my house temperature.

But what about the Thermocouple that provides the "Current Temp"? We use that to compare to the Mode and Set Point so that the Thermostat can tell the HVAC to turn on or turn off.

There is no natural user story involving the homeowner and the thermocouple.

My idea is to add event modeling as defined by Paul Ward and Stephen Mellor. An event is something that occurs at some point in time in the environment of a system and, for which the system should have a response.
This could also apply to the users but I think the user story format is fine for that. Below is a table that captures some of the events for this system

Battery inserted
Battery runs low
HVAC begins heating
HVAC begins cooling
HVAC stops heating
HVAC stops cooling
Temperature fluctuates

When the battery is inserted and when the battery runs low can both be determined by measuring the voltage.
We are not interested in the current voltage at anytime just these two events.

The diagram below shows the modes of the HVAC

This is a basic state diagram. If the behavior of our system will be different depending on what mode (i.e. state) it is in then using such a diagram helps separate the behavior and to better understand what would trigger the system to change states. For example the event of HVAC begins heating could occur when the system is Off. It should not occur when the HVAC is already cooling. Many events are important because they help us organize these modalities.

Finally, the Current Temperature that fluctuates is a special kind of event. The temperature always exists and has a value that the system wants to measure to determine if it should be heating or cooling and it wants to display the current temperature to the homeowner.

Events (like user stories) are intentionally abstract. As the response to the event is being analyzed one must answer how we will determine that the event has occurred. We must focus on the system boundary and look at the interfaces. Sometimes these interfaces are constrained. For example, suppose the HVAC manufacturers have gotten together and decided on a specific interface standard for status/controls. They might dictate the HVAC Status would be conveyed by a twisted pair wire with +5 volts indicating Heating, -5 volts indicating Cooling, and 0 volts indicating Off. So our thermostat could monitor the voltage and detect when the four events occurred.

So lets put this together in a user story / event table as shown below.

Conclusions
By adding events to user stories, I have introduced a means to capture requirements for embedded systems that do not have significant behavior at the human interface. This is consistent with the general approach of agile development because:

• The event/response/benefit complexity is similar to the user story and can be treated in a similar fashion in SCRUM
• The events have an outside-in perspective similar to the user story. This avoids "the system shall" type of requirement.

Stay tuned for Part II (Can Hardware be designed from User Stories / Events?)

Jeff Sutherland's Pearls

Last week I attend an Agile RTP meetup hosted at the offices of Relevance Software . I heard Jeff Sutherland speak about the "Five Problems solved for PatientKeeper". If you are into Agile then for me to repeat what he said would be redundant, and if you are new to Agile then you probably need some basic education before jumping into his talk.

However, I captured the following pithy quotations from Jeff:




1. "World domination always gets people excited". When the PatientKeeper management team was forming the company, they needed a vision of what PatientKeeper would be when grown-up. Jeff speculated that Bill Gates had a vision of owning the PC desktop. Sooo... the PatientKeeper team decided to own the mobile devices used by clinical professionals. They wanted to create a framework that would be considered the gold standard for third party medical application developers.

2. "If it is impossible show me the impediment list". Attributed to the CEO who took over PatientKeeper in 2003 and wanted the code deployed to hospitals after each Sprint. When told that the installation time was a bottleneck to this tempo, he formed the "Live by Five" program, which brought in PatientKeeper expert services to work with the hospital IT staff to make sure the installation took place by 5:00 the day of install.

3. "If Lean is all about removing waste, then SCRUM is all about removing impediments". Jeff likes to teach Lean Manufacturing to executives trying to adopt agile development because he believes that they can relate to the examples from the world of manufacturing.

4. "Is the Tango a methodology? Neither is agile". Someone in the audience asked Jeff to compare the light-weight "method" of agile with a bureaucratically heavy approach like CMMI. Using the analogy to the Tango, Jeff said that like that dance, the Agilista does not plan so much but responds to the circumstances of the project.