There are several possible approaches. To leave it in use case terms, simply write a postcondition for use case...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
1 that will ensure that the corresponding precondition for use case 2 automatically will be satisfied when use case 1 has completed execution. Aligning preconditions and postconditions like this implies a specific sequence of use case execution.
From the perspective of functional requirements, you could write one or more functional requirements that test whether the precondition for use case 2 is satisfied. If the precondition is fulfilled, meaning that executing use case 1 left the system in the proper state, then the system can proceed with executing use case 2. If not, though, the system must take some other action since it isn't ready to proceed with use case 2 yet. The functional requirement isn't checking specifically to see if use case 1 has been properly completed. Instead, it is testing to see whether the necessary precondition for use case 2 has been fulfilled. From a practical point of view, there isn't any difference. But doing it this way means that the system doesn't need to "know" anything about use cases, just specific conditions that it can check.
A third strategy is to take a test-driven approach. Here, you would write a test that sees whether the system proceeds as intended when that precondition for use case 2 has been fulfilled. A second test would verify that the system doesn't proceed with use case 2 if that precondition hasn't been satisfied because use case 1 has not yet executed successfully.
Any of these approaches will work. They're just different ways of thinking about the same situation. Aligning the use case postconditions and preconditions is a usage-centric approach. Specifying the functional requirements informs the developer of functionality that he or she must implement to make sure the system is ready to proceed with use case 2. And the tests provide a black-box way to verify that the implemented software is behaving properly.
Dig Deeper on Gathering Software Requirements Use Cases
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.