Clear Conceptual Thinking

Levels of Spec Principle, Non-Functional Requirements

2009-07-13T07:49:00.006+01:00

Follow me on Twitter: @rolfgoetz

Just a quick remark: I added a grammar representation to the "levels of specification principle" on PlanetProject. For those of you who like precision.

If my boss sees this, he again will call me a "theorist." :-)

A Quest for Up-Front Quality

2009-07-03T11:46:00.006+01:00

Today I'd like to point you to the presentation slides of a talk I gave at this year's Gilb Seminar on Culture Change in London.

You'll find the file if you go to this PlanetProject page on Zero Defects, navigate to principle P6 and click the link titled "presentation".

The title was "A Quest for Up-Front Quality".

Short outline:

Why I wanted to have a rigorous QA effort for the first steps of a real-life project
What I did to achieve this (Tom Gilb's Extreme Inspections, aka Agile Inspections, aka Specification Quality Control (SQC))
What the outcomes were, in terms of both quality and budget (with detailed data)
What the people said about the effort
What the lessons learned are

If you want to see truely amazing results for one of the most effective methods of software development history, don't miss the slides. Any questions? Just ask!

The talk was warmly welcomed by the great Value-Thinkers of the seminar, special thanks to Ryan Shriver, Allan Kelly, Giovanni Asproni, Niels Malotaux, Matthew Leitch, Jerry Durant, Jenny Stuart, Lars Ljungberg, Renze Zijlstra, Clifford Shelley, Lorne Mitchell, Gio Wiederhold, Marilyn Bush, Yazdi Bankwala, and all others I forgot to mention.

History Repeating?, or A Case for Real QA

2009-06-01T11:47:00.007+01:00

Jeff Patton of AgileProductDesign.com has an excellent article on Kanban Development. He does a great job in explaining the kanban idea, in relation to the main line of thinking in Agile. The article is about using a pull system rather than a push system like traditional (waterfall) development or agile development with estimation, specification and implementation of user stories.

Reading the first couple of sections got me thinking about another topic. Isn't this agile thing "history repeating"?

First of all, I'd like to question how common agile development really is. It's clear that the agile community talks a lot about agile (sic!), but what does the numbers tell us? I don't have any, so I'm speculating. Let's assume the percentage of agile developments is significant. (I don't want to argue against Agile, but I want to know if my time is spent right ;-)

Jeffs writes:

"Once you’ve shrunk your stories down, you end up with different problems. User story backlogs become bigger and more difficult to manage. (...) Prioritizing, managing, and planning with this sort of backlog can be a nasty experience. (...) Product owners are often asked to break down stories to a level where a single story becomes meaningless."

This reminds me so much of waterfall development, a line of thinking I spent the most of my professional career in, to be honest.

First, this sounds a lot like the initial point of any requirements management argument. You have so many requirements to manage, you need extra discipline, extra processes, and (of course ;-) an extra tool to do that. We saw (and see) these kind of arguments all over the place in waterfall projects. Second, estimation, a potentially risky view into the future, has always been THE problem in big bang developments. People try to predict minute detail, the prediction covering many months or even years. This is outside most people's capacity. Third and last, any single atomic requirement in a waterfall spec really IS meaningless. I hope we learn from the waterfall experience.

Jeff goes on:

"Shrinking stories forces earlier elaboration and decision-making."

Waterfall-like again, right?

If user stories get shrunk in order to fit in a time-box, there's another solution to the problem (besides larger development time-boxes, or using a pull system like Jeff has beautifully laid out): not make a user story the main planning item. How about "fraction of value delivered" instead, in per cent?

Jeff again:

"It’s difficult to fit thorough validation of the story into a short time-box as well. So, often testing slips into the time-box after. Which leaves the nasty problem of what to do with bugs which often get piped into a subsequent time-box."

This is nasty indeed, I know from personal experience. BTW, the same problem exists, but on the other side of the development time-box, if you need or want to thoroughly specify stories/features/requirements. Typical solution: you put it in the time-box BEFORE.

