Fixed #42, citing Parnas and Clements.

requirements.html

@@ -31,9 +31,41 @@
 
 		<p>It depends. This mentality towards product design works fine with building and deploying something is cheap and getting feedback has no consequences. Simple consumer applications often benefit from this simplicity, especially early stage ones, because there's little to lose. But what if a beta isn't cheap to build? What if your product only has one shot at adoption? What if you're building something for a client and they want to define success? Worse yet, what if your product could <em>kill</em> people if it's not built properly? In these settings, software teams take an approach of translating a design into a specific explicit set of goals that must be satisfied in order for the implementation to be complete. We call these goals <b>requirements</b> and we call this process of <b>requirements engineering</b> (<a href="#sommerville">Sommerville & Sawyer 1997</a>).</p>
 		
-		<p>The relationship between requirements and design is somewhat murky. In design disciplines, designers tend to express requirements in the form of prototypes and mockups. These <em>implicitly</em> state requirements, because they suggest what the software is supposed to do without saying it directly. For some types of requirements, they actually imply nothing. For example, how responsive should a web page be to be? A prototype doesn't really say; an explicit requirement of <em>an average page load time of less than 1 second</em> is quite explicit. Requirements can therefore be thought of more like an architect's blueprint: they provide explicit definitions and scaffolding of project success.</p>
+		<p>
+			In principle, requirements are a relatively simple concept.
+			They are simply statements of what must be true about a system to make the system acceptable.
+			For example, suppose you were designing an interactive mobile game.
+			You might want to write the requirement <em>The frame rate must never drop below 60 frames per second.</em>
+			This could be important for any number of reasons: the game may rely on interactive speeds, your company's reputation may be for high fidelity graphics, or perhaps that high frame rate is key to creating a sense of realism.
+			Whatever the reasons, expressing it as a requirement makes it explicit that any version of the software that doesn't meet that requirement is unacceptable.
+		</p>
 		
-		<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. 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>
+		<p>
+			The general idea of writing down requirements is actually a controversial one.
+			Why not just discover what a system needs to do incrementally, through testing, user feedback, and other methods? 
+			Some of the original arguments for writing down requirements actually acknowledged that software is necessarily built incrementally, but that it is nevertheless useful to write down requirements from the outset (<a href="#parnas">Parnas and Clements 1986</a>). 
+			This is because requirements help you plan everything: what you have to build, what you have to test, and how to know when you're done.
+			The theory is that by defining requirements explicitly, you plan, and by planning, you save time.
+		</p> 
+		
+		<p>
+			Do you really have to plan by <em>writing down</em> requirements?
+			For example, why not do what designers do, expressing requirements in the form of prototypes and mockups.
+			These <em>implicitly</em> state requirements, because they suggest what the software is supposed to do without saying it directly. 
+			But for some types of requirements, they actually imply nothing. 
+			For example, how responsive should a web page be to be? A prototype doesn't really say; an explicit requirement of <em>an average page load time of less than 1 second</em> is quite explicit. 
+			Requirements can therefore be thought of more like an architect's blueprint: they provide explicit definitions and scaffolding of project success.
+		</p>
+		
+		<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. 
+			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>
 		
 		<p>Expressing requirements in natural language can mitigate these effects, at the expense of precision. They just have to be <em>complete</em>, <em>precise</em>, <em>non-conflicting</em>, and <em>verifiable</em>. For example, consider a design for a simple <strong>to do list</strong> application. It's requirements might be something like the following:</p>
 		
@@ -67,6 +99,7 @@
 			<p id="lamsweerde">Axel van Lamsweerde. 2008. <a href="http://dx.doi.org/10.1145/1453101.1453133" target="_blank">Requirements engineering: from craft to discipline</a>. In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering (SIGSOFT '08/FSE-16). ACM, New York, NY, USA, 238-249.</p>
 			<p id="mader">M&aumlder, P., & Egyed, A. (2015). <a href="https://doi.org/10.1007/s10664-014-9314-z" target="_blank">Do developers benefit from requirements traceability when evolving and maintaining a software system?</a> Empirical Software Engineering, 20(2), 413-441.</p>
 			<p id="mohanani">Rahul Mohanani, Paul Ralph, and Ben Shreeve. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568235" target="_blank">Requirements fixation</a>. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 895-906.</p>
+			<p id="parnas">Parnas, D. L., & Clements, P. C. (1986). <a href="https://doi.org/10.1109/TSE.1986.6312940">A rational design process: How and why to fake it</a>. IEEE Transactions on Software Engineering, (2), 251-257.</p>
 			<p id="sommerville">Sommerville, I., & Sawyer, P. (1997). <a href="https://books.google.com/books?id=5NnP-VODEc8C" target="_blank">Requirements engineering: a good practice guide</a>. John Wiley & Sons, Inc.</p>
 		
 		</small>