Requirements and the Software LifecycleAny Good Software Development Process should haveTraditional Software Process ModelsThe Waterfall ModelThe Waterfall Model (Royce 1970)The Waterfall ModelWaterfall Model ProblemsIncremental DevelopmentPrototypingThe Spiral Model (Boehm, 88)Spiral Model’s 4 SectorsThe Spiral Model’s propertiesThe Iterative Approach (Kruchten, 95)The Iterative Approach: Lifecycle PhasesThe Iterative Approach: Lifecycle PhasesSlide 16Slide 17Slide 18The Iterative Approach: IterationsSlide 20The Iterative Approach: DisciplinesSlide 22Slide 23Requirements in the Iterative ModelKey Points1Requirements and the Software Lifecycle • The traditional software process models• Waterfall model• Spiral model• The iterative approachChapter 32Any Good Software Development Process should haveCollect + Analysis: Identify what the system should doDesign:Determine what is the best way to do itImplementation + Test:Build the system correctly3Traditional Software Process ModelsEffective requirements management can occur only within the context of a reasonably well-defined software process that defines the full set of activities your team must execute to deliver the final software product. In order for your team to reach its goal, your team's software development process should define who is doing what, when and how.4The Waterfall Model The waterfall model is sequential: •Software activities proceed logically through a sequence of steps. •Each step bases its work on the activities of the previous step. The waterfall model was widely followed in the 1970s and '80s and served successfully as a process model for a variety of medium- to large-scale projects.5The Waterfall Model (Royce 1970)6The Waterfall Model1. Collect major requirements (hardware, software & human parts), define clearly, and document them. 2. Design & plan how to meet the req.3. Code the system and test units, 4. Link all parts, install and test as a whole5. Corrective, adaptive & perfective maintenance7Waterfall Model ProblemsInflexible partitioning of the project into distinct stages makes it difficult to respond to changes in customer requirements.Therefore, this model is only appropriate when •the requirements are well-understood and •changes will be fairly limited during the design process. Long process and no intermediate builds, but•Stakeholders need to gain confidence•Designers and developers need confirmation that they are building what is needed and wanted.Some team members are idle (because they are not involved in the current development phase)•We need to put people to work on several phases at once8Incremental DevelopmentNotice thatSuccessful large system is originally successful small project that grows incrementally.Two incremental models:•Spiral Model•Iterative approach9PrototypingPrototype is a system or partially complete system that is built quickly to operate some aspects of the requirements.Thus, it may have poor performance, less functionality, limited data processing capacity, and low quality.10The Spiral Model (Boehm, 88)11Spiral Model’s 4 Sectors1. Objectives setting: specific objectives for the phase are identified.2. Risk assessment and reduction: risks are assessed and activities put in place to reduce the key risks.3. Development and validation: a development model for the system is chosen which can be any of the generic models.4. Planning: the project is reviewed and the next phase of the spiral is planned.12The Spiral Model’s propertiesRisk-driven and incremental development process Process is represented as a spiral rather than as a sequence of activities with backtracking.Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design loops in the spiral are chosen depending on what is required.Risks are explicitly assessed and resolved throughout the process.The main advantage of this process model is the availability of multiple feedback opportunities with the users and customers.13The Iterative Approach (Kruchten, 95)In the iterative approach, the lifecycle phases are decoupled from the logical software activities that occur in each phase, allowing us to revisit various activities, such as requirements, design, and implementation, during various iterations of the project.14The Iterative Approach: Lifecycle PhasesIt has 4 phases1. Inception: scope & purpose of project2. Elaboration: analysis of the req. and the structure of the system3. Construction: writing the code4. Transition: installing the system15The Iterative Approach: Lifecycle Phases1. Inception phase•The team is focused on understanding the business case for the project, the scope of the project, and the feasibility of an implementation.•Problem analysis is performed, the vision for the solution is created, and preliminary estimates of schedule and budget, as well as project risk factors, are defined.16The Iterative Approach: Lifecycle Phases2. Elaboration phase•The requirements for the system are refined, an initial, perhaps even executable, architecture is established, and an early feasibility prototype is typically developed and demonstrated.17The Iterative Approach: Lifecycle Phases3. Construction phase•The focus is on implementation. •Most of the coding is done in this phase, and the architecture and design are fully developed.18The Iterative Approach: Lifecycle Phases4. Transition phase•Beta testing•The users and maintainers of the system are trained on the application.•The tested baseline of the application is transitioned to the user community and deployed for use.19The Iterative Approach: Iterations20The Iterative Approach: IterationsWithin each phase, the project typically undergoes multiple iterations. An iteration is a sequence of activities with an established plan and evaluation criteria, resulting in an executable of some type.Each iteration builds on the functionality of the prior iteration; thus, the project is developed in an "iterative and incremental" fashion.21The Iterative Approach: Disciplines22The Iterative Approach: DisciplinesIn the iterative approach, the activities associated with the development of the software are organized into a set of disciplines. Each discipline consists of a logically related set of activities, and each defines how the activities must be sequenced to produce a viable work product (or artifact).Although the number and kind of disciplines can vary, based on the company or