Threaded Discussions: minimum One paragraph of 5 sentences or more per question. Not a paper. Place answer with the corresponding question.
The Traditional Waterfall Method/Model has been much maligned. As the online lesson states, it's a VERY common engineering project management approach, and it's also favored by the old-school project managers (the PMI's PMP is built around it). It's also favored by the accountants/finance folks because it's super easy to track spend, progress, etc.
But, just like the online lesson states, it didn't work well for many kinds of software (SW) development projects.
Question. Is the Traditional Waterfall Method/Model really that bad? Should it never be used? Why?
If there is ever one very contentious part of a SoftWare development project it's the "Requirements". The Requirements are supposed to capture "what" the system is supposed to do, so the engineers can figure out "how" to build it, and then build/test and deploy it.
If you mess up the Requirements, then your project is doomed - even before it gets going. And, even if you get the Requirements perfect (super hard to do), the customer/market can change on you in the middle of your project ... making your Requirements invalid. This is one of the reasons Agile methods are preferred for some types of projects.
A MAJOR problem in getting the Requirements correct is that people tend to be biased - i.e., they seem to believe that customers are like them, so if they like a feature, then customer should like it too - or the customers should be made to like it (think of Windows Vista, ugh).
Question. What are some approaches that companies take (using either the Traditional Waterfall or Agile) to gather the user Requirements so that bias is reduced?