Status Report #1 Requirements Analysis

Date: 28.05.2018

1. Status

First of all, we are renewing the requirements to remove redundant points. However, it is not finished and in the report we will have the older version. During the summer most probably we will revise the requirements and all again to match references in the requirements again. Our new requirement's current status is just fine. I think it comprehends all the requirements stated in the project description. We have divided requirements into main two categories: Functional ones and nonfunctional ones. Under functional there were two categories before, system and user requirements. However, in the last revision of the requirements it is realized that it causes redundancies a lot. Therefore, they are removed or combined. Other than these issues, our new requirements may be:

• 1- Missing some requirements due to the fact that it is too early and we cannot see them. However, most of the requirements are visible before starting implementation, I think, which means missing ones will be negligible for now.

• 2- We may written some unnecessary and hard requirements. Having good features in the application is nice but every requirement looks easy from far.

If we can find any of them we will fix them for sure.

Also, we have started a requirements analysis grooming page recently. In that page, we will write what can be added, what is unclear and replacement suggestions. We think in this way we will keep the requirements updated.

It is empty now, since we have revised the requirements recently, but you can check here and go to grooming page to see. go to requirements

2. Acquirements

Of course we have learned a lot from requirements. Some of them are:

• 1- We have learned that requirements are derived from people's own needs.

• 2- We understand that writing good requirements and finishing it first as much as possible is very important. Even if it would take most of the time and design, implementation etc. other steps hasn't started, it is worth to clearly understand the requirements first. Starting the requirements and the design is a big mistake I think, because any change in the requirements leads to bigger changes in the design and implementation.

• 3- Being simple and specific is important for requirements because when testing or implementing the project developers need to refer back to requirements and seeing there is a messy and unorganized requirements is very sad for everyone.

• 4- Learned that requirements has a well defined language, we should use "shall be able to" for required musts, and we should use "should be able to" for additional features to the project.

• 5- We have learned that, when working with a team on a project, having a requirements document is important; whereas if you are working on a small project on your own and you don't need to tell what is the project about to anyone, then only writing comments would be enough.

• 6- We have learned that communication at the beginning of the project is more important since the requirements is the core of the project and agreeing on the same requirements is very important for the rest of the project developments process.

• 7- Learned that enumerating is important due to the need of referring back in the future and referring is important for the faster communication.

3. Difficulties

• 1- First of all requirements analysis is something hard because it includes understanding people's ideas and requests. I mean it can be harder than our situation if a customer does not be clear enough. This job is hard enough that there is a job called requirements engineer.
• 2- One of the other difficulties is working on a requirements together is just hard. Every person's comprehension is different from each other.
• 3- Enumerating was hard.

4. Suggestions

We need to stick to our requirements and constantly update requirements if there is a need to do this. We have a grooming page feature for this purpose.