Exemplary Visions

Gold Plating is a concept from requirements management which for some strange reason I find amusing. Gold plating is simply the creation of “stuff” which it has not been agreed satisfies any stated need. We might be lucky and the gold plated “stuff” turns out to be useful. On the other hand we may end up seeing an ashtray on a motorbike.

With pleasing symmetry to my last posting about knowing when you are finished, gold plating turns out to be just another report, but at the lower implementation level:

with respect to the SR, gold plating in the “slides” is identified by finding any slide which does not have an outgoing satisfaction link and drawing a red box around it, as we have done for the white elephant. This corresponds to the situation where the owner of the SR has outsourced the implementation of the SR as the creation of slides, and is interested in tracking what is happening. The contractor has not yet proposed a satisfaction link for the white elephant, perhaps because they know that any such link would not be agreed meets a stated need in the SR (the SR owner gets to decide whether satisfaction links are good or not).

My postings on RM traceability are informed from my experience of talking to systems engineering consultants and practitioners who know what they are doing on very large systems and budgets, and so I am comfortable that at least some people in the world are happy to invest in a requirements management process where you actually do write down requirements and make links between them and with other life cycle assets. For my next RM posting project, I’m going to think about how to spread the word to those folks who would rather cut their own heads off than write down a requirement, never-mind user, system and test requirements.

Share This

No Comments »

An important application of traceability is to let you assess how complete your project is - and not just with a binary “yes I am finished” or “no, still work to do”. We can use the presence or absence of approved traceability links to to measure progress at a much finer level of granularity, and in terms of both qualification (is this bit tested yet?) and satisfaction (has something lower down been built which satisfies this need?). Consider the link between SR:16 and the slide which depicts a “bored audience”, highlighted below (the idea being that the “bored audience” slide may contribute some humor to the presentation):

If for some reason the contractor who is doing the slides for the person who is responsible for the SR had not yet proposed this satisfaction link (i.e., let’s delete it), the SR owner may be interested in running a report which shows all requirements which are not linked by approved satisfaction links:

If your SR is full of red boxed requirements, then you know you are far from finished (notice that SR:1 also has no incoming satisfaction links, so it too is highlighted with a red box).

Share This

1 Comment »

(October 12) I’ve just done what I think is an improved version of this post here.

Further to my first post on this topic, I’ve been working on making things a bit less abstract, the end result being the above diagram, which I explain at length below so don’t worry about it yet. If you are not well versed in the concepts of requirements management, you may have very little intuition as to what User Requirement (UR) or Acceptance Test Plan (ATP) documents are, along with the SRs, STPs, STs, SSRs and the rest which featured in my 3D diagram of last time.

In a few weeks I shall be presenting at the PowerPoint Live User Conference in New Orleans. The subject I am speaking about is how applying principles from requirements management (RM) can help us build better presentations. Since the audience already understands a lot about presentations, I thought I’d illustrate RM by applying its formal information model to the construction of the presentation that they will be watching me give. Here’s a sneak preview, beginning with:

My UR above contains just an illustrative sample of 4 user requirements; my real talk covers 10 principles of requirements management and I have more additional objectives than just entertaining the audience. The first thing to note about user requirements is that they should try not to mention solutions (like using slides) - they should contain only things you want to achieve - in this case the communication of some ideas I think are useful to share with the audience, together with a more general goal which experience teaches should not be ignored at this stage!

A requirement that can’t be tested is not a proper requirement. So anytime you write or contribute to a user requirement, you should think about how it is going to be tested. And before getting directly into tests, you should do a bit of test planning; the ATP is a high level description of what the tests should achieve. So here I decided that I am going to test the audience’s learning of the principles by an examination. ATP:33 is going to help us qualify that the audience was actually entertained by measuring something that may be an indicator of that.

In the acceptance tests we specify tests which will be performed to qualify the acceptance test plan. Here we just show tests for qualifying the audience’s learning of two of the two RM principles mentioned in the ATP. In real systems development, one would not ask such blatantly leading questions! 

Now we think about the system which we will build to satisfy the user requirements. And for the UR presented above we make the decision that a slide show will be fit for purpose, and again, I just pick a sample of 4 slides from the much bigger presentation. For this slightly contrived exercise, I’ve decided to use the finished slides themselves to represent their corresponding system requirements. A more realistic system requirement for a presentation would be something like “There shall be a depiction of a bored audience”.

So even when we just have a rough idea of a slide, we should still consider how we will judge that the slide does its job. So we should write down what the slide is meant to represent and what impact we expect it to have on the audience.

Our last document is the system tests, where we specify how to test the system test requirements in the STP. So now we can show what traceability is by linking the requirements, test requirements and tests together:

Now you can’t read the words but you can always refer back to the original documents, here are some of the things that are going on:

