[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Privacy Requirements -- Functional or Non-Functional
Hei OASIS PbD-SEers. After an interesting internal discuss on this topic, I wanted to offer some further discussion words. We agree with the point that Dawn and others made that ideally privacy requirements should be functional requirements. However, it was pointed out by our internal discussions with agile/SCRUM team members that many privacy requirements (e.g., if someone references one of the 7-Foundation Principles
of PbD), initially appear as non-functional requirements because they are not transposed into concrete presentation/logic/data layer requirements for an application, for example. But as the non-functional requirement takes on form, it should be manifested
into concrete implementation features and become transformed into functional requirements.
If this cannot be done to the satisfaction of a software engineer, then the requirement(s) remain as non-functional requirements. Summary: We should always strive to transpose the privacy requirements into concrete implementation and hence functional requirements. The software engineering accepted definition
of functional requirements should not be abrogated just to reclassify a non-functional requirement. Frank/ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]