Example of Use Case Preconditions
The User Must Be Authorized
Often analysts will contend that they simply have to document with preconditions that the user must be authorized in order to use the functionality of the use case. It is inconceivable to them that this may not be correct or may not even be a requirement in the first place. Let's examine this further.
Use Cases Do Not Have Pre- or Post- Conditions
We discuss in detail on another page why
a use case cannot have a pre- or post- conditions.
We show that a use case interaction can have a precondition because, unlike a use case, an interaction is a behavior. Only behaviors can have them.One approach is to put the precondition on the first interaction of the use case. Suppose we have a use case called Use Secret App that requires a user to enter a password. We could write it:
1. The user, playing the role of Secret App User, enters a password.
2. The user specifies log in.
3. The system presents the main screen. Steps 2 and 3 constitute an interaction. The user does something the system understands by logging in and the system responds appropriately to the users action. This interaction consists of two separate behaviors - one by the user and one by the system.
Couldn't The User Behavior Have the
"User Must Be Authorized" Precondition?
The UML Specification describes a precondition as:
"An optional set of Constraints specifying what must be fulfilled when the behavior is invoked."What would it mean for an application to know that a user is authorized when the user logs in? Two characteristics a requirements should have are:
1) it must be testable and
2) it must be feasible
Let's examine each characteristic individually.
Is the "User Must Be Authorized" Testable?
The straightforward scenario where a user enters a password is testable. The password is either correct or incorrect. A test can be written for each case.But what about another scenario. Suppose you start to log in and you enter your password. Your manager calls you out of your office for a critical situation and you leave immediately. Someone walks into your office and hits the Enter key. That person is now accessing the use case functionality. Put on your QA hats. The question is, Can you write a test for this scenario? If so, what would it look like? If not, why not? We submit that this scenario is not testable because it involves behavior that is outside the scope of the automated system. This raises a question about the validity of the precondition. As an undesirable side effect, it also sets unrealistic expectations in stakeholders regarding security of the application. Wasn't there a precondition that only authorized users can gain access?, they ask later. But the strongest challenge is yet to come.
Is the "User Must Be Authorized" Feasible?
Remember that UML says "an optional set of Constraints specifying what must be fulfilled when the behavior is invoked" (italics added). Put on your architect hats. Can you think of a way that the system can know that the user is authorized while the behavior in Step 2, the user specifies log in, is invoked? Doesn't it actually work this way?
- The user attempts to log in.
- The system receives the log in request.
- The system either logs in the user OR
- If log in fails, the system presents a message saying that the log in failed. Note that the system does not know whether the condition "User Must Be Authorized" is true until after it has evaluated the user's request during its behavior! This does not meet the UML definition. If you have a way for the system to know while the user action, log in, is occurring that the user is authorized, please let us know. Otherwise, we submit that "User Must Be Authorized" is not feasible as a precondition.
Not Testable, Not Feasible, Not a Precondition
Since "User Must Be Authorized" is not testable or feasible it does not meet the criteria necessary to be a precondition - even if it was permitted by UML.
How Would the Building Requirements Consensus™ Methodology Handle This Situation?
The Building Requirements Consensus™ Methodology assumes that a use case completes and delivers its perceivable benefit of value or it is not a use case. Look at the first three use case steps again:
1. The user, playing the role of Secret App User, enters a password.
2. The user specifies log in.
3. The system presents the main screen.We have already covered that the functionality works as expected. We do not need to say anything else.
What If the User Mistypes the Password?
For the scenario that allows the user to recover during this execution of the use case, there would be a branch that allows the user to retry some number of times. If the user successfully enters the password, the use case completes and delivers its perceivable benefit of value. All is well.If the user does not enter the correct password on the last allowable try, the system issues an exception and the use case ends. The Building Requirements Consensus™ Methodology
defines an exception
as a way a use cases fails to deliver its perceivable benefit of value.
Applying the Building Requirements Consensus™ Methodology Simplifies Use Cases
The concepts of the Building Requirements Consensus™ Methodology applied correctly simplify writing use cases. We agree with the UML Specification and eliminate preconditions, and postconditions, while documenting use cases.
From Examples to Use Case Preconditions
From Example to Use Case Concepts 201
From Examples to Building Requirements Consensus™ Home
|
