US: RepairRequest overview

[MiKessels]

As a repairman or volunteer I want to have an overview of repair requests, so I can manage to complete them.

Description

When the volunteers (users) add a repair request, the repairman must be able to see all the repairs requested in an easy way. Therefore are some requirements for the requests made by the volunteers.

Acceptance criteria

• Migrate the 2 current views into one (repairman as default with bottomnavigation from volunteer
• Implement API endpoints #37
• Create overview on all repairs #38
• Create detailview of repair #39
• Create a view to add a repair #40
• Create mock server in Postman #41

Criteria for a repairrequest

• Title
• Description (long/short)
• Location
• Priority
• Extra textfield for repairman to take notes
• Status

Tools

[MiKessels]

@joeyvonck @Prupke If the criteria for a repair request are different than your design, feel free to add, delete or change the criteria.

[cyrildewit]

@MiKessels little tip about what acceptance criteria means. It's usual a list of hard requirements that must all be implemented or finished, before a ticket can go from the status ready on acceptance to ready for production. You, me, other non-it'ers should be able to use it to assert that the ticket is finished. They cannot be a list of tasks, because the criteria wil be used in many steps of the development process. You use it for example to develop your work. The product owner uses it to make sure focus is laid on important topics. Functional testers can use it to assert the ticket is implemented correctly.

I usually maintain a technical tasks list to work out. Creating this list is part of the design phrase and can of course be extended at anytime in the process.