5.1 Requirements and Feasibility

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

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 requirements to explain the targeted business capability and change – “why” and “what”
  • Delivery requirements to outline stakeholder expectations on delivery – “how” and “when”
  • Solution requirements to describe features, functions, and characteristics
  • Non-functional requirements to consider predicted volumetrics, performance, security, availability levels and characteristics, scalability, maintainability and serviceability
  • Project requirements to consider actions, processes, competences and other conditions
  • Transition requirements to ensure service capabilities required to achieve the service release readiness.
  • Quality requirements to verify acceptance criteria needed to validate successful completion
  • Portfolio requirements to understand assumptions, dependencies, constraints with other projects.

 

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.

 

Incremental development

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:

  • User stories which are short requirements or requests written from the perspective of an end user
  • Epics which are large bodies of work that can be broken down into several smaller tasks called stories
  • Initiatives which are collections of epics that drive toward a common goal
  • Themes which are large focus areas that span the organisation
  • Acceptance criteria which are conditions that the product must satisfy to be accepted
  • Non-functional requirements which describe how the system works

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.

 

Feasibility

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:

  • Business feasibility to ensure that the project will stay within a manageable and affordable cost level, relating both the development and running phase, support and maintenance, costs. The expected business benefits should cover the costs and also some surplus
  • Technical feasibility to ensure that the proposed development fits with the overall business technology strategy, roadmap and enterprise architecture. At the same time, it tests if the proposed technical solution meets the overall requirements and especially the non-functional requirements
  • Deliverability feasibility to ensure that adequate resources, skills and capabilities are available throughout the development and for the ongoing service.

 

Business feasibility

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:

  • Increased sales revenue
  • Increased gross margin
  • Increased quality and business continuity
  • Increased business capability
  • Decreased operating cost
  • Decreased financing cost
  • Decreased enterprise expenses
  • Decreased risk.

 

Technical feasibility

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:

  • Application architecture to determine how the various elements operate
  • Integration architecture to determine how individual components or services inter-operate, including the links with other external systems and services
  • Data architecture to determine how data will be gathered, structured and managed
  • Security architecture to determine how the solution will be secured and regulatory or legal requirements supported
  • Infrastructure to determine how the solution will be hosted and support predicted volumetrics, availability, etc
  • Service management to determine how the solution will be managed and supported once implemented.

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.

 

Deliverability feasibility

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.