Skip to main content

Use Cases: Requirements or Design?

When a product manager writes a market requirements document (MRD), she typically includes a section with use cases. Use cases describe how actors interact with the product to achieve goals.

Use cases typically come in one of two forms. A use case diagram merely depicts the actors and use case names without detailing individual interactions with the product. Text use cases are narratives that detail actor interactions with the product.

Since use cases come from the user perspective and treat the product as a black blox, they play a useful role in requirements documentation. But do use cases communicate requirements or design?

Craig Larman, in Applying UML and Patterns, answers that "use cases are not exactly requirements or functional specifications, but they illustrate and imply requirements in the stories they tell." I agree with Larman but would like to draw attention to some distinctions.

The names of the highest-level use cases of a product communicate functional requirements. Such names should reflect the highest-level goals that stakeholders are trying to achieve to overcome the problems they face. A functional requirement states what the product must do to solve or avoid a prospect problem. Since use case names imply what the product must do, or at least help the user do, to solve a prospect problem, it follows that the names of the highest-level use cases represent functional requirements. Therefore, use case diagrams that depict the highest-level use cases are appropriate in a requirements document.

However, text use cases do not represent pure requirements. When we describe how a user interacts with the product to achieve goals, we venture into product design. For example, if you specify that the user of a TV presses a button to turn it on, you have already gone beyond requirements and into solution space. Not only have you prescribed a particular solution for switching on the TV, you have assumed that turning on the TV is a necessary step in achieving the user's real goal, which is watching TV. Fleshed-out text use cases are not appropriate in requirements documents (except perhaps to provide background information about how customers currently achieve their goals without using the product, or perhaps to illustrate one possible way the product might meet the requirements).


Great post, completely agree. Too many BA's get bogged into designing their use cases and simply end up wasting time and money.

Less is more.
JuanCarlos said…
Good Points! For the use case to represent requirements, it is important for the business analyst to NOT include design elements in the use case and to focus on 'What' the system has to do rather than on 'How' to do it. Therefore, I scan my use cases for the word 'click', 'point', etc. and reword sentences to ensure I do not inadvertantly include design in the use case that would un-necessarily constrain the application developer.
Roger L. Cauvin said…
Juan, thanks for your comment. I have a somewhat unconventional view: it's virtually impossible to keep design elements out of fleshed-out use cases.

Some point to the distinction between "real" and "essential" use cases. I maintain that no use case containing more than two steps is purely essential (i.e. completely free of design assumptions).

Fleshed-out use cases are very useful, but for specifying interaction design, not for specifying requirements.
Rupinder Parmar said…
What if you have to assume a design decision. This would be espeically true in case of software maintenances. For e.g. to maintain consistency on a particular screen when a new feature is being added to it, if everything else on the page is a drop-down, the new feature would be a drop-down, and thus gets reflected in the use case.
Roger L. Cauvin said…
Rupinder, it's useful to think about why you are adding a feature and why you think it should be a drop-down.

The feature and the drop-down are not themselves the requirements. The reasons for them are the requirements.

When you are enhancing an existing use case, the trick is to decide the preconditions, postconditions, and invariants of the use case that are changing, and that are motivating the change to the sequence of steps within it.
brad said…
Think you need to provide a little more context for terms like 'requirements', what roles you have in your organisation and what level of detail your use case goes to, to help articulate your point.

From my perspective, a detailed use case, that describes the interaction of a user with an interface(of a system), must be specific. The BA must/should have involved designers, usability, actual users & the business to write it. Therefore this use case is defining User/Functional Requirements.

This use case is used to realise the Business Requirements (captured earlier) - that defined WHAT needs to be achieved, but not HOW....
Arrived here via Requirements Engineering discussion on Requirement and Interaction Design.

It is important to recognize the distinction and stop over-specifying but over-specification is less harmful than under-specifying and leaving everything to be revisited and specified at the time of design and implementation.

In OOAD UML, it is not necessary to make a fuss about the distinction.

At times, a design may express a requirement more clearly than a pure statement of requirement. In any case, the designer can recognize the situation and give a superior design if he or she is capable of it.

Putcha V. Narasimham
Roger L. Cauvin said…
brad, what you're referring to as "user/functional requirements", I call "design", for it is the deliverable that results from someone having designed the user interactions with the system.

