Writing many high quality artefacts

Type: Process
Sources: Tom Gilb, Jeffrey K. Liker ("The Toyota Way", McGraw-Hill, 2004) my experience as a QA manager of a project in which a team of business analysts had to write 200+ use cases
Note: If you are curious about what kind of system has more than 200 use cases, I'm not going to say that these were real use cases ;-)


To produce many artefacts ("mass production"), conforming to high levels of quality, and do so with the least effort possible.


This process helps to achieve quality AND do an economically sensible activity, if you need to do much work. By much work I have in mind writing large documents, for instance specifications with lots of requirements, use cases, UML diagrams, or test cases, or simply a multi-chapter book or a detailed plan. Anything that in whole is large enough to cause pain if after "finishing it" you find out you need to do a lot of rework to make it reach a necessary quality level.

Note: I think the need for "mass production" of documents and the like deserves a second thought. Wouldn't it be better to deliver value to a customer instead of using time to write intermediate work products? It would be better, no doubt. But there are situations where it seems easier not to change the whole system development process. In the project I mentioned above even the contractor was not selected, but we used the time to write the spec. We were aware of the risk of meanwhile requiremets creep.

Summary of Steps in this Process

Entry Conditions

E1: Make sure you know the rules to which your work has to comply.

These rules may evolve in the course of the process, stemming from the analysts or stakeholders who are most involved in the process. If in doubt, invest 5-10% of the time planned for the activity to find out what to do exactly (that includes a deeper look into "why" to do it), and what "done" will really mean.

E2: You need to have some inspection process established.

Simply put, an inspection checks a piece of work against a set of rules (see E1). So you can determine quality quantitativly. I like the extreme version of inspections, outlined here.

E3: You need a defined quantitative goal level of quality for your work.

Say, 1 major defect per page, where a major defect is a potentially expensive violation of a rule (see E1).

Steps and Notes


S1: Write 10-20% of your document, i.e. 1 to 3 use cases.

This can be anything. The idea is to write just as much so that a) you can check the results by means of a defined quality assurance process(see E2), and b) you don't get overwhelmed by the possible rework in case you find out you have to start over. This also helps if the writing or the rules are new to authors: Do small steps, because there is less *uncertainty* to overcome.

S2: Do an inspection on your work, using a sample from your newly written material.

Goal: find out if the material is good enough (according to the rules and the defined quality level).
This step provides the minimal necessary feedback for improvement (see S4), and, finally, excellent quality. This step is the only step in the process which provides the information to find out about the quality of the product. You cannot see quality by watching busy analysts, churning away on writing spec after spec.

S3: If your work is not good enough (according to the rules), re-write and go to S2.

S4: Actually use the material written.

It is best to use the first 10-20% of work in the next process downstream, like design, programming, test, rollout, actual use, BEFORE doing the next 10-20%. That way you discover problems caused by the work done, and can correct it before you repeat the errors. This seems counterintuitive, as you have to stop what you are doing to wait for results. Remember that you are actually preventing rework to be done later. Use the time to improve the rules and other work standards.

S5: Write the next 10-20% of the work and go to S2, until done.

This is the key to an efficient process: do small portions of work, learn, and do the next small portion. Consider to start the next portion only when the next process downstream (design?) calls for more specs. Because of requirements creep it is risky to have a large pile of specs "done" before anybody starts reading them.

Exit Conditions

X1: Every patch of work has been inspected …

… at least by one sample AND has exited the inspection process with a quality level of at least the threshold you defined by E3.


"Build a culture of stopping to fix problems, to get quality right the first time." Principle 5 of 14 from Jeffrey K. Liker, The Toyota Way"Feedback is the only teacher with proven effectiveness." (freely adapted from D. Doerner)
"I have been driving for two hours without an accident, so now I can close my eyes while driving." - Tom Gilb

Related Pages

Where to go from here? Link other pages in bullet list.

rating: 0+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License