Channels ▼
RSS

Open Source

Beyond Functional Requirements On Agile Projects


Developer Education

The fourth strategy for addressing NFRs and constraints on agile teams, and on traditional teams for that matter, is to educate developers in these issues. It's easy to say that you're going to identify and then validate NFRs pertaining to consumability, security, and green IT, but if developers don't have even a basic understanding of these issues then how could they possibly do so effectively? I'm not saying that everyone needs to become a security expert, but they should understand the fundamentals.

Many organizations balk at the concept of training their developers to this extent, a decision that is incredibly short sighted. Yes, giving everyone a two-day training course in each of 20 to 30 topics adds up. But, when you spread these costs over a 30-year career, they're very small. When you look at the total value provided by improved knowledge and skills, it often proves to be a very good investment. When you enhance your training and education efforts by nonsolo development practices such as pair programming and modeling with others, you quickly see benefits from the training courses.

The four strategies for addressing nonfunctional requirements and constraints on agile projects go hand-in-hand. You need to first identify these issues through requirements envisioning and formulate a viable technical strategy through architectural envisioning during Iteration 0. The details are then explored on a just-in-time (JIT) manner throughout construction and validated via parallel independent investigative testing. Finally, to ensure that everyone involved understands these issues, your organization must invest in educating IT professionals, giving them knowledge beyond the intricacies of the technology de jure that will improve their overall productivity throughout their careers. Disciplined agilists go beyond the prioritized stack approach to requirements management and adopt a more holistic approach that addresses not only functional requirements but nonfunctional requirements and constraints as well.


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.
 

Video