Let's again find a different solution using one of my favorite tools, the 5 Whys.

Why do we put testing in the next time box? Because it consumes too much time.
Why does it consume a lot of time? Because there is a significant number of defects to find and fix (and analyse and deploy and...), before we consider the product good enough for release.
Why is there a significant number of defects to be found with the testing stage? Because the product brings a significant number with it.
Why does the test-ready product have a significant number of "inherent" defects? Because we have not reduced them significantly them further upstream.
Why didn't we reduce it further upstream? Because we think testing is very effective in finding all kinds of defects, so testing alone (or along with very few other practices) is sufficient for high defect removal efficiency.

It is not. Period.

From an economic standpoint it is wise to do proper QA upstream, in order to arrive at all subsequent defect removal stages (including testing) with a smaller number of defects, hence with fewer testing hours needed. This works because defects are removed cheapest and fastest as close as possible to their origin.

What do I mean by proper upstream QA? Well, I've seen personally that inspections (on requirements/stories, design, code, and tests) deliver jaw-dropping results in terms of defects reduced and ROI. I'm sure there are a couple more, just ask you metrics guru of choice. The point is, see what really helps, by facts and numbers not opinions, and make a responsible decision.

Estimation with Use Cases: Deeper Thoughts

2009-05-22T09:20:00.003+01:00

I came across a thought provoking white paper written by John Smith of Rational Software. It's on Estimation of effort based on Use Cases.

If you have ever tried estimation with use cases, you know that the various levels of decomposition encountered in the wild are troublesome. John does an excellent job in conceptualizing this problem.

The article seems to be from 1999, and I'm not sure whether John's ideas made it into the various estimation tools. For me, reading them brought a great deal of clarity in the levels-of-use-cases concept, so I think it's worth reading anyway.

Atomic Functional Requirements

2009-05-05T14:33:00.002+01:00

The discussion on shall vs. must at Tyner Blain , on which I have blogged recently, triggered me to wrap up what I have learned about atomic functional requirements over the years.

See 3 principles and 4 rules on PlanetProject. Feel free to do responsible changes.

The article explains how to write atomic functional system requirements so that the spec is easy to read, and ambiguity is kept to a minimum.

Note that it is NOT about the even more important (non-)functional user requirements here, in a sense of what a stakeholder expects from the system, which problems shall be solved, what shall be the inherent qualities of the solution etc. I do not intend to argue that any spec must include atomic, functional requirements. But sometimes setup is so that it must. Don't forget to establish the context first.

Now enjoy the article on how to write atomic functional requirements. Thanks for your comments.

Tweets from Rolf

2009-04-28T15:38:00.001+01:00

Just in case you're interested and did not notice, you can follow me on Twitter using http://twitter.com/rolfgoetz

Shall or must to markup mandatory requirements?

2009-04-28T15:07:00.002+01:00

Generations of Business Analysts before me had to decide which auxiliary verb to choose in a mandatory system requirement. "Shall", like in "The system shall..." is probably most widely used in the English spec-writing world. But is it a good idea?

Scott Selhorst of Tyner Blain did some research using a novel research method on how ambiguous shall and must are. The bottom line: if for any reason it might not be clear to some reader that shall means mandatory, use must (consistently throughout the spec, of course, and put the convention in your requirements management plan).

I think the shall (as opposed to must) dates back to the old MIL-STD 498, or even DOD-STD 2167A. And anyone who "grew up" BA-wise in the military or air traffic control fields like me, is very accustomed to the shall, and must might sound too harsh. But, hey, here's my favourite answer to that: "You're writing a spec, and you're not gonna win the literature Nobel prize for it!"

Interesting enough, as Scott points out in his article, in many languages other than English shall is not really used for the meaning of mandatory. In German, for instance, the meaning of shall is much closer to should than must. And we all know what happens in waterfall projects when acceptance testing is due and the developer has implemented only half of the should requirements...

Writing Many High Quality Artefacts - Efficiently

2009-04-28T11:00:00.003+01:00

