Thursday, July 28, 2005

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


Michael Craig said...

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.

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

Putcha said...

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.

Putcha V. Narasimham said...

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

The One with Varun997 said...

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