Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Beyond Functional Requirements On Agile Projects


Scott is Practice Leader Agile Development for IBM Rational.


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.

[Click image to view at full size]

Figure 1: The full system lifecycle.

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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.