<< Keyboard Jedi on Windows7 64-bit | Home | Pair Programming and Formula One >>

The 7 fundamental principles of Software Requirements




When trying to reach a moving target, making a good plan is extremely hard, while planning and executing small steps within short inspect-adapt loops is extremely easier.

The faster the target is moving, the more increasing inspect-adapt frequency is beneficial/advantageous/profitable over perfecting the plan.
After all it is not possible to adapt the reality to a plan, it works better to adapt the plan to the reality. Here 2 stories: Speed of Iteration Beats Quality and how Paul MacCready won a million dollars prize




When trying to deal with unknowns & uncertainty & disagreement, making a good forecast is extremely hard. When dealing with change that is outside our area of control and influence is impossible. Indeed learning from feedback and making informed decisions is extremely easier.

The more certainty or agreement is far, the more increasing feedback sources and inspection is beneficial/advantageous/profitable over perfecting the forecast.
After all it is not possible to adapt the reality to a forecast, it works better to adapt the forecast to the reality. Here is another true story: Moving Fast at Scale.



How much, in your day-to-day experience, software requirements are a moving target far from certainty and agreement?



Here follow the 7 fundamental principles of software in software engineering:

  1. The Uncertainty Principle in Software Engineering (UPSE) [1]:
    Uncertainty is inherent and inevitable in software development processes and products

    Sometime referred as Ziv's law: specifications will never be fully understood


  2. Humphrey law [2]:
    For a new software system, the requirements will not be completely known until after the users have used it.


  3. Wegner’s lemma [3]:
    It is not possible to completely specify an interactive system


  4. Langdon’s lemma [4]:
    Software evolves more rapidly as it approaches chaotic regions


  5. From the Lehman's laws of software evolution [5]:
    E-type programs embedded in the real world become part of it, changing it and evolve in concert.


  6. From Wicked problems definition [6]:
    A problem is not understood until after you have developed a solution.


  7. The Cone of Uncertainty [7]:
    The actual effort or scope can be 4 times or 1/4 of the first estimates.




Two more stories where there principles reveal themselves:
- Dear Customer The Truth About IT Projects
- Every project initially is based on unvalidated assumptions that are presented as requirements



[1] H. Ziv and D.J. Richardson, May 1996. See http://www.ics.uci.edu/~ziv/papers/icse97.ps
[2] Watts S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995.
     See http://en.wikipedia.org/wiki/Watts_Humphrey
[3] Peter Wegner, Why interaction is more powerful than algorithms, Comm. of the ACM, May 1997.
     See http://www.cs.brown.edu/people/pw/papers/ficacm.ps
[4] W. B. Langdon. See also http://www.cs.ucl.ac.uk/staff/W.Langdon/
[5] Meir M. Lehman and Laszlo Belady, 1974-1996. See http://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution
[6] Horst Rittel and Melvin Webber, Jeff Conklin, 1967-2008. See http://en.wikipedia.org/wiki/Wicked_problems and http://www.cognexus.org/wpf/wickedproblems.pdf
[7] McConnell, 2006. See http://en.wikipedia.org/wiki/Cone_of_Uncertainty

Print | posted @ giovedì 23 settembre 2010 03:30

Comments have been closed on this topic.