Tender vs. Requirements vs. Solution Design

Question

Conventionally, which of the above documents is deemed to hold the most weight when it comes to system acceptance?

I recently had a conversation along these lines:

It was argued that the initial requirements / tender documentation should be used to determine system acceptance. It was said that the solution design only serves to describe the way in which the system will solve the problem, not the problem it will solve. Furthermore, it was argued that if requirements are missed during solution design, the requirements should be referenced during system acceptance and that if any requirements were missed then the original tender should be referenced.

Conversely, I suggested that - while requirements may be based on the original tender - they supersede it once agreed with the stakeholders. Furthermore, during solution design, analysis is performed to address and refine these initial requirements, translating them into a system capable of meeting the actual requirements. Once signed off by the relevant users, this solution design should absolutely represent the requirements (by virtue of the fact that it's designed upon them) but actually supersedes them as the basis for system acceptance.

Is one of the above arguments more valid than the other?

EDIT: Apologies for the ambiguous terms. In this situation, tender is the document the customer took to market when shopping for a provider - it includes details of all the high-level features they're looking for. Solution design is not a technical document, it's the functional specification.

Answer 1

Passing acceptance testing is an indication that the system meets the users' requirements acceptably. As such, the requirements document is generally considered the source of truth for acceptance criteria.

There will almost always be further elaboration of requirements during design. If these are truly an expansion of scope, the requirements document should be updated to reflect this. Depending on how formal your process is, this may involve change requests, blah blah blah.

Answer 2

System acceptance should be against the customer's requirements. You are correct that analysis and derivation is performed against the customer's initial set of requirements. Often, customer requirements aren't enough to design and implement against, so it's necessary to elaborate on the needs of the customer, refine their requirements, and produce technical system requirements that is suitable for engineers to work against. In some cases, it may even be necessary to add requirements due to regulations or to meet business objectives. All of these refinements and derivations should be validated with the customer to ensure that everyone understands what must be done and what the end products will be or do.

The derived requirements should be traceable to some higher level requirement, either a customer requirement, a regulation, or a business objective. This will ensure that your design and implementation fulfills known requirements. Ensuring that each customer requirement is identified at a system/technical requirements level also helps to avoid missing requirements in design and implementation activities.