A footnote to the recent discussion of requirements....
In Competitive Engineering Tom Gilb argues that development groups spend a lot of time focusing on functional requirements but they should actually focus on performance and quality requirements:
“ From the point of view of understanding ‘competitiveness’, ‘levels of achievement’ and ‘associated risk’, the performance requirements are by far the most interesting requirements. Yet, traditionally, too much attention has been given to specification of functional requirements and resource requirements.” Tom Gilb, 2005
Put that in the context of an imaginary payroll software company: understanding what payroll software needs do do is fairly straight forward, most products on the market will do the same thing. But what makes the product competitive is how well it does it.
It relatively easy to list the things your software should do but listing how the software will be more competitive than the opposition, or delivery real business value - rather than a shopping list of features - is more difficult.
I've recently been hearing a lot of questions from delegates on agile training courses about the best way to deal with non-functionals.
ReplyDeleteMy general advice is to treat those as stories with internal stakeholders as the roles - e.g. "As the enterprise IT security officer I want the the average cost of hacking into the system to be greater than the average benefit any hacker can gain by doing so, so that hackers leave our system alone". This story should lead to a conversation with the customer about getting an external consultant to perform some penetration testing...
Students sometimes find it difficult to get their heads around this notion, because internal roles are not seen as legitimate in this context. I don't share that view, because everyone who comes into contact with the system while carrying out their job roles is a legitimate stakeholder. Stories about users in roles purely concerned with creating the system itself (such as developer, tester, product owner) might be questioned to verify that they are valid, but I think they can be in some circumstances - e.g. to improve the level of testability.