Summary of Use Cases

High Level Description

  1. Description of steps or actions between a user (or actor) and a system which leads to achieving something useful;
  2. User or actor can be a person or another system interacting through an interface; &
  3. Use cases treat the system as a black box, concentrating on what must be done rather than how thus avoiding any implementation-specific language.


  1. Identify features (system requirements) to implement; &
  2. Capture functional requirements.


  1. Focus on how to achieve a goal or a task without giving any consideration to implementation;
  2. Multiple Use Cases will be needed to thoroughly define the scope; &
  3. Project formality and current stage will influence the level of detail included in each.


  1. Requires some form of interaction so does not consider non-functional requirements, e.g. performance; &
  2. Not a complete answer by itself, Use Cases are 1 viewpoint and should be combined with other analysis & design tools to drive out a holistic product.

What Motivates Us?

For me, it’s about learning.  People never stop learning.  There’s even a phrase… “…learnt something new today!”

So when the presenter in the animation talks about Atlassian‘s “Free-for-All Thursdays”, I bet everyone who has watched this nodded their head in agreement at that point.  Being given the time and freedom to explore a topic of interest, at least for Atlassian it seems, is delivering tangible results.

In business, there has always been a background “pressure” to do more and more with the same resources or less.  That pressure is pushing its way to the front in the current climate and whatever (little) freedoms people have had in the past, I think, are being eroded.

My argument is for allowing some slack for research and (personal?) development in everyone’s work schedule.  As with Atlassian, that freedom also comes with the responsibility to feedback the benefit derived from it.  However, I think the results would be surprising in whatever scenario it was used.


Sustainability in the I.T. Project Lifecycle

This was the title of a recent BCS Event in Leeds.  I’ve included some few key phrases from the information presented ostensibly to see what reaction they will generate.

We now know that the IT industry represents 2% of Carbon Dioxide  emissions worldwide, which is roughly the same as air travel.  However,  there is a case to be made for increasing the emissions from IT as this  will replace the emissions from other less sustainable activities,  primarily travel.

Sustainability is defined as “…development which meets the needs of   the present without compromising the ability of future generations to   meet their own needs…“ and is not to be confused with longevity.

Sustainability should be embedded within everything we do.

The overriding theme I took away from it was displacement borne out by the examples of success given: 1) replacing aging printers with multi-function devices; and 2) rolling out collaboration tools such as Office 2010 and Google apps.  No consideration seemed to have been given to the costs of developing the technology in the first place and bringing the product to market; the starting point always seemed to be an upgrade or newly available technology.

While the principle is admirable, the reality seems a long way off.