Meeting use case preconditions and postconditions

Meeting use case preconditions and postconditions

I have a precondition that before starting use case 2, use case 1 should be completed. How do I write requirements with this condition?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

There are several possible approaches. To leave it in use case terms, simply write a postcondition for use case 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.

Software requirements resources:
Use cases don't need to include all system functionality details

Software requirements analysis: Five use case traps to avoid

Software requirements gathering techniques

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.

This was first published in May 2007