Writing out what you're doing before you do it is super boring. You want to build stuff! Make stuff happen! Set something on fire!
And somewhere towards where we think the 80 percent mark to 'done' is on really big stuff, things start to pop up that we really did not anticipate. Our roadmap suddenly has these looming monsters that go bump in the night, and we have a spray bottle to fight them with and no time to do it in. This is the point where your project manager lights their hair on fire to get things finished.
What's that? There might be a better way? If we think like a pirate, we might not have to light our hair on fire?
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.
In this longer session, we'll walk through a trial run of functional requirements documentation. You'll have a list of questions to answer before it's complete, you'll have seen it in action, and we'll talk through all of the bajillion things you'll want to consider before your project should start. We'll also cover the 'open source trickery' of functional requirements. There might be a contributed thing that does the things you need, but in order to be really good at it, you have to forget about it in the beginning. Pirates don't just wing it.
Educational Open Source Geek, Drupal Enthusiast. Also a fan of open content. bio from Twitter
Life rocks everyday of the week. Add in web development, open source and stir for a good time. Cloudminer. Drupal'r. Mimosa Engineer. bio from Twitter
Sign in to add slides, notes or videos to this session