2

I have a subfunction, which is referenced in a number of my use cases. It looks something like this:

  1. User has the system fetch a list of all requests.
  2. User can filter and sort the list (filtering/sorting details below).
  3. User chooses a request and has the system fetch the full details of the request.

I wish to detail exactly which data is required at which step, something like this:

  1. User has the system fetch a list of all requests, including request id, date, status.
  2. --||--
  3. User chooses a request and has the system fetch the full details of that request, including service name, service type, date.

I want this because I know exactly what data is relevant for the user to be able to carry out particular actions in my use cases. Would this information generally be considered too low-level? E.g. looking at Alistair Cockburn's book I'm unable to find an example, which would have this kind of detail - they all just vaguely state "system presents report details to the user" and that's it.

1 Answer 1

Reset to default
4

How far are you along in designing the system?

If your painting a broad picture in the early days of the project then a simple user can list and filter requests saved to the server and drill down to their specifics is enough detail to get everyone understanding the point.

If your developer and testor want to write code, and setup tests then that isn't enough information. They will need to know what details are being listed and can be filtered on, as well as what details are provided in the drill down. These things usually collect meta-data that you don't want public.

At this point though I wouldn't be writing it in a sentence. I'd be drafting it into a table along with formatting information, filter types, and all of those details. Much easier for a developer or a testor to answer their own questions, and for them to spot deficiencies.

3
  • I am trying to write a proper functional spec for a project, based on a client-provided description, where UI elements, functional & tech requirements, open questions, etc. have all been thrown into a single pile. The main purpose of the document is to be able to evaluate the scope, and these details would thus be irrelevant. However, the client did specify what data to display when, and I feel like I should include that in the spec because: 1) my company won't be the one implementing the project and 2) I don't want any of the provided information to be "lost in translation".
    – Avius
    Commented Jan 20, 2021 at 14:14
  • @Avius I'm no Business Analyst, I'm a Dev by trade though I get around a lot. By scope I presume this document is going to be used to figure out how much money is changing hands, and/or when it will be delivered by. I'd provide a high level overview, and a medium level description of each desired functionality in a single document. Place all of the extra details (like specific columns) into a second details document. This way one document paints the general purpose, reasoning, and feel of the system. The other is a kind of Open Question/Answers document capturing those extra details.
    – Kain0_0
    Commented Jan 20, 2021 at 22:48
  • Your assumption is spot on : ] That's kind of the route that I have taken, except that I am putting all these details in the same document but in an entirely different section. This allows me to reference them with links where appropriate.
    – Avius
    Commented Jan 21, 2021 at 1:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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