Meeting use case preconditions and postconditions

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Software Requirements Gathering, Analysis, Quality and Testing How to write a Software Requirements Specification (SRS) document Problems caused by skipping analysis stage of SDLC Software development life cycle phases, iterations, explained step by step Waterfall versus iterative development misconceptions Differentiating between Functional and Nonfunctional Requirements Writing a software requirements specification (SRS) for a portal app Should QA check changes from outside the requirements document? Software testing metrics for a medium-sized project Template for requirements use cases What should a business analyst's requirements document include? Use cases and misuse cases Requirements practices evolving, but organizations still struggle Defining report requirements with use cases How requirements use cases facilitate the SDLC Excelling in the art and science of requirements elicitation Requirements use cases tutorial: Advanced formats, test case comparisons Use cases for software requirements tutorial: Strengths, flaws, formats Writing a software requirements specification (SRS) for a portal app Agile software development tutorial: Agile requirements gathering Pros and cons of requirements-based software testing How to avoid requirements creep

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary use case  (SearchSoftwareQuality.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

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.