The design phase starts with approved requirements as its initial input. Design elements are built for each requirement or requirement set. Design elements describe the software functions and features in detail. It usually includes functional diagrams, screen layouts, business rules, business process diagrams, and an entity-relationship diagram with a full data dictionary.

Design elements describe the software in sufficient detail that the developer can build the software with minimal additional input.

The technical specialists begin to translate the requirements into specific design solutions that will create the systems, features, and functions that are necessary to achieve the business and functional requirements. In the previous requirements definition phase, the focus was on defining specific capabilities desired by and in support of the organization, and its customers and end-users. In the system design phase the attention turns to defining systems and technical requirements.

This is also the phase where prototyping is likely to occur, as a prototype can serve as a bridge between requirements, design and development. A prototype can be as simple as a mockup of the proposed screen layouts, while a more complex prototype may have selected business rules instantiated as work flows within the application with active fields to capture and show data or information.

Once the project is approved and properly planned, for a fairly large project, requirements gathering, analysis and documentation can take 6 to 8 weeks to complete. In addition, the Design Phase can also take 6 to 8 week to complete, with perhaps a couple of weeks in overlap between the Requirements and Design Phases. What this means is the first 10 to 12 weeks of the project will be spent on requirements and design related activities before development can start. Add in another 2 to 4 weeks for initial project planning, and development should not be expected to start until 12 to 14 weeks into the project.

Short changing these activities in a Structured, Waterfall approach to development will almost always lead to Scope Creep, as the project team will not have taken sufficient time to fully gather, analysis, document and vet their findings. Scope creep is where the project expands beyond the approved budget and schedules - not a good thing to have happen.