You are on page 1of 8

focus 2

requirements and agility

Agile Requirements
Engineering Practices:
An Empirical Study
Lan Cao, Old Dominion University

Balasubramaniam Ramesh, Georgia State University

T
he rapidly changing business environment in which most organizations oper-
An analysis of data
ate is challenging traditional requirements-engineering (RE) approaches. Soft-
from 16 software
ware development organizations often must deal with requirements that tend
development to evolve quickly and become obsolete even before project completion.1 Rapid
organizations changes in competitive threats, stakeholder preferences, development technology, and time-
reveals seven agile to-market pressures make prespecified requirements inappropriate.1
RE practices, along Agile methods that seek to address the challenges zations, we sought to answer two questions: What
with their benefits in such dynamic contexts have gained much interest RE practices do agile developers follow? What ben-
among practitioners and researchers. Many agile efits and challenges do these practices present?
and challenges.
methods advocate the development of code without
waiting for formal requirements analysis and design How we conducted the study
phases. (In this article, “requirements engineering” Carolyn Seaman argues that software engineer-
means the same thing as “requirements analysis,” as ing’s blend of technical and human-behavioral as-
is common in the RE literature.) Based on constant pects lends itself to qualitative study.3 Qualitative
feedback from the various stakeholders, require- methods let you delve into a problem’s complexity
ments emerge throughout the development process. and develop rich, informative conclusions. For a rel-
Evolving requirements in a time-constrained devel- atively “uncharted land”4 such as agile RE, a multi-
opment process cause the RE process for agile soft- site qualitative case study approach is appropriate.
ware development to differ from that for traditional To understand how and why agile RE differs
development. from traditional RE, we collected data from 16
Few studies report on RE in agile development organizations that employ agile approaches. (The
(see the related sidebar). Proponents present agile “Study Participant Characteristics” sidebar pro-
methods as a panacea for all the ills of software vides details on the organizations. To protect their
development, often focusing on the proposed prac- identities, we use pseudonyms.) These organizations
tices’ possible benefits.2 Critics, on the other hand, are in three major US metropolitan areas.
have focused on the challenges that agile practices The study had two phases. In the first phase,
might present. In contrast, we’ve been systemati- we conducted cases studies in 10 organizations
cally studying the agile practices that developers ac- that characterize themselves as involved in agile or
tually follow. Using a qualitative study of 16 organi- high-speed software development. Although these

60 IEEE Soft ware Published by the IEEE Computer Society 0 74 0 -74 5 9 / 0 8 / $ 2 5 . 0 0 © 2 0 0 8 I E E E

Authorized licensed use limited to: KING SAUD UNIVERSITY. Downloaded on October 4, 2009 at 06:56 from IEEE Xplore. Restrictions apply.

