The Quality of Requirements in Extreme Programming Richard Duncan Mississippi State University
Total Page:16
File Type:pdf, Size:1020Kb
The Quality of Requirements in Extreme Programming Richard Duncan Mississippi State University Extreme Programming (XP) is a software process methodology that nominates writing code as the key activity throughout the development process. While at first glance this sounds chaotic, a disciplined group utilizing XP performs sufficient requirements engineering. This paper describes and evaluates the quality of requirements gener- ated by an ideal group using XP and discusses how the XP process can assist or hinder proper requirements engi- neering. ent throughout the development, that cus- stories and acceptance tests, while the pro- xtreme Programming (XP) is a hot, tomer can be considered part of the speci- gram parameters are dealt with in release Enew software process methodology for fication since he or she is available to and iteration planning. medium to small sized organizations. It is answer questions and clear up ambiguity. The product parameters are chiefly designed with requirements drift as a fun- The XP life cycle is evolutionary in communicated through stories. These sto- damental occurrence to be embraced, nature, but the increments are made as ries are similar to Use Cases defined in rather than dealing with it as a necessary small as possible. This allows the customer UML, but are much simpler in scope [4]. evil. XP nominates coding as the key activ- (and management) to see concrete Developing a comprehensive written spec- ity throughout the development process, progress throughout the development ification is a very costly process, so XP uses yet the methodology is based on econom- cycle and to respond to requirements a less formal approach. The requirements ics [1]. changes faster. There is less work involved need not be written to answer every possi- Barry Boehm presented that the cost in each release, therefore the time-con- ble question, since the customer will of change grows exponentially as the proj- suming stages of stabilization before always be there to answer questions as they ect progresses through its lifecycle [2], releases take less time. With a longer itera- come up. This technique would quickly Stuart Faulk reiterates this by stating that tion time it may take a year to incorporate spiral out of control for a large develop- the relative repair cost is 200 times greater a new idea: with XP this can happen in less ment effort, but for small- to medium- in the maintenance phase than if it is than a week [1]. sized teams (teams of fewer than 20 people caught in the requirements phase [3]. XP A fundamental of XP is testing. The are most often reported) it can offer a sub- challenges that this is no longer the case. customer specifies system tests; the devel- stantial cost savings. It should be noted, While it is more expensive to modify code opers write unit tests. This test code serves however, that an inexperienced customer than to modify a prose description, with as part of the requirements definition – a representative would jeopardize this prop- modern languages and development tech- coded test case is an unambiguous medi- erty. niques it is not an exponential increase. um in which to record a requirement. XP The programmers then take each story Instead, Beck asserts that the cost for calls for the test cases to be written first, and estimate how long they think it will change levels out. Rather than spend extra and then the simplest amount of code to take to implement it. Scope is controlled effort in the requirements analysis phase to be written to specify the test case. This at this point – if a programmer thinks that nail down all requirements (some of which means that the test cases will exercise all the story, in isolation, will take more than will become obsolete through require- relevant functionality of the system, and two weeks to implement, the customer is ments drift anyway), accept that changes irrelevant functionality should not make it asked to split the story. If the programmers due to incomplete requirements will be into the system [1]. do not understand the story they can dealt with later. XP assumes that lost This paper describes and evaluates the always interact directly with the customer. resources in rework will be less than the requirements engineering processes associ- Once the stories are estimated, the cus- lost resources in analyzing or developing ated with the XP paradigm. tomer selects which stories will be imple- to incomplete requirements 1. mented for the upcoming release, thereby The primary vehicle for requirements The XP Requirements driving development from business inter- elicitation in XP is adding a member of Engineering Process ests. At each release, the customer can the customer’s organization to the team. evaluate if the next release will bring busi- Harwell et al. break requirements into two This customer representative works full ness value to the organization [1]. types – product parameters and program time with the team, writing stories – simi- Each story to be implemented is bro- parameters. A product parameter applies lar to Universal Markup Language (UML) ken up into tasks. A pair of programmers to the product under development, while Use Cases – developing system acceptance will work to solve one task at a time. The a program parameter deals with the mana- tests, and prioritizing requirements [4]. first step in solving a task (after under- gerial efforts that enable development to The specification is not a single monolith- standing, of course) is to write a test case take place [5]. The customer who becomes ic document; instead, it is a collection of for it. The test cases will define exactly a member of the XP team defines both user stories, the acceptance tests written by what needs to be coded for this task. Once product and program parameters. The the customer, and the unit tests written for the test cases pass, the coding is complete product parameters are defined through each module. Since the customer is pres- [1]. Thus the unit tests may be considered June 2001 www.stsc.hill.af.mil 19 Software Development Methodologies a form of requirements as well. Every test attributes. write test cases for it. These test cases (across the entire system) must pass before Unambiguous, Correct, and Under- become a permanent part of the specifica- new code may be integrated, so these unit- standable: Since the customer is pres- tion/test suite. Customers (with the help test requirements are persistent. This is not ent, ambiguity and problems understand- of the XP coach) will also make sure that to say that simple unit testing counts as an ing the requirements are generally mini- the specification is verifiable, since they executable specification – but XP’s test- mal and easily solvable [1] . Requirements know that they will have to write test cases for it. driven software development does record are correct if and only if each represents an Annotated by Relative Importance: the specific requirements of each task into actual requirement of the system to be The customer defines which user stories test cases. built. Since the customer writes the stories they wish implemented in each release. The final specification medium for from business interests, the requirements Hence, each requirement is annotated by product requirements is the customer should all be correct. With so much relative importance at this time – the cus- acceptance tests. The customer selects sce- responsibility and freedom, clearly the tomer should ask for the highest-priority narios to test when a user story has been selection of an appropriate customer rep- stories to be implemented first and pro- correctly implemented. These are black- resentative is crucial to the success of the grammers are never left guessing priorities. box system tests, and it is the customer’s project. Even if the customer does not Achievable: Since each release provides responsibility to ensure that the scenarios know exactly what he or she desires at the some business value, a portion of the sys- are complete and that they sufficiently start of the project, the evolutionary tem found to be unachievable should not exercise the system [6]. These acceptance nature of XP development leads to a sys- leave the customer with a very expensive tests serve as an unambiguous determiner tem more in line with the customer’s yet unusable piece of technology. If the as to when the code meets the customer’s needs. high-risk piece is important, it will be expectations. Modifiable: The XP lifecycle allows implemented first, in which case the changes to the requirements specification unachievable component should be found How XP Rates at nearly any point in system develop- quickly and the project aborted relatively The XP requirements engineering process ment. The specification exists as a collec- inexpensively. If it is less important, then can be analyzed by considering the 24 tion of user stories, so the customer can the system may be delivered in useful form quality attributes for software require- switch out one future story for another without it. ments specification (SRS) proposed by with little impact on existing work. Since Design Independent: Design inde- [7]. Davis et al. propose that a quality SRS the planning, tests, and integration are all pendence is a classic goal for requirements, is one that exhibits the 24 attributes listed performed incrementally, XP should but today’s object-oriented development in Table 1. Rather than applying these receive highest marks in modifiability. Of methods recognize that design independ- metrics to a given document, they are used course, work may be lost in this ent requirements are often impractical. here to measure the requirements that the- changeover, but with XP the programmers Portions of the requirements (such as the oretically come out of the XP process.