Info

You are currently browsing the archives for the requirements category.

March 2010
M T W T F S S
« Feb    
1234567
891011121314
15161718192021
22232425262728
293031  
Links

Archive for the requirements Category

Jason Fried of 37Signals - Business of Software 2008

One of the things I love is being able to see presentations from conferences I was unable to attend. A coworker passed on a link to this video (55 minutes) from the Business of Software conference. In the talk, Jason Fried of 37Signals, makes of Ruby on Rails and Basecamp, speaks on many aspects of running a software company and keeping teams working effectively.

Here are some of the slide titles, topics and items Jason discussed:

  • Planning is vastly overrated - no roadmaps, specifications, projections. Get rid of distractions. Functional specification does not reflect reality and leads to an illusion of agreement.
  • Decisions are temporary - optimize for now
  • Red flag words - need, can’t, easy, everybody, nobody. These are the words that cause projects to be late
  • Interruption is the enemy of productivity - the closer the team is physically, the less you get done. Interruption is not collaboration. A fragmented day is not a productive day.
  • Underdoing - target non-consumption
  • Find the right size - imagine the software as a physical item
  • Follow the chefs - what is your cookbook?
  • Always be questioning - Why are we doing this? What problem are we solving? Is this actually useful? Are we adding value? Will this change behavior? Is there an easier way?
  • Give up on hard problems - there is an abundance of easy problems
  • You’re an editor - Curate your product. Say no to more things than you say yes.
  • Work Less
  • Q&A - Starts 28 minutes into the video

An enjoyable video, especially the first half before the Q&A session.

 

My Definition of a Requirement

I recently received an invitation to join the Yahoo Requirements Engineering Group. This led me to thinking about my definition of a requirement. I saw a similar definition in a document (it was part of the boilerplate text) delivered by a consultant at a prior position. It was the most useful item in the document… (For the life of me, I cannot remember who the consultant nor firm was.)

Requirement - A testable assertion of a customer’s need.

I like this definition a lot because it is simple and lacks a lot of the technical jargon or background knowledge required for other definitions. The terms are understandable by business users. The one thing I always add when I deliver this definition is that customer is not limited to our external customers - it is inclusive of all our internal customers.

|