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?
