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.
