Objective:
The objective of this phase is to transform business requirements identified during previous phases, into a detailed system architecture which is feasible, robust and brings value to the organization.
Entry Criteria
The Design step of the SDLC process can begin when the Customer has approved (signed-off) the Functional Requirements Document.
Roles & Responsibilities
Customer – sponsor project and signs off team effort; review strategy and artifacts.
End User – Final users of the system.
Business Analyst – Provide requirements to the design team; review software design and artifacts.
Project Manager – Finalize data conversion strategy and test strategy; review software design and artifacts.
Technical-Architect, Tech-Designer, Design-Team – Design system architecture, software components, etc; Design walk-through.
Developer/Construction Team – Assist in finalizing data conversion strategy; review of the architecture and software components.
Testing Team/Tester – Assist with identifying and finalizing testing strategy; review of the architecture and software components.
Database Team – Assist with architecture design and data conversion strategy.
The most important role in this step is that of the Technical Architect as she aims to describe the required functions and operations such as screen layout, business rules, database layouts for the system in detail and also provide the architectural plan down to the physical level. A system architecture is not only a product of requirements but equally a result of organizational goals, architect’s experience and her technical environment.
Common Artifacts
System design documents reflect a systems architecture, the structure of the components of a program or system, their interrelationships and the principles and guidelines governing their design and evolution over time. Relationships are both run-time and non run-time and hence architecture is also expressed in terms of components and connectors. A system architecture is not only a product of requirements but equally a result of organizational goals, the architect’s experience and her technical environment. The system design provides overall guidance on system functions, performance requirements, security requirements, platform characteristics and should comprise:
- Business rules/application logic
- Interface design (app-to-app, app-to-db)
- User interfaces (GUI)
- Database design (data storage and db access)
Some additional artifacts/documents produced due to activities in this phase include :
- Data Dictionary
- Process diagrams
- Screen layout diagrams
- tables of business rules
- prototype/Proof-of-Concept
Test plan documents include the planned test activities that address user requirements including a description of the levels of tests that take place during development: integration, system security, and user acceptance tests, and the planning that is needed. The test environment is described in terms of milestones, schedules, and resources needed to support testing.
Training plans are meant to identify the users and how they will be trained on the new solution. Generally required for large projects.
Maintenance manuals include system procedures required to install, configure and support the system. They’re created during design phase and revised during construction and test phases and finalized at the implementation phase. Maintenance documents may contain emergency response procedures; backup arrangements, procedures, and responsibilities; and post-disaster recovery procedures and responsibilities.
User manuals contain the information necessary to employ a system or component to obtain desired results. Typically described are system or component capabilities, limitations, options, permitted inputs, expected outputs, possible error messages, and special instructions. A user manual is distinguished from an operator manual when a distinction is made between those who operate a computer system (mounting tapes, etc.) and those who use the system for its intended purpose.
Review (Revision)
Reviewed by the stakeholders other than one who prepares the document e.g. SDD is prepared by Technical architect and reviewed by all stakeholders (including those who inherit the plan) such as customer, PM, business analyst, developer, and tester. Revision may follow.
While reviewing, care should be taken to ensure that a system’s architecture never depends on a “particular version of a commercial product or tool. In case it has to then it should be structured such that changing to a different product is straightforward and inexpensive.” Courtesy of SEI Series in Software Engineering
Approval
Approval/sign-off required by customer, developer, tester and business analyst (all stakeholders including inheritors). Once approved the focus shifts to the next process step.
Exit Criteria
- Technical specifications (system design document) is completed and reviewed.
- The artifacts in the Master Test Plan associated with the Design step, are completed, reviewed and placed in the baseline.
- Work on the following documents has begun and is in progress.
- Maintenance manual
- Training plan
- Training manual
- User manual