Requirements in early phases
While methods for requirements engineering have greatly advanced over the last years, these techniques mainly focus on engineering tasks that need to be carried out after a project is already started.
However, before starting a project, standards like PRINCE2 [OGC 2009] demand for a project mandate and a business case, to evaluate if the project should be carried out or not. Usually the business case should estimate the benefits of the project as well as the costs. To do so, it is first of all necessary to determine the scope of the projects requirements.
However, it is within the very nature of a project that the scope is not a fixed size throughout the course of the project. Barry Boehm was one of the first to describe this behavior with what is now commonly called the Cone of Uncertainty. The notion this image conveys it that the scope of a project is much more prone to fluctuations in early phases than it is in later phases. This is shown by the tapering of the cone to the right.
Thus, the problems a requirements engineer faces in early phases are:
- An unclear project scope due to early stage of problem definition.
- Limited time and means to create the first requirements documentation.
- Capturing the functional scope necessary for cost estimation.
Though the first problem can’t be solved by any methodology – it is due to the very nature of the Cone of Uncertainty - we will provide useful tools to deal with the last two issues in this article.
To determine the solution scope, use case diagrams will mostly be the method of choice in early project phases. The advantages are: They offer a good first overview of functional requirements from a user point of view and can be captured, structured and documented easily. Therefore use case diagrams are often used as a basis for discussion and communication with stakeholders [Rupp et al. 2009]. Nevertheless, as we will describe later, a plain use case diagram is insufficient for both an adequate presentation of functional requirements and as a basis for an effort and cost estimation.
Understanding the business use case
For a reliable size measurement it is necessary to understand how business use cases (what) translate into system use cases (how). However, usually it already takes a long time to describe the business use cases, so we cannot expect to have enough time to describe the system use cases as well in pre-project phases. Therefore, we propose to address this conversion in short stakeholder interviews.
It is our experience that stakeholders who define the business use case often have limited technical knowledge concerning the actual implementation of their requirements. However, they very often possess a very in-depth understanding about what systems and interfaces are involved in the new application. That’s because they often have a coarse overview of the IT landscape of their company and know where to draw the needed information from, e.g. customer data, or what applications will provide services for the new IT product. Also they understand when input data needs to be manipulated or processed to generate the desired output data.
In our experience sufficient information can often be gathered even in early or pre-project phases if the requirements engineer has access to the right stakeholders and poses the right questions. Here are some simple steps that we think can be carried out in any project no matter how tight the schedule is:
- Document the preliminary business use cases (what).
- Hold a workshop together with business people and technical staff.
- Clarify for every use case the rough details of its implementation (how) by asking:
- Which actors are interacting with the system?
- How many other systems are involved?
- What interfaces need to be defined?
- How many steps does it take to process the raw data?
- How many steps does it take to process the output data for displaying?
- How many alternative scenarios are there and of how many steps will they be comprised?
- How many error scenarios are there?
Dr. Carl Friedrich Kress works as Senior Consultant and Innovation Manager in Germany. He has written many articles about the scientific background of software cost estimation methods and metrics. His work helps IT project managers to reliably estimate and plan software development projects. Working in an agile environment he’s also experienced in creating precise requirements for agile developers.