> For the complete documentation index, see [llms.txt](https://docs.eventoframework.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eventoframework.com/getting-started/todolist-recq-tutorial/problem-description-and-requirement-gathering.md). # Problem Description and Requirement Gathering The Todo List We need to implement a Todo list application, only the backend in terms of REST API. ### Problem Description We need to implement a Todo List app where a user can create Todo Lists. Each Todo list has a name. Each Todo list contains a collection of a maximum of five todos with a proper description and a checked flag. Once a todo is checked we cannot delete or edit it and also we cannot delete the Todo list containing it. We want to keep auditing each action knowing who has created or edited a to-do list and each contained todo.

Todo list concept

### Requirement Gathering To analyse the problem we need to decompose the description in a list of requirements. Let's split the analysis into two sides: Domain and Constrains, in the next chapter we will see another technique. #### Domain Starting from the prompt we need to individuate all the entities involving the domain: > We need to implement a Todo List app where a user can create Todo Lists. Each Todo list has a name. Each Todo list contains a collection of a maximum of five todos with a proper description and a checked flag. Once a todo is checked we cannot delete or edit it and also we cannot delete the Todo list containing it. We want to keep auditing each action knowing who has created or edited a to-do list and each contained todo. By a term inspection, we can individuate three entities: TodoList, Todo and User. *** With a second inspection, we can define properties and relations between entities: * TodoList * name - the list name * todos - the collection of Todo * Todo * description -the todo description * checked - the flag indicating the completion * User * identifier - we do not have enough information about it we can use the username *** In the end, we need to identify non-functional fields and technical ones. * TodoList * identifier - the list UUID * name - the list name * todos - the collection of Todo * createdAt - creation audit * createdBy - creation audit * updatedAt - update audit * updatedBy - update audit * Todo * identifier - the todo UUID * description -the todo description * checked - the flag indicating the completion * createdAt - creation audit * createdBy - creation audit * checkedAt - check audit * checkedBy - check audit * User * identifier - we do not have enough information about it we can use the username *** #### Functional Requirements Once we've analysed our domain and all the information let's express and formalize any requirement in the form of user stories: * As a user, I want to create a to-do list in order to fill it with todos. * As a user, I want to delete a to-do list that does not contain checked todos because now is useless. * As a user, I want to add a to-do inside a to-do list to check it later. * As a user, I want to remove a todo from a todo list because it will never be checked. * As a user, I want to check a to-do inside a to-do list to mark it as done. * As a user, I want to get a list of all the Todo Lists in the systems to explore them. * As a user, I want to get the details of a to-do list in order to know every todo status.