Exemplary Visions

(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