Development of any product, solution or service should not begin without a clear set of requirements and approved feasibility. The level of detail can be improved over time, but it is essential that the baseline requirements are agreed before the actual development starts. Therefore, requirements are an essential part of any development request and the foundation upon which a solution, product or service will be built.
The approach to capturing and managing requirements will differ depending on the selected development approach.
As illustrated in the diagram below, the incremental development methods anticipate resources to be fixed by capacity, and time to be constrained by time-boxes. This allows requirements (also known as features) to be flexible in contrast to sequential development where requirements and time are fixed, and therefore resources are variable.
Figure 5.1.1 Sequential and incremental development approach
Sequential development defines and finalises most of the requirements before development begins, thus determining the project scope to produce a full project plan. This approach works well when the business requirements are clear and the business objectives are fixed. However, if the business needs change after development has started, there is a risk that the final deliverable is based on outdated requirements and does not meet the final business objectives. It also may cause the project being delayed or exceeding the estimated costs due to extra work required for modifications and fixes.
Figure 5.1.2 Sequential development
The following categories of requirements should be documented before development starts:
Business Analysts (BA) analyse, define, document and manage requirements. They identify business needs and are responsible for documenting and prioritising the requirements with stakeholders. Business Analysts also ensure that the projects deliver business benefits.
The incremental development approach does not demand a full list of predefined requirements, and therefore the value delivery starts quickly with every iteration round. With this approach, gathering or producing requirements is very flexible. Typically, the stakeholders and development teams take an active role in generating new features and requirements via user stories.
Requirements remain flexible as needs change or as new design considerations are discovered throughout the development. Documentation should be kept unsubstantial and updated only based on the development team’s actual needs. The team has a clear perception of the product vision, accompanied by a visual representation of the roadmap to help them to achieve the desired outcomes.
Incremental development provides speed and agility but fails sometimes to recognise the big picture and the time, effort and coordination required in business transformation. This is where sequential development may complement the incremental development with a business transformation programme going parallel and synchronised with incremental development.
Figure 5.1.3 Incremental development
The requirements can be articulated by:
A DEV lead / product owneris responsible for reviewing, approving and managing the requirements in the product backlog. Their aim is to maximise the value of the product resulting from the work of the development team.
Irrespective of whether the development is using a sequential or incremental approach, testing the feasibility will help avoid costly mistakes, delivery risk, user dissatisfaction or failure to deliver envisioned benefits.
Feasibility testing consists of a variety of actions including at least the following:
In sequential development, the business case must be produced throughout the planning stage by gathering requirements, comparing solutions, assessing the architectural fit, and estimating the development costs. This can often lead to identification of extra costs and risks due to additional complexity or features being identified. The business case will determine the overall project feasibility, which may result in amendments to the project scope or even project closure.
Incremental development does not have a complete set of requirements and features upfront. Therefore, the business case is developed for the value stream instead of the specific project. Funding a value stream for incremental development enables value to be delivered without delays.
The business case must clearly articulate business benefits that are targeted to be achieved. There are typically seven types of business benefits that can be achieved:
It is essential that the development includes a solution architecture definition. This will allow the development to determine how it will meet the overall requirements. It typically includes a variety of different facets including:
Architectural feasibility is important to deliver confidence in the proposed solution. A sequential project typically covers more details than incremental as the requirements are better known. However, in the incremental approach, it is equally important to cover enough details to build confidence in the overall solution.
With incremental approach, the architectural design can also be tested early in the development lifecycle by prototyping and planning major technical (or high risk) features into early increments so that the identified issues can be fixed at an early stage. On the other hand, sequential development often relies on less risky standard solutions in implementation.
The quality of the deliverables often depends on the development teams’ skill-level throughout the development. Identifying the required skills and sourcing the right competence to required roles and teams is therefore important already in the planning stages.
When using external resources, it is important to use assessment criteria that help to select reliable and competent partners. Common assessment criteria are for example the following: employee size, area of expertise, past and current client references, cultural fit, value vs cost, geographical location, and availability of resources.
