Traps and cost driver

Up to now we have been looking at the benefits. Now, let's have a look at the costs. Below, I will explain the mistakes that can potentially be expensive, without weighting them according to their order.

Balancing act between intelligibility and clarity

In order to keep the description of the requirements clear, they should not be too extensive. But then the participants should be able to understand the requirements even after several years. Therefore, all important details must be included. To address this problem, it's a good strategy to

• define the requirements audience, e.g. which information should be noted
  • for the author himself to remember after one year all the relevant informations or
  • for department staff members, to apprise requirements,
• start with a high level of abstraction and become consistent at this level
• To keep important details in important cases.

  Different Views

  In the simplest case, you need only one view on the requirements. Typically, this view connects the business architecture with the requirements included. But often there will be the need for more different views after short time: For the testing team, for the project teams, for further specification, for operation or for training. A method providing only one view, will not be sufficient at all. Therefore different views are considered in the presented approach.

  Violation against DRY (Don't Repeat Yourself)

  Important business insights are described in the requirements. These insights will be useful in many cases. Just think of descriptions for testing, work packages, requirement specification, project plans, manuals, status reports, contracts, or error messages. In all these cases, you are often tempted to insert parts of a requirement. The costs will become clear as soon as such a scattered requirement changes. Therefore, the challenge is to combine the comfort of “copy & paste” with the lack of redundancy.

  A better understanding of problems leads to structural changes

  The demand for structural changes nearly always increases due to a better understanding of the technical problem. According to A. Cockburn, the requirement analyst would be well advised not to consider the functional decomposition within the requirements. Nevertheless, requirements are mentally linked with the future business architecture, which itself reflects the structural changes. Everyone working with this system feels the need for a reasonable structure. This structure is reflected by one or more views within the presented approach. Therefore, the better structure and content of the requirements can be separated, the lower are the restructuring costs.

  Change of requirements over time

  The whole world is changing as fast that IT has a lot of trouble to keep pace. This is also the case for managed requirements, particularly in the following dimensions: The change of requirement is of interest at the level of a individual requirement: How has the requirement evolved? Who initiated the change? What were the reasons for the former decision and do these reasons still exist? The changes of complete requirement networks are also of interest – in the terms of continuing the analysis of the requirements while a stable version is implemented in parallel. Dealing with both of these requirements in version control are described in the appendix.