Relationship between requirements list and use cases

Question

When starting to develop a system, and even throughout the development process, it is common to maintain a list with the functional requirements of the system. In my understanding we always start by assembling this list and then from it we write use cases to describe in detail the interaction between the user and the system. It’s important to note that I’m not talking about diagram use cases, but rather the use cases themselves.

It turns out that in recent times I am reading a book about analysis and design in object orientation and the book suggests that in addition be done also the opposite, ie when writing a use case check if it is necessary to add any more requirements to the list.

I didn’t understand that, why would it be done? In my view, listing the functional requirements is precisely to find the use cases and know what is necessary to describe the system. What is the basis of doing the reverse process and starting with the use case? In my understanding starting with the use case there is no usefulness in adding anything to the functional requirements list.

Answer 1

When adopting a formal process of Software Engineering, it is important that the various artifacts (documents, models) are consistent among themselves. For if these artifacts exist, they are to be consulted, and if one or more of them are outdated, they lose their usefulness as reference material - they become "useless work", which one has wasted time writing to ultimately be thrown away.

For this 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 out of all that was done back there (specification of requirements, analysis models, etc.). In doing so, not only do you contribute to the inconsistency between what the system does and what the system actually does, but you also incur the additional risk of overshooting the deadline and the budget (because they were estimated based on the project, and this estimate needs to be continuously reviewed as requirements change). Finally, you may be the victim of Scope creep - in which case new functionalities begin to be added to the systems simply "because it can" or "because the client wants", without this being justified given the mission of the system.

Okay, but does that mean that every little document needs to be updated every time something changes? It depends on the following: this "requirements list" is a document permanent or not? It’s something that is part of the project’s baseline, or something that you wrote as Brainstorm, to be used and then thrown away? Some more bureaucratic processes require (or attempt to require) that everything be meticulously documented, that nothing goes out of the plan, and that at each change all artifacts be updated to reflectla, even when this is impractical in practice and/or these documents and models are rarely or never consulted by anyone. Others already predict - albeit in an organized way - the obsolescence of certain artifacts, and prefer to archive them rather than keep them up to date.

It is up to you to determine, on a case-by-case basis, what makes sense to keep and what makes sense to archive. Who does this "list of requirements" help? The customer? Just to developers? To other actors in the development process? And the relationship of use cases, helps whom? Each company, each team, can do this differently, with pros and cons that are the subject of much heated discussion. The most important thing, whether in an organized team or even in a disorganized one (i.e. that proposes to follow a process, but always ends up deviating from it) is to differentiate which documents are consistent with the system as it is (or as it will be) and which are obsolete, so that others do not waste time and/or have their expectations frustrated by being consulting something that does not match the reality of the project.