Requerimientos ágiles

Copyright Rational Software 2002

http://www.therationaledge.com/content/jul_02/f_agileRequirements_dl.jsp

Agile Requirements Methods
by Dean Leffingwell Software Entrepreneur and Former Rational Executive To ensure that their software teams build the right software the right way, many companies turn to standard processes such as Rational Software's Rational Unified Process® (RUP®), acomprehensive set of industry best practices that provide proven methods and guidelines for developing software applications. Through the application of use cases and other requirements techniques, the RUP helps development teams build the right software by helping them understand what user needs their products must fulfill. Moreover, the RUP and many other contemporary software processes prescribe asoftware lifecycle method that is iterative and incremental, as this method helps teams address the risk inherent in a new development effort more effectively than did earlier, more rigid "waterfall" process approaches. Risk can originate from a variety of sources: technology and scale, deficient people skills, unachievable scope or timeline issues, potential health or safety hazards defects, andso on. Experience has proved repeatedly that addressing these risks early in the lifecycle is a key factor in producing successful project outcomes, and requirements management is one very effective way to accomplish this.

Mitigating Requirements Risk with Effective Requirements Practices
In our book Managing Software Requirements: A Unified Approach,1 Don Widrig and I described a comprehensiveset of practices intended to help teams more effectively manage software requirements imposed on a system under development. As the systems teams are building today can be exceedingly complex, often comprising hundreds of thousands or even millions of lines of code, and tens to hundreds of person-years in development time, it makes sense that requirements themselves are also

likely to beexceedingly complex. Therefore, a significant variety of techniques and processes -- collectively a complete requirements discipline -- are required to manage requirements effectively. But lest we lose sight of the purpose of software development, which is to deliver working code that solves customer problems, we must constantly remind ourselves that the entire requirements discipline within thesoftware lifecycle exists for only one reason: to mitigate the risk that requirements-related issues will prevent a successful project outcome. If there were no such risks, then it would be far more efficient to go straight to code and eliminate the overhead of requirements- related activities. Therefore, when your team chooses a requirements method, it must reflect the types of risks inherent in yourenvironment. Each of the requirements techniques we describe in our book, as well as those recommended in the RUP, was developed solely to address one or more specific types of requirements-related risks. Table 1 summarizes these techniques, along with the nature and type of risks that each is intended to mitigate.
Table 1: Requirements Techniques Address Specific Project Risks

TechniqueInterviewing

Risk Addressed
- The development team might not understand who the real stakeholders are. - The team might not understand the basic needs of one or more stakeholders. - The system might not appropriately address classes of specific user needs. - Lack of consensus among key stakeholders might prevent convergence on a set of requirements. - The team might not discover key needs orprospective innovative features. - Priorities are not well established, and a plethora of features obscures the fundamental "must haves." - The prospective implementation misses the mark. - The approach is too hard to use or understand, or the operation's business purpose is lost in the planned implementation. - Users might not feel they have a stake in the implementation process. - Implementation...