“Just-in-Time Requirements Analysis—the Engine That Drives ments negotiation. In each organization. organizations didn’t explicitly follow any specific responses included information on multiple projects “brand” of agile methods. Restrictions apply. benefits. Erickson. www-di. This approach is exploratory rather than ment and consulting. we identified larger patterns by systematically available. 2002. the agile-RE literature is limited to a few high-visibility Time-Constrained Requirements Eng. “Extreme Programming Modified: Embrace Require- whether developers are actually using the practices that agile ments Engineering Practices. Sillitti et al. Grünbacher and C. “Agile Modeling. theses. no. “Requirements That Handle Ikiwisi. agile ing top management. We performed assurance personnel. Hofer. Jepsen. and K. vol. 4. as is common in qualitative research. Yoffie. and project managers. “Managing Uncertainty in Requirements: A Survey in Documentation-Driven and Agile Companies.” Proc. J. In the second phase. we focused Results from preliminary data analysis guided fur.A. vol. synergistically. 99–102. 2000. Touchstone. 308. environment is different. 41–61. We collected data through confirmatory. “Requirements Honesty. 33.8 and using cooperative strategies for RE.1 others 1. phase. Cusumano and D. Two coders cused on current or recent project experiences. we used the grounded- Scrum.” Proc. 2002. . 2002. case studies (such as at Microsoft and Netscape)6 and ex.pdf. pp. and Rapid Change. pp. semistructured interviews.4 a well-established qualitative- six organizations that used XP. and selective and documentation review. It lets you develop insights about The participating organizations represent a rich a problem under investigation. senior axial coding to uncover relationships among prac- architects.7 Eng. Although most interviewees fo. Related Work on Requirements Engineering in Agile Development Although critics argue that agile software development References approaches simply repackage established techniques. 2002 Int’l Workshop ment. and Extreme Programming: The State of Research. data and labeled them as agile RE practices.13 Some of 12. from previous experience. coding. without prior hypo­ mix of fields from healthcare to software develop. Scrum. and F. Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft. F. pp.pdf. Recent studies have identified several problems that could 9. 2003. K. A. 13.br/~julio/tcre-site/p5. “Time Constrained Requirement Engineering—the Cooper- ative Way. 8. 138–141.puc-rio. H. (RE 02). 8th Int’l Workshop Principles of Software these approaches might help mitigate the challenges that our Evolution. perience reports. 2009 at 06:56 from IEEE Xplore. comparing the practices. M.4 However. it isn’t clear Database Management. Maurer. IEEE Press. A. Araujo and J.br/~julio/tcre-site/p3. pp. from a requirements honesty viewpoint. or agile RE challenges. 70–77.. Requirements methods prescribe. participant observations.2. Ribeiro. 7. 2005. Merisalo-Rantanen. tices among the 16 organizations. Symp. 11th IEEE Int’l might negatively affect the requirements principles of pur. Pinheiro.” In spite of the centrality of effective RE in agile develop.5 4. “Is Extreme Programming Just Old Wine in New Bottles: A Comparison of Two have recognized that requirements engineering in an agile Cases. no. and we compared the January/February 2008 I E E E S o f t w a r e  61 Authorized licensed use limited to: KING SAUD UNIVERSITY. and M. 32. Negotiation. software developers. Also. pp. Tuunanen. 1999. research method.C. IEEE CS Press. about how real agile projects conduct RE. Springer. study identified (see the main article). they followed RE prac.2. Springer.” J.inf.” Computer. Eberlein. In selective cod- requirements documents such as story cards when ing. no.” Proc. 3rd Int’l Conf. “Embracing Change with Extreme Programming. 3rd Int’l Conf. O.9. 88–99. B. puc-rio. 17. www-di. Extreme Programming and ing aspect-oriented concepts. vol. 12th IEEE Int’l Workshops En- as Extreme Programming (XP) advocate RE throughout the abling Technologies: Infrastructure for Collaborative Enterprises (Wetice development life cycle in small. (XP 02).10 establishing traceability. 2002. pp.10 These approaches include using explicit require. informal stages. pp. no. 140–143.inf. 5. each organization tices that were similar to those suggested by agile was the unit of data analysis. (TCRE 02). product managers. 4. includ. appropriateness. result from the lack of detailed requirements specifications8 10.E. Rossi. Boehm.7 Much research has focused on assessing 6. we identified groups of we interviewed a variety of stakeholders. C. pp. Extreme Programming and Agile lems. “Towards an Aspect-Oriented Agile Re- quirements Approach.. 2002 Int’l Workshop Time-Constrained Requirements Eng. 303–310. IEEE Joint Int’l Conf.3 For example. Lee. T. IEEE Press. agile development 3. 2000. p. (TCRE 02). p. P.” J. axial. posefulness. So. Beck et al.” Proc. Siau. 2005. Software Metrics (Metrics 05). methods such as Extreme Programming (XP) and To analyze the data. Data analysis involved open. on similarities and differences in agile RE prac- ther data collection. 2002. 03). We conducted additional We conducted data analysis and data collection interviews to gain clarification on some concepts.” Proc. IEEE CS Press. or both. Computer. We also reviewed tices. Processes in Software Eng. 2005. and improving agile requirements approaches as defined in 7. Lyytinen. agile methods such 2. Paetsch. Downloaded on October 4. 2005. 10. “Complementing XP with Requirements and suggest several approaches to address these prob. F. 11. vol. K. Nawrocki et al.” Proc. COTS. To generate insights from this analysis. quality RE benefits..4 In open coding. and truthfulness. Little is known Development. and challenges.” Proc. “Requirements Engineering and Agile Software Development. we collected data from theory method. 16. (XP 02).12 incorporating an explicit RE Agile Processes in Software Eng. 16. J. Agile Software popular agile methods such as XP and Scrum. 105–108.” Proc. Database Management. J.11 incorporat- the Planning Game. M. their separately coded the data.

