The software development community has generally recognized that the waterfall method is fundamentally flawed as an approach to the software project lifecycle. The most recognized weakness in the approach is that system requirements are rigidly defined too early in the development lifecycle, which produces incorrect or incomplete requirements.
The poor requirements then create a situation of requirements volatility. Success or failure of a software project is largely dictated by the quality of the requirements, and the more volatility and inaccuracy in the requirements the more likely a project will go overtime, over budget or release the wrong functionality.
Given that some requirements will not, or cannot, be known at project inception, and, furthermore, those that are ‘known’ are often later revealed to be erroneous or to be expensive to We call this requirements process “The 4 Steps to Clarity”.
•Define the goals through use cases
•Determine the tasks to achieve those goals through activity diagrams
•Draft the corresponding GUI’s to visualize the system
•Publish the specification
The process more easily maintains the communication and understanding from stakeholder to programmer. End-users and executive management understand use case and activity diagrams, because the diagrams are written in their business language. Programmers understand the required system behavior from the activity diagrams. Everyone understands GUI’s because they use them every day.
Click on the file attachment below to read the complete article.
