Putting the System in its Place – Context Diagrams

Alex continues discussing capturing requirements, this week looking at Context Diagrams and how they can help us understand the environment in which the system under development can operate... 

Although not strictly related to use cases, which I have previously stated as the theme of my series and upcoming posts, the development of a context diagram is an excellent first step in understanding the environment in which the system under development (SUD) will operate.

While some might consider this an unnecessary step in development I find that the development of a separate context diagram has two major benefits. Firstly it allows you to model elements which do not directly interact with you system but indirectly affect it and secondly it allows you to consider different system usages.

With regard to the former you might ask “why would I want to model things that don’t directly affect my system?” Take, as an example, the command and control (C²) for a complex weapon system (credit must be given here to my colleagues who worked with me to develop the example I am using – I’d tell you who they were but then I’d have to kill you). On a use case diagram you would represent things that directly interact with you system but at no point does your C² directly engage the target, it is the weapon itself that does that and it would be illegal UML or SysML if you modelled the interactions between the weapon and the target as it is out of scope. Not modelling this, however, does not accurately represent the system purpose as you end up with a model that explains what your system does but not why. A context diagram showing the larger scope of system usage is the perfect place to communicate this.

In my title I refer to context diagrams (plural) and have done so deliberately. A good system (or software) model considers more that the, obvious, operational context. There are many other points of view to be considered; as an example I cite the defence lines of development (for the purposes of not defence developers I have attempted to demilitarise them – the MoD definitions can be found at http://www.aof.mod.uk/aofcontent/strategic/guide/sg_dlod.htm):

•  Training - the provision of the means to practise, develop and validate, within constraints, the practical application of a capability.
• Equipment - the provision of platforms and systems needed to outfit an individual, group or organisation.
•  Personnel - the timely provision of sufficient, capable and motivated personnel to deliver outputs.
• Information - the provision of a coherent development of data, information and knowledge requirements for capabilities and all processes designed to gather and handle them.
• Concepts and Doctrine - a concept is an expression of the capabilities that are likely to be used to accomplish an activity in the future. Doctrine is an expression of the principles which guide actions and is a codification of how activity is conducted today.
• Organisation - the organisational relationships of people.
• Infrastructure - the acquisition, development, management and disposal of all fixed, permanent structures in support of the required capabilities.
• Logistics - the science of planning and carrying out the operational movement and maintenance.

Remember that your first attempt at context modelling is likely to be based on a limited understanding of the system and is therefore merely a starting point. Further analysis of the requirements will result in a refining of the system boundary and is likely to cause the context to change. As with all good development, producing a system context is an iterative activity.

Alex

Timeboxing

 Fiona, who has to manage her time incredibly well as Product Delivery Manager at Objektum Solutions introduces the concept of Timeboxing...

Everyone is familiar with the phrase “so much to do, so little time”.  In today’s busy world we are trying to balance multiple lifestyles, wishes and aspirations.  As people of the 21^st century we are always looking for ways of managing our time more productively. The workplace has especially become more demanding with shorter deadlines and increased workloads. We’ve all experienced that feeling of being completely overwhelmed by the sheer volume of work and effort needed to complete a task. 

One technique available to us is timeboxing. I first learnt of timeboxing at a University lecture discussing effective time management for our upcoming final year. I later studied timeboxing in terms of software development and its usefulness in delivering iterative and incremental system designs. Timeboxing necessitates that schedule deadlines determine the project features. Put simply, falling behind on the programme is not an option. 

Timeboxing means allowing yourself a limited amount of time to complete a task and ensuring that under no circumstance will you go over this time. We can use timeboxing effectively in our everyday lives. For example, you need to buy a present for your mother-in-law and you know that this could lead to a great deal of procrastination with little to show for it. Instead, allow 30 minutes to find the perfect gift and commit to putting in the effort to achieve this goal. 

 Timeboxing is an equally useful technique to use on a project. In fact, I stuck religiously to my timeboxing schedule during my final year project at university. I also had a great motivation technique to use when feeling lost under piles of notes and diagrams and not really knowing where to begin to tackle the task ahead. Just 30 minutes of allocated time to embark upon a particularly difficult task can really make a difference to the completion deadline of the project. 

Here is my list of why timeboxing really works:

• It makes a project less off-putting as the content is reduced down to realistic goals
• It assists in determining what is actually achievable in a task or project
• Timeboxing eliminates procrastination which swallows so much of our time   
• It facilitates incremental software development reduces the risk associated with large scale system development 

With the help of time management techniques like this we’ll soon find ourselves saying “So much time, and so little to do”.

Fiona 

The Path of Most Resistance - Discovering Use Cases

Systems and Software Lecturer Alex starts to teach us a thing or two about use cases in his second post in the series on Use Case Diagrams...

Having recently ranted (OK so rant might be a bit strong but it’s a favourite word of mine) on the inappropriate application of use cases it seems to me that I should, at the very least, offer an opinion (not that I’m opinionated, just ask my colleagues) on how they should be written.

  As a subject that is considerably more involved that the UML notation implies, as well as being one that is close to my heart, I hope I will be forgiven if I make this a series of posts rather than trying to tackle the subject in a single monologue. The effect of such an attempt would undoubtedly spiral out of control and be likely to require a publishing agent.

Many years ago our Technical Director, Derek, introduced me to use cases as an analysis technique. After listening to everything he had to say I, like the petulant child I was, set out to prove I could do it better. Though I didn’t realise it at the time, I was well on my way to making the first of many mistakes that I now try to guide people around.

Using an example that we had for one of our training courses I set out to improve the use cases I was given, smugly believing that something had been overlooked. Over the years I refined and remodelled until, eventually, I ended up with a use case model that was so close to the one I had inherited that it was almost impossible to tell the difference. It’s been several years since that moment but I’m still reeling from the blow to my ego.

   

Writing good use cases is an art; no-one can teach it to you. That might sound strange coming from someone who makes a living teaching people how to write use but it’s a fact. People can give you the benefit of their experience in use case development and provide you will a solid foundation but, like I did, you will discover that this is only the beginning of the journey. Good use cases are written by those who are humble enough to accept the guidance of those who already undergone a journey of retraining their analysis paradigm.

 

In the coming weeks I would like to present an approach to use case modelling that is not my own but rather the distilled wisdom of everyone I have learned from.

Alex 

Make sure you subscribe to our blog (on the right hand side) so that you can read Alex's next post in this series...

How to Market A Technical Company (and Be Taken Seriously)

Cat, who works on the strategy and communications of Objektum Solutions, gives us a refreshing look on how to market within the technical world...

Over the last few years I have been working with technical experts and something I have noticed is that there is often a misconception of ‘Marketing’. In a world of models and code, I understand that marketing can sometimes look a little “fluffy”. Whilst ‘Social Media’ has opened up avenues for millions of people across the globe, the jovial nature of a lot of the tools hasn’t helped marketing folk to be taken seriously. Let’s face it, Twitter ain’t mission-critical.  

Whilst working on the marketing of the company, I’ve been talking to colleagues about what we’re doing and why we’re doing it. Everyone who works here is intelligent but sometimes it is not easy for them to see why we’re doing something that doesn’t produce a tangible (or even measurable) output.

So, over the years I’ve explained elements of marketing to the team and vice versa, they have helped me by explaining the technology behind it all. Understanding marketing as a function is important even if you’re not directly involved. The team here have found it interesting (they say that anyway, but that might also be to shut me up!) and so I’ll be occasionally blogging marketing ‘bites’ for you, such as this....

How to Market a Technical Company (and be taken seriously)

Marketing is about telling a targeted market what you have to offer and why they should come to you to solve their problem. It’s finding the customers and then, when you’re front of them, what is it that you say. Here are some pointers:

1. Plan and measure – marketing isn’t just about writing fancy words and pretty pictures. As with any strategy or project, there must be objectives and although it’s hard, one needs to measure return on investment. Planning is of prime importance so that you can be consistent with your message.

2. Be consistent – all the best brands in the world are kept visible and consistent. This is the message, the tone, the way you interact with customers etc. Customers will only get to really know and trust you when you have a consistent image. They will also remember you.

3. Relevance – keep your message relevant. Know your audience and whilst your key points should remain the same, your message needs to address the concerns and areas of interest of those who you are communicating to.

4. Be concise – one of the paradoxes of our age is that there is more clutter and less time to sift through it. People will be eternally grateful if you can keep to the point.

5. #don’tjustfollowtrendsforthesakeofit – for those of you not on Twitter, this may look like my keyboard has malfunctioned but, as with my last point on consistency, think about how your message is being carried across and what the perception of your company is. If Twitter, Facebook, Ning (the list goes on) doesn’t fit in with your company, leave it. Don’t do it because everyone else is doing it; do it because it works for you and your customers. LinkedIn works well for us because of the forums and the business focus, so that’s what we use.

 

6. Product Demos – now this is something we’re working on at the moment. We frequently do webinars but we have all this brilliant technology, but can anyone see what it does by looking at our website? No. Do they have to read paragraphs and paragraphs of text to work out what it does? Yes. Make sure your work is showcased so people can see how you can solve their problems.

7. Show off a little - respect your client’s privacy but show off your successes with case studies. Case studies have a beginning, The Problem; a middle, The Solution and an end, The Result. It is such a simple formula but it is one of the most effective ways to show what you can do.

8. Remember, it’s not all online - get out there and meet people. Now, I’m not the biggest fan of the ‘elevator pitch’. I’ve attended so many networking sessions where I have heard too many pitches that I just switch off. Have a clear understanding of what you do but most importantly listen and have interesting conversations.

9. Collaborate – work with partners, suppliers and customers to achieve more than you can could if you were all working in isolation. 

10. Practice what you preach – you can come up with the best marketing strategy, the greatest website and the slickest tag line but if you don’t deliver what you promise, that’s the message that will spread and the marketing really does all turn into fluff. 

 Cat

Use (less) Cases

Alex travels around the world teaching organisations about creating systems and how to use Use Case diagrams effectively. A huge percentage of people are sceptical about Use Case Diagrams but in this new series of posts he is going to be teaching us how to use them to make a difference in our work...

I love use cases. I love teaching them, writing them; in fact I love everything about use cases, well almost. What I really don’t like about use cases is the frequent way in which they are poorly introduced into an organisation. 

At Objektum Solutions we talk about the “use case hoax”; the fact that many people focus on the “stick men and bubbles” while failing to understand the underlying concepts of use case development. For us use cases are not about the notation but about the thought processes that are employed in their development.

One of the problems that I often encounter is the inability of engineers (particularly those who have spent years at the detailed design or implementation level) to abstract their thinking in order to express how the systems they develop will be used in the real world. All too often I find use cases that are developed purely to “tick” the relevant boxes and therefore add little or no value.

As with any new technique (and by new I am speaking from the relevant point of view of the deploying organisation as use cases have become an old friend to many of us), careful consideration has to be given to how to introduce use case driven development.

In order to successfully apply use case modelling to a project, engineers must first be taught why they are doing it and what the expected result is. For me use cases offer more than just an understanding of how the system under development will be used. They are a means of discovering what questions need to be asked of the stakeholders in order to ensure that a project is suitably equipped to move the development effort forward.

Over the years I have taught many aspects of software and systems engineering but there’s still nothing more gratifying that the look, at the end of a use case course, which clearly says “wow, I never realised how powerful this technique is”.

As a consultant it is my job to teach people modelling languages but as an engineer it is my mission to teach people how to model.

Alex