I have been arguying with a developer who insists that 1 functional request (FR) == 1 use case (UC). I think that is nonsense as there are requirements often describing situations arising from the same point - for this the use cases have alternate flows.

For example:

FR01 - User can log in
FR02 - User's account will be locked after 3 incorrect passwords.
FR03 - Logged user can log out

I believe all these can be nicely captured within a single use case, describing the interaction between the user and the system.

But maybe I am missing something?

EDIT: According to the book "Use Case Modeling" from Bittner, Spence:

a use case contains a set of description of requirements, the requirements are presented in the form of narrative rather than an itemized list...

So I would say definitely more requirements can be captured within a single use case.

  • I'm assuming FR = Functional Requirement
    – metacubed
    Jul 16 '14 at 8:41
  • Yes, of course. and UC=use case..
    – KhDonen
    Jul 16 '14 at 8:56
  • 1 FR does not equal 1 UC. Typically what you'd do is write the use-cases and then figure out what requirements can be derived from the use-cases and that most certainly will not be a 1 to 1 mapping. Each use-case will result in quite a few requirements. However, from your examples, I'd say FR01 "User Login" is the use-case, but FR02 would be an alternative scenario. FR03 would be its own Use-Case. OR you can simply have "User Authentication" use-case that contains all 3 as separate scenarios. There's no hard and fast rules, just what is most useful. More use-cases is definitely not better.
    – Dunk
    Oct 14 '14 at 18:49

A use case describes an independent, complete interaction done by the user. Think about what the user will be doing.

A use case is descriptive. It describes the motivation of the user, what purpose the feature serves, why the feature is important, etc. It does not have the "hard" functional requirements used in a PRD. But it describes the same scenario with more context.

Then break that down into "hard" functional requirements. Based on your examples, I think you are mixing the two scopes. Assume the example of a shopping website:

UC 1: As a customer, I want to log in to the site so that I can save relevant data to my profile. This helps me to save time and effort by entering the data only once. I want my data to be secure and visible only to me.

FR 1.1: If user is already logged in, they should not be able to log in again

FR 1.2: If not logged in. a login screen should be shown

FR 1.3: If login is successful, ...

FR 1.4: If login is unsuccessful, show an error message.

FR 1.5: User's account will be locked after 3 incorrect passwords

and so on.

  • But that is it - a single use containing more than one functional requirement. As the book I mentioned stated - it is just narrative way instead of a list of requirements. As usually you have FRs, then build UCs to describe them as an interaction. In addition, your example places FRs within a UC - there must be steps done by the user and responses from the system. THis does not make much sense..
    – KhDonen
    Jul 16 '14 at 9:24
  • In your example, you are mixing functional requirements and use case steps. Use cases look like: User clicks on Login. System opens a dialog. User enters a password...
    – KhDonen
    Jul 16 '14 at 9:28
  • A use case is descriptive. It describes the motivation of the user, what purpose the feature serves, why the feature is important, etc. It does not have the "hard" functional requirements used in a PRD. But it describes the same scenario with more context. Let me expand on my answer.
    – metacubed
    Jul 16 '14 at 9:33
  • 1
    I see your point but you basically say that UC01 contains FR1, FR 2... and that is my point. According to the books, it is correct - a single use case describes functionality of one or more requirements. So it is not true that 1 FR = 1 UC
    – KhDonen
    Jul 16 '14 at 10:58
  • @KhDonen:Use-Cases tend to be more useful and less brittle when you don't specify implementation (just like requirements). So your example should be more like: User initiates Login. System authenticates login information. The fact that there's a Login Button which opens a Dialog that lets the user enter their password is a design-time decision. If you have to do the login exactly as you described then that can be handled by a "notes" section of the use-case.
    – Dunk
    Aug 15 '14 at 16:24

There is no single rule to govern your situation. There are valid arguments for a single use case for all your requirements, and there are valid arguments to make each function a use case. Either is fine. Agile isn't about the methodology, it's about getting the work done.

If you can easily get all of the requirements done in a sprint, and that work can be accurately estimated, there's no need to break it down into separate stories. In fact, one could argue that doing so makes more work for the team, which is definitely not agile.

On the other hand, if some of those requirements are hard to implement and some are easy, and some you want to get into your users hands as soon as possible, breaking the story down will make your sprint easier to manager. This would result in you being able to deliver some of those features easier, which definitely is agile.

The goal is to get the work done. If doing all of that work as a single story gets you closest to that goal, do it. If making the requirements separate stores, do that.

Keep focused on your real goal, which is to deliver high quality software.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.