Published by: Nuru
Published date: 16 Jun 2021
The Design Analysis Phase seeks to develop detailed specifications that emphasize the physical solution to the user's information technology needs. The system requirements and logical description of the entities, relationships, and attributes of the data that were documented during the Requirements Analysis Phase are further refined and allocated into system and database design specifications that are organized in a way suitable for implementation within the constraints of a physical environment (e.g., computer, database, facilities).
A formal review of the high-level architectural design is conducted prior to the detailed design of the automated system/application to achieve confidence that the design satisfies the system requirements, is in conformance with the enterprise architecture and prescribed design standards, to raise and resolve any critical technical and/or project-related issues, and to identify and mitigate project, technical, security, and/or business risks affecting continued detailed design and subsequent life cycle activities. During the Design Phase, the initial strategy for any necessary training is also begun. Estimates of project expenses are updated to reflect actual costs and estimates for future phases. In addition, the work planned for future phases is redefined, if necessary, based on information acquired during the Design Phase.
The analysis phase defines the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details. The purpose of the Analysis Phase is to formulate and formalize the system's requirements.
This is accomplished by establishing what the system is to do, according to the requirements and expectations of the system's end users. The modeling of these requirements is then performed in the form of business, data, event, and process models to demonstrate the understanding of the requirements. This enables the developers and customers to move forward under the same set of expectations with respect to scope and requirements.
In the Design/Build process, the Phase fee is nominal to cover the team’s time to complete a needs analysis, make necessary regulatory investigations, create a preliminary design and seek bidding resources for a preliminary budget. Having a pretty accurate, yet ballpark, estimate early in the process helps an owner obtain funding earlier. The information gained during the Phase is accurate and sufficient to take to a bank to secure financing.
Clients never get a separate bill for the Phase cost unless the project doesn’t come to fruition, then the fees are billed to cover the team’s time at a fraction of the cost of a full set of plans. Furthermore, if obstacles arise while a customer is planning to build a building that causes them to change their mind, it’s less risky to commit to a portion of the cost of the design while working through the initial process.
Additionally, having the flexibility to “tweak” the preliminary design so it fits within your budget is much more economical because you don’t have the engineering elements involved, yet. Those get explicitly defined in the Phase drawings.