EbizCo Packaged software development. manager. CIO. 6 Senior manager. and home healthcare providers. architect. and Offers forecasting tools. and quality assurance specialist AgileConsult Software consulting. 4 Director. and developer Entertain Film and television industry. 2 Senior developer and project lead Offers consulting services on agile software development. o rg /s o f t w a re Authorized licensed use limited to: KING SAUD UNIVERSITY. project manager. product Offers software for Internet security. 2 Senior software engineers Offers information systems solutions to hospitals. Restrictions apply. the organizations. chief financial officer. operations officer. companies online. user Carries out human-resource administration for other interface designer. manager. specifications pated in the study. and Internet site developer Transport Transportation and logistics industry. chief Helps brick-and-mortar companies develop a Web presence. quality services for business-to-business communication. physicians’ offices. NetCo Network software consulting. We then recoded the data to arrive at a set Our study identified seven agile RE practices in of practices common across these organizations. project manager. Agile RE practices cussions. 4 Project manager. and Web developer ServeIT Consulting and services. 3 Human-resources manager. 6 CIO. and Web developers HealthInfo Healthcare information systems. Web designers. 7 Project manager. project manager. 2009 at 06:56 from IEEE Xplore. Offers high-tech indexing and search tools online. results. Offers services online. 5 Software engineer. SecurityInfo Security software. c o m p u t e r. lead developers. 6 Senior manager. Study Participant Characteristics Organization No. VP of technology Offers an online service to help customers select health operations. of employees pseudonym Industry and products interviewed Organizational roles represented Enco Energy and communications. marketing specialist. 2 General manager and senior software Offers services on developing network systems architect and architectures. agile RE aims to 62 IEEE Soft ware w w w. and developers Venture Across industries. senior Web developer. and quality assurance specialist HuCap Administration. Downloaded on October 4. The agile RE practices and their respective bene- fits and challenges we present reflect the perceptions Face-to-face communication over written and beliefs of the software developers who partici. Differences were resolved after detailed dis. Offers online services. 3 VP of operations. Internet site Offers insurance online. senior developer. 1 Senior software architect Offers software that handles financial transactions. project manager. project lead. architect. BankSoft Banking information systems. We studied the part of the firm that offers consulting quality assurance manager. senior manager. According to the participants. director of marketing insurance and utility services. software developer HealthCo Healthcare and utilities. research. 6 President & CEO. 1 Software developer Offers online payments. . 1 Senior software developer Offers e-business connections and transactions. FinCo Online financial-transaction support. and Web developers ManageRisk Across several industries. assurance specialist. quality assurance manager. and Web developers TravelAssist Transport and tourist industry.

