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).
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).
Comments
Less is more.
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.
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.
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....
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
putchavn@yahoo.com
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.
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.
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
putchavn@yahoo.com
12JAN15
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.
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...
Thanks
Varun
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.
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
putchavn@yahoo.com
08NOV18
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.