The Solution Design stage begins upon Customer and stakeholder approval of the System Requirements Review (SRR) and its associated artifacts. Solution Design is specific to Scrum projects only. Design is not typically required for Kanban process cycles involving Problem Reports and smaller “break-fix” tasks. Partnet’s Solution Design stage consists of two elements: functional design and technical design.

Functional Design: User stories form the basis for functional design and planning. User stories are short, textual statements corresponding to a specific feature or business need that the software solution must fulfill. Requirement Managers write user stories based on the approved solution requirements. During functional design, user-story reviews are convened with members of the Delivery Team to formally discuss each user story in detail and specify its acceptance criteria. All outstanding questions and assumptions are documented for follow-up with the Customer and other external stakeholders. User stories are then allocated into specific development tasks and subtasks that constitute the Product Backlog.

Technical Design: In parallel with user-story reviews, our development and engineering group prepares the technical design solution. Aspects of the technical design include:

  • Analysis of necessary changes to the general solution architecture.
  • Review new interfaces for third parties.
  • Protection of system security posture.
  • Identification of required hardware components, operating systems, and network architecture.
  • Research supporting software technologies and libraries.
  • Determination of necessary changes to the data model(s).

Partnet convenes an internal design review to collect and incorporate final feedback on the designed solution from Software Developers, Test Engineers, Configuration Managers, Project Managers, security specialists, and support staff. This review focuses on specific items affecting the solution design, such as:

  • Ensuring the design minimizes development and maintenance costs.
  • Identifying opportunities for business-user configuration (i.e., administrative utilities that allow the Customer to configure and manage the software without new code).
  • Identifying changes with the potential to cause problems in other areas of the application.
  • Assessing the design’s extensibility, i.e., the capacity to accommodate future expansion.
  • Analyzing the proposed solution for portability and identifying opportunities for code reuse.
  • Determining whether the solution design can be thoroughly tested.

This internal review ensures the solution design is thoroughly vetted by multiple, cross-functional team members and perspectives—while providing a venue to identify improvements or necessary revisions.

In addition to regular weekly status calls, Partnet likes to conduct one or more Product Design Reviews with the Customer and broader stakeholder group until consensus on the proposed design is reached. Page wireframes and mockups will also be presented to document any proposed changes to the user interface.

The final milestone of the Solution Design stage is the Critical Design Review or CDR. The  CDR provides the Customer with an opportunity to evaluate the proposed design against its business requirements, and give final approval before software development begins. As part of the CDR, Partnet will discuss all completed design tasks and identify any outstanding tasks required by the designed solution.

Upon CDR approval, Partnet will develop and submits two formal documents:

  • Technical Specification
  • System Security Plan (SSP)

Step 4 – The Software Development, Testing, and Quality Assurance stage also begins upon CDR approval. Part 4 of our blog series, the importance of a defined Software Development Life Cycle, will cover the Testing and Quality Assurance Phase.

I hope that you have enjoyed Part 3 of our Blog Series, the Importance of a Defined Software Development Life Cycle. If you have missed any parts of the series, check them out at