Requirements gathering: Formal or Agile 02 Mar 09

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Requirements gathering is one of the most important early steps in a software development project. Let’s assume company A has an outstanding software product idea and they hire company B to write that software. Requirements communicate what A wants B to create for them. It’s like an architect handing over the blueprint to the construction company and they build it, right?

Unfortunately some characteristics of software make the analogy of the requirements to the blueprint quite a stretch:

• Software is intangible which makes it inherently difficult not only to come up with all detailed requirements before development starts but also to communicate them to another person or group.
• Software represents dynamic workflows. The definition of a workflow consists of what one wants to happen, what one does not want to happen and how to deal with it in case it does happen. That is a lot to think about at once without a feedback mechanism.

Therefore change is an integral part of a software development process. Not to speak of the incredible boredom when spending hours, days and weeks meticulously defining requirements in every possible detail using well known formalized approaches.




We don’t want to get bored with what we are doing, so we decided to use an agile approach. Here requirements are used as a basis for discussion between A and B rather than exact instructions what to do. This approach also takes change into account and change requests can be integrated easily.




We expect the following from this approach:

• Shorter initial requirements gathering phase
• Increased communication with the developers should lead to less misunderstandings and also better control over the development process
• Increased ability to act on changing requirements
• Shorter time to market