Bugs vs Requirements

An example in our case is a performance bug: end user reports functionality we have a requirement for already works correctly, but too slowly. We’ve agreed it’s a bug to be fixed. We don’t have “motherhood ” requirements for performance.

In requirements documentation, that higher level should be a requirement such as system reliability. We sometimes call them "motherhood requirements" like "all equipment must perform its intended function."

They may have been generated as part of a scope decomposition, but for audit traceablity in a system like IBM's DOORS (Rational Dynamic Object Oriented Requirements System) if they are required as part of the scope, they need to be defined and managed as requirements. If not, and I'm an auditor, I'm going to start asking very specific questions about configuration management and how you keep your requirements documentation synced with your scope decomposition document.

Keith -

A lot depends (as usual) on the expectations on requirements completeness and those will tend to be industry or company specific. With pharma validation requirements, such overarching quality requirements would need to be explicitly documented whereas in most of the financial services companies I've worked with, those are assumed to be there, and you'll get eye rolls if you try to add them in to a requirements document or repository.

Kiron

Rosanna,
That would typically be a functional requirement such as, "The system shall respond in an acceptable duration of time." What is acceptable in this case is based on your customer's inputs, and might have to be broken down into stated times to perform specific functions. That may be further broken down into derived requirements for how fast different parts of the system must process their parts that contribute to the function including both hardware and software. That is part of the "logical architecture" of how the systems perform the functions.On distributed teams or distributed computing like cloud services, it could be the difference between one team using metric and the other imperial units.

Defining those high level requirements can be very important when there are disagreements by the parties as to what is acceptable. Some customers may follow a strategy of signing a contract planning to add in a whole lot of additional work for free not in the original agreement knowing that the performing team is already fully invested in the project and will eventually agree. In many cases, not having some of those requirements defined up front (or at least how you will agree on what is fast enough) and having to change or add customer driven requirements later can be very expensive and arguing that between lawyers it is important to have very clear paper trails.

Fair enough. In aerospace, another very highly regulated industry those motherhood type requirements have extensive guidance from the regulators on how to show compliance and/or the manufacturer, operator, etc. must get approval for how they will show compliance whether per existing guidance or by proposing an alternate means.

Much of the showing of compliance through adherence to an approved quality management system that includes formal processes followed for different aspects of document management, engineering standards, manufacturing standards, etc. That might be written as something like All software must conform to Quality Doc XYZ123.

Requirements originally developed through some scope document would become some type of formal configuration specification which is itself under formal configuration control. That config spec is part how to show compliance, in essence saying this is what we mean when we say the product must perform all intended functions.