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

156478Complex business knowledge and specs

Expand Messages
  • Otto Behrens
    Mar 1, 2011

      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

      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.
    • Show all 6 messages in this topic