Design involves determining a solution to a business problem by analysing the requirements and deriving a solution to these across design abstraction layers, from business to technology perspectives, using an Engineering Approach and which is aligned with a standard project delivery process.

The Inception phase confirms the high level solution scope and the Elaboration phase is where the requirements are defined and analysed to determine the functional and logical system design. For larger projects this can be an iterative process where a prototype solution is also developed to allow early user testing. This ensures stable requirements and functional design for input to the construction phase. It also decomposes the solution into more discrete elements to enable the subsequent delivery to be broken up into incremental phases.

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

A systematic software engineering method involves a standard development cycle of requirements definition, design elaboration, build, test and implementation phases

Analysis and Design (the focus of this site) involves determining a solution to a business problem by decomposing the requirements and deriving a solution to these across a number of abstraction layers, from business concept to technology platforms.

Construction involves building a working software product that realises the solution design specification. Construction methods may be specific to the target technology platform.

Testing involves confirming that the software product realises the design specified for each level of abstraction and solves the business problem defined by the requirements. Release Delivery involves configuring and packaging the product through the transition to production.

Project Management defines the processes and practices to be used in the delivery of projects and programmes, including governance, tasks, roles and responsibilities of project participants throughout the development life-cycle.

Projects follow a Delivery Process, which defines the sequence that we go through to complete the development cycle, of which waterfall (i.e. sequential) and iterative (i.e. repeated) are the two general options, although both can also adopt an incremental approach and/or include degrees of overlap between phases.

Software construction delivers a working solution to the design specification and is dependent on the target technology platform. It involves detailed design, build and test of individual technology components.

Testing activities are based on the corresponding Analysis and Design activities as defined by the industry standard V-model . In particular Functional Design should be verified in System Test and the end-to-end Technical Design in Integration Test. To progress from one testing phase to the next, the product needs to meet pre-defined criteria for test execution progress and outstanding defects. During this period design and development is revisited to resolve software related defects as necessary.

Integration and System Test are carried for project specific solution elements. Project deliveries are then combined together into a single Release which goes through a Release Delivery method that subjects them to Integration, System and User Acceptance Testing, as well as an Operational Acceptance Test. Regression testing may also be applied at System and User Acceptance Test.

The design approach can be applied to both traditional Waterfall and more Agile based delivery approaches, but which generally involve different disciplines and capabilities.

Agile methods are considered adaptive and therefore more flexible to meet changing requirements, whereas a Waterfall methods is more predictive but less flexible to change. A key enabler of flexibility is through iterative and/or incremental delivery – however this can be applied to Waterfall methods in order for them to be more agile, without having to make the more fundamental shift to Agile methods. For projects where the concern is to reduce delivery risk rather than be adaptable to significant scope change, this may be a more appropriate approach given existing capabilities.

In a waterfall based approach phase containment is the principle of ensuring that the activities associated with each delivery phase are properly completed before using them as input into the next phase.

However in reality, there will always be a degree of ongoing clarification and re-work for any given activity. Also if a more iterative approach is adopted then it is natural to cycle around the various delivery activities for each iteration. In addition some activities may be brought forward to support prototyping and reverse engineering, for example to be able to describe current behaviour where there are no existing up to date requirements or design specifications.

The phase containment principle should be applied to avoid unnecessary re-work in later phases where it is much more expensive and difficult to manage – but it is also important for to plan for some re-work and any reverse engineering.

Often there is a push to begin development quickly in order for the project to be delivering a tangible product. However, if this is done at the expense of producing complete requirements and design specifications then there is significant risk that the product will not deliver the anticipated value due to a mismatch against business needs.

The Functional Baseline is the point where the solution architecture, functional design and system design have been completed, and therefore the solution scope is well defined; it is only at this point that the effort for the subsequent construction and transition activities can be accurately determined and therefore this is an important milestone in the Project lifecycle.

Outside of our ability to engineer a solution that meets the requirements, one of the greatest challenges to delivery is Clarity and Control of Scope.

Clarity of Scope relates to ensuring that the requirements and associated solution are well understood, and taken further to ensuring that the requirements reflect a business need.

The former is achieved by the Systems Analyst ensuring that requirements are structured, complete and unambiguous - but this does not validated that they meet a business need – this is facilitated by Business Analysis defining a clear Target Operating Model.

Scope Control is a key aspect of Design both in terms of ensuring that the solution is aligned with the requirements and/or design from the previous phase, and to be able to manage the delivery within the constraints of time, quality and available resources (cost).

Due to ambiguities in the requirements and because there may be multiple solution options (e.g. different workflows) with differing levels of features, the detailed solution scope can be variable. There may also be technical constraints and reuse considerations that have a bearing on scope and effort required, so continuous assessment of feasibility is also key.

This is facilitated through close collaboration between the System Analyst, Business Analyst/User and Technical Analyst/Developer during the Functional Design phase.

Quality also has a significant bearing on scope as it can require significant effort to achieve higher quality. The level of quality should be balanced with the criticality of the solution.

The extent to which existing solutions are harvested to support the requirements influences which design deliverables are mandatory from an IT delivery perspective.

Any harvesting approach must be technically feasible, and this will be validated by the Solution Architecture during the early phases of the project.

It is generally recommended that Functional Requirements are defined in any case in order to:

• Allow early validate that the business demand is captured correctly and avoid surprises in user acceptance testing or production where these are expensive to resolve and will be treated as business change requests
• Support a comprehensive user acceptance test which is normally based on requirements
• Provide IT with clearly defined input so that IT can validate the solution is functionally fit for purpose