Рет қаралды 16,305
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:
www.fceia.unr.e...
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.