Dr. Dobb's Journal - October 2008 - (Page 64)

D10ambler_p5db 8/14/08 4:00 PM Page 64 The Agile Edge by Scott W. Ambler Beyond Functional Requirements On Agile Projects Strategies for addressing nonfunctional requirements STUDY AFTER STUDY has shown poor requirements management is the leading cause of failure for traditional software development teams. When it comes to requirements, agile software developers typically focus on functional ones that describe something of value to end users—a screen, report, feature, or business rule. Most often these functional requirements are captured in the form of user stories, although use cases or usage scenarios are also common, and more advanced teams will iteratively capture the details as customer acceptance tests. Over the years, agilists have developed many strategies for dealing with functional requirements effectively, likely one of the factors leading to the higher success rates enjoyed by agile teams. Disciplined agile teams go even further, realizing that there is far more to requirements than just this, that we also need to consider nonfunctional requirements and constraints. Nonfunctional requirements (NFRs), also known as “technical requirements” or “quality of service” (QoS) requirements, focus on aspects that typically cross-cut functional requirements. Common NFRs include accuracy, availability, concurrency, consumability (a superset of usability), environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, support, and timeliness. A constraint defines a restriction on your solution, such as being required to store all corporate data in DB2 per your enterprise architecture, or only being allowed to use open source software (OSS), which conforms to a certain level of OSS license. Constraints can often impact your technical choices by restricting specific aspects of your architecture, defining suggested opportunities for reuse, and even architectural customization points. Although many developers will bridle at this, the reality is that constraints often make things much easier for your team because some technical decisions have already been made for you. I like to think of it like this— agilists will have the courage to make tomorrow’s decisions tomorrow, disciplined agilists have the humility to respect yesterday’s decisions as well. Although agile teams have pretty much figured out how to effectively address functional requirements, most are still struggling with NFRs and constraints. Some teams create technical stories to capture NFRs and constraints in a simple manner as they capture functional requirements via user stories. This is great for documentation purposes but quickly falls apart from a management and implementation point of view. Agile requirements management strategies (see www.agilemodeling.com/essays/ changeManagement.htm) assume that requirements are self-contained and can be addressed in a finite period of time, an assumption that doesn’t always hold true for NFRs and constraints. Figure 1 depicts a high-level timeline for an agile system lifecycle. It shows how the full system lifecycle addresses the preproject activities of Iteration –1 (see “The Iteration Negative One,” www.ddj.com/architect/209902719), the full software development lifecycle (SDLC), the Production phase where the system is operated and supported, and an optional Retirement phase where the system is completely removed from your environment. The system development lifecycle includes Iteration 0, the construction lifecycle, and the release iteration(s) and is gone through once for each successful release of your system. During Iteration 0, also called the Inception phase, you do the work required to get the project started, including initial modeling and planning. During the construction lifecycle, the portion of the lifecycle that most agile methods focus on, you build the system. Disciplined agile construction includes an independent investigative testing effort (see “Agile Testing Strategies,” www.ddj.com/architect/196603549) that runs in parallel to development activities. During the release iteration(s), also called the Transition phase (see “The Agile End Game,” www.ddj.com/architect/198800565), you do the work required to deploy the system into production. This lifecycle is important because it reveals three of the four strategies for addressing NFRs and constraints on agile projects: • Initial requirements and architecture envisioning during Iteration 0 to identify NFRs and constraints. • Just in time (JIT) model storming through the construction lifecycle to explore the details. • Independent investigative testing throughout the lifecycle to ensure that the system addresses the NFRs and constraints appropriately. • Developer education so that they understand the fundamentals of the full range of architectural concerns described in the requirements. Figure 1: The full system lifecycle. 64 Dr. Dobb’s Journal l www.ddj.com l October 2008 http://www.agilemodeling.com/essays/changeManagement.htm http://www.agilemodeling.com/essays/changeManagement.htm http://www.ddj.com/architect/209902719 http://www.ddj.com/architect/196603549 http://www.ddj.com/architect/198800565 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - October 2008

Dr. Dobb's Journal - October 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook Is Your Next Language COBOL? Conversations Safe Coding Practices Code Signing in Adobe AIR OpenID Single Sign-On The Book Cipher Algorithm Indexing and Searching Image files Extending Continuous Integration Into ALM The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - October 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.