Forgotten Requirements

03 September 2010

Recently, I had the opportunity to look at a set of user stories on an upcoming project and apply a high level estimate to each. These estimates were going to provide a starting point for determining project timeline and schedule. Every time I'm presented with a request for estimation, I shiver a little because I'm so bad at it. As I understand it, I'm not alone in this weakness. I have found, however, that the more requirements that can be defined and the more detail that can be described for each, the more accurate a timeline can be established.

The focus of requirements on every project is different. This fact is influenced by many things: the type of project, the members of the team, the culture of the company, the maturity of your process, the number of specialists with eyes on your project (eg, think of the equivalent of a security Nazi in your organization), and so on. This list is definitely not definitive or all-inclusive, but I'd call my favorite animal a liger before I'd bet that no half-awesome software type has forgotten to specify one of these requirements. Just let your Internet-bored eyes glaze over those bullets that aren't applicable to your project.

In no particular order, try not to forget...

  • Integration with authentication system
  • Version control repository setup
  • Test environment setups
  • Hardware - requirements, setup, VIPs, clustering, load balancing
  • Uptime / Service Level Agreement (SLA) - consider lowest SLA of integrated subsystem
  • Bug-tracking system setup
  • Local development environment setup
  • Unit test environment and actual unit testing
  • Integration and automated tests
  • Test case-tracking environment
  • Web framework selection and setup
  • Coding standard
  • Targeted environment/browser, screen resolutions, capabilities, required plugins, graceful degredation, and cross-browser testing
  • Training for new platforms/environments
  • 3rd-party library selection and integration
  • Urls - exact paths required
  • Errors - conditions, handling, messages, triggers
  • Performance - response times, page sizes, http requests
  • UI - corporate standards, validation, max lengths, empty views
  • Timeouts - requirements/limitations of request, session, server
  • Privacy - terms of agreement
  • Data - backup, security
  • Scalability - future growth model
  • Deployment - method, schedule, automation
  • Operations - support after launch

This list is born of my experience -- both triumphs and frustrations. What are some of the requirements that you would either add or remove?

After listing all these potentially missed requirements/activities, I'm driven to also say that the best projects are the ones that meet the business need by delivering the simplest product for the least cash. So, don't make it more complicated than requirements come to dictate.