Miroirs/cooperative-software-development
1
0
Fork 0
mirror of https://github.com/amyjko/cooperative-software-development synced 2024-12-25 21:58:15 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fixed #30, addressing GDPR.

Browse source
This commit is contained in:
Andy Ko 2019-04-09 12:25:15 -07:00
parent fd4cd64989
commit e26c0dab27
1 changed files with 11 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
requirements.html
View file

@ -59,10 +59,17 @@
<p>
And yet, like design, requirements come from the world and the people in it and not from software (<a href="#jackson">Jackson 2001</a>).
Therefore, the methods that people use to do requirements engineering are quite similar to design methods.
Requirements engineers do interviews, conduct user research, create prototypes, and iteratively converge toward requirements (<a href="#lamsweerde">Lamsweerd 2008</a>).
The big difference between design and requirements engineering is that requirements engineers take the process one step further than designers, enumerating <em>in detail</em> every property that the software must satisfy.
They sometimes even use formal methods to specify requirements, allowing them to automatically identify <em>conflicting</em> requirements, so they don't end up proposing a design that can't possibly exist.
Sometimes requirements even come from law, as is the case of the European Union's General Data Protection Regulation (<a href="https://eugdpr.org/">GDPR</a>) regulation, which specifies a set of data privacy requirements that all software systems used by EU citizens must meet.
Therefore, the methods that people use to do requirements engineering are quite diverse.
Requirements engineers may work with lawyers to interpret policy.
They might work with regulators to negotiate requirements.
They might also use design methods, such as user research methods and rapid prototyping to iteratively converge toward requirements (<a href="#lamsweerde">Lamsweerd 2008</a>).
Therefore, the big difference between design and requirements engineering is that requirements engineers take the process one step further than designers, enumerating <em>in detail</em> every property that the software must satisfy, and engaging with every source of requirements a system might need to meet, not just user needs.
</p>
<p>
There are some approaches to specifying requirements <em>formally</em>.
These techniques allow requirements engineers to automatically identify <em>conflicting</em> requirements, so they don't end up proposing a design that can't possibly exist.
Some even use systems to make requirements "traceable", meaning the high level requirement can be linked directly to the code that meets that requirement (<a href="#mader">Mader & Egyed 2015</a>).
All of this formality has tradeoffs: not only does it take more time to be so precise, but it can negatively effect creativity in concept generation as well (<a href="#mohanani">Mohanani et al. 2014</a>).
</p>