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

RE: [scrumdevelopment] Need for Functional Specs

Expand Messages
  • Roy Morien
    Michael s response is quite reasonable, but it doesn t address the question of exactly what a Functional Spec actually is, or what it should contain, how much
    Message 1 of 5 , Nov 26, 2008
    • 0 Attachment
      Michael's response is quite reasonable, but it doesn't address the question of exactly what a Functional Spec actually is, or what it should contain, how much time should be spent on it.
      The problem often seems to be that it is the creation of a weighty and well presented FS that is the main intention of the activity. If it is big, heavy and beautifully presented, it must be good, and the author(s) are judged on that, rather than the correctness or appropriateness of the content. This may come from the basic education problem where students are required to prepare FS as an exercise that is assessed, but the teacher has no way of knowing if the content of the FS is the least bit useful ... the only assessment criteria is weight, size and beauty.
      Roy Morien

      To: scrumdevelopment@yahoogroups.com
      CC: salilprasad@...
      From: myip11@...
      Date: Wed, 26 Nov 2008 04:18:16 -0800
      Subject: RE: [scrumdevelopment] Need for Functional Specs

      The concept of "Done" includes writing specifications. Consistency and quality may be defined ahead of time. The member of the team starts to write what is relevant to the slice he/she is working on within an iteration for a set of story points. It is possible for others to iteratively build on that FS in other iterations over time. As you can see, as functionality changes overtime, this framwork allows you to adapt and adjust expeditiously.

      --- On Wed, 11/26/08, Roy Morien <roymorien@hotmail. com> wrote:
      From: Roy Morien <roymorien@hotmail. com>
      Subject: RE: [scrumdevelopment] Need for Functional Specs
      To: scrumdevelopment@ yahoogroups. com
      Date: Wednesday, November 26, 2008, 1:38 AM

      In my view, and I believe others' too, the User Story is just the place to start to understand requirements. You have to analyse the user story, and identify the features that it implies, and define the details of that. You can't not define the requirement clearly and in detail.
      BUT you must now consider what written specs you will prepare. Do you need a detailed, nicely paragraphed and sub-paragraphed document? No, I don't think so. It would be interesting to see exactly what those Functional Specs that those others you mentioned created. You need as little documentation as possible, but as much as is needed. It is difficult to know exactly how much documentation is too much, or just enough. But my view of documentation is this: first, it is for the future to communicate information that will be useful for those developers who follow you, maybe years ahead. Second, it is to describe things that are not obvious, and you need to explain to those future people. Third, within that constraint, it shouldn't duplicate what you have in other mediums ... for example, why document a report layout? The report itself is obvious. Why document a screen layout ... just develop it using appropriate tools, such as Dreamweaver or Delphi or Visual Studio etc. Why document something that you will do tomorrow, just so that you can say you have documented it?
      AND whatever documentation you do, whatever detailed analysis of USer Stories that you do, only do it for the very near future activity ... Just in Time requirements analysis!! Keeping a large store of fully detailed requirements is waste.
      And there a various levels of analysis of User Stories. One level is to understand the requirements at a level that enables you to have a good idea how complex the requirements are, for Story Point estimation purposes (or whatever estimating method you use). This certainly doesn't need to be in great detail. Knowing that you must develop a webpage, and the approximate difficulty of that is all that is necessary, for example. The exact layout, content, design, appearance etc. can come later, when you are actually designing the webpage ... then you must know details, but will use some design tool as your story board and design peg-board, not create a big design document.
      Always remember ... Just enough, Just in time.
      Roy Morien

      To: scrumdevelopment@ yahoogroups. com
      From: salilprasad@ yahoo.com
      Date: Tue, 25 Nov 2008 21:04:22 -0800
      Subject: [scrumdevelopment] Need for Functional Specs


      If we have most of the requirements written in user stories format, is there still a need for functional spec? Can someone point to a good resource that could help with that? In our current dev env, I see people writing 60-70 pages of FS for 200 person day project and it appears we are spending lot of time in documenting functional requirements before doing coding and I am having tough time in changing the waterfall mindset.

      Any good book/reference would be much appreciated.


      Find great deals on eBay Net yourself a bargain

      Sell your car for just $40 at CarPoint.com.au It's simple!
    Your message has been successfully submitted and would be delivered to recipients shortly.