because. However. Many partici- who serves as a surrogate customer to discuss the pants reported that establishing trust between the requirements and alternative solutions. In most organizations. RE is often intertwined with design. especially when their require­ments In 14 organizations. Customers familiar with a the need for frequent communication. So. or their own understanding of the software High-level RE occurs at the project’s beginning. the development team ■ Informal communication obviates the need for acquires a high-level understanding of the appli- time-consuming documentation and approval cation’s critical features. site customer representation is difficult. but neat. the project pany policy mandates formal documentation. only two projects had a full-time. even for such security-critical applications. All 16 organizations rely extensively on two customers who didn’t have high confidence in face-to-face communication between the team agile methods weren’t “good” customers in terms and the customers. a company that de­ grate the requirements through negotiations with RE process. ■ Customers can steer the project in unanticipated Iterative requirements engineering di­rections. they use simple techniques had only part-time access. in several meetings to discuss requirements. ments are discussed at a greater level of detail. rather than create extensive doc. projects that can’t achieve such high-quality inter. Also. instead. requirements aren’t pre- evolve owing to changes in the environ­ment defined. achieving consensus or compromise or trust developers discuss requirements in detail with the in the short development cycle is challenging. The project Customers sometimes find it difficult to under- team meets frequently with the product manager. is a primary source of requirements. cluding customer availability. the projects we studied. onsite product manager. stand or trust the agile RE process. worse customer meets with the development team to pro- still. [but] I want something different. initially include high requirements volatility. each development cycle. the project manager suggested that the Benefits. mentation plan. require- customer and team depends on several factors. none of which is specified formally. find it difficult such as user stories to define high-level requirements. “Everything is am. at NetCo. solution. During this process. development team must spend extra effort to inte- One exception is BankSoft. which doesn’t biguous. Formal customer and developer. During this brief process. incom- plete knowledge of the technology used in develop- Challenges.effectively transfer ideas from the customer to the Many organizations reported that achieving on- development team. and trust between the customer and ten results in a set of fine-grained requirements and the developers. they emerge during development. this approach poses risks such as require. they [the customers] are going to say. This activity of- tomer groups. that’s ect included three customer representatives. vide detailed information on a set of features that The effectiveness of communication between the must be implemented. The the agile customers before and/or during development. the others sometimes of specifications. and sometimes even an imple- stages. with each concerned about different aspects to understand anchors for further discussions with customers. their agile RE practice prefers face. as traditional development process might not under- a BankSoft participant noted. if you give me exactly what the customers produce detailed requirements. product managers acted as Customers to-face communication over written specifications. Restrictions apply. One NetCo proj- want. Most organizations shun formal documentation surrogate customers. each group. January/February 2008 I E E E S o f t w a r e  63 Authorized licensed use limited to: KING SAUD UNIVERSITY. At each cycle’s start.” only one had a positive opinion of agile RE. consensus among cus. These short. In most of umentation. Downloaded on October 4. development without spending much time on RE especially with evolving requirements. For example. Several participants reported that this ment. the ments that are inadequately developed or. in order face-to-face communication with the customer to achieve consensus. stand or trust the agile RE process. . which are perceived as unnecessary. which is essential for agile documentation of requirements doesn’t eliminate RE. and customers who can clearly define the re- practice’s effectiveness depends heavily on intensive quirements only when they see them (“I’ll know it interaction between customers and developers. Instead. can be challenging. abstract descriptions serve mainly as When more than one customer group is in- volved. The participants reported these of their ability to provide relevant information and benefits: feedback. Reasons for commencing processes. For when I see it”). In this project. 2009 at 06:56 from IEEE Xplore. How. agile RE continues at action. The of the system. in. velops banking-industry software and whose com. especially during the project’s early a preliminary design. wrong. manager forced customers to physically participate ever.

Restrictions apply. as happened with HuCap. which uses formal re- new members into the development team. reported that their prioritization is based predomi- The second challenge is minimal documentation. the customers aren’t clear at the outset about The participants identified at least two impor- their requirements and are willing to explore the tant differences between traditional and agile RE ways in which the evolving system can help their in requirements prioritization. Prioritization often happens during the challenges. planning meetings at the beginning of each cycle. 64 IEEE Soft ware w w w. “we were delivering high value in agile development. performance early in the process results in major is- derstandable because of the immediate access to sues as the system matures and becomes ready for changes often customers and their involvement in the project when larger-scale deployment. orities helps the development team better meet cus- ware. Customers identify the features that pro- project scope is subject to constant change. according requirements. priority features early so that customers can real- issues. in traditional RE. covery of potentially interesting solutions. a variety of problems. These include. every step of the way. Customers often First. In contrast. Be. nantly on one factor—business value as the cus- When a communication breakdown occurs owing tomer defines it. … I think the agile [RE] lent itself to … a very robust rich implementation of features … on the evolving system. c o m p u t e r. Benefits. Because the dencies. safety. and induct tomer needs. in traditional business goals. rapid changes to requirements. All the organizations prioritize their feature lists repeatedly during de- version of the . and is based on the known user stories.” quirement specifications. as scalability. For example. they can provide business rea- complexity. particularly ments and the system design. o rg /s o f t w a re Authorized licensed use limited to: KING SAUD UNIVERSITY. Participants reported three major ment cycle. requirements are typically prioritized once. costs. Benefits. cost. agile RE practitioners uniformly for such projects could be challenging. requirements are clearer and more un. portability. The first is cost and schedule estimation. One common exception is the focus on ease of use. In many organiza. In contrast. also benefits from frequent The third challenge is neglect of nonfunctional reprioritization of requirements because. especially when the customers are even in stable in the quality of the software [and] the stability of intensely involved in providing constant feedback business the software. in contrast to traditional development. tions. in the 16 organizations. the “inability to scale the soft. evolve the application over time. come from needed. or the application’s growing development process. and many more get added dur. developers identify accurate cost and schedule estimates for the entire technical risks. the original estimates must be requirements prioritization—for example. agile RE in- volves prioritizing requirements in each develop- Challenges. a major concern with iterative RE to one participant. 2009 at 06:56 from IEEE Xplore. personnel turnover. or be appropriate tomer compared his experience with agile RE and traditional RE: “I think the difference for me came performance. might be discarded. ness value. as one ServIT Such a clear understanding of the customer’s pri- participant noted. many factors drive ing development. Moreover.NET framework. Second. Here’s how a SecurityInfo cus. and implementation depen- velopment. Iterative RE has two reported benefits. Because customers are very involved in the tomer representatives. maintainability. or implementation difficul- project is difficult. Downloaded on October 4. Even BankSoft. Obtaining management support ties. such as ServeIT and TravelAssist. creating vide them the greatest benefit. Many participants acknowl. during early development cycles. busi- adjusted (sometimes quite dramatically) during de. for example. First. foreseen technical issues. suggested that the ten- environments [for] the first time. especially when adopting new technologies. Flexible RE facilitates this joint dis. requirements are prioritized together cause none of the organizations follow a formal RE with other development tasks such as incorporat- phase. the initial estimation of project size typically ing changes to existing functionality. understanding of the project evolves. it creates a more satisfactory relationship focus on core functionality and ignore NFRs such RE might with the customer. the lack of documentation might cause sons for each requirement at any development cycle. . Many participants. to. So.” edged that NFRs are often ill defined and ignored Also. unavailability of appropriate cus. Many of these refactoring. FinCo used a beta ize the most business value. and the evolving velopment as the customer’s and the developer’s technology caused several changes to the require. bug fixes. as requirements are added or modified. RE. unforeseen The participants suggested that iterative RE might be appropriate even in stable business envi- Requirement prioritization goes extreme Agile development implements the highest- technical ronments where the changes often come from un. risks.” dency to ignore critical issues such as security and where the Second.

