I am trying to figure out some questions to help me decide whether a use case should be written for that requirement or not. Is it neccesesary to have a use case for each requirement?

E.g I have a functional requirement which is about creating a new DB table for the new parameters that will be selected from the UI. The FR also states the what ariables should present each parameter in the table etc.

  • 2
    About the functional requirement, isn't specifying that a DB table should be created beyond the scope of what a functional requirement should be about; and which variables to use even more so? – Kasper van den Berg Feb 5 '15 at 14:21
  • You don't write use-cases based on requirements. It should be the other way around: You start with a use-case and you derive functional requirements from that. – Bart van Ingen Schenau Feb 6 '15 at 16:09
  • What you have doesn't look like a requirement at all, but rather a piece of design that can be fed directly to a machine for implementation. – Bart van Ingen Schenau Feb 6 '15 at 16:10

Questions to decide whether to write a use case:

  1. Will (or might) a use case provide more information to the business, the developers, and/or the user about:

    1. whether the requirement should be implemented;
    2. what priority the implementation has?
  2. Will a use case give the developers more information about what functionality to build?

  3. Is the requirement about stand alone functionality or is it an inseparable part of something else?

    [Edit, as requested per comment]

    To distinguish whether a requirement is stand alone functionality or not you can consider the following:

    • Can a system that implements this requirement and another system, that is completely the same as the first except in that it does not implement the requirement, both (in theory) exist?

      For example, if you have an access control system allowing people entry to a building. The use cases "allow an authorised person to enter the building" and "allow an authorised person to leave the building" are two independent use cases, even though they are very similar from an implementation/design perspective and when "allow an authorised person to leave the building" is not implement while "allow an authorised person to enter the building" is implemented the building would become very crowed, hypothetically we could implement one and not the other.

      If so, then this is a good candidate for a use case.

    • Is this requirement an extension of some other requirement? I.e. some other use case must be implemented for this use case to make sense.

      For example, "authenticate persons on sight within 100ms" is a refinement, i.e. an extension, of the more general "authenicate persons". Another example, "allow only authorised person to enter the building" can not exist without "enable ersons to enter the building".

      If so, then you can often still model it a separate use case and most methodologies do have some way that you can specify Use Case A extends Use Case B.

    • The third category are requirements that are inseparable.

    [Currently I can't give an example.]

    When you have a group of requirements that belong together, write a single use case for them.

  4. Does the software engineering methodology you follow or the project procedure require use case documentation?

  • Thank you. I have to write the use cases mostly because of the methodology and procedures. About your 3. question out of curiosity: how would you approach something more abstract? – Cemre Uludag Feb 5 '15 at 14:48

A functional requirement wouldn't state that a new DB table needs to be created so that different layers of your application can relay user input from the UI. And it certainly shouldn't specify the schema of the table.

What you have is not a Function Requirement. It may have started off as one but it looks like somebody along the way has suggested some implementation details.

Do you still have the original FR? If so, you should be able to write use cases around that (which wouldn't reference any implementation details).

  • So perhaps with a functional requirement that has degenerated into implementation details a use case, that specifies WHY the user wants some data stored and what the user wants to do with the data, is more important than ever. – Kasper van den Berg Feb 5 '15 at 14:28
  • Interesting point. That's if the implementation details were actually specified by an end user and not somebody else who was just trying to be helpful. – MetaFight Feb 5 '15 at 14:32
  • @MetaFight9 The implementation details were actually specified by the customer. I am a junior analyst so I am not sure how should I treat implementations details as you say. @KaspervandenBerg In that case what would be the right way to present that implementation detail in a use case? – Cemre Uludag Feb 5 '15 at 14:43
  • 1
    It depends on the use case, often the right way to present that implementation detail in the use case would be not. However, the use case might be "the new system has to interact with system X, then you can specify that the interface with system X is a database table structured as ... . – Kasper van den Berg Feb 5 '15 at 14:48
  • There is never a need to specify that "the interface with system X is a database table structured as"....in a Use-Case. If you want to add a notes section to your use-case then you put it there but the use-case itself doesn't need those types of details. It only opens the floodgates to adding other types of details which in the end makes developing the use-cases take way longer than it should and makes the use-cases fairly worthless because the useful information you are supposed to gain from them is buried in the details. – Dunk Feb 5 '15 at 21:24

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.