I finished a process description on writing many artefacts, like use cases, requirements, book chapters, test cases, in high quality with the least effort possible. Please have a look, I'm eager to see your comments. After all, it's a Planet Project wiki article, so if you feel like it, just edit.

This, again, is on evolution, or learning by feedback. Makes heavy use of inspections. Inspections BTW, are one of the most effective QA methods known in software engineering history, according to metrics expert Capers Jones.

Understanding the exponential function

2009-04-17T10:50:00.004+01:00

I was pointed to a set of videos that explores the exponential function and what most people think about its consequences. Seems to be a boring topic.

It isn't. I watched the first 10 minutes, only to realize my jaw has dropped to the floor. This is stuff I knew and didn't grasp at the same time. I strongly suggest you invest the ∼75 minutes and watch it.

It hit me two days after I started to drivel about me liking sustainable solutions. I wasn't up to all my senses, obviously. ;-)

0-defects? I'm not kidding!

2009-04-16T18:04:00.003+01:00

Today a post by Michael Dubakov at The Edge of Chaos provoked some thoughts. He basically argues, that a zero-defect mentality causes several unpleasant effects in a development team:

- Not enough courage to refactor complex, messy, buggy, but important piece of code.

- Can’t make important decision, instead make less risky, but wrong decision.

- Do everything to avoid responsibility, that leads to coward and stupid behavior.

Well, I guess the solomonic answer to this critique is 'it depends'. Actually, I'm quite enthusiastic about the zero-defects thought. However, I also know that zero-defects are extremely hard to attain, or can easily be attained by chance ;-)

You maybe remember the post where I detail 10 Requirements Principles for 0-defect systems. Therefore I posted the following as a comment to Michael's post, argueing

- that we should not call defects 'bugs',

- that zero-defects can be attained by using principles that have almost nothing to do with testing, but with requirements,

- that testing alone is insufficient for a decent defect removal effectiveness.

Hi Michael,

thanks for another thought-provoking post! i enjoy reading your blog.

Hmm, several issues here.

1) First of all I think we should come to a culture where we do not call more or less serious flaws in IT systems 'bugs'. To me, it does not make sense to belittle the fact. Let's call them what they are: defects (I'm not going into the possible definitions of a defect here).

This said, look here: scroll down a bit, and laugh.

And here's a funny cartoon.

2) A couple of years ago I had the luck to be part of a team that delivered (close to) zero defects. I wrote down the 10 principles we used from a requirements perspective. See

the short version on PlanetProject, more or less uncommented, or Part 1 and Part 2 of

a longer version on Raven's Brain.

Interesting enough, only 1 out of the 10 principles is directly related to a defect-finding activity. We had a 'zero defect mentality' in a way that we all seriously thought it would be a good idea to deliver excellent quality to the stakeholders. Fear or frustration was not at all part of the game. Mistakes were tolerable, just not in the product at delivery date. Frankly, we were a bit astonished to find out we successfully delivered a nearly defect-free non-trivial system over a couple of releases.

3) While it seems to be a good idea to use the different strategies that you proposed in the original post, I'm missing some notion of how effective the various defect-reducing strategies are. The only relevant quantitative research I know of come from metrics guru Capers Jones. If I remember correctly he states that each single strategy is only about 30% effective, meaning that you need to combine 6-8 strategies in order to end up with a 'professional' defect removal effectiveness. AND you cannot reach a net removal effectiveness of, say, 95% with testing alone. From an economic standpoint it is wise to reduce the number of defects that 'arrive' at testing in the first place, and this is done most effectively by formal inspections (of requirements, design and code).

Greetings!

Rolf

PS: if you find a defect in my comment, you can keep it ;-)

Value Thinking: Using Scalpels not Hatchets

2009-04-13T15:43:00.003+01:00

Ryan Shriver, managing consultant at Dominion Digital, has put out an excellent article on Value Thinking. I think his views are extremely relevant, as we see cost reduction programs all around the IT globe. I can't tell you how much Ryan is spot on, considering the organization I work for (sorry, can't tell you more in public).

The article is short, gives ample information on the WHAT and (more importantly) the WHY.

Ryan writes in due detail about 4 policies and 5 practices, his advice to struggling IT shops and IT departments. Thanks Ryan!

It's on gantthead.com, and I recommend signing up if you aren't already, it's free.

Extracting Business Rules from Use Cases

2009-04-11T15:16:00.002+01:00

A while ago I posted a process for Extracting Business Rules from Use Cases, on this blog and on PlanetProject. I'm proud to announce an article on the very same subject. While the original form was quite condensed, the new version has more background, and examples. It has the core process of course. Find it at modernAnalyst.com as a featured article.

I'd be happy to discuss the topic here, there, or work with you on improvements on PlanetProject.

Rules for Checking Use Cases

2009-04-06T11:49:00.000+01:00

A couple of months ago I assumed the role of a quality manager for one of my projects. I learned that document quality control requires a set of defined rules to check documents against. Because the documents to do quality control on were 90% use cases, I defined a set of 8 rules for checking use cases, working with authors and checkers, as well as subject matter experts (read: customers). you can find them on Planet Project.
For all readers who face the challenge to find a BA job, or at least a (second) job where BA skills are applicable, there's an interesting discussion going on at the modernAnalyst-Forum. I suggested to move to a QA perspective. This idea fits with the above Use Case Checking Rules.

Update on Specifying Goals

2009-03-05T16:07:00.003Z

I updated the Planet Project article on Specifying goals, using some of Tom Gilb's approaches and recent experience with the topic from one of my projects.

In this project, we struggled somewhat to explain to our subject-matter experts the importance of beginning with the (ultimate) end in mind. They thought they had to describe every little step, every button and every view of an IT application down to the smallest detail.

My favorite example was the following sequence (from a use case description), repeated a hundred times within the requirement specification:

User does some inputs
User "sends" the input, i. e. confirms his inputs
System checks inputs against rules X and Y
Systems shows an error message in case the checks fail.
...

I finally got them with suggesting an alternative solution, roughly like this:

User does some inputs
(System has to make sure rules X and Y are not broken)

I guess the key was to make up a scenario which used quite a lot of sarcasm:

"I think I am an expert user."
"I do these simple inputs. Damn I'm good!"
"Now send the stuff to the stupid machine." *klick*
"Ooops ... What the ...."
"The stupid machine says I did it wrong?!"
"Why didn't it prevent me from doing it wrong, is there anything this machine is useful for?"

:-D

Do you care about your customer, every day?

2009-02-15T12:38:00.004Z

There's a wonderful parable on real customer satisfaction on the "i must be an acrobat" weblog by Joshua Hoover.

He compares eating out in a restaurant with inattentive waiters to developing software without delivering real results to a customer.

7 Habits of Highly Effective Risk Managers

2009-02-11T08:20:00.004Z

I'm proud to announce that Raven, author of the wonderful Raven's Brain weblog published another guest post of mine.
It is on effective risk management, titled "7 Habits of Highly Effective Risk Managers".

As you can expect from my material it is a set of rules, that risk managers can easily apply to their jobs. It might also help if you are NOT the risk manager in your endeavor, but want to help someone who is.

Here's the condensed version:

R1: Be responsible.
R2: Analyse in depth.
R3: Use hard facts.
R4: Do more than one thing.
R5: It's not fire and forget.
R6: Integrate.
R7: Don't change the scales of measurement.

In the blogpost itself I explain every rule/habit in detail. Thanks Dick Karpinski for nitpicking and thanks Mr. Covey for the title.
Enjoy!

Estimating with Use Case Points - FREE template

2009-01-30T06:44:00.005Z

Being lazy, I was looking for a free, read-made, comprehensive and easy-to-use spreadsheet template for estimating project effort with use case points. I needed it for one of my current projects, in which we are writing 200+ use cases (sic!, see my remark below), and prepare a project proposal for senior management.

I came across Scott Selhorst's material on Use Case Point Estimation. Very useful!

Check out:

