Open cgendreau opened 6 years ago
I think this is a very good idea. Use cases are a great way to ensure that we are moving in the right direction. Personally i think it would be nice if the name of the use case could describe what it is and if its located in a module folder i guess the identifier dont need to include the name of the module. Thinking of something like [id]-[description-in-dashes-that-potentially-can-be-long]
My main concerns would be when a use case is renamed (for example we change the scope). Then we need to update all the references and it can be tricky (e.g. commit messages).
I definitely like the idea of restructuring the repo the way you describe @cgendreau. I think that changing the structure could make it easier for us to collaborate on this. I also like the idea of having descriptive names as mentioned by @antonoberg (we'll see how to solve this...).
I may have time to look into this in the beginning of next year. Anyhow, I will talk to @lisasund already next week and keep you informed.
@kcranston and I could already start moving taxonomy use cases in the develop
branch (using descriptive names).
@cgendreau and @kcranston: Please proceed with doing this.
Done inside 'taxonomy-uc' branch https://github.com/DINA-Web/dina-use-cases/tree/taxonomy-uc/taxonomy
Very good!
I talked with @lisasund today and she also likes your ideas of how to restructure the repo. I will start restructuring our use cases in the same way when I'm back after x-mas. I'll keep the issue open until it has been done.
Currently, we look at the repo as a knowledge bank, so feel free to merge your stuff into the master
branch if you wish! We might want to give the repo a more formal status in future.
I split the collection use cases: https://github.com/DINA-Web/dina-use-cases/tree/split-collection-uc/collection
We still need to update them so they use the same template.
Looking at the use cases, I'm unsure how to develop them, and how (in)complete they currently are. Do you have a plan about how to use these @kcranston & @cgendreau ?
Earlier use cases on this repository have been used mostly for describing edge cases, so that they would not be forgotten. (Correct if I'm wrong @jmenglund )
Development at NRM especially during the last months has been based more on short "user story" type of descriptions of user needs. These have then been implemented as features in cooperation between developers and other team members during our sprints. No formal use cases have been written. This is agile, but isn't effective for distributed planning, so something more is needed for this part.
Thanks for the clarification, @mikkohei13 . Helpful to know the info about edge cases (explains a lot about the scope of what we found here). Are your user stories available somewhere?
Our plan going forward is to use this repo to document use cases across the modules - adding new use cases for missing functionality, prioritizing existing use cases, etc. It doesn't really matter to me what format we use (use cases vs user stories) but I think it is important that we make this documentation available and have a means for comment / discussion.
Earlier we used mostly Redmine to capture user stories https://support.dina-web.net/projects/dina-web-collection-management-system/agile/board, lately we have just Google Docs file for sprint goals and list of higher-level features to have. (I can send a link.)
I feel that user stories or something less formal even would be good basis for discussion. Use cases are too focused on how to do something than what to do in the first place. (As I see them, though there are different ways of making/using them.)
I agree, we don't always need use cases and we can have both here (use cases and user stories). Some user stories may evolve in use cases if necessary (inside the same document). The main goal here is to capture the requirement (in a single place) and be more specific with system interactions when it brings something new and/or useful.
The main goal of the following suggestions is to make it possible to reference and search use cases more easily. It would also bring the revision history at the use case level instead of having it for the all use cases.
Example:
Of course, this is all open for discussion.