The only true requirements, in my view, are what you're calling "business requirements". Functionally, the only thing "required" to satisfy stakeholders is to deliver the functionality communicated by the name of the use case. The sequence of steps is an interaction design choice.
Roger L. Cauvin said…
Putcha, I agree that design specifications can help communicate requirements. However, when you state, "a design may express a requirement more clearly than a pure statement of requirement", I think you have to be careful.

Often, in such cases, the lack of clarity in the "pure requirement" is an indication that the requirement is not fully understood. It's usually possible to express a fully understood requirement as a pass/fail measurement.
Roger Cauvin: I wanted to quote and cite your "Test for PURE requirement" but I landed here. but your TEST is not available here.

You said (not exactly in these words): Test if the statement of requirement suggests some way of meeting or satisfying the requirement. If it does, it is NOT a PURE REQUIREMENT. If it DOES NOT then it is a statement of PURE REQUIREMENT.

This is very profound and I got it only from you and I keep quoting you. Since the searches are NOT turning up your original statement, you may as well make the statement afresh and establish your claim of having said it first.

All the best,

Putcha V. Narasimham
Roger L. Cauvin said…
Putcha, thanks as always for the comment and the kind words.

Please see this blog entry on requirements testing and let me know if it contains the statement you would like to cite.

I've made similar statements in several forums, so the exact one to which you're referring may be buried elsewhere.
Q1. What can be the objective criteria to distinguish between a requirement and design?
Q2. Sample Statement: I have an example where a user needs to create multiple entries like in excel sheet. If I state that the user shall have the option ADD,DELETE OR MODIFY an entry after she has created an entry.The System shall provide the option to submit the entries once filled.
Does the above statement transgress requirements boundary specially when I say that the system shall provide or user shall get option...

Roger L. Cauvin said…
Varun, thank you for the question.

Please find my definition of requirement here. You can use it to distinguish between a requirement and design.

The first question to ask is what customer or market problem you intend to solve. Then you can determine the least stringent condition that would indicate the absence of the problem. That condition is the requirement.

In your example, I see that you are proposing a solution, specifically something resembling CRUD functionality. Usually, a CRUD specification represents design. It also presents opportunities to consider the problem CRUD is intended to solve, in the context of the user's higher-level functional goal.

Thus to reveal the true requirement, you will need to determine - and clearly express in measurable terms - what problem this proposed solution is intended to solve.
Roger Varun and Roger again:

I thought that your test of pure requirement is really profound. I will have to dig into my notes to discover your original post but I am surprised you are not able to locate it. Anyway your answer to Varu reflects your concept of "pure requirement". You have rightly pointed out that CRUD is a means of satisfying a need but not of the need itself.

The same example also proves my point that people find it easier to indirectly specify a need through a design specification (like CRUD) than specifying the user or business need.

Putcha V. Narasimham
Roger L. Cauvin said…
Thank you, Putcha. You rightly point out that identifying and specifying the true business and user needs is hard. But as some have stated, a problem understood is a problem half solved. So it is worth the effort and thought to understand the problem. Thinking of requirements in this way makes for more effective problem-solving.
This comment has been removed by the author.
Dear Roger and Putcha, many thanks for your responses. I now understand that the root of my question and confusion "whether CRUD specifications are design or requirements and is it a BA's job" is really in the vocabulary used in software development projects ( specially IT service companies).
As the teams need detailed specifications for s/w development, the role of BA is to deliver s/w specifications beyond only stating the business need/requirements and these specifications are generally called requirements.I believe the correct use of these terms i.e. 'design requirements' and 'business requirements' shall clarify this confusion. But the additional question I have is whether gathering of design requirements is a BA's job? I must say as per IIBA notes, gathering information on use cases (flows) and use case modelling (which is nothing but detailing the user/system interaction) clearly allows/ makes BA responsible to perform this job.Going with this logic I would say stating the CRUD specifications is "design requirements" and BA of the project can detail it. What's your take on this?

Thanks for your time to read this.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Use Case as a Black Box

Consider the following use case: Purchase Items Actor: Purchaser Precondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40. Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased. The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items. What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement . Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint: Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no

Henry Ford's "Faster Horse" Quote

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the