Waterfall requires meticulous planning and evaluation, which in the early stages of the development process, maybe impossible. When developing software, not everything can be planned in advance, and problems must be expected at runtime. Initial assumptions are likely to change or may be completely unrealistic.
Waterfall teams are usually quite large, and members are not interchangeable - each is responsible for a specific job:
Developers play one of the most important roles. They should avoid mistakes during their work because a single defect can cause the whole project to restart.
Testers also play a significant role. Waterfall tests are usually performed in the final stages of implementation. That is why QA specialists must find all the bugs in the end products and return the software to the developers so that they can correct any defects.
Business analysts are responsible for developing adequate and working business strategies.
The project manager
The project manager is responsible for the quality of the final product. His main task is to manage the project, to distribute tasks among other team members, and to control the implementation.
The decision phase is the moment when a decision is made about what is required to be created as software. There are three stages to this phase:
Business case - what does the user want to achieve with the software? What are his expectations?
At this stage, the key value that can be attached to a future project is an adequate and in-depth analysis of customer requirements - what the software needs to do to meet the business purpose, make the system specification - what the software needs to do to meet customer requirements:
- What is the situation in business and software?
- What are the business cases that the software will cover/solve?
- What are the different decision strategies, and how feasible are they?
- What are your preferred solution strategies?
- What are the costs versus benefits?
- What are the probabilities, risks, and limitations?
- What will be the approach for meeting the requirements?
By now, the bulk of the work has to be done by consumers with the involvement of developers to clarify business cases. At this stage, the adequate roadmap of the project is created. Despite the lack of efficiency, consistent planning and documentation has advantages, especially for clients and stakeholders who like to know in advance what they get at the end of the engagement, as detailed documentation of project requirements, specifications, and planning form the basis of the waterfall, and the client starts the project with a specific idea of the price, scope and its term.
It is crucial to nominate appropriate end-users, business methodologists, and developers who have an adequate understanding of the business language. Management should support both parties by preventing the involvement of random people in the process and participate as a fair arbiter in potential conflict situations.
User requirements set out the collection of specifications and the system development strategy to ensure that the system meets the business requirements.
Functional requirements - what the system should do, e.g., to store client record details.
Non-functional requirements - they can be many - from the expected start time, the cycle of work, compliance from any you.
System processes - what kind of technical process is required to execute each business process.
External interfaces - what is needed for the external communication system, including:
Transactional interfaces - what is needed to communicate with users, e.g., screens.
Report Interfaces - What types of reports are required.
Application interface - what connections are needed to other software systems.
Consumers develop both Business Cases and Consumer Requirements. It is essential to find the boundary between user requirements and system specifications here, as there may be significant overlaps since both are developer-oriented.
At this stage, the business value of the project on the part of the teams is the correct identification of the key differences, namely:
User requirements are written by users with the help of the developer, while the developers write the system specification with the help of the user.
Consumer requirements express the required functionality concerning what the business wants to achieve, while the system specification expresses the feature concerning what software systems could provide.
Because the entire project is built on the original requirements, errors in the collection of requirements or documentation can cause a total mess in the process leading to reworking, if not discovered at later stages such as testing and implementation process as the quality assurance test is at the end of the project. Since everything is consistent, it must be done only to get started again.
Very often, consumer requirements are too ambitious, bordering on fantasy. On the other hand, systems may not always provide such functionality. It is often necessary to change the business processes of an organization that is related to the future system so that impact analysis is fundamental. It should, of course, be supported by the Management.
The design phase is when the various requirements are already described, and implementation decisions are made.
This phase focuses on how the software will be built:
- System design - how the software will be structured into components.
- Component Design - How each component will be structured.
The design phase of the system involves the specification of the system and its architecture. This is done by defining a series of components with what they do and how they interact with other components. These components may be other systems, interfaces, code modules, screens, databases, etc. It is not yet defined in detail how each component will work.
Design of components
The stage of component design is the detailed design of how each particular component will work and its integration with other components through its interfaces.
Very often, no documents are covering all design components, as different people design them. In many cases, these designs are made by the developers themselves.
Management needs to require such documentation, especially concerning external systems and the specifics, which include the fact that this often leads to changes in processes with external suppliers, contracts with them, etc.