I agree with Pawel to keep your WBS for this project as simpe as possible. A WBS is deliverable-oriented, so I would not add the individual tasks right away. Tasks are added in the next step when you have a clear understanding of the full project scope.
Focus on every deliverable that needs to be produced in order to come at the end of the project. Project scope includes both the product scope and the supporting processes to create that product.
Everything that is not included in the WBS is out of scope and will not be done.
So my WBS for the above project would look something like this
1.1 Requirements analysis / Product backlog
1.2 Domain Model
2.1 Authentication Module
2.2 Task screen
2.3 Search module
2.5 Reporting module
2.5.1 Basic reports
2.5.2 Admin reports
In principle you could break it down further to each individual report, if that would be appropriate. Size of each deliverable is important here: if one report only takes an hour or two or it is only a single task to develop one, than this level might be too detailed for follow-up. That is the idea behind the WBS: you break it down up to a level of detail that makes sense for organising your project. The lowest level is the work package level = a deliverable that you can further break down into tasks, like Pawel did. Detailed analysis can be part of each deliverable, or combined into a single deliverable (requirement analysis document for instance), depending on how you will organise the project.
Next you have to add the other processes that surround the creation and deployment of this application. That might look like the following:
3.1.1 Test scenario's
3.1.2 Final system tests
3.1.3 User Acceptance testing
5. Business Roll-out
5.1 Support organisation
6. Project Management
6.1 Project Charter
6.2 Status reporting
The next step is to write down a few (or more) sentences about each element of your WBS (called a WBS dictionary). It doesn't have to be a complete analysis, but it should help everybody understand what is going to be done (eg for training: are you going to write a complete manual, an online help file or just some powerpoint slides with some screenshots; the same with the reports: list the number of them and a fwe words about their contents, ...). The aim is to have a clear understanding of what will be realised.