Open Source Bridge

Creating functional requirements as a part of the planning process is like creating a treasure map. You want to get compensated for the value your cool built-with-open-source-thing is providing to your clients. Your clients want it to work better than what they originally had in mind. If you do the work upfront, you’ll know when you’ve hit the X marks the spot.

Speakers: Amye Scavarda, Bill Fitzgerald

Return to this session's details

Contributed notes

Slides on slideshare: http://www.slideshare.net/msamye/functional-requirements

The Message

Making a commitment to a milestone can add stress in the short term. But in the long term, it helps you measure and communicate.

The Details

For freelancers, hours worked == hours paid. Don't give away your most important asset. Functional requirements can help prevent these kinds of time overruns. For this discussion, think of functional requirements as a kind of roadmap.

Agreeing to a milestone is scary. But when you couple it with a transparent development process, you catch surprises early. You have open, honest discussions with the client about what's not working and what you can both do about it.

Everybody on the team has the technical chops. But we need to build our communications skills. Even the best requirements doc is no substitute for communication.

If the requirements are complicated / time-consuming to write, consider doing paid discovery / RFP. How do you convince a client to pay for RFP? Tell them what they can get for a little (free, 2-5 hr.) vs. a lot (pay for your expertise) of access to your time. Call it an "audit," if you think that'll help.

Types

• SRS (Software Requirements Spec): enterprisey, "shall / will / must" documents. Unsurprisingly, this big document style has a big IEEE spec describing it. If you're a subcontractor on a huge job and the client doesn't have one of these, worry.
• Series of Checklists
  • Discovery, Development Environment, Design Tasks, Launch, Support, etc.
  • Good for "microsite"-style projects
  • Start with a boilerplate set of lists (e.g., with MediaWiki), and customize it
  • Like a packing list for a camping trip
• Graphic novel
  • Storyboard with picture-in-picture screen mockups
  • Distant cousin of user stories

Ask and get answers for the big questions while you're writing these documents. Who's it for? How long will it be deployed? What will replace it? What does the existing system do / not do? How did it come to be? What would happen if nothing got done?

Tools

• Intake survey (show design samples and get a sense of their style)
• Docs from client (org charts, existing tech manuals) can give you clues about the project, culture, and potential problems. For example: an out-of-date org chart may mean they've just let a bunch of people go, and could have trouble making payment.
• Use a tracking system that works for you
  • Written doc
  • Wireframes (e.g., http://gomockingbird.com, http://www.omnigroup.com/products/omnigraffle)
  • Estimates / milestones
  • A ticket system that works
    • Basecamp is good during design discussions, but it's "the worst of all" for the software development phase. It gives you the illusion of being organized. But when it comes time to assign tasks to people and track them against milestones, it doesn't do enough.
    • The presenters enjoy using http://unfuddle.com.
  • Project management / time tracking (e.g., http://www.myintervals.com)

You need two communications lead people. One is in your shop, and one is at the client, both with the authority to say yes or no to a decision. No two-week, asynchronous, email-fests. Make sure the client understands your process.

Catch Red Flags Early

• What issues are a technical challenge for team / client?
• Security requirements?
• Performance requirements?

Money Quote

"The requirements doc is more of a cane than a cage. It guides you, but doesn't bind you."