Log in / Register
Home arrow Computer Science arrow The Privacy Engineer’s Manifesto
< Prev   CONTENTS   Next >

Privacy Requirements Engineering

Historically, in many organizations, requirements for systems to process personal information were set by inherent limitations, such as technical systems limitations or the lack of configurable features across applications or systems. Any data were forced to fit a system or series of systems rather than the systems adapting to reflect the user's and management's actual desired requirements for a task or use case.

The exponential rate of systems' capabilities and choices that have been developed in recent years can allow the privacy engineer to flip that equation and lead with person requirements first, data second, and technical limitations third in priority for design.[1] The evolution, or indeed revolution, of data-centric and person-centric processing

vs. machine-limited data-processing design potentially creates a rich and creative environment for innovation and downstream economic benefits based on new business models. In fact, a person-centric design may be a way forward beyond the buying or selling of ads or other content-independent schemas to create “value” from new algorithms and person-first services.

Additionally, many hours of frustrating double talk have transpired where a legal team member asks a development team to ensure that there are “reasonable” controls included in the system before it can launch, only for both teams to discover that neither had the foggiest idea what was really expected from the other, another oft-occurring potential pitfall. If nothing else, privacy engineering models and techniques should provide an earlier and more productive conversation starter (or finisher). The launch party for new business models and systems may even enjoy a mutual clink of the glass for the legal, design, technical, customer advocacy, compliance, risk, and other business teams—the mind reels at the remote possibilities. “Legal” becoming a friendlier term for the enterprise is, unfortunately, beyond the scope of this book.

Thus, requirements engineering must be considered a team effort that demands a combination of hardware, software, human factors, privacy knowledge, and system design engineering expertise as well as skills in interpreting and communicating with other people with differing perspectives and lexicography.

  • [1] This addresses a potential pitfall. So often both businesspeople and IT will think in terms of technology first and user later. This is a shortcut to user unhappiness.
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
Business & Finance
Computer Science
Language & Literature
Political science