Loading ...
Sorry, an error occurred while loading the content.

156485Re: [XP] Complex business knowledge and specs

Expand Messages
  • Rick Mugridge
    Mar 2, 2011
      Hi Otto,

      Gojko Adzic has an excellent book coming out, "Specification by
      Example", Manning which covers this very well. It's based on his looking
      at the practices of many teams and distilling the important "patterns"
      for success.

      I've used these techniques myself with clients, and they've worked very
      well in complex business domains. For me, the critical points are:

      * Writing (or verifying) the specs needs input from people with
      various skills. This process usually needs to be part of the continuous
      flow of a project. Early in a project, the whole, wider team may be
      involved in workshopping the specs. As a system matures, there need only
      be a few people involved. It depends on how important it is for everyone
      to understand, and have input into, the business goals and potential

      *The specs need to be written at a business level, in terms of
      business rules and processes. They serve an important role as examples
      for the wider team, aiding discussions and communication. See "/Doubling
      the Value of Automated Tests: FitLibrary Storytests" /(2006)/,/with
      links for video and slides at

      * You can verify the consistency of the executable specifications and
      the system, so you can tell they're up to date and thus can be trusted.

      * Executable specifications have to evolve along with the thinking
      about the domain and what's needed. Hence some will need to be
      refactored from time to time, as with code.

      * If instead they're written as tests in terms of the concrete
      implementation of the system they will be verbose, hard to understand,
      have little value in answering business-level questions, and will be
      difficult to maintain. Most people who apply test automation at this
      level fall into this trap. Many tools don't support making a distinction
      between the DSL of the business layer and the DSL of the implementation
      layers (eg, database, xml, ui, message), and don't support a clean
      mapping between them. For the first couple of articles on such DSLs, see

      One circumstance where executable specifications don't add value is
      where the domain experts are also the software experts. Then it's easier
      to write specs in code, getting the value of refactoring support and,
      potentially, the benefit of type-checking. This appears to be the case
      with Industrial Logic; Joshua has talked about how they don't need
      executable specifications for their eLearning system.

      Cheers, Rick

      BTW, I'm soon to release an open-source tool for refactoring executable
      specifications that are based on FitLibrary.

      On 2/03/2011 1:52 a.m., Otto Behrens wrote:
      > Hello,
      > We find it difficult to figure out how parts of the system should be
      > working because of the complexity of the business domain. We have
      > reasonable test coverage, and the tests do tell us (often) how a
      > certain part of the system works. But we end up spending quite some
      > time in the debugger on a restored production database to figure out
      > why a certain value is what it is, or why a certain rule was applied
      > or not. (For example, why is the Capital Gain on a particular
      > investment $1234.56). The system often behaves correctly (sometimes
      > not) and we help the business people out by explaining how it works.
      > Part of the answer is probably that we must just have more tests. And
      > well refactored tests so that it's easy to figure out.
      > Could it be that we need more documentation (business specifications)
      > that contains formulas and rules on how the business domain works?
      > We've been reasonably successful at extracting requirements when we
      > need it, which reduces lead times. This means that when we deliver 2x
      > a month, we can adapt to new projects without waiting for someone to
      > write a spec.
      > The business traditionally keep specs as a reference on how the system
      > should implement business requirements (in other teams in the
      > company). When we reduce the system specs, there is a need to
      > understand things. I think reducing specs is good thing because specs
      > often 1) take too long to write 2) are out of date and 3) don't not
      > reflect what was implemented anyway. How do you retain information /
      > knowledge even years after business people and IT people have moved
      > on?
      > Another (somewhat) related question is that we often don't get good
      > detailed analysis done on solving the problem. Writing specs have the
      > effect that someone sits down and *thoroughly* thinks through the
      > problem and the potential alternative solutions. There are numerous
      > reasons why we don't want to do this. But we end up losing that
      > thoroughness if we don't. Any ideas where we should focus here?
      > Thanks for your help.
      > Otto

      [Non-text portions of this message have been removed]
    • Show all 6 messages in this topic