CFUnited 2009: Peter Bell - Requirements and Estimating

Peter looks at projects in roughly 3 categories.

• Configuration < $8000 - free spec (just set up something already built)
• Customization < $50,000 - paid spec (requirements gathering, setting up and customizing packages)
• Exploration $50,000 - no spec (hard to even define scope)

Configuration

These projects are all about efficiency. You will need to simplify the specs for these types of projects. You will need to have/use configurable code to implement deliverable. That could be via something with a setting file or configuration wizard. In some cases you might use DSLs (domain specific languages). And for very simple stock types of things you can even reuse prior specification documents (copy and paste, or compile stock specs as you go).

Customization

I think here he was talking about a site that will use a lot of code that you or someone else already wrote.

But, you can tell early on that they want it to be tailored to their specific needs. So, there will be some "customization" involved. These project are about setting expectations. You will have to go through a requirements gathering process before you can estimate a "customization" project. He uses a process he calls Intent Driven Design.

• Determine Business Intent (Why are we doing this? Why bother?) Use cases answer these questions.
• Identify Audiences/Roles (Who will use this? What do they need to do?)
  • Functional roles
  • User can have multiple roles (vistitor, site admin, ...)
• Objectives (What do THEY want?) It's our job to help them figure out what they want.
• Gather User Stories (layman's term: "A list of tasks")
  • As a ROLE
  • I want a FEATURE
  • so that BENEFIT
  Example:
  • As a CUSTOMER
  • I want an ORDER STATUS DISPLAY
  • so I can CHECK ORDER STATUS ANY TIME.
• Develop Use Cases (Takes a 'User Story' and get's way more specific). Once you can get sign off on a use case and you develop the application to satisfy the use case, you can measurably be done. These use cases would consist of:
  • Screens (Names of screens the user will see)
  • Actions (Things the user can do on that screen)
  • Steps (Default, alternate and error paths)
  Example: The Default Path would go to the "Login" screen. There would be a "processLogin" action. If that succeeds, there would be a "getUserOrderList" action and a "MyAccountOrderList" screen. From that screen you could select an order. That would cause the "getOrderDetail" action to run and the "OrderDetail" screen to render.

Exploration

These can be difficult to gather requirements on and nearly impossible to estimate. You may need to ask the client to choose 2 (fixed price, fixed scope or fixed time). Agile methodologies could be a good fit for these projects as they may need to evolve over time (as time/budget permits).

Managing Risk

Peter looks at features as four different types.

• Rocket Science: These features are almost impossible to estimate. It may be possible. It may not. It might take you 2 months. It might take you 2 years. One possibility on feature of this nature is to present a price for an R&D period (after which you can re-evaluate it's feasibility). Another option is to dumb the feature down to where it's still usable/functional but realistic to accomplish.
• Lab Experiment: These are caused by non-functional requirements. His example was that something had to work really "fast" or handle x amount of operations per x. So, you can't accomplish that without a cycle of coding->testing->coding->etc.
• New to you: These have been done before. But, you will have to figure it out for the first time personally.
• With a twist: You've done something very close to it before, just slightly different.

Peter also talked about dealing with Dark Matter. What you don't know ALWAYS hurts you. Nothing is "obvious". So, if it's not specified, it is not included. (In other words If it's not written down, it's not part of the project.) Something to keep in mind is that you can't always make people happy. You can however, "implement" a written specification. You should also expect Revisions and have a process in place to manage them.

Summary: I have been working on the same team on the same application for 6 years. But, this stuff still applies to me. There is always another feature to add to our app. And I have learned painfully, from experience, the truth and utility of some of these suggestions. Because my "client" is my boss, we used to just start a project and then he would come by our desks daily and help us "evolve" the spec. This was a painful system that led to lots of false starts and dead ends. So, I do my best now to facilitate a requirements gathering process bringing in end users where their domain specific knowledge is needed. Then I ask for the interface to be designed before I start. Once we have the interface designed (and sometimes approved by end users), then I will finally start on the project. IMHO, it has greatly lowered my stress level having a more concrete goal to shoot for when working on a project.