Principios de la Ingeniería de Requerimientos (01)

Presento los que a mi criterio son los cuatro principios de la Ingeniería de Requerimientos: 1) el negocio detrás del sistema es el criterio para incluir, rechazar y priorizar cada requerimiento; 2) los requerimientos están en el dominio de aplicación y se los debe describir usando el vocabulario de ese dominio; 3) los requerimientos no funcionales, también son requerimientos; y 4) nunca ir a una reunión con el cliente sin un prototipo.

Para profundizar en estos temas sugiero la siguiente bibliografía:

Ingeniería de Requerimientos en general: pueden ver mi apunte de clase:

http://www.fceia.unr.edu.ar/%7Emcrist...

Allí encontrarán otras referencias bibliográficas, en particular:

Brian Berenbach, Daniel Paulish, Juergen Kazmeier, and Arnold Rudorfer. Software & Systems Requirements Engineering: In Practice. McGraw-Hill, Inc., New York, NY, USA, 2009.

Principio 1: Suzanne Robertson. Requirements and the business case. IEEE Software, 21:93-95, September 2004.

Principio 2: Michael Jackson. Software requirements & specifications: a lexicon of practice, principles and prejudices. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 1995. En particular leer el capítulo "Requirements".

Principio 3: Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2 edition, 2003. En particular leer el capítulo 4.

Principio 4: Michael Schrage. Never go to a client meeting without a prototype. IEEE Software, 21(2):42-45, 2004.