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: RE: Privacy Requirements -- Functional or Non-Functional


Hei Anthony.

Engineering Principles are different than Engineering Requirements.

The former find themselves the focus of a design principles manifesto for a software team. The latter end up in the sprint backlog.

Frank/

 

From: ext Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: 24 September, 2013 16:57
To: Dawson Frank (Nokia-CIC/Dallas); pbd-se@lists.oasis-open.org
Subject: RE: Privacy Requirements -- Functional or Non-Functional

 

So each of the 7 show behavioral intent, thus this is why I think they are functional, I agree that these are not well defined to actually  be implementable in engineering environment but can be functional principles to architects

From: Frank.Dawson@nokia.com [mailto:Frank.Dawson@nokia.com]
Sent: Tuesday, September 24, 2013 2:34 PM
To: Anthony Nadalin; pbd-se@lists.oasis-open.org
Cc: Frank.Dawson@nokia.com
Subject: RE: Privacy Requirements -- Functional or Non-Functional

 

Hei Anthony.

Let us just recap the 7-Foundation Principles [1]:

1.      Proactive not Reactive; Preventative not Remedial

2.      Privacy as the Default Setting

3.      Privacy Embedded into Design

4.      Full Functionality – Positive-Sum, not Zero-Sum

5.      End-to-End Security – Full Lifecycle Protection

6.      Visibility and Transparency – Keep it Open

7.      Respect for User Privacy – Keep it User-Centric

These are “principles”. Oxford dictionary [2] indicates that these are “a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning”. As such, they are subjective and often difficult to measure until they are transposed into functional requirements.

For example, Principle #1 can be transposed into a software team’s way-of-working by committing to including as a part of their design phase a completion of a data management plan that would include data analysis and data flows for the primary use cases of the release. In addition, commitment to conduct threat analysis to identify design privacy vulnerabilities and commit to applying privacy safeguarding controls to mitigate identified vulnerabilities. A practical approach to turn Principle #3 into functional requirements would be adopt the Microsoft SDLC, including TAM processes with the deliverables being addition of mitigating controls to the sprint backlog of functions, such that the feature can be mapped back to threat that is mitigated and which privacy principle (e.g., OECD FIPP) is being supported. An example of transposing Principle #5 would be to have a milestone checklist of activities and deliverables that must be completed as exit gating requirements for that milestone. An example of transposing Principle #6 for a web service would be that a hyperlink to the site’s privacy policy and terms of service had to be visible on a 4.5 inch mobile browser within one touch on the initial screen (i.e., not buried at the bottom of a long scrolling HTML page) and that the cookie policy needed to be implemented as a persistent pop-up on first user or post-90-day-inactive-returning user until acknowledged.

In summary, one of the key motivations for the OASIS PbD-SE TC is that existing 7-Foundation Principles are not sufficiently explanatory for a software engineer and more detailed transposition of these Foundation Principles into software engineering guidance is needed.

The 7-Foundation Principles are excellent design philosophy for a software project’s security & privacy design considerations, but too high level to be considered functional requirements.

Frank/

[1] http://www.privacybydesign.ca/index.php/about-pbd/7-foundational-principles/

[2] http://oxforddictionaries.com/definition/english/principle?q=Principle

 

 

From: ext Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: 24 September, 2013 16:14
To: Dawson Frank (Nokia-CIC/Dallas); pbd-se@lists.oasis-open.org
Subject: RE: Privacy Requirements -- Functional or Non-Functional

 

So I do think that the things like the 7-Foundation Principles do reflect behavior and behavior is what I do expect from a functional requirement

From: pbd-se@lists.oasis-open.org [mailto:pbd-se@lists.oasis-open.org] On Behalf Of Frank.Dawson@nokia.com
Sent: Tuesday, September 24, 2013 8:23 AM
To: pbd-se@lists.oasis-open.org
Subject: [pbd-se] 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]