TABLE OF CONTENTS Use cases represent the services provided by our system, which means that they are the central elements in our requirements analysis. The services a system provides determine that system's meaning and purpose. This means that all functional requirements of the use cases have a high priority. All other requirements, such as response times, weight, or size are of qualitative or supportive nature. That doesn't mean that these requirements could not be important. An airbag that unfolds several minutes after its triggering is absolutely useless.
We've already collected requirements, including functional requirements, such as rent car without staff assistance. Use cases help us refine these requirements and describe them in greater detail. A use case itself is not a requirement.
Ours is a top-down approach, which means that we can achieve a broad collection of requirements in an early project phase. It also helps us obtain a full picture rather early. This provides us with a good basis, e.g., for cost and time estimates, in an early project phase [57].
One of the most important benefits of our approach is scalability. The depth of details of our model can be adapted to the project. Each step is realizable and achievable, from a superficial analysis to get a rough insight, e.g., for a feasibility study, to very detailed executable models. This allows us to further detail a superficial analysis model at a later point in time. And a very detailed model can appear like a superficial analysis...
