search

vansh284 / pe

0 stars 0 forks source link

DG - NFR Unreasonable #16

Open vansh284 opened 10 months ago

vansh284 commented 10 months ago

image.png "Searching and filtering within 2s" seems like too high of a limit for searching and filtering. If users had to wait up to 2 seconds in order to search for a patient, it would be quite a significant decrement in productivity. Most applications can do searching/filtering in the order of magnitude of milliseconds. (I'm assuming this restriction is for an address book of 1000 persons, as mentioned in the NFR above this one).

nus-pe-script commented 10 months ago

Team's Response

During the early stages of development, it's common to set broader or looser upper bounds for non-functional requirements. This approach allows for more flexibility in exploring design options, experimenting with different implementation approaches, and avoiding premature optimization. Tight performance constraints can limit the exploration of innovative features or architectural choices.

We will seek to further optimise in future iterations of the application and tighten the NFR requirements.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: "it's common to set broader or looser upper bounds for non-functional requirements" I do not think this is a general rule. Especially, for an NFR like this, which is critical to the success of the software: the application would be unlikely to succeed if it required 2 seconds to search/filter.