I am wondering how you would describe the functional requirements for a large/free system like Photoshop or Excel. In this case, we want to describe the requirements of an existing system which we are redesigning now. Since the software is about 10-15 years old, it's a challenging project at various points. The description is needed to make the cost estimation and also to hand it over to the it-architecture team.

Like I said we are now describing the functional requirements of the system, based on the existing system and the current functionalities of the software. We tried it with use cases at first. But every use case came up with a bunch of different ways to be solved. With the common approach to describe one main path and a few alternative/error-paths we didnt come very far.

In the second step we tried to write down user stories. This approach was more effective but the difficulty is the level of abstraction. Some user stories were broken down into one specific action like "As a user, I want to copy elements of type-x, so that I can expand my plan into the future." - which is pretty clear. Other ones were like "As a user, I want to increase the capacity of element-y, so that I can satisfy the expected market demands." and thus described a requirement which the user can solve in different ways and also has different reasons for.

So..Besides the use cases/user stories, how would you generally approach the description of the requirements for such a system? What do you think about the approach of writing user stories and which level of detail is right?

  • Maybe step away from all of the data you have and simply ask 'Why are we redesigning this? Fundamentally, what does it need to do that it doesn't do already? Start with a list of 5 absolute essentials, see how much you can boil it down and I'm sure all the other requirements will spring out of this list.
    – user43251
    May 22, 2014 at 8:27

1 Answer 1


I don't have experience with this yet, so this might not answer your question fully. But have you looked at job stories? Introduction to Jobs-to-be-done here

This article goes into why job stories are better in some cases (and I believe in your case) than user stories.

Since you compare it to photoshop and excel, I think you have a system that has many goals or functions. With describing your job stories you can get the functionality and the goals of your system on paper. I don't actually have put it into practice yet, because I did all of the research for a design project I will start in 2 months.

I'm not very good at explaining in English either, so here is a whole bunch of other information on the subject:

Focus on causalities rather than personas

Jobs-to-be-done Interview On the 'official' JTBD website.

JTBD in practise on designing

A whole company based on Jobs-To-Be-Done research

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.