in creating formal requirements documents. he had to re- It’s constantly being revisited as these things change. Occasionally. and Venture. The early and constant validation of re. tain quick customer feedback on requirements. ment of the code created for experimentation with The study participants believe that frequent com. the production software it- ment change is interesting because this ability is of. the architecture the development problems. Redesign of the ar- Transport. the only alternative is to throw away the code and ment and cost less in agile development. satisfy customer needs. the cost of addressing a change request de- provides numerous opportunities for reprioritization. The ability to quickly deploy newer versions the developer engages in detailed discussions with of the products on the Internet also contributes to the customer to roughly understand what he or she this tendency. Challenges. positioning. maintaining or evolving example. . For example. Piloting applications and In the 16 organizations. reduce the margin of error. quirements largely minimizes the need for major changes. this approach team chose during the early cycles became inad- resulted in an architecture that wasn’t scalable.” Participants commonly reported two types of Prototyping requirements changes: adding or dropping features. Some organizations are recognizing the most of the change requests are “usually more a case risks of deploying prototypes in production mode. chitecture added significantly to project cost. some participants observed ior. Managing requirements change Moreover. at FinCo. refactor software depends on many factors. One AgileConsult developer veloper observed: “Planning is a constant activity. 2009 at 06:56 from IEEE Xplore. about five times. of- Accommodating requirements changes during ten doesn’t completely address the problem of inad- development is a way of tuning the system to better equate or inappropriate architecture. As an AgileConsult developer described. Changes are easier to imple. releasing them to end users in iterative fashion are tively rare. this kind of change is rela. their customers to validate and refine requirements. such as ServeIT. Customers provide feedback and can re. write large application modules (200–330 KLOC) Because we don’t make fixed plans. self can be a form of operational prototype. Furthermore. Refactoring changes software’s internal struc- ficiency) that might initially appear secondary to the ture to make it easier to understand and cheaper customer but that become critical for operational to modify without changing its observable behav- success. little graphical things … for For example. and the ability to with caution. creases dramatically compared to traditional soft- ware development. Downloaded on October 4. rewrite entire modules. color. Before implementing a feature. the developer gets constant feedback from the customer as the features are implemented. commodate requirements (such as security and ef. the need for that continuous reprioritization. needs. agile RE So. and try to con. Many organizations. a NetCo de. several tions reported a low need for major changes to the organizations use prototyping to communicate with delivered features. Using business value (often focused on time-to-market) as the only or primary criterion Challenges. at Entertain.where achieving reprioritization is difficult. leads to instability. “This helps quest major changes if their expectations aren’t met. According to one ServeIT participant. and changing already implemented features. it resulted in a system that couldn’t ac. At equate as requirements changed. such as FinCo for requirements prioritization might cause major and AgileConsult. because of this problem. other useful practices. accommodating change is easier. of tweaks … spelling. At the Transport. … reported that. features. Benefits. Instead of incurring the overhead involved Organizations that practice such intense interac. In several organizations. To a certain extent. some participants reported that refactor- through constant planning ing. required features. tests evaluate the implemented features to settle requirements specification quickly. the rush munication between the developer and the customer to market encourages a tendency to deploy these during development obviates the need for changes prototypes rather than wait for robust implementa- after development. form to them. develop a prioritized list of end of each cycle. Challenges. HuCap. a refine- ten touted as an important benefit of agile processes. when not practiced refactoring isn’t always obvious. as an ongoing activity to improve the design. Restrictions apply.” prototypes is difficult and has caused problems with January/February 2008 I E E E S o f t w a r e  65 Authorized licensed use limited to: KING SAUD UNIVERSITY. In several organizations. However.” Such a low occurrence of major postdevelop. Also. Eleven organizations regularly use prototypes to ob- Benefits. for most participants. tions. such as the developers’ experience and schedule pressure.

However. I sit down with most one-third of the organizations don’t practice 66 IEEE Soft ware w w w. al- is when. In most organizations. tions seldom occur. the review meet- challenges code. Most of the organizations rank high or me- meetings for requirements validation. “You write code that talks about even though the meetings’ original purpose is to re- what the system’s behavior should be. TDD treats writing tests as part of a require. new things he found out as he was talking to more practices tic expectations among customers. You get very quick feedback Challenges. Surprisingly. not all the each development cycle. 2009 at 06:56 from IEEE Xplore. Many organizations use tests to capture and to identify problems early during development. it requires. customers. … You write code that talks about agile RE practice focuses more on requirements what the system’s behavior should be. several organizations find implementing challenge is that TDD requires a thorough under. This traceability ment support for the project by providing frequent makes incorporating changes easy. Another testing. Almost all the organizations nel. At the end of dium for most of the practices. organizations use QA personnel to help customers because it involves refining low-level specifications develop these tests. the developers demonstrate the deliv. Owing to these challenges. So. although prototyping is back [from the review meetings]. most developers aren’t accustomed to the discipline ager described. at TravelAssist. to increase customer trust and confidence in the team. Also. “We basically get some minor feed. such testing difficult owing to the difficulty of access standing of the requirements and extensive collab. During reported that their most common challenges are the meeting. claimed an Ag. Consistency checking or formal inspec- before coding. they hold a meeting with organizations are encountering all the challenges developers. at the start of the iteration. Downloaded on October 4. as we mentioned before. for TDD is the least-used practice (only six organiza- many organizations. Most developers in the study admit. and other stakeholders. to the customers who develop these tests. many oration between the developer and the customer. ask questions and provide feedback. and robust. . The PM sometimes brings up Agile RE pro­totypes in the early stages has created unrealis. However. these review meetings cover tions adopt it) because. code’s behavior. most organi- zations reported that they’re unable to implement A comparison of agile RE practices this practice. ments/design activity in which a test specifies the tomer and other stakeholders in the organization.” Acceptance tests that the customer develops.” validation than traditional approaches. management. quality assurance person. features such as scalability. we determined the degree to which Use review meetings and acceptance tests the 16 organizations reportedly followed them (see Almost all the organizations use frequent review table 1). the inability to gain access to the customer and ob- ered features. ted that they don’t consistently follow this practice Although agile practices emphasize acceptance because it demands a lot of discipline. As the SecurityInfo project man. to be more adventurous in terms of making changes and trying out ideas. iteratively.’” meeting’s perceived benefits include the opportuni- explained an AgileConsult developer. ties to ascertain whether the project is on target. They have been unwilling to accept longer development cycles that customers. However. The participants suggested that their if it goes wrong... updates on project status and progress to project ileConsult developer: “Having those tests allows you sponsors. to the TDD is an evolutionary approach in which de- velopers create tests before writing new functional Benefits. security. complete requirements and design documentation These meetings help considerably to obtain manage- that are linked to production code. quick deployment of talk about features. A major challenge to TDD’s adoption is because there’s no formal modeling of detailed re- that developers aren’t accustomed to writing tests quirements. it doesn’t address aspects of formal verification Challenges. Some organizations treat these tests as part of require- nor poison Test-driven development ments specification. . Restrictions apply. the product manager [the surrogate customer] to ness. ings primarily provide progress reports to the cus- intrinsic to RE. So you end up view the developed features and get feedback. To develop a detailed understanding of the agile RE practices. only minor issues. o rg /s o f t w a re Authorized licensed use limited to: KING SAUD UNIVERSITY. are neither are necessary to develop more scalable and robust sometimes with help from the QA personnel. another means for validation and verification. Benefits. are panacea implementations as the product matures. c o m p u t e r. The writing very explicit specifications and not ‘tests. of agile RE practices. and the customers and QA people taining consensus among various customer groups. … The big thing considered one of the most established practices.

25. should carefully compare the costs and benefits of agile RE practices in their project Log on to our Web site to environment. Boehm. Balasubramaniam Ramesh is a professor of computer information systems at Georgia State University. Norfolk. She received her PhD in computer information systems from Georgia State University. Instead of following a formal procedure to produce a complete specification that accurately describes 4. July 2000. and knowledge management. Agile development oc- curs in an environment where developing unambig. no. K. pp. • Subscribe or renew ment.computer. Siau. Lyytinen. “Agile Modeling. 1999.edu. Her major research interests are agile software development and in agile RE. vol. Corbin. such as improved understanding of customer needs and the ability to adapt to the evolving needs of today’s dynamic environment. • Submit your article for and Rapid Change. “Requirements That Handle I kiwisi .org/software ies of Software Engineering. they’re evenly spread throughout development. ur study reveals that agile RE differs from traditional RE in that it takes an iterative discovery approach. www. Erickson. they pose several distinct challenges. While the literature on traditional development About the Authors laments the inadequate attention paid to reviews and tests. pp. 4. Contact him at the Computer Information Systems Dept. pp. “Qualitative Methods in Empirical Stud. The study suggests that agile RE practices are neither panacea nor poison to the challenges intrinsic to RE. software process modeling and simulation. agile RE processes aren’t centralized in one phase before development.” IEEE Trans. Georgia State Univ. 2009 at 06:56 from IEEE Xplore.. Seaman. we report here. B. 16.” J. lcao@odu. COTS. therefore. 557–572. no. C. He’s a member of the IEEE. Restrictions apply. These fundamental systems from the Stern School of Business. 2005. 99–102.. Development organiza- tions. Basics of Qualitative the system. Table 1 Agile requirements-engineering practices in 16 organizations Practice Adoption Face-to-face Extreme Constant Test-driven Reviews level communication Iterative RE prioritization planning Prototyping development & tests High 8 9 10 8 8 5 11 Medium 8 5 6 6 3 1 4 Low 0 2 0 2 0 0 1 None 0 0 0 0 5 10 0 it. agile RE is more dynamic and adaptive. New York University. GA 30302.computer. Atlanta. .” Computer. As we mentioned before. Sage Publications. publication Agile Software Development. VA 23529.org/csdl.. • Search our vast archives • Preview upcoming topics • Browse our calls for papers References 1. 88–99. bramesh@gsu. agile uous and complete requirement specifications is im- software development. Old Dominion Univ. For more information on this or any other computing topic. please visit our Although agile RE practices provide benefits Digital Library at www. 2.B. vol. Research: Techniques and Procedures for Developing Grounded Theory. He studies requirements engineering and traceability. and the Association for Information Systems. A.. and Extreme Program- ming: The State of Research. of Information Technology O and Decision Sciences. He received his PhD in information possible or even inappropriate. Strauss and J. Downloaded on October 4. differences have led to the set of agile RE practices ACM. The study participants identified the intensive communication between the developers and customers as the most important RE practice. Software Eng. 3. January/February 2008 I E E E S o f t w a r e  67 Authorized licensed use limited to: KING SAUD UNIVERSITY. the 16 organizations use them extensively Lan Cao is an assistant professor of Information Technologies and Decision Sciences at Old Dominion University. and K. 1990. Database Manage..edu. Contact her at the Dept. J. 35 Broad St. 4.