Nailing Down Non-Functional Requirements

Posted by Vikas Hazrati on Jun 22, 2011

Sections

Process & Practices,

Architecture & Design

Topics

Requirements ,

Customers & Requirements ,

Project Management ,

Agile Techniques ,

Agile

Share |

RELATED Research

Non-Functional requirements are often associated with the state of the system and not with the functionality that the system has to offer. General 'ilities' of the system such as scalability, interoperability, maintainability, portability, performance and security fall under this umbrella. Agile teams usually struggle with defining and estimating the non-functional requirements in their projects.

Mike Cohn suggested that almost all non-functional requirements can be characterized as user stories. He gave a few examples to show that non-functional requirements might be able to fit into the standard user story template

Fortunately constraints / non-functional requirements can be easily handled as user stories. Here are a couple of examples:

• As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on.
• As the CTO, I want the system to use our existing orders database rather than create a new one sot that we don’t have one more database to maintain.
• As a user, I want the site to be available 99.999% of the time I try to access it so that I don’t get frustrated and find another site to use.

However, Mike did caution that the user story template should only be used as a thinking tool. It should not be used a fixed template for all non-functional requirements.

Jason suggested that instead of trying to address non-functional requirements at story level, teams should be better equipped to see them as a part of the big picture. According to Jason, in their team, they were trying to address the non-functional requirements at individual story level and that did not help. He mentioned,

I like the idea of writing these NFR user stories on the wall and posting them in the work area as a reminder that the team should factor those constraints in when giving estimates.

Mike also suggested a definite way to estimate non-functional requirements. According to him, non-functional requirements have two costs associated to them

• Cost of initial compliance – The amount of work the team would spend in satisfying the non-functional requirement. For example, effort spent on performance testing in sprint five.
• Cost of ongoing compliance – Amount of work required to remain compliant to the non-functional requirement in the subsequent sprints.

Once the team accepts a non-functional requirement into the project (as our team did here in sprint five) they need to remain in compliance with that non-functional requirement for the remainder of the project. I think of this cost as a tax. Doing performance testing (or staying in compliance with any non-functional requirement) creates some amount of overhead on the team (the tax). This overhead or tax must be paid regularly.

For the purpose of estimation, Mike suggested that both the costs should be considered separately. Cost of initial compliance should be estimated just like any other user story or product backlog item. For the cost of ongoing compliance, the team and the product owner need to decide on how often they need to work for compliance.

For example, suppose the team and product owner agree that they will do performance testing in every fourth two-week sprint. The team then estimates that it will take six points of work every fourth sprint. That’s about 1.5 points per sprint. If a team has a velocity of 30, 1.5 can be thought of as about a 5% tax.

Nick Xldis made a very interesting observation on the compliance cost. According to Nick,

If the tax has to keep going up over time you’ve got architecture or process problems that might need attention. This makes it a good barometer for technical debt.

Scott Ambler shared his thoughts on managing non-functional requirements by enabling an independent test team.

Kassab, Olga, Maya and Alain introduced NFR size measurement method (NFSM) to reduce the uncertainty in estimating the non-functional requirements.

Thus, handling non-functional requirements might not be a huge struggle. The key is to handle them early and be aware of the ongoing cost.

Note:- There are various opinions which debate the use of the term non-functional requirements. Mike Cohn would rather call them constraints, where as Tom Gilb would strongly call them quality requirements.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   Nailing Down Non-Functional Requirements

   by Venkataraman ramasubramanian

   IMO, the NFRs should/can not be handled using a User stories. A typical user story has a tracking and closure at some point of time. But the NFR should be considered while architect a solution and the awareness of these important NFR should be translated to the Development team. The NFR should be translated as a checklist in Code-review, Document review ,testing to make sure that we are meeting the NFR.

   Reply

2. Back to top

   Re: Nailing Down Non-Functional Requirements

   by Vikas Hazrati

   Venkataraman, i would kind of agree with your point that NFR most of the times cannot be handled along with existing user stories. However, they could exist as separate user stories which are sticking on the wall all throughout the project as Jason suggested. This is something that worked really well for us. Vikas

   Reply

3. Back to top

   城市地方

   by Joe susan

   Now, there can be a increasing longing for resume design, to boost well being. Without athletic shoes managing come forth.||}{|Now, there can be a Kso, Discount Vibram Your fiveimproving desire to get go back to characteristics, to reinforce health and fitness. Without shoes doing work come about. especially vibram 5 palms will come,Finger Shoes exceptional conditioning course instructors and training companies in addition propose without runners working. Several huge corporations will be staring at the advantages of without running shoes. Vibram's Several Hands shoes or boots for individuals that desire to near get in touch with utilizing the soil to deliver a sophisticated,five handy shoes, unusal reply without footwear with assortment with all the human being human body function, for the wide variety of surroundings.

   Reply

4. Back to top

   Re: Nailing Down Non-Functional Requirements

   by Ronald Miura

   A story that is on the wall all throughout the project is not a story, it is a reminder. It`s probably good to keep it visible all times, but keep it in the kanban board as an everlasting 'on going' activity could cause the bad feeling of never closing the iterations.
   
   On the other hand, making it clear in a certain story what the non-functional requirements are, may be very important. Many times, the most accessed page in a system is also the most complex or that aggregates most data, and it will be the most prone have to performance issues. So, keeping it clear that it must respond in less than X (milli)seconds, or must handle X simultaneous requests, could be an important factor of success.

   Reply

5. Back to top

   Security

   by Simon Chatwin

   Traditionally 'Security' is clumped in the Functional arena (see FURPS: en.wikipedia.org/wiki/FURPS). And this makes some sense when we realize how security aspects can alter the user story and the scenarios. However there are some aspects of security (e.g. use of PKI) that may not fit in the story and ar best handled as separate things.
   
   I like putting non-story related things onto the wall for general consumption. How do I translate this to a larger team (SCRUM of SCRUMs, say)?
   
   Also I'd strongly differentiate constraints and requirements: constraints are non-negotiable limits on what can be done in the solution; requirements are a little softer and can be negotiated with users, developers etc. The effect of this is that changing a constraint dramatically changes the project---often causing you to go back to square one and start again!

   Reply

6. Back to top

   Non-functional requirements and software design patterns

   by Lori Witzel

   My colleague Marc Talbot at Seilevel has this to say about non-functional requirements and design patterns:
   "Many design patterns are actually driven not so much from functional requirements as they are from non-functional requirements. For example, scalability and maintainability requirements frequently drive architectural choices. Knowing that a customer wants to be able to add functionality in the future helps us to pick design patterns that minimize the cost of adding functionality in the future. Many business analysts pay only lip service to non-functional requirements, even though these may define some of the most fundamental architectural decisions made in a piece of software."
   
   If you want, you can read more here:
   requirements.seilevel.com/blog/2011/06/design-p...

   Reply