We're a transparent startup founded by Aviel Ginzburg and Damon Cortesi building solutions in the social media and public relations spaces.

Follow along as we share the ups and downs of building a startup.

Follow Untitled Startup on Twitter
Tweeps Who Like Us
ericpetersmattappersonfbaumdavidhoangdudeman718kevinmarkslouisgrayjoannalordmsaleemshaunacauseysh3n3rdpistachiorsarvereddavemcclurescobleizerneilpatelkegill

Requirements Gathering

Jan
31
By Damon Cortesi

I just wanted to make a quick post about requirements gathering. We also just put up a video about making mistakes.

Twice now, we’ve gotten bit by not doing proper requirements gathering when working on RowFeeder. Specifically, we’ve evaluated solutions and it appears that they’re going to work – but we haven’t actually layed out on paper exactly what it is we need and if the potential solution matches those needs.

Unfortunately, and perhaps stupidly, both cases had to do with extremely similar situations. In the first instance, we were implementing the OneForty Payments API. We assumed that we could have multiple “editions” of our application, which is now the case, but wasn’t when the API first launched. That caused us a decent chunk of time, but we were able to work around it easily enough.

In the second instance, we were implementing Spreedly. Notice already that I’ve used the word “implementing” rather than “researching”, or “evaluating”, or anything else that would indicate a proper amount of planning. Nevertheless, it seems that Spreedly subscriptions don’t support multiple purchases of the same subscription. For example, if we want to sell two monthly subscriptions each tracking a separate term, this is not possible. Unfortunately, this wasn’t something we realized until after a day of work when we finally reached the point of integrating the Spreedly API. We’re waiting to hear back from Spreedly if they have a solution, and I hope they’ve got something up their sleeve that will help us out. I love their API thus far and would love to deploy it on RowFeeder.

This would have been extremely easy to prevent had we taken the following steps:

  1. Take 15 minutes and write down our different requirements
  2. Review the documentation of payment system $x
  3. Check off each requirement
  4. If all boxes are not checked, evaluate other options

See. Not that difficult. Remember that next time you want to rush to implement an external API. If you hadn’t guessed, I’m still learning the ropes of formal software development. And unfortunately, I’ve had to learn about requirements gathering the hard way. Additional tips to prevent head->desk scenarios much appreciated.

    blog comments powered by Disqus