5

It seems the world is doing a good job at managing functional requirements for a system - you can link them to benefits, prioritize them and manage their implementation schedule (let's assume an ideal world :)

Now consider 'ilities' like modifiability, usability, adaptability, reusability, security, reliability, availability etc., etc.,

Technically one can link them to potential end benefits and also prioritize their importance for a business - but just HOW should one manage their implementation? Assuming you prioritize the functions and the ilities in the same 'pile' so to speak, it's possible that availability may be lower than 'booking tickets' feature-set (for example).

Agilists may argue that the design should reveal itself and that they can 'refactor' availability or security etc., later. Honestly, everything can be added to the system by refactoring but the costs may be prohibitive and that's why one must spend some time (may be more) upfront when accounting for such ilities IMO.

So my question is this: should you preform a separate prioritization for ilities? Should they be in a separate 'pile' (or backlog) of their own? What should be a good sequencing order when implementing the system? If you indeed perform two independent prioritization activities then how can you compare amongst them and convince the stakeholders that you are indeed doing valuable things first? Basically how would you justify doing ility-management/planning/design over feature-set designing?

Since ilities have tradeoffs associated with them you must be able to balance them well and thinking about it later or following YAGNI (You ain't gonna need it) won't suffice. What do you suggest?

3

Non-functional requirements, 'ilities', or (the better name for them in my opinion) quality attributes have significant influence over the architecture. Since quality attributes aren't really something that your system does but rather something that your system is, you should treat them differently than functional requirements.

It is for this reason that it is not appropriate to treat quality attributes in the same way you would other items on your backlog. Putting them in the backlog implies that they can be "done" which can never happen since many quality attributes have influence across many features across many iterations -- something like testability or scalability or maintainability isn't something a customer can pick for a sprint, so don't treat it like a feature on the backlog.

So my question is this: should you preform a separate prioritization for ilities?

Yes. Quality attributes are usually recorded as as a scenario. These can be "formal" 6-part scenarios or simple use stories. The most important thing is to record the stimuli, response, and environment. The more specific and measurable the better. The best thing to do is to collect the big ones, the most important ones at the beginning using a technique like the Quality Attributes Workshop. The outcome of the QAW is a prioritized list of quality attribute scenarios.

Should they be in a separate 'pile' (or backlog) of their own?

Yes. Quality attributes should be tracked separately. Two reasons.

  1. You can't test quality attributes in the same way that you test features. Often times you will need to reason about the architecture to understand whether a specific system property is appropriately promoted or inhibited. As the system is developed, some kinds of quality attributes may become testable (e.g. performance, or reliability -- influences dynamic structures), others won't (e.g. maintainability, modifiability -- influences static structures).
  2. Many Features will influence (potentially many) quality attributes. For example, security is not simply a feature that you add at the end -- "Let's do security this sprint!" -- but something that needs to be built into, potentially, every feature you create.

What should be a good sequencing order when implementing the system?

The catch to this is that you can put discrete Technical Debt stories in the backlog (with some customers). That is - discrete tasking that directly influences specific quality attributes. An example: "The XYZ module has a lot of bugs because the code is poorly written, we need to refactor to make it more maintainable."

There are many strategies for dealing with debt -- low hanging fruit, squashing "bug farms", "zippering" debt with features to ensure you're staying on top of things...

If you indeed perform two independent prioritization activities then how can you compare amongst them and convince the stakeholders that you are indeed doing valuable things first? Basically how would you justify doing ility-management/planning/design over feature-set designing?

There may be trade-offs within a design -- for example, security is more important than performance -- which is why it is so important to know the big ones up front. Remember, quality attributes influence the design; they aren't the artifact being delivered. You don't do security, this is a property of the software you build. Agreeing on this up front is the only way to ensure that the features you deliver achieve the right quality. There could be a million ways to solve a problem -- but only a few with the desired properties. Miss these and your features will be rejected every time. "Yes, it calculates the XYZ correctly... but two minutes is just too long..."

  • That makes A LOT of sense. Thanks for the point by point clarifications! – PhD Jan 11 '12 at 1:22
  • 2
    +1; You're right that you cannot track the Quality Attributes themselves. I'd add that requirements/stories/features can be extracted from them, and those can be tracked and prioritized. My answer assumed this was done, in which case it's my opinion that they should be tracked and prioritized along with everything else. – Merlyn Morgan-Graham Jan 11 '12 at 1:44
2

should you preform a separate prioritization for ilities? Should they be in a separate 'pile' (or backlog) of their own?

The other answers here are on the right track. Features for developers should be in the same queue as features for other business stakeholders.

This will allow you to track dependencies between business-related features and ility features. It will also help with your next question:

What should be a good sequencing order when implementing the system? If you indeed perform two independent prioritization activities then how can you compare amongst them[?]

Once you treat all features the same way, you can prioritize them the same way:

  • Cost/benefit analysis
  • Budgeting vs predicted business need - not just for this sprint, but for the next quarter or year
    (or however long your backlog is)

...[how can you] convince the stakeholders that you are indeed doing valuable things first? Basically how would you justify doing ility-management/planning/design over feature-set designing?

On teams I've worked on, we used the term Technical Debt to help business stakeholders understand the importance of housekeeping the code base.

  • Technical debt sounds like a good idea but it has the risk of being the lazy man's pit i.e., things could just be tossed over and as long as the 'business is in the money' no one would really pay much attention to it IMHO (I know of few such instances personally :) – PhD Jan 9 '12 at 20:01
  • I do subject all the features to the same analysis (including ilities) however, there is no guarantee that ilities will always surpass the feature in the prioritization and it may just be quite hard to say 'we have to do that first'... – PhD Jan 9 '12 at 20:05
  • @Nupul: I am suggesting Technical Debt be used to help them understand the concept in general, so they can understand why ility features are showing up in the same queue. I'm not suggesting it be used as a bucket to pitch items into or an unlimited resource sink. You don't implement features or make changes unless you have to and/or have the budget, and have made an educated prediction of what benefit it will bring. This is the same as features coming directly from core business requirements. Did you mean something else? – Merlyn Morgan-Graham Jan 9 '12 at 21:09
  • @Nupul: You shouldn't use a process that guarantees that ilities will always have a higher priority. Items should be prioritized based on cost and benefit, which should be based on as realistic a prediction as you can make. The prediction should be on basic cost, cost-dependencies, and cost "interest". E.g. if you implement this now, it will cost less, or if you implement A before B, B will be cheaper. In a lot of cases this prediction can be made via understanding of scope of each business feature and what code it will probably touch, then a code grep, & maybe a spike implementation. – Merlyn Morgan-Graham Jan 9 '12 at 21:19
  • 1
    That makes sense...so it may be okay for the ilities to come out as less important to some features, but later implementations could be prohibitively expensive and that can be used to factor into the cost/benefit or tradeoff analysis... – PhD Jan 11 '12 at 1:19
1

I'd handle them in the same backlog as all your stories. We usually tackle non functional requirements in 3 ways (in order of preference):

As part of our Definition of Done where it is applicable to the entire application.

In our Acceptance Criteria for those that only apply to a story or subset of stories.

As a Story where they can't be neatly considered as part of the first two but we don't want to forget them.

  • 1
    I'm aware of 'how to handle them' - the question is how to plan for them for implementation - they may require upfront architectural analysis and may not lead to any code per se for that sprint/iteration. You just can't 'put it off' for a later iteration where the costs of refactoring may be overwhelming! It would've been much cheaper to think about it earlier...and I wish to know how to balance/plan/handle something like that – PhD Jan 9 '12 at 20:03
  • @Nupul: What you're describing is no different than features that implement core business requirements. They're both activities in requirements gathering and CBA. You can't know anything about what you ignore :) As for sequencing, devs could gather requirements on ilitys in parallel with Business Analysts gathering requirements on core features. Prioritizing before that (on what to even gather requirements for) has to be based on intuition and agreement between stakeholders (devs are a stakeholder WRT ilitys). – Merlyn Morgan-Graham Jan 9 '12 at 21:35
  • My point is that it's quite rare that we need to think about prioritising them separately. Most of the time, they are covered either by our definition of done or acceptance criteria so are just done as a matter of course with their stories. On the rare occasion we do need to create a story for it it gets prioritised by the product owner with the rest of the backlog. – Ben Jan 10 '12 at 10:26
1

Always have a single backlog and let the business needs dictate priorities.

Non functional requirements are usually trickier to iron out vs functional requirements and whether to prioritize then over or under functional requirements,is a question you would need to ask stake holders or the product owner

The prioritization order entirely depends upon the context/business needs of your product .

I work in testing embedded systems for public safety organizations and for a patrol cop (our typical user) reliability of the product is paramount and is miles ahead in terms of priority versus new feature set that the product has to offer.

  • Oh absolutely! I can imagine that to be the case in your domain. The places where it is kinda easier to ascertain the value of ilities these problems don't arise. The situation that is a bit irksome is when it's not clear and refactoring the 'architecture' is prohibitively expensive and you need to do it upfront... – PhD Jan 9 '12 at 20:07
  • I completely agree that a single backlog for 'functional' and 'non-functional' requirements is key here. Also important is to have the budget-holder (or product owner) responsible for the operational effectiveness of the product. Several people have found this blog post I wrote useful: Let's Talk About Operational Features, not Non-Functional Requirements: blog.softwareoperability.com/2013/04/08/… – Matthew Skelton Oct 14 '13 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.