Every piece of software started as an idea. As a requirement that needed to be satisfied. This is the untold beginning of the SDLC. A client or a manager asks their IT department to either improve current software for the company or come up with a new system. They then give that idea over to them people to see if it’s feasible. SDLC then has feasibility studies. “A feasibility study is designed to provide an overview of the primary issues related to a business idea. The purpose is to identify any “make or break” issues that would prevent your business from being successful in the marketplace. In other words, a feasibility study determines whether the business idea makes sense” (University of Wisconsin, n.d.). These studies see if this idea can be realized. They ask the 5 W’s to get a real life approach and framework for the idea that a system is being made for. Imagine if we wanted to make cars but didn’t ask who was going to make them. Imagine if we didn’t ask where the materials would come from. Feasibility studies make sure that the idea we have is not only possible, but good for the business. Feasibility studies can be broken down into many classes, but are usually organizational, economical, technical, and operational. Others can include cultural, legal/ethical, and schedule.
Once we see that our project has good feasibility, we move into the analysis phase. This happens in three steps. The first phase is requirements. When designing a car, an analysis has to be done to identify what the car will do. Imagine a car without blinkers. It just wouldn’t work. By defining the requirements of a system, it ensures that there are no business necessities that will be missed. A sales based business probably has a web component for sales as a requirement. They definitely need an inventory system of some sort. The requirements set the blueprint for the next part of analysis which is specification. Once the requirements are defined, the SDLC then asks how to satisfy those requirements. If were designing a sports car, we know we need some good tires. Now let’s specify which tires we want to use. Each requirement is given a specification as to how to satisfy it. By combining these specifications, we create the last step of Analysis: the system. We now have a framework of requirements covered by a network of specifications that is the beginning of our new system. Analysis should produce a system idea that gives the next phase its starting point. Design is the phase where the system takes the framework given and gets fancy with the actual design of the system. Design could also be called development. It’s where the fine touches are applied and the artwork of a system is made. It is important to note that a car is not a good analogy due to the face that often times cars are designed externally and then framework and internal components are applied. Software does not work that way. Once the development portion of design is done, it’s time for some testing. “Whether you write user stories on sticky notes on the wall, or use cases in a big thick document, your tests should be derived from and linked to those requirements.” ("Testing In The Software Life Cycle", n.d.). Testing can be done sooner based on the needs of the system, but it typically falls after development is done and there is a prototype. Testing can have its own requirements, but it should also satisfy all of the requirements already established as well. When