8 comments

• 

  David :Locke

  9 months ago

  Agile and waterfall requirements are exactly alike. What Agile and the waterfall do is package different sized collections of requirements. In Featuer-Driven Design, an Agile methodlogy, you create minimal-marketable functionality, all the requirements for one feature that works enough to show a customer, and you develop that in one or two iteractions. In the waterfall, you would specify all the requirements for all the features.
  
  Consider the need for feedback being the purpose of iteractions, and cash flow being reason for releases, you get more feedback, and more releases with fewer requirements even if you waterfall just one requirement if you don't work in an agile shop. You also reduce your risk with smaller requirements package.
  
  So what is a requirement, a decision to develop something, a what, a functional requirement. That one functional requirement will spawn several non-functional requirements, decisions as to how well the what should work before it is released to the customer. They are decisions. They look like modal sentences.
  
  Requirements are value packages. With smaller sets of requirements you can maximize the value delivered to the customer. You can also reduce the training effort required to use the delivered functionality. A series of small releases will get your customer up to speed quicker than a waterfall of all that funcitonality at the end.
  reply
• 

  Adam Bullied

  9 months ago

  David -
  
  I completely agree. I've always thought of features being a collection
  of requirements. It just happens that agile "features" are usually 1:1
  - 1 requirement, 1 feature. Whereas waterfall are typicall
  many-to-one, as you point out in your comment.
  
  The difference lies in how they are packaged and presented and worked
  on, but not essentially what they are - that always remains the same.
  
  Thanks for the thoughts and turning the perspective around.
  reply
• 

  Stewart Rogers

  9 months ago

  I agree that Agile user stories, scenarios, requirements are equivalent to waterfall requirements. Fortunately FeaturePlan is aligned with that. ;-) However, I am not sure I agree that Agile features are 1:1 with Agile requirements but I would recommend that is a goal. Too often people starting writing requirements and it is either one line that breaks all requirement writing rules or becomes one big paragraph that breaks rules in the other direction. This is why I am such a big fan of Mike Cohn's user story template. Short, specific and well written. http://blog.mountaingoatsoftware.com/?p=24
  reply
• 

  Adam Bullied

  9 months ago

  I love that user story template - it's the one I use frequently. Sorry if
  the the post was un-clear, but I always think about a feature as a
  collection of requirements; not necessarily 1:1. With agile, you can get in
  to much trouble that way for the exact reasons you mention.
  reply
• 

  Edwin Schumacher

  8 months ago

  There is a Dutch company called Synergio and they have published a very practical guide on writing good requirements. The essence is that you make a clear disctinction between writing the business need and the potential IT solution.
  
  You can preview the book, which is written in English at: http://www.synergio.eu/?menuid=259
  
  I am interested in your comments
  reply
• 

  Adam Bullied

  7 months ago

  Thx for passing the link along, Edwin. I will download the guide and have a
  read as soon as I can.
  reply
• 

  Charlie

  6 months ago

  I would disagree that waterfall method pushs you away from communicating a design. In agile you comunicate only what is needed to ge the programer started and then your project sucess depends on the creativity and quality of the programer. In waterfall as you call it the focuse is on clearly defining the product up front. This is done buy interviewing users, managers and stakeholders in such a manner that the scope of the project is clearly defined. You can teach anyone to code software and as long as it is very clear as to what they have to do, the coding is the easy part.
  Most of us who have writen our own programs have used the agile process and we all know how that comes out.
  Agile has its place in the developement world but it should be use for what it is good at. Rapid demos and software that is constanly changing. Its good for small teams that work together in a bullpin type of enviorment. Its not so good for large projects that have firm delivery dates or contractual needs. Its also not good for critical software (Banking, Aviation, atomic bombs and such).
  In closing waterfall is all about comunicating in clear detail and envolving all the stakeholders.
  reply
• 

  Adam Bullied

  6 months ago

  I agree that agile certainly has a place - and for some very heavy procedural-style projects, it may not be the best way to go.
  
  But the major issues I have with waterfall is this - requirements change - you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking - they are very smart people.
  
  And, more importantly - you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.
  
  If a developer feels a "crystal, crisp, and clear" requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, "I coded this to spec - that's a requirements bug" then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.
  
  Conversely, the person writing requirements can argue, "well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug."
  
  It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.
  reply