Identify Subsets

When writing a requirements specification it is important to clearly identify the minimal subset of requirements that might be useful. This is also known as identifying the minimum viable product. Now, extend that minimum viable product concept across the timeframe from when development starts and the completion of the product. Identify the minimal increments that might make the minimal subset more and more useful. Such identification provides software designers with insight into optimal software design. It will enable designers to:

1. More easily embed just one function per component.
2. Select architectures that are more contractible and extendable.
3. Understand how to reduce functionality in the case of a schedule or budget crunch.

A very effective technique of recording subsets is to rank the order of a products features by value. Compliment that ranking by grouping features into minimum viable products over the schedule of the product. Take your software requirements specification (SRS) and include columns in the margin beside each requirement. Each column corresponds to a different version of your product. These versions can represent multiple flavors of a product, each tailored to a different customer or situation, or they can represent increasing levels of enhancement through time. In either case, place an "X" in the appropriate columns to indicate which versions will have which features.

Reference:
Parnas, D., "Designing Software for Ease of Extension and Contraction," IEEE Transactions on Software Engineering, March 1979.

Record Why Requirements Were Included

A requirements specification is the culmination of many different activities: debates, discussions, architectural studies, statements of work, etc. So, when someone wants to change a requirement we need to know why that requirement exists - what was the motivation behind that requirement - before we can decide if it is safe to change it. Similarly, when a system fails to satisfy a requirement, we need to know the background of the requirement before we can decide if we should modify the system to meet it or modify the requirement to match the system. If your agile team is not giving any such consideration to missed acceptance criteria then your agile team needs to include the person writing the acceptance criteria.

When a requirements decision is made about an acceptance criteria, record a pointer to its origin. For example, if the decision was made during an interview with a customer, record the day and time, as well as the participants in the interview. It is only with such documentation that you can

1. evolve requirements later or
2. respond to situations where the as-built system fails to satisfy the requirements.

Reference:
Gilb, T., Principles of Software Engineering Management, Reading, MA.: Addison-Wesley, 1988.