Site Loader

18-02-_2016_21-58-19During the last posts (here and here) I’ve discussed the overall problem and the hybrid software development process in general. This post will detail the requirements part of the hybrid model.

How requirements are covered and business analysis is performed is discussed in several books, articles and reports somewhere else (please have a look at this search or IIBA for some information).

The basic problem is that several parts of a requirement are either

  • not yet finished (i.e. the user department cannot give a final commitment on all parts of the requirement) or
  • the customer has not yet decided on several options to fulfill a specific requirement

As this information is necessary to create a binding offer while using a regular process/project model, it may be left over in a “fuzzy” state with some restrictions that allow us to create an offer based on the given information.

Any “fuzzy” information known at this point in time is usually more stable than any information from the requirement’s author when the author is forced to give a final statement on a requirement while.

So, instead of insisting that the requirement needs to be finalized, those points are marked as “open” or describe several (similar) “option”s.

Open Requirements

Open requirements are requirements which allow a concrete estimation for the offer but leave enough space to define the details on this particular requirement later during the development phase.

An example of an open requirement would be a report where the data to be shown on the report is defined but the format/layout is still open.

Another example of an open requirement would be a set of rules to define several levels of contribution levels. It is clear how many are there but which account accumulates to which contribution level can be defined later on during development.

It is very important to define the rules and margins on every open requirement to enable the vendor to create a estimation on this requirement that can be used as part of a fixed price offer.

Defining Options

Options define similar functionalities (from the user’s perspective) which allow the customer to decide later on which option to take. The options may have similar efforts.

An example for options is to decide on CSV or Excel (XLSX) format for an import later during the project. In case if efforts are not similar, the customer needs to be aware that as of the fixed price project only one price tag will be communicated and the price doesn’t change in case the customer decides on the cheaper one.

How to manage open requirements and options during later phases of the project

It is very important that the customer is aware of the fact that there has to be a decision to be taken for each and every open requirement and option during the development process. It has to be agreed (latest) during the contractual phase if and when the decision needs to be done. If the decision is not there at the point where it is needed project delays or additional costs may occur.

Advertisements

Post Author: Stephen

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.