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.
- 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).
- 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..."
