• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Are There Functional Requirements in Assumptions of Use Cases?

Classical training in deriving requirements from Use Cases directs the Business Analyst to go through each line in the Normal Flow or Alternate Flows of a Use Case and see if there are Functional Requirements at each step. Chances are that if the Use Case is well written and the Business Analyst is thorough, a nice chunk of Functional Requirements will be identified and captured. But what about all those things that are in the Header section of a Classic Use Case like Actors, Assumptions, Triggers, Preconditions and so on? Are there requirements hidden there? I am going to look at Functional Requirements hidden in Assumptions in this post.

Assumptions are conditions that the system assumes to be true (or false) since it does not have a way of verifying them at run time when the Use Case is executed.

Consider for a moment that you are writing a Use Case that defines specific features of a Sales Application that is used exclusively by your Sales Team and no one else. Your system is going to use an Authentication Service to validate users who want access to your application. So, in your Use Case Header information  section, you could add the following two assumptions to ensure that the reader knows that access authentication is done by a different system and that you are expecting that system to behave in a certain way.

Assumption 1 – The authentication system is maintaining the User ID and Password to authenticate users who want access to the Sales Application.

Assumption 2 – The authentication system can differentiate between Sales and Non Sales users who want to gain access to the System.

Looking at the two assumptions, writing a specific functional requirement for Assumption 1 is likely overkill. But, if you want to be safe, you will write out one Functional Requirement that the user login and password data be maintained in the authentication system.

Assumption 2 on the other hand is extremely dangerous to assume away without an explicit Functional Requirement. If the authentication system does not know that it is required to filter out valid users who pass authentication but do not meet your criteria (Sales Users only), then you will almost certainly have invalid users in your Sales Application. For this assumption, you will definitely need to provide the team that manages the Authentication System with your specific filtering requirements.

This is a very simple example to show that Assumptions can have crucial Functional Requirements hidden in them. So, the next time you are writing your Use Case, look at your Assumptions critically to see if they have hidden requirements in them.

One Response to Are There Functional Requirements in Assumptions of Use Cases?

  1. Roger L. Cauvin April 29, 2011 at 12:21 pm #

    Ajay, I think you raise some important points about the assumptions that lie behind use cases and the need to codify them as requirements. However, I think you have it somewhat backwards.

    The name of high-level use case represents a functional goal of a user or stakeholder. For example, the name of the use case “Purchase Items” represents a shared goal of the store owner and customer. The goal is functional; i.e. it’s an activity the actors are collaborating with the system to achieve.

    This activity is the only true functional requirement the use case represents or implies. The individual steps reflect into how we’ve designed the interactions to achieve the larger goal of the activity. The individual steps only reflect or imply “requirements” in the sense that we have made design choices such that the system “must” support them. They are not required from the point of view of the user; the user could possibly achieve her goals with a different sequence of interactions that still satisfy the larger goal.

    The hidden assumptions in a use case generally are nonfunctional requirements. Security, for example, is a nonfunctional requirement. How secure must the system be? Who should be able to access the system, and who shouldn’t be able to access the system? Answer those types of questions in measurable terms, and you have defined the security requirements. They are not functional requirements, because they are attributes exhibited as users and system engage in the activity, the functional goal the use case name represents.

    In summary:

    1. The name of a high-level use case represents a functional requirement.
    2. Many assumptions lie behind a high-level use case, and those assumptions typically are or imply nonfunctional requirements.
    3. The individual steps in a use case represent a functional decomposition we’ve designed, and the steps imply “requirements” only in the sense that the system must support the interaction design choices we’ve made.

    See my classic blog entry on black box use cases for more information.

Leave a Reply

Your email address will not be published. Required fields are marked *