So we already know that we want requirements documents that are consistent, complete, modifiable and traceable. We also have to deal with the individual statements within that. But of course, things are going to change and the requirements may not be complete or correct in your very first pass of getting information from the customers. This brings us back to the software lifecycle. Effective requirements management can only occur in the context of reasonably well-defined software process. This specialization is focusing on the requirements portion of the software lifecycle. But it's very important as a software engineer to have experience in the others as well. At least have an understanding of them. This understanding includes requirements, design, implementation, testing and management. As a requirements engineer, you are the person finding out what the customers really want, what the customers really need and relaying that to the designers or the developers. In design, we move to figuring out what the product will really look like. This starts with a high level design process. For example, you might decide that you need a software as a service application. Software as a service, is a software distribution model in which a third party provider hosts applications and makes those applications available to customers over the Internet, or through some very lightweight sort of browser thing. So once you have software as a service, you then need to ask yourself, what the product will look like and what models can be used. When I say models, I mean, architectural sort of models. Given your product, should you use a model view controller structure? Should you use a Template structure? Or, something else? This is high level design. Low level design then makes you think and write about what kind of language structures are needed. Should it be object oriented? Should it be procedural? Why? If you decide that it should be object oriented, then, what objects do you need to create? How are they linked? How does data flow from between activities? So on and so forth. Some of these goes into your requirements document but a lot of it, will go into a design document. Once you've come up with design, then you code, then you test and hopefully you get a good product out and then, you can manage it. So given that there's so much to do, there are different software requirements lifecycles that have been created. The very first was back in 1970. And perhaps surprisingly, it's also what we automatically fall back on whenever things start failing in whatever model we're trying to do. It's a danger. This model from 1970 is called the waterfall model. It has each step of requirements, design, implementation, testing and maintenance. And in waterfall, you follow each and every one of those in order. As you move through, you finish all of the requirements, move onto design, finish all of the design, move on to implementation and so on. In some later models, that were variations of the waterfall model, feedback loops were also added between stages. Within those feedback loops, there were also some prototypes. In the waterfall model, documentation is key. Planning is utterly important. The requirements documents created in the waterfall are very often huge. I'm talking hundreds or thousands of pages. You define absolutely everything. So for example, imagine that you're creating a library system, how do you define a book? I asked this to one of my students and they said, "Well, it's something that you can read." I said, "Well, I made a flip book of images that's really horribly drawn. Is that a book?" And she said, "Yeah, I guess so." Said, "Okay, my neighbor's kid drew this picture with some text. Is that a book?" "No." Even in defining something as simple as a book, it gets very challenging for both you and your customers to really understand. What are simple terms? In the document, you will also need to figure out what implicit requirements are. Explicit requirements are those that come directly from the customer. Implicit requirements are ones that you have to kind of figure out on your own. Sometimes you have to make assumptions. Mark them in your assumptions section of your requirements document. You also need to explain all reasons, alternatives, risk analyses etc, within your requirements and documents. Because of this, within the waterfall model especially, these documents take years to complete and they result in a lot of work. Oh hey, and guess what? Then, your customer changes their mind.
