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