Deaver has a new heroine, Kathryn Dance, briefly introduced in the last Rhyme story, whose forte is reading body language. I read this in one sitting while flying from Heathrow to Houston (modulo a crappy stop at Detroit where we had to go through immigration and customs before reboarding the same aircraft - BA did not mention this on the website when I booked the ticket - grrrr).

Back to the new Deaver: I liked every aspect of it. The plot was twistier than the bad guy was twisted and twisting, and the focus on behaviour rather than forensics worked for me; I look forward to more Dance as well as Rhyme. I can’t publish my only criticism without danger of a plot spoiler, so ask me once you’ve read it, and with curious coincidence, the same criticism applies to the latest Rebus. One clue: Michael Connelly has used the same plot device in at least one Bosch story and I’m getting a little tired of it.

Share This

 Anyway, if Rankin did decide to stop the Rebus series with this one, it would be on a splendid high note - highly recommended.

Share This

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

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

I am discovering that it takes a lot of work to create even a “toy” requirements traceability example, but I think I am getting close. As I did before, I shall start with the “end result diagram” which you can now click on to get to a more detailed version:

In a couple of 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 one of its formal information models to the construction of the presentation that they will be watching me give. Here’s another, more refined 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 can imagine writing down other requirements on the presentation such as that it will be between 45 and 52 minutes long. 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 or constraints imposed by the environment (e.g. I only have one hour in the conference schedule).

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 -it contains test requirements not tests. So here I decided that I am going to test the audience’s learning of the principles by an examination. ATP:11 is going to help us qualify that the audience was actually entertained by measuring something that may be an indicator of that.

For URD:15, we have an easier test requirement, ATP:15. We only need to demonstrate that further engagements are requested when that happens.

In the acceptance tests we specify tests which will be performed to qualify the acceptance test plan. Above we just show the test for assessing whether the audience understood the principle about distinguishing problems from solutions. 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 images with commentary (i.e. a slide show) will be fit for purpose. To meet the requirement URD:15, which was about generating spin-off engagements, I’ve decided that one way of doing that will be to make sure that the audience is entertained, and one way of doing that is to employ humor in the slides and commentary. So even if the audience don’t understand what is being said or shown, if they have had a laugh now and then, they might still rate the presentation highly enough to secure further bookings for the presentation and/or the speaker.

and above we see a sample of 4 slides which will be used to satisfy requirements in the SR. The slides are our final implementation layer (we don’t bother with test plan and tests for this layer of our example).

The SR requires a system test plan to qualify its system requirements. STP:1 is about testing to see whether 90% the audience “believes” that the images and commentary successfully explain the concepts they are being used to portray. This is a much weaker test than examining their actual understanding!

Our last document is the system tests, where we specify how to test the system test requirements in the STP. I was worried that measuring how often people smile was maybe a too crazy idea for even a toy example, but then I remembered how much importance Hollywood places on the results of measuring the reaction of test audiences to movies - so my example is maybe not so contrived after all.

At last we can show what traceability is by linking the requirements, test requirements and tests together, which leads us back to the first image again:

(please click the image for more detail).

In this trip out to tackle traceability, I’ve pushed to three levels, so there are now two sets of satisfaction links; the first is between the SR and the UR, and the second is between the slides (aka SSR or implementation) and the SR. Three of the slides help satisfy SR:2, one of the slides helps satisfy SR:16 (humor), you can’t really see what the image providing humor is, but its title is “bored audience”.

There is much more that can be said about the above traceability diagram, but for now I am happy I’ve created a firmer foundation for having those conversations in future posts.

Share This

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

What did they do to incur my wrath?

• Peter Snow is asking the questions
• no ”Jorkins” (Kevin Ashman)
• a discordant reduction in formality (no use of titles such as Mr.)

I enjoy listening to Peter Snow in the right context, but this is not it. Nor am I saying the program can’t exist without Robert Robinson, since Russell Davies did a grand continuity job in 2004 by maintaining the key elements of polite authority, wit and erudition (which must be the key requirements for hiring a BoB quiz master).

Only by surfing beyond the dismal BBC BoB site did I discover some clues as to what is happening. The Times report that the lack of “Jorkins” and the 27 years serving producer Richard Edis is due to BBC cost cutting. I’d vote for no cuts in radio (I pay a BBC TV license fee and very rarely watch their TV shows).

 Sigh.

Share This

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

Share This

What if you are posting poems already written using Mircrosoft Word? The first method I’ve found is to select text from Word and paste it into “Code” mode using the system clipboard. This preserves line breaks and one space of indentation. You can then go to Visual mode to tidy up spacing and change fonts if necessary.

Another way involves using the “advanced” menu - which is activated by typing <Alt>-v. Having first selected and copied the title and stanza you want in a Word document, use the “Paste as Plain Text” button. If you use the “Paste from Word” button you may find that the Word document used singly spaced paragraphs with no “after” space to achieve line breaks rather than using multiple hard line breaks within a paragraph corresponding to a stanza.

“Paste as Plain Text” is also useful for scraping poems from webpages as the visual editor often gives unexpected results with arbitrary HTML markup. I grabbed the following from http://www.bartleby.com/101/489.html:

The Tiger

TIGER, tiger, burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?

If you use normal system paste you get this almost but not quite faithful rendering of the original HTML table:

Not really what I wanted. Keep it simple and remember <Alt>-v and <Shift>-<Return>.

Share This