By the way, I do agree that we should probe if “too much time” is really the users’ concern, or if “too difficult to find” is more accurate. Either way, we need to be able to formulate it in quantifiable terms.

You’re of course preaching to the choir about use cases and the design inherent in fleshing out the steps.

But the question still remains about the relationship between interaction design and functional requirements in your model. In your model, by “functional requirement”, do you mean what Wiegers means by the term (i.e. functional specification element)? Or do you mean the functional goal of the use case?

You raise a VERY good point about the challenges of embedding design into use cases, as they imply sequencing. I think that is one of the reasons I’ve migrated to use case briefs and user stories (depending on the teams with whom I’m working) – easier to avoid embedding a procedure or process design in the description of “what a user needs to be able to do in order to achieve a goal.”

On #1: I guess I see ‘acquiring a classic kid’s toy…’ as a practical goals of the user, which is then manifested as user stories for find and order.
On #2 – the limits on time, without segue, I’ll agree that it is acceptance criteria for a user story. With use cases, I would identify it as a constraint that applies to the use case.

With segue in hand, I would say that the surveyed users expressed “too much time” as their criticism, but I would wonder if that’s really what it is. “Too difficult to find” is more representative of the way you described it. I think you could approach solving the problem with several implementation approaches, one of which is ‘make it faster’, but really the goal is ‘make it easier.’ Assuming you had used an example that was explicitly time-dependent (like recharging a defibrillator in under X seconds), I would stick with my #2 response above.

Could you elaborate on what a functional requirement is in this context?

The Wiegers view (to which I do not subscribe) is that you define the steps in a use case, and that each of these steps represents, corresponds to, or calls out, functional requirements of the system. A consequence of Wiegers’ view is that functional requirements come after, and are determined by, interaction design (since interaction design determines the steps in use cases). Thus Wiegers’ view is incompatible with your model, since your model shows interaction design coming after functional requirements.

1. Finding and ordering classic kid’s toys are essential functional goals.
2. There need to be limits on the amount of time it takes to find and order the toys.

How do these two items fit into your conceptual model?

In my conceptual world, the first item would be a functional requirement and could be represented by the identification of a use case or user story. The second item would be nonfunctional requirement and could be represented by the use case’s preconditions, postconditions, and invariants or by the user story’s acceptance criteria.

thanks for another useful article.