OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pbd-se message

[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]