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
After detailing requirements in section 9 and 10-17, the document seems to be missing a traceability matrix to link use cases to the functional requirement. It is crucial to do this part of the document to understand what functional and non functional requirements is associated to each use case, making it easier to track the quality of the requirement and how well the system is achieving them. With so many non functional and functional requirements using a traceability matrix helps to view them quickly and ensure its being referenced for each use case.
I would also advise to think more in detail for functional requirements. The current list is a good start however could be broken down. For eg. The functional requirement description is very long and detailed which could be broken down into description, rationale, and fit criteria. At a glance, I should be able to read a one line sentence of the requirement to get a good gist of what is needed.
We will include a traceability matrix, thanks for reviewing.
With regards to functional requirements, considering the problem is relatively open, I don't know if it makes sense to make each entry even more segregated
artifact under review.
SRS Document
team number (for the team doing the review).
Team 22
description of issue.
After detailing requirements in section 9 and 10-17, the document seems to be missing a traceability matrix to link use cases to the functional requirement. It is crucial to do this part of the document to understand what functional and non functional requirements is associated to each use case, making it easier to track the quality of the requirement and how well the system is achieving them. With so many non functional and functional requirements using a traceability matrix helps to view them quickly and ensure its being referenced for each use case.
I would also advise to think more in detail for functional requirements. The current list is a good start however could be broken down. For eg. The functional requirement description is very long and detailed which could be broken down into description, rationale, and fit criteria. At a glance, I should be able to read a one line sentence of the requirement to get a good gist of what is needed.
@CSchank
The text was updated successfully, but these errors were encountered: