Income should be numerical

[josh1248]

The current implementation permits only low, medium, high, or unspecified incomes for each individual person. This represents a diminished utility for insurance sales representatives as numerical income details may be required for e.g. qualification for certain insurance schemes. An implementation change without substantial effort would be to parse the field as a non-negative integer input, like age, but with a larger income bound.

[nus-se-script]

Team's Response

Changed severity to Low as it is only a minor inconvenience that doesn't pose an issue to the app's functionality.

This is intended so that adding and filtering is easier for our users, without having to worry about specific numbers. It can leave the none, low, medium, high income interpretations to the user, thus not bounding them by our definitions. Though we agree that this can be improved to be more flexible in future.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: I disagree that this feature flaw is NotInScope, given that minimal implementation effort is required to process income as a number rather than an enumeration here - it would use almost the exact same validation code as the numerical age field, but with a larger income bound, suppose between 0 and 1000000.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** I disagree and believe that the severity still remains on the `High` side for this bug. My reasons and responses: - The testers mention that "it can leave the none, low, medium, high income interpretations to the user, thus not bounding them by our definitions". However, I would argue that the use of numerical incomes would be much less subjective and hence bounded by definitions as opposed to none/low/medium/high. - Numerical income is extremely important for many insurance schemes, where hard income boundaries determine which insurance tiers that clients are eligible for. An example could be insurance schemes for enterprise software that cover for lost income should the software fail - such schemes would be bounded and dependent on the numerical incomes of the client. Hence, the use of the `none / low / medium / high` is too subjective and not granular enough to highlight to the agents when such income boundaries are pertinent. - Hence, it qualifies to be a `High` severity feature flaw as justified in my bug report. I argue it meets the criteria (ss below) of "would most potential users say 'Oh? Then I'm not going to use this app!'" if they are aware of this feature flaw. For most insurance sales representatives, I foresee that the omission of granularity of such an important aspect of the client would turn them off from using the app. 

---