An introduction to use case point estimation with good context for use case newbies
A How-to for the final calculations
The free template

The template can also be googled and found at modernAnalyst, another useful source of information for business analysts and such folk.

Note on the large number of use cases: I personally think they are no real use cases. It's quite close to a functional decomposition done in use case form. I expect the system to arrive at about 8000 Function Points, but estimates range from 1.000 to 15.000 as of now :-)

Software Development Practice in the 21st (22nd?) Century

2008-12-25T09:22:00.005Z

A couple of months ago I published an article about 10 Critical Requirements Principles for 0-Defects-Systems (on Ravens Brain). Anecdotal evidence on how I once achieved zero defects in one of my projects.

If you like the thought of reliable software (sic!) you might as well like Charles Fishman's article on the On-Board Shuttle Group, the producer of the space shuttle's software. Yes, they have a lot of money to spend, but many lives and expensive equipment are at stake.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. -- Charles Fishman on the software product the Group puts out

BTW, they seem to use three key pracices: very detailed requirements, inspections and continuous improvement.

The way the process works, it not only finds errors in the software. The process finds errors in the process. -- Charles Fishman on the On-Board Shuttle Group's process

Happy New Year! (Note that 2009 is a year of the 21st century. Can't we do any better?)

PS: I'm going to go on vacation from Dec 28 to Jan 20. More interesting topics still to come, please be patient.

Lewin on Theories

2008-12-22T13:49:00.003Z

Just this cute little quote here, for all of you who need to be assured of their "sometimes too theoretical work":

There's nothing as practical as a good theory. - Kurt Lewin

Merry Christmas, and sorry for all the clutter around short posts ;-)

News in the Field of Systems Engineering

2008-12-22T11:50:00.002Z

For a VERY comprehensive monthly newsletter on Systems Engineering go to the Project Performance International website. A quote from the site:

Project Performance International is proud to produce a monthly Systems Engineering newsletter, named "SyEN". The newsletter presents in-depth coverage of the month's news in systems engineering and directly related fields, plus limited
information on PPI's activities and relevant industry events.

The nice thing is, advertising is REALLY limited. I find the newsletter do be both interesting and easy to read. They will send you and E-Mail with an table of contents, and you can then go to the website and read it. PDF format ist also provided.
From this months contents:

Featured Article: The ISO Way - Alwyn Smit
Featured Society: Association for Configuration and Data Management (ACDM)
Systems Engineering Software Tools News
Systems Engineering Books, Reports, Articles and Papers
Conferences and Meetings
Education
People
Related News
Systems Engineering-Relevant Websites
Standards and Guides
PPI News
PPI Events

Why Re-work isn't a Bad Thing in all Situations.

2008-12-21T11:20:00.006Z

Software Development has many characteristics of production. I'm thinking of the various steps that as a whole comprise the development process, in which artifacts are passed from one sub process to another. Requirements are passed on to design, code is passed on to test (or vice versa, in test driven-development), and so on.

Alistair Cockburn wrote an interesting article on what to do with the excess production capability of non-bottleneck sub-processes in a complex production process. In the Crosstalk issue of Jan 2009, he explores new strategies to optimizing a process as a whole. One idea is to consciously use re-work (you know, the bad thing you want to avoid like the plague) to improve the quality of affairs earlier rather than later.

In terms of what to do with excess capacity at a non-bottleneck station, there is a strategy different from sitting idle, doing the work of the bottleneck, or simplifying the work at the bottleneck; it is to use the excess capacity to rework the ideas to get them more stable so that less rework is needed later at the bottleneck station.

Mark-up is mine. You see the basic idea.
In conclusion he lists the following four ways of using work that otherwise would have spent idling around, waiting for a bottleneck to finish work:

* Have the workers who would idle do the work of the bottleneck sub-process.

Note: Although this sometimes is mandated by some of the Agile community, I have seldom seen workers in the software industry that can produce excellent quality results in more than one or two disciplines.

* Have them simplify the work at the bottleneck sub-process.

Note: An idea would be to help out the BAs by scanning through documents and giving pointers to relevant information.