• ST:1, which asks a test audience whether the given image is a good representation of the desired concept in the linked test requirement is applied to STP:2 and STP:3. STP:2 is linked to the slide of a drill, STP:3 is linked to the slide with the hammer and nail.
• ST:2 is linked to STP:4 which in turn is linked to the slide of a “bored audience”. This and the previously mentioned links have all been “qualification” links, which go from right to left within the same level of abstraction.
• The “bored audience” slide has a “satisfaction” link up to UR:55, contributing to the overall entertainment of the audience (we expect that it will take more than one slide which raised some smiles to entertain the audience).
• It takes 3 slides in the SR to satisfy UR:2.
• I’ve not shown all links, e.g. ATP:33 has no acceptance test and is not yet linked to UR:55. In requirements management you know you still have work to do when there are missing links.
• One thing more experienced RMers might be worrying about is the fact that I reuse the same test twice, ST:1 is applied to both STP:2 and STP:3. The idea here is that the test “text” of ST:1 can be reused as many times as we like, but we’ll have to keep separate instances of any test results; I’ll need to explain that in its own article.

Main take away this time - requirements traceability boils down to the following: you need to have a user requirement for every goal you want to achieve. You need to show that each of those requirements is qualified (i.e. that we can demonstrate that the goal is achieved) and you need to show that something in the sub-system below you satisfies every requirement (e.g. you have built a set of slides which can communicate ideas and make some of us smile some of the time). Finally you reach a concrete/physical layer of abstraction (e.g. a real slide) which does not need any additional level of sub-system to implement it.

Share This

1 Comment »

I plan to write some posts delving into important aspects of Requirements Management, with the added twist that I shall be using the 3D graphics tool Perspector to illustrate the concepts involved. I do this because I have 13 years experience working in the requirements management (RM) industry, and one of the reasons I wanted to see a tool like Perspector being created was that I had great difficulty trying to illustrate some of the concepts used in RM just using 2D diagrams. Now with the help of Perspector, I can draw the diagrams I used to have trapped in my head.

This first installment takes a look at requirements traceability.

The wikipedia article just cited is a very reasonable summary, but it lacks a picture of an example information architecture employing traceability; here is one:

above we show three levels of problem/solution decomposition. The first level is used to manage the “problem” and contains the User Requirements (UR), Acceptance Test Plan (ATP) and Acceptance Tests (AT). We call this “Level 0″ and use “0″ super-scripts in the labeled circles which represent requirements (r), test requirements (tr) and tests (t). Within a level we have arrows representing traceability links between the requirements and the test requirements (e.g. r1 is traced to by tr1 in level 0), and between tests and their test requirements (e.g. tr1 is traced to from t2 in level 0). We call this ”horizontal” traceability relationship “Qualification”. Essentially a requirement should be “qualified” by a test requirement which specifies how we will know that the requirement has been met. These test requirements in turn need to be qualified by tests which when executed contribute to the measurement of  the qualification so far achieved.

The next level down, numbered 1, is the start of the solution, where we begin with the system requirements, which will specify the system which will be built to satisfy the user requirements. Which brings us to the next type of traceability relationship, which is “Satisfies” and runs vertically between levels. In our example user requirement r2 at level 0 is ”Satisfied” by the level 1 requirements r2 and r3. Just like the layer above, the system level has the horizontal “Qualification” traceability relationship happening between the System Requirements (SR), the System Test Plan (STP) and the System Tests (ST).

We only show one further level of requirements decomposition, but there may be more depending on the complexity of the system being developed, here we stop at the “Sub-System” level, numbered 2, where we have Sub-System Requirements (SSR), a Sub-System Test Plan (SSTP), and Sub-System Tests (SST).  The point is that additional layers can be added as necessary, by simply repeating the same pattern as established between the first two layers.

You are doing well as an engineering concern if you even manage to use parts of just level 0 and/or level 1; however, mature systems engineering organizations have been known to fully deploy 7 or more layers.

Caveat - this is just an introductory short article, and so I have had to lie by omission - there is a lot more that can happen and needs to be said (e.g. multiple sub-systems in the same layer, and one reason I used “Qualification” was to side step a lack of agreement in the industry as to the meaning of “Verification” and “Validation”). But I hope to return to this and related topics.

Share This

1 Comment »

PowerPoint Live 2007, the PowerPoint user conference, is being held on October 28-31 in New Orleans. I’ll be going as an attendee, exhibiting Perspector and giving the seminar “Lessons from the Rocket Scientists: Building presentations that take off” - which draws on my experience in the requirements management/systems engineering industry. The idea of applying lessons from requirements management to giving presentations was inspired by this posting I did back in April.

Tim’s blog has special offer links for those considering going.

This is a wonderful event for presentation professionals and I’m very excited about participating and maybe getting a chance to show you Perspector in action.

Share This

1 Comment »

Edward Tufte’s marvelous series of books on the art of displaying information has long been a joy for me to read, and still is. His books as artifacts in their own right reflect and reinforce the messages and ideals of their author - I love that kind of recursion when it pays off - and I thank Richard Stevens of DOORS fame for drawing my attention to this work in the early days of QSS (1993ish).

