Throughout the project’s lifecycle, users should be able to test all intermediate outcomes. #
Customers are urged to define their needs as precisely as possible throughout the definition and design phases. This is challenging for two reasons. To begin, consumers have a limited understanding of the potential and impossibilities of information technology. They have no notion what is or should be feasible, nor do they know what they should or should not desire. Second, consumers often lack a thorough understanding of their own business processes.
Numerous IT initiatives include the computerization of an organization’s current business processes. Even though consumers have worked with processes for a long period of time, they often lack the ability to design their own business processes. They may function well in their own way, but cannot specify what that manner is. Exact process definition is required before developing software that will drive computerization. Customers’ complexity rises as a result of having to explain current procedures.
Determining Criteria #
Frequently, the list of criteria produced during the definition phase is incomplete. Programmers create software in accordance with this partial list during the implementation phase. When consumers encounter beta versions of new software, extra needs become apparent. ‘It looks nice, but could you perhaps fix it so I don’t have to constantly input my password?’ Programmers often lament that clients are unsure of what they want. Customers assert that, as experts, software developers should have identified what the customers want earlier in the process.
A comprehensive functional design was created for a software project that included the automated processing of applications for a web-based service. Numerous customer needs were compiled. After adding a few screen designs and flow drawings, the programmers could get started.
Managing Clients and Constraints #
Possibly as a result of the project’s severe time constraints or possibly as a result of the customer’s rather chaotic organization, the designers had forgotten to consist of a critical component: manual administration. The programme processed the applications. Because the applications were to be processed automatically, the programmers reasoned that no human administration would be necessary. This criterion was likewise omitted from the functional design.
When the programme was provided for testing, the client discovered that many apps had exceptions. These applications cannot be processed automatically and must be dealt with manually. However, the programme operated entirely automatically.
The waterfall project management requires testing of the project’s real outcome at the conclusion of the implementation phase. This is a late stage of development. Between the definition phase, design phase, and implementation phase, months or even more than a year may pass. If design flaws are found at a late stage of the project, it may be costly, if not impossible, to modify the programme without starting a new project completely. Given that it is virtually impossible to define all criteria in advance, a working approach that enables testing of (intermediate) outcomes is desirable.
Analyzing Requirements #
When comparing a number of potential software companies, a client inquired about the possibilities. One party was hesitant and questioned the feasibility of many of the customer’s demands. The opposing side was represented by an aggressive sales agent.
When a client inquired about the feasibility of a specific request, the sales person called his coders. ‘Can we create a function that does X?’ The programmer, who mainly thought in technical terms, said that anything was theoretically conceivable. Neither the programmer nor the sales person was concerned about project management feasibility (e.g., time, money, complexity, and risk).
The sales representative’s excitement outperformed the other party’s restrained demeanor. The client selected the sales representative’s aggressive offer. The newly acquired project was then handed over to a project manager and a team of programmers.
After some time, it became clear that the project was falling short of the customer’s expectations. This was partly due to the fact that the procedures were much more complex for the client than they looked initially. During a heated exchange between the two parties, the client said that the salesperson ‘had stated that functionality X would not be an issue.
