Every behaviour of a system should be there because it adds concretely to the business value of the system as a whole.
All too often software projects gain some kind of perverse impetus of their own, where features are added or technologies are chosen because they are “cool” or because the technical folk associated with the project feel that they are protecting their sponsors against some possible future requirements that the sponsors haven’t thought of or considered yet.
It is surprisingly common for organizations to run software projects and for them to have no view of whether the investment made in the project is ever recouped! This is a contributory factor to the SoftwareIndustryRecordOfFailure.
Focusing development activities on business value is a vitally important control to apply to any commercial software project, but is not necessarily always easy or straight-forward.
In BehaviourDrivenDevelopment an important aspect of every story is the value associated with it, this is true for all stories including TechnicalStories. This information can be used to inform planning decisions, and to guide everyone toward a sensible weighing of costs vs benefits.
TechnicalStories are included the same as any other, because technical requirements (aka NonFunctionalRequirements) need to achieve suitable benefits for their costs as much as any other. No more “As fast as possible”, instead more a case of “How fast can it be for $xxx?”
This approach acts as a brake on the tendencies of technologists to get carried away in their enthusiasm for the technology and on the business from getting carried away with dreams of their ideal system. It makes it clear to both groups that software is an expensive thing, and that trade-offs usually need to be made in the real world, thus mitigating the temptation of software users to ask for a Rolls-Royce solution, when all they really need is a motor-scooter and for software developers to try and build an aircraft carrier when all that the users need is a row-boat!