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.
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

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio