Monday, December 21, 2009

Requirements

Requirements artifacts are the documents that are created, managed, and published by business analysts or product management to define the scope and content of the development project.

Requirements must be captured and tracked in a version control system just like any other class of project artifact. In addition, specific requirements must be labeled in a way that allows items to be tracked through the entire life cycle: specifications, implementation, test, release, and support.

The granularity or specificity of the labels employed depends on the rigor of the project. A product with very high quality standards, such as a medical application, will have very detailed requirements that can be tracked in precise detail.

Requirements are often sketched out in natural language and carry informal instruction to the design specification team. A very effective way to organize functional requirements is to use the concepts of User Roles and Scenarios to develop Use cases. This process creates a formal model of the system. The model can then be analyzed to create formals specification of the components of the system.

An advantage of this approach is that formal requirements and specifications can be created as relatively small modules that can be worked on separately. This allows development and test of the modules or components of the system to proceed in parallel and supports the use of an Agile development process.

1 comment:

  1. A client asked if I had a sample of a “requirements map” that I could share, or something else that would help her to think through that phase.

    Here is what I wrote:

    There are many ways to draw the map. Requirements are typically written as English text in a document. Outline form can be helpful. If you want to go all the way to a "mind map" that's fine too. There are no rules for the form. It all depends on how you can best express yourself clearly and completely.

    The key is to include everything you want to consider - not all the details but a complete overview - so that your developer can start to imagine the structure of the project. The worst thing you can do is give it to him piecemeal. Filling in details later is much better. Whatever you can do to get the highest level view, however approximate, will be your best method. Start with the outline and don't worry about the amount of detail. Fill it in as you need to and as long as you don't change the overall plan you will have a happy developer.

    ReplyDelete