ArgonDigital - enterprise automation experts

Share This Post

Use Case Assumption vs Pre-Condition – Continuing the Conversation

In response to this post, Bruce Melendy asked:

“I have a use case in which a user requests access to a restricted form. As part of the flow they must either a) create an account; or b) log into an existing account.

“I am assuming that most users do not already have an account (or don’t want to use an existing account) and so will do a), which is therefore a step in the normal flow; b) is handled in an alternative flow.My question is, is my assumption regarding a) an *assumption* or a *precondition*? Strictly speaking the use case can start whether it is true or not, so it would not appear to be a precondition. However, given the definitions you and Debbie have given, I don’t see its being false as an occasion to reevaluate the requirements. On the other hand, its being true helps the NF make sense.

This suggests to me that there is another category of assumptions that inform a use case: things that must be true for the normal flow to proceed (or make sense). Not all NFs would involve such assumptions, but where they do it seems useful to distinguish between this sort of assumption and that which, as your examples indicate, lie outside the scope of the use case and if false might lead to re-evaulation of the requirements.”

Bruce, thanks for a great question! I agree, this would not be a pre-condition.

As far as whether or not it is an assumption, my question would be—does it impact your requirements? If it does, I’d document it. If it doesn’t, you don’t need to. The assumption that most users do not already have an account could imply a usability requirement about how easy it is for new users to find and access the create account function. In this case, I’d document it, because if it is wrong, then the requirement is unnecessary. Also, if you’re working in an environment where the use case steps are considered requirements for the user interface design team (i.e., the fact that it is in the normal course means they need to optimize the user experience), then it is an assumption about requirements and needs to be documented.

If you’re simply anticipating that people will ask about your selection of create account as part of the normal flow and you’d like to provide an answer in the document, there are ways to handle that. You could add it to the description of the use case. You could foot note it. Or, you could even add it to the assumptions section, depending upon how your audience will receive it there. Most audiences are fine with a few extra assumptions that aid their understanding, but don’t align with the strict definition of a Use Case assumption.

Use Case Assumption vs Pre-Condition – Continuing the Conversation

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage