Requirements

Requirements are the problems that need to be solved. Not all problems can be solved with software. Users frequently have problems that they’d like to solve with software even though software is not the simplest, cheapest, or most robust way to solve them. Users often offer requirements in the form of software specifications: this is what the software should do. Developers often think users are crazy and stupid when they ask for specific functionality that the developer sees as bizarre and/or impossible. Users are not crazy or stupid. They simply have needs that developers don’t start out understanding, and they sometimes skip right over the articulation of their needs to telling developers how to give them what they need. Likewise, developers often skip right over understanding user needs to figuring out cool ways to implement what we think users might or should need.

It is important for developers to respect our users, and take seriously even the most bizarre and impossible-seeming feature requests. Our job is to find out what users need, and then together discover the best way that those needs can be met, whether with software or with paper and pencil.

Requirements analysis is not about having the answers. It is about asking the questions.

Some projects need to have formal requirements analysis before any coding starts. They may need fairly well-articulated requirements documents before the project proceeds: perhaps to receive funding or a go-ahead from management, perhaps to satisfy regulatory requirements for software development. Other projects can follow an “agile development” methodology: users and developers work closely together to iterate through versions of the software quickly, to accommodate changing understanding of the project. Except in the most highly regulated environments, most projects can benefit from some level of “agile development”.

Max and I have years of requirements analysis experience. We’ve written requirements documents for major software projects. I’ve worked on requirements for projects involving FDA computer systems validation. I’ve also attended the Atlantic Systems Guild’s course Mastering the Requirements Process.

Contact us today to talk about your requirements.