When we think about the benefits and drawbacks of the waterfall model we just spent a few minutes discussing, relatively easy to use, very broad in scope as you can see. A detailed specificity of documentation because hopefully we would do a good job upfront with requirements design. A requirements analysis rather than gathering, and that leads into good design, a good documentation, but the drawback, and this is an important one for you to be aware of, assumes a static set of requirements that are captured before we actually go in and start building stuff. In other words, we talked to John once upfront, we don't go back to John again on the waterfall model. John's input is got at the beginning, and then we assume that John's mind is not going to change. And if at the end, six months later, we get John sprocket b plus and John looks at us and goes, wow that's kind of nice, but guess what? John's going to write another check, as we are going to start over again because John had no more input in the process. So we need to understand that the key issue with waterfall is that because of its linear progression, stage to stage, output equals input, going one to the next, we don't circle back, there's no iteration, there's no way to get feedback from John at various stages of the model. Because of that, we have to assume that the requirements will not change. That may or may not be a good idea. As a matter of fact, we often know that making assumptions tends to be a bad idea. And in this case, it may be, because John's mind may have changed, the business requirements may have changed. Speed of technology and the pace of deployment today is moving so quickly that six months is an incredibly long time to take to develop something. In those six months, the needs of the requirements, the needs of the requirements of the customer and the stakeholders may have changed. And if we're not aware of that, we may be putting out a product that is no longer necessary, or at least is not focused at the same level that it should be based on the new requirements. This is an issue with the waterfall model, and this is something we have to be aware of to just make sure in our mind we're keeping track of. Requirements gathering and analysis, as we said, is really about making sure we capture what the specificity of the customer, of the stakeholder is in their mind, we get that distilled down, we should capture that and document it in what's called a project charter. This is kind of standard project management, 101 stuff. The project charter is the document that gives us our marching orders, tells us exactly what we should be doing, lays out who is responsible, who is the customer, who are stakeholders, who is going to do the work, what we're going to do, and all the things that we are given permission to do at a very broad high level. We then fill in the gaps with something called a statement of work which will detail out the exact specifications we're supposed to meet, the timelines we're supposed to use, the resources, all those things will be documented in what's called a work breakdown structure, the WBS. These are all components of project management. These are all documents and tools we use to manage this lifecycle. So we see these things coming together. We do requirements definition, as we've been discussing. We go through functional and nonfunctional requirements that are documented from the customer, elements of both may be important. Talk about security requirements being incorporated as early and as often as possible. The security requirements will be specified in the nonfunctional requirements area. Your security requirements will be, we need to make sure that the system is going to use this kind of an algorithm or provide this kind of protection or whatever it may be. Functional requirements would be things like, we should be able to print, we should be able to open up a web browser and start a session using HTTP, whatever it may be. Those are functional requirements, things we want it to do; the nonfunctional requirements are going to be things like what kind of security we need and how we're going to achieve that. Then system design, as we said, lays out the general design document. This is just a review of all the stages we've talked through over the last few minutes. We will often walk through those in iterations looking at various aspects. We review them as you can see here before we actually go in and start constructing in the implementation area. Implementation is where we actually are building a software or a system. Remember we said the S is interchangeable, could be a software or system development lifecycle. We're just using software as an example here, but it can be either one. Functional design specifications are actually translated here, and we get something that's going to effectively be the individual module units of functionality that we will integrate and test to build the whole system, coming out of this phase. Integration occurs when multiple functions or units are effectively put together, and as we talked, that will take sprocket a, sprocket b, sprocket c parts, integrate them all together, come up with our overall sprocket, sprocket b plus, and that's what we do in integration. And then testing, of course, allows us to be able to go in and validate that the integration is good. We validate by unit testing, integration testing and system testing. Unit testing as I said is going to be the individual modules being tested on their own. Integration testing is putting them together to make sure that they work. System testing is the entire sprocket finished up after full integration is done to make sure it works the right way. So we're testing in multiple levels. We're stepping through individual build and then system level testing to ensure at each step that things work, security requirements are met, functional and nonfunctional requirements broadly are met, and we understand how the entire system, end to end is going to behave when we go operational. We turn it on in effect and deliver it.
