# Keep requirements traceable as software changes

Taiga Learning · Worksheet
https://taiga.training/en/lessons/specifications/

Use fictional or approved information. Do not put secrets in this worksheet.

## Learning objectives
- Write an observable requirement with explicit boundaries.
- Trace a requirement through a change and its checks.
- Identify downstream documents affected by a changed assumption.

## Exercise
Write a requirement for a manager to export active customers. Include permitted users, organization boundary, fields, failure behavior, and a measurable completion condition. Link it to a fictional test and release. Then change the requirement to include archived customers and list the affected decisions.

## Your response
- Scenario and scope:
- Assumptions and open questions:
- Proposed answer or decision, with reasons:

## Verify your response
| Claim or criterion | Evidence or test | Result or gap | Owner |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Next action
- Action, owner, and date:
- When will you review this response?

## Principle to retain
A specification is useful when its claims connect to decisions and verifiable behavior. Keep those connections current as the system changes.

## Sources
- [NIST: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- [Google Engineering Practices: What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)

This worksheet supports learning. Completing it does not itself authorize a production change.