When adopting a formal Software Engineering process, it is important that the various artifacts (documents, templates) are consistent with each other. For if these artifacts exist, they are to be consulted, and if one or more of them are out of date, they lose their usefulness as reference material - they become "useless work," which someone wasted time writing in order to be thrown away. p>
For that reason, if throughout the project you determine that a new functionality is interesting, but you are already well advanced in development, it is tempting to simply implement it and leave it behind everything that was done back there ( specification requirements, analysis models, etc.). By doing so, you not only contribute to the inconsistency between what is described by the system and what the system actually does, but also the additional risk of breaking the deadline and budget (as they were estimated with based on the project, and this estimate needs to be continually revised as requirements change). Finally, you may be a victim of scope creep - in which case you start adding new features to the systems simply "because you can" or "because the client wants", without this being justified by system mission.
Ok, but does that mean that every little document needs to be updated whenever something changes? Does it depend on the following: is this "list of requirements" a "permanent" document or not? Is it something that is part of the baseline of the project, or something you wrote as brainstorm, to be used and thrown away afterwards? Some more bureaucratic processes require (or attempt to require) everything to be meticulously documented, nothing out of the blue, and that with every change all artifacts are updated to reflect it, even when this is impracticable in practice and / or such documents and models are rarely or never consulted by anyone. Others already predict - even in an organized way - the obsolescence of certain artifacts, and prefer to file them to keep them up to date.
It is then up to you to determine, on a case-by-case basis, what makes sense to keep and what makes sense to file. Does this "list of requirements" help who? To the client? Only to developers? To other actors in the development process? And the use-case relationship helps who? Each company, each team, can do this differently, with pros and cons that are the subject of much heated discussion. Most important, whether in an organized team or even in a disorganized (ie, who proposes to follow a process, but always ends up straying from it) is to differentiate which documents are consistent with the system as it stands (or will be) are obsolete, so that others do not waste time and / or have their expectations frustrated by consulting something that does not fit the reality of the project.
