You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I will copy-paste the feedback from Piazza here. We all should solve them when we have the time. Please cross out what you have completed so that we will be able to track them.
Requirements
In Glossary: Rather than Users, you may want to add separate entries for normal users and food serving outlets since there will be differences in their roles and capabilities.
Please also enumerate non-functional requirements.
Most of your requirements start with “The application shall…” or “The system shall…”. This style is only appropriate for requirements that are not based on direct user interaction. It is also important to emphasize for which type of user a requirement is written for. For instance: Req. 1.2 should be something like “The users shall be able to see the total amount of calories a food has”. Another example: Req. 2.1 should be “The users shall be able to filter the searched content according to their preferences”. Regarding this example, the Req.s 2.2-2.6 are actually elaborate on Req. 2.1, so you may actually make these Req.s subitems of 2.1. Think of it as first presenting a general requirement and then going into details. Please revise all your requirements according to these suggestions.
Req.s 1.7 and 1.9 are not really features that the customer wants. The informational aspect of your project is more focused on nutritional information and personal diet awareness.
It is important to make a distinction between a registered and non-registered user, since their capabilities will be different. For instance, a non-registered user should not be able to tag, comment or rate food or make any other contribution. They may use search/filter or browse content though.
~~You do not have any requirements about semantic tagging, semantic search and web annotations. Please do a little research on these concepts and think about how they can apply to your project. After you write the related requirements, we can talk about how they can be changed or improved.~~
~~Req.s 3.1 and 3.2: What can be these keywords, i.e. can a user search for an ingredient, a tag or will you simply employ string-matching with the name of the food?~~
Req. 4.1: Please elaborate: Make comparison how?
~~Req.s 6.2 and 8.2: You write about information in a user profile but you do not specify exactly what information can be entered. You need some dedicated requirements for this since it is very important.~~
~~A very important feature of your project is to compile and present an analysis of user contributions to the food servers. You have no requirements about this.~~
~~You do not have a dedicated requirement for being able to add a food to the system (by a server), and which information can be provided in the process. I think this is the cornerstone of the project since other requirements cannot be fulfilled without any food content in the system!~~
~~Non-functional requirement 5: This is not really a non-functional requirement since tags will be provided by the users and are involved in direct interaction with the user while searching.~~
~~Non-functional requirement 6: What do you mean? Is this quantifiable, how do you measure or validate this?~~
Non-functional requirement 7: This is also not a non-functional requirement.
Project Plan
You need to define milestones. Please refer to the lecture slides. Try to find a balanced number of them and rearrange timing of tasks. Each milestone should have an objective (e.g., validating requirements & design documents, demonstrating first working product, demonstrating a complete functionality such as search) and deliverables (e.g., report, presentation, demo, prototype, final product).
Your tasks are generic: Planning, Implementation, Testing and Deployment for each main activity. Please refer to your requirements to come up with more specific tasks that are atomic, meaning that they can be completed in a reasonable amount of time by one or a few people and are testable.
We expect Android development to go parallel with web and it will certainly not be a port (it should be a native app). Please revise you plan accordingly.
You may diversify you plan by adding separate entries for frontend/backend or client/server, since the required work for each of them is actually diverse and probably would require separate people to do them in parallel.
Please specify exact dates rather than just week numbers. The current format makes it very difficult to find out where we are at the moment.
RAM
RAM should cover all the activities that you specified in your project plan for the entire project, not just the assignments. We are aware that it will change in the future, so just think of it as a first draft.
It would be beneficial to start thinking what the development sub-teams will be in the implementation phase (e.g. backend, frontend, web, Android).
Communication Plan
Important items are missing: Issue management system, piazza…
What about communication with the customers (assistants and instructor)? How do you plan to do it?
The text was updated successfully, but these errors were encountered:
Transfering feedback to issues is the right action.
However lumping all responses to issues is not a good way of creating issues.
Issues should define specific work items that are assigned to persons and tracked in terms of time estimation and status.
You have come up with a strategy of tracking via crossing out items, however this use is not what issues are good at documenting and tracking.
For example, it is not possible to see what work emerged, who completed the work, what were the estimated and actual times required to complete the tasks.
At this point, one would expect to be many many more issues of various statuses and assignment.
Please keep these in mind for future issue creation.
I will copy-paste the feedback from Piazza here. We all should solve them when we have the time. Please cross out what you have completed so that we will be able to track them.
Requirements
In Glossary: Rather than Users, you may want to add separate entries for normal users and food serving outlets since there will be differences in their roles and capabilities.Please also enumerate non-functional requirements.Most of your requirements start with “The application shall…” or “The system shall…”. This style is only appropriate for requirements that are not based on direct user interaction. It is also important to emphasize for which type of user a requirement is written for. For instance: Req. 1.2 should be something like “The users shall be able to see the total amount of calories a food has”. Another example: Req. 2.1 should be “The users shall be able to filter the searched content according to their preferences”. Regarding this example, the Req.s 2.2-2.6 are actually elaborate on Req. 2.1, so you may actually make these Req.s subitems of 2.1. Think of it as first presenting a general requirement and then going into details. Please revise all your requirements according to these suggestions.Req.s 1.7 and 1.9 are not really features that the customer wants. The informational aspect of your project is more focused on nutritional information and personal diet awareness.It is important to make a distinction between a registered and non-registered user, since their capabilities will be different. For instance, a non-registered user should not be able to tag, comment or rate food or make any other contribution. They may use search/filter or browse content though.Req. 4.1: Please elaborate: Make comparison how?Non-functional requirement 7: This is also not a non-functional requirement.Project Plan
RAM
Communication Plan
The text was updated successfully, but these errors were encountered: