unique visitor counter

On Software Requirement Specification

  • Category :
  • technology
  • October 17th, 2006

    During the 4 years I was an engineer at Amaon, I never found requirement spec to be useful.  Instead they uses a concept called one pager, which is to describe the problem vaguely in one page, and hand it to the developer to figure out the rest.  It is then the responsibility of the engineer to understand the problem space and make the best technology decision to anticipate what detail feature the business really wants.  Rapid prototyping, using something close to code as your canvas to refine your picture.  This, I found, have shorten the development cycle; and give the engineers the sense of ownership they are looking for.
    Part of the team I am working now with requires a set of specification similar to those of a Boeing airplane plan.  Basically you are fronting all the thinking into the requirement phase and allowing a long period of dark time for development.
    In the three months that we spent doing requirement, the business needs have changed significantly.  So the process becomes constantly having to jump hoops to adjust the requirement to fit the changing business needs.  By the time the product is finished, the market might have changed, and the software is not flexible enough to accomedate that.
    The problem of the first approach is that you need engineers who are willing to take risk to own a problem space.  If he gets the problem wrong, he should be held accountable and his head should be on the chopping board.  At the end of the day, all business folks are held accountable for the same thing.  Why shouldn’t engineers be treated the same?   You need to find engineers who is capable of doing that, which I think is the main problem why a lot of people go with the second approach.

    I can’t say which approach will win.  Having been on both side of the fence, I persoanlly do not believe in software requirement spec anymore.  The flattening of the world introduced a huge inflaux of engineering talet at a much lower cost.  These engineering talent are mostly commodities to fill the second type of work.  You cna now get an army of them to bang out code for you.  So probably what will happen is big company who have a more stable requirement can afford the time to use this method; and small company who wants to out speed them will stick mostly to the first type of engineers.

    So as an engineer, the two caree choice I see is either to provide more value by taking on more business risks, or to place yourself as the management of these commodity resources, or to compete for the finite space of being the industry expert on things like pubsub and do that all day.  The days where average engineers can just code is getting shorter and shorter.

    Entry Filed under: technology

    2 Comments Add your own

    • 1. EK  |  December 1st, 2006 at 1:52 pm

      Kavin, I believe that you are looking in a wrong direction.
      Just couple points here:
      - Engineer cannot own a business (if he or she is still an engineer) – these are just two different types of mindset
      - Not capturing major requirements upfront can and will lead to a single-use non-flexible architecture (remember any big system you’ve worked on before)

      Taking architecture aside (e.g. you may have it in place or your task is not complex architecturally), check requirements approaches in:


    • 2. kv  |  December 1st, 2006 at 4:31 pm

      But with Agile you are discovering requirement as it comes along. Each iteration on the canvas works over the last one, and you refine what you’ve built. Much so as discovering what works and what doesn’t as it moves along. And a lot of things (like the algorthm of the product alloment of a dutch auction) are decided while you are coding it.

      The SRS process employed by a lot of consulting company is that the business would issue a 1000 page document containing every screen and every button and every algorithm on how the final product would be like, sign off and tell IT to “build this for me”. And IT would come back in 1 year with the product as described, without considering how it would be used and future expanson plan. If you didn;t mention monitoring, chances are the product is not going to have it. But my real problem is the effort in producing the 1000 page doc and how it limits the flexiblity of it

    Leave a Comment


    Required, hidden

    Check Spelling
    Activate Spell Check while Typing

    Some HTML allowed:
    <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

    Trackback this post  |  Subscribe to the comments via RSS Feed


    October 2018
    M T W T F S S
    « Aug    

    Most Recent Posts