Can, or Should, Use Cases Contain All System Requirements?

Yes, you can write use cases that contain user requirements, business requirements, functional and non-functional requirements, contain the definitions of business rules, and list the technical constraints on the software architecture.

You also could put the system code into your use cases. You could do all of this.

But should you do all of this?  No. Never.

Scope of Use Cases

The scope of a use case is to specify the behavioral requirements of a software system. These are the specification of what behavior the system will provide to meet a user’s goals.

A properly scoped use case does not discuss design, technology, user interface widgets, screen flows, data formats or communication protocols. A proper use case conveys “what” the system does to meet the user’s goals, not “how” the system will be implemented to do this.

Use cases do have specific relationships to business requirements, functional and non-functional requirements. I hope you will avoid the confusion that use cases contain and define these various types of requirements.

The diagram below illustrates the correct relationships:

Business requirements constrain the other three types of system requirements. Business requirements determine what must be satisfied to meet the goals of the business. These are rather high-level compared to the content of a use case or a functional specification. All of these other requirements must enable satisfaction of the business requirements, which serve as the target, or reference, for everything we do in our project.

Non-functional requirements describe what a system “is”, that is, the properties of a system, not its functionality. Non-functionals describe security, performance, scalability, availability, reliability, usability, etc.: all of the “-ilities” for our system.

Functional requirements describe what a system “does”; that is, the total functionality that must be implemented, deployed, and maintained. These requirements are constrained by both the business requirements and non-functional requirements. Every line of code that we write should be in our system because it enables achieving one or more business requirements. And every line of code should be written to conform to the defined properties of our system: its non-functional requirements.

Use cases capture our user requirements; that is, the behavior our users will see that allows them to achieve their goals. Note that the use cases are a proper subset of the system’s functional requirements. So, use cases also describe what a system “does”, but with a different perspective than the functional requirements. A use case describes “what” a system does through the interactions of a user with the system to meet that user’s goals.

The key to understanding the relationship between use cases and functional requirements in the diagram above is:

Use cases describe a proper subset of system functionality

Use cases are a form of functional requirements; specifically, that functionality that is linked into a sequence of user-system interactions

There are functional requirements that are not properly expressed in use cases (e.g., requirements for internal algorithms that are not directly visible to the end-user)

Use cases describe that limited set of system functionality that is visible to users and which contributes to meeting the user’s goals

Business Rule Definition

It is productive to avoid defining business rules inside your use cases. Put these definitions in a separate business rules document, or in a business rules section of your software requirements specification. In your use cases place references to these definitions. The reasoning here is not complex. If you have a business rule that applies to multiple use cases, or to your entire system, you do not want to duplicate that rule N times. You will want to follow the practice of programming languages which allow you to define a variable once, and then declare references to that variable as many times as you want. Let your use case enforce your business rules, but do not define these rules in your use cases.

The Bottom Line

Requirements categories differ qualitatively. Each category focuses on a particular perspective that your software should satisfy. Use cases define your user requirements, and they enlist the services of various functional requirements to meet users’ needs and goals. They also enforce business rules, but do not define those rules.

Not only are use cases not all of your system’s requirements, they define a relatively small percentage of your total system requirements. Do not neglect your other requirements by forcing them into your use cases. Doing so will make your use cases brittle, boring and unreadable. Use cases are just another tool in your requirements toolbox; they should never be confused as being the toolbox itself.