It was therefore a shock to me when Perspector’s CEO Adrian Doyle was sent a copy of Tufte’s anti-MS PowerPoint polemic last year by the great man himself - which was very kind of Professor Tufte, but unnecessary as being the big fan I am, I had already bought a copy and I bore all my Perspector colleagues at any opportunity about the wonders of Tufte books. I should explain that Perspector is the product with which I enjoy the role of CTO, and it adds 3D and animation capabilities to PowerPoint (shock horror).

Of course, I disagree with Tufte about PowerPoint. I don’t disagree that there are dreadful PowerPoint presentations inflicted on long suffering victims every hour of every day, BUT, it has also been my pleasure to see great artistry and skill applied to the art of communicating to an audience, and, even more shock horror, PowerPoint played a useful role in some of those presentations. As an example, I suggest watching the webinar I blogged about here by Cliff Atkinson. Tufte himself has even written “Of course full-screen projected images and videos are necessary; that is the one harmless use of PP.” Sounds like a charter for exactly following the very visual style of presentations which Cliff is so eloquently promoting!

I think Don Norman has the best article I’ve read on why Tufte is wrong about PowerPoint, or to end with a flurry of mixed metaphors; bullets don’t kill, just the lazy so-and-so who puts too many on a slide.

Share This

2 Comments »

An effective technique in delivering a message, especially a message conveyed using images, is to make a comparison. For simplicity we shall start by comparing 2 things.

Let’s say I am concerned about salads featuring tomatoes:

OK, no point having tomatoes without the catalyst of basil:

In fact I would go as far as to say:
Basil is more important than tomatoes on a pure taste per cost of ingredient basis.

Now, I’m not sure I believe what I just said about my salad, but I hope the images helped me convey the idea. The third image, which shows the relative importance central to my argument, is made easy to do in Perspector with its layout features; I can insert and then scale the size of each image into a new Perspector frame in seconds. I chose a side by side frame layout to emphasize the fact that the two images are strongly related (more-so than just using 2D). The outcome is that I can argue the relative importance of the two ingredients just using pictures. And pictures help make great presentations.

Share This

No Comments »

I just watched Cliff Atkinson’s webinar “First Five Slides” and was struck by the resonance it has with some best practices in requirements engineering. Essentially Cliff suggests that the first five slides of a presentation should be about:

• setting
• role (of the audience)
• point A (where the audience starts)
• point B (where the audience needs to be)
• solution (to make that happen)

I recommend watching the webinar to get the whole story - it is very well done. In requirements speak these slides correspond to:

• context
• stakeholder descriptions
• problem pre-condition
• problem post-condition
• solution

The problem can also be characterized as a “capability gap”. 

A common mistake in poorly written requirements is to ignore the problem and dive straight into a solution; it takes real discipline to keep the problem separated from the solution (or even to recognise that the problem should be analysed), but folks procuring massive systems like aircraft carriers have figured this one out.

What Cliff does is show the power of resisting the presenter’s natural inclination to focus on the solution, but rather to start by focusing on what the audience (the stakeholders) need to hear, which is why they should care in terms of their world being changed. This is what engages the audience’s emotions and keeps them around for the pitch.

(I updated this posting in August to use the word “audience” rather than “user” in the first set of bullets - hard to shake the RM mindset!)

Share This

No Comments »

One of the main goals achieved by Perspector is to enable users to quickly and easily construct layered hierarchy diagrams like the following:

This is from a Microsoft PowerPoint presentation which I managed to find a copy of today (it’s in better quality and at slide 38 here, but there is 10 Megs to download) - I remember seeing it or something similar at the 2003 PDC. This diagram was not built using Perspector; it uses only PowerPoint drawing shapes - an amazing bit of work if it was done by hand.

These kind of diagrams crop up again and again in technical papers - but they always look to have been hand crafted. Just try a Google search for “hierarchy diagram filetype:ppt”. You will find lots of examples like:

The diagram above shows how the “Premix Production Process” decomposes into 3 steps using an IDEF0 diagram, well, actually two diagrams with a hierarchical relationship. Doing 3D diagrams with a 2D tool is difficult. I remember when working with CASE tools like CADRE’s Teamwork and Aonix’s Software Through Pictures in the early 90s that the user manuals for the tools would have splendid pictures of the hierarchical relationship between diagrams, but the tools themselves would never offer an automated 3D view of the same.

In Perspector you can do these diagrams very quickly. Start with normal 2D slides for each of the layers, e.g.:

Create a new slide, insert a new Perspector image, and then insert a 2 placeholder vertical stack layout. Now just insert/link each 2D slide into the stack:

put a connector between the layers, tweak a few colors and transparencies, and you are done. If you have to change the content of any layer, the composite image will be rebuilt with the changes made to the linked slide. This is a very powerful way of working - decompose a scene into 2D parts and then assemble them in a 3D layout. You can hide the 2D slides if they are no longer needed for the presentation.

Here is our first DSI example done with Perspector:

I was able to play about with different camera angles and shift things about until I thought they looked good.

And finally, some fun locating a building using Google Earth:

Share This

No Comments »