* Have them rework material to reduce future rework required at the bottleneck sub-process.

Note: See the introducing quote by A. Cockburn. Idea: Improve documents that are going to be built upon "further downstream" to approach a quality level of less than 1 major defect per page.

* Have them create multiple alternatives for the bottleneck sub-process to choose from.

Note: An example would be to provide different designs to stakeholders. Say, GUI designs. This can almost take the form of concurrently developing solutions to one problem by different engineering teams, for the best solution should be evaluated and consciously chosen.

Lack of Engineering Practices Make 'Agile' Teams Fail

2008-12-13T07:45:00.005Z

James Shore wrote a blog post that is among my TOP 5 in this quarter. Go read it! He argues that the industry sees so many agile projects fail because most teams that call themselves 'agile' mistake the real idea with the wrong set of practices. Maybe this quote says best what his article is about:

These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff--the stuff that's really Agile--they're setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won't last.

This speaks from my heart. It's exactly what happened when I tried to turn a project 'agile' in a super waterfall organization (picking up this metaphor I'd say it's an Angel Falls organization). We will have technical debt to pay off for at least a decade. However, we found that out quite quickly ;-)
If you're looking for some method that is strong both in the management and engineering field, check out Evo by Tom Gilb. I know I recommended Mr. Gilb's work over and over again in the past 2 years, and it almost seems ridiculous. Be assured, I'm not getting paid by Tom :-)
To get a very clear perspective on iterative planning check out Niels Malotaux' Time Line.

Use Case Content Patterns Updated

2008-12-10T17:59:00.002Z

Martin Langlands incorporated "my" DESTRUCTOR pattern into one article, now version 2 of his Use Case Content Patterns description. Have a look here, the whole thing is easier to handle now.

Hint: Click 'files' at the bottom of the wiki page to see the pattern file. Sorry for the inconvenience!

Patterns for Use Case CONTENT, anyone? Yes, finally!

2008-12-01T14:46:00.003Z

While modelling use cases, have you ever thought 'I have modelled something very similar before.'? Here's a solution to re-occuring modelling tasks. Martin Langlands has developed a bundle of patterns for the content of use cases. He developed these with an extensive backround in banking and insurance systems. After reading his well written article it I found myself in a very different field but still the patterns were applicable, to say the least. I think they are ready to use in most areas of concern, and the idea should set the use case modelling world on fire!

Visit Planet Project to see the respective Process.

Note: I proudly contributed the idea of another pattern to Martin's, the DESTRUCTOR pattern ;-) Go have a look.

Failure by delivering more than was specified?

2008-11-27T18:15:00.000Z

I stumbled upon a puzzle. Please help me solve it.

It strikes me as odd, but there might be situations where a provider fails (i.e. the system will not be accepted by the customer), because he delivered MORE than was specified. I'm not talking about the bells and whistles here, that (only) wasted resources.

Imagine a hard- or software product that is designed to serve more purposes than required by the single customer. Any COTS product and any product line component should fit this definition.

Which kind of requirements could be exceeded, scalar and/or binary requirements? I think scalar requirements (anything you can measure on some scale) cannot be exceeded, if they do not constrain the required target on the scale on two sides. Haven't seen that (It's always "X or better", e.g. 10.000 transactions per second or more.
Even if it was constraint on two sides, this simply would mean a defect.

But there can be a surplus of binary qualities, i.e. functions. A surplus function can affect other functions and/or scalar qualities, I think.
Say, as a quite obvious example, the system sports a sorting function which was not required. A complex set of data can be sorted, and sorting may take some time. A user can trigger the function that was not required.
- This might derail overall system availablity (resonse time), a user required quality.
- It might open a security hole.
- It might affect data integrity, if some neighboring system does not expect the data to be sorted THAT way.
- It might change the output of another function, that was required, and that does not expect the data to be sorted THAT way.
(First fantasy flush ends here.)

So, if you find a surplus function in a system, what do you do? Call it a defect and refuse to accept the system?

Eager for your comments!