| |
||
SENG 613Requirements Engineering in Agile Processes: Summary |
||
Summary |
Agile processes, collectively, share a few common traits. First, they are share the following values:
In other words, the aim to keep software development simple by allowing for ease-of-communication between project stakeholders (although the different methods allow fro different stakeholders), and for requirements to be defined more loosely than other process models. In contrast, the traditional waterfall model calls for the requirements to be set down in the official requirements specification before proceeding to the next phase, development. By following an iterative process, agile models allow for the requirements to emerge throughout the development process. The idea is that rather than petrifying the requirements in the early stages, changes are welcomed, even in the later development stages. Extreme Programming Extreme Programming (XP) is by far the most well know of the agile process models. The basic elements include pair programming, iterative development cycles, heavy user involvement (writing user stories, and functional and acceptance tests), and a disciplined approach to development. With regards to requirements engineering, XP has two main tools: user stories and the planning game. User stories are written by the user, who ideally is at least a part-time member of the development team. Resembling use cases, they are simple walk-throughs of a system task required by the business. A key here is that the author must learn to write effective stories. Inexperienced authors can be given guidance, and may be paired up with an experienced team member. The idea is to describe exactly what needs to be done, but now how to do it (that is left to the designers). The Planning Game is a broader view of the elicitation process, and involves two abstracted participants: development and business. Using the analogy of a game, the following are defined:
It is also worth noting that XP is very structured and disciplined. The day-to-day schedule is rigidly defined during a project. Since this relates more to design than requirements this is not discussed further here, but it is worth noting since the life cycle is very iterative. Crystal Crystal, in contrast to XP, is meant to be extremely light-weight. In contrast to methods like XP, Crystal does not seek to optimize the process of production. The priority is on productivity and habitability. Productivity here is defined as eliminating anything that slows development, and habitability simply means the survival of the development team (and their willingness to repeat the process). Another important aspect is that Crystal is a family of methods (starting with Clear and progressing to darker crystal colors), each of which is defined based on the size of the project. Thus it is scalable in terms of team size, and it also scales to fit projects in terms of risk factors. Relating to requirements, the tool of choice is the use case, which should be written by the user (ideally the customer should be at least a part-time member of the team). However, Crystal defines all of the various work products produced throughout the life cycle very loosely, allowing it to be applied to a broader spectrum of projects. If desired, user stories could be substituted here for use cases. SCRUM Somewhat like Crystal, SCRUM focuses on removing anything that impedes software development, and focuses on communication. The basic elements of SCRUM include:
SCRUM is meant to allow for changing requirements, and does so through "backlogs." At the lowest level, the sprint backlog consists of the tasks a team will implement for the sprint. At a higher level exist a startup backlog and a product backlog. The startup backlog is the initial features defined when the project begins. The product backlog is the ongoing collection of features, functions and bugs that will comprise the product once implemented. An item is removed from the product backlog when the related sprint backlog items are completed. Changing requirements are essentially handled by the fact that the sprints are short. Since the backlogs are prioritized, new or changed prioritized requirements call for reorganizing or adding to the backlogs. However, immediate changes cannot be handled easily since they involve altering the plan for the current Sprint. The unique aspect about SCRUM in terms of requirements is the short management planning phase. The initial startup backlog is generated quickly, and the first Sprint begins. There is no desire to establish a complete set of requirements in this early phase. Rather, it is expected that the requirements will become more clear and defined as the process continues. DSDM DSDM evolved from early Rapid Application Deployment (RAD) concepts. Two key concepts for DSDM are that "nothing is built right the first time," and that 80% of a products value can be built in the first 20% of the total development time. The process can be broken into 4 phases:
The last 3 phases overlap a great deal, and the process is iterative between them. A key aspect to DSDM is that while it is based on agile principles, it also has a good deal of the infrastructure of more traditional techniques. One aspect that is criticized in agile circles is that it involves more paperwork than other methods. Requirements are addressed firstly in the business cycle phase. As mentioned above, the model is very iterative, and thus the business study can be revisited in order to address changing requirements. Another aspect worth noting is that DSDM is defined in a fairly high scope, and is meant to have the potential of being combined with aspects of other agile methods, especially XP and RUP. However, despite that DSDM has existed since the early 1990s, it is not used extensively outside of Great Britain. RUP The Rational Unified Process (RUP) is a set of software engineering practices that provide guidance in streamlining development activities. It is designed to be an industry-wide process, from which components can be selected to fit the needs of a specific process. The goal is to provide a more productive process by unifying the team and using common processes communication and a common understanding of all tasks, responsibilities and artefacts. Rational Software, a commercial vendor and advocate of RUP, provides a set of tools corresponding to the various stages of the development lifecycle. It is worth noting here that it is arguable that RUP is in fact an agile process, partly because it is a proprietary set of methods and tools. Since roughly the same number of sources include it as exclude it, we have included it here without entering the debate. Thus, we assume here that it is an Agile process, but do not necessarily agree that this is the case.
The most unique aspect of RUP is that it provides a
set of tools for managing and tracking requirements. Since it is meant to
be an agile method, these tools are meant to allow a project to more
easily accommodate changing requirements.
|
Comparison |
Agile vs. Cleanroom These two processes differ in their main purpose. Cleanroom seeks to develop software of high quality software by eliminating sources of "contamination" early in the planning stages. To this end, a number of techniques are used including formal specifications and mathematical models. To is contradictory to one of the fundamental principles of agile processes, which insists that the process be kept as light weight as possible. The goal of delivering valuable, usable software as quickly as possible dictates a very different path than the goals of Cleanroom. Agile is also an iterative process and allows for the elicitation of requirements throughout the cycle, while Cleanroom calls for the requirements to be defined up front. One similarity the two methods share is that both seek to eliminate unneeded requirements. Agile does so by following very sort increments, preventing following a "wrong path" for a long period of time. Cleanroom seeks to accomplish the same, but through specification and models. Agile vs. QFD Agile and QFD share the common goal of catering to the needs of the customer, and providing software with the maximum value. They both call for prioritizing of requirements to this end. Aside from the tools used (such as QFD's house of quality), a main difference is that agile is iterative in nature. QFD sequentially calls for the requirements to be specified, then analyzed related to one another and market conditions, then implemented. Thus, is does not allow for evolving requirements in that the process is very long and involved, and changing requirements while in the middle of development would be very costly. A benefit of QFD over Agile is the accounting for market conditions in a competitive industry. Taking the end users priorities into account in creating the house of quality accomplishes this, but it may be argued that by continually involving the user in agile iterations the same result is achieved. Agile vs. SASD These two methods seem very different in every way. SASD calls for modeling of every aspect of the system under development, which contradicts agile light-weight principles. Agile methods often only call for work products "when it hurts," whereas SASD documents everything. This is a benefit for agile in terms of a project's time to market, but it is a benefit for SASD in other ways. One common critique of agile methods is that the lack of documentation becomes a problem if maintenance is required on a past system, and the original team members are unavailable. New developers have very little to work from. In contrast, under SASD there are many sources of information for the developer to get up to speed. Agile vs. JAD/PD The biggest similarity here is that both methods involve the user heavily, and concentrate on improving the designer-customer relationship. However, JAD goes a bit further and involves all stakeholders in the JAD session. Also, once the JAD session is over, the development team takes over and the user is not necessarily involved in the actual design. In this respect, Agile and JAD differ, but PD and Agile are similar. Both PD and Agile involve the user throughout the lifecycle, and in the actual design of the system. One obvious difference between Agile and JAD/PD is that Agile methods span the entire software lifecycle (at least most of them do). Agile also concentrates on staying light-weight and describe methods for design and implementation. In contrast, JAD does not address design and implementation, and because of the generic nature of PD it is not addressed here either.
|
References |
For references please see the presentation. |
|
 |
|||
|
Last Update:
12/8/02
|
|
|||
