Ingeniería de requerimientos
De Wikipedia, la enciclopedia libre
En la ingeniería de sistemas y la ingeniería de software la Ingeniería de requerimientos comprende todas las tareas relacionadas con los requerimientos de un sistema nuevo o modificado, tomando en cuenta los diversos requerimientos de los inversores. Puede ser conocida también como "Análisis de requerimientos", "especificación de requerimientos", etc.
El propósito de la ingeniería de requerimientos es hacer que los mismos alcancen un estado óptimo antes de seguir adelante con el proyecto. Los buenos Requerimientos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
Tabla de contenidos |
[editar] Técnicas principales
Desde un punto de vista conceptual, las actividades son de 3 clases.
- Obtener requerimientos: A través de entrevistas o comunicación con clientes o usuarios, ara saber cuáles son sus deseos.
- Analizar requerimientos: Detectar y corregir las falencias comunicativas, transformando los requerimientos obtenidos en entrevistas en requerimientos en condiciones apropiadas para ser tratados por el diseño
- Documentar requerimientos: Igual que todas las etapas, los requerimientos deben estar debidamente documentados.
Dada la importancia de los cambios que introduce un sistema nuevo, es importante que se tome en consideración a todos los implicados en el mismo y se obtengan y depuren sus requerimientos de la forma más fidedigna posible.
[editar] Entrevistas
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requerimientos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallas.
Las entrevistas pueden ser personales o grupales.
[editar] Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requerimientos. En sistemas muy complejos éstos pueden tener centenares de páginas.
[editar] Objetivos mesurables
Los requerimientos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.
[editar] Prototipos
Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.
[editar] Casos de uso
Un caso de uso es una técnica para documentar posibles requerimientos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una "caja negra", y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas.
[editar] Fuentes
- McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules, 1st ed., Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
- Wiegers, Karl E. (2003). Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle, 2nd ed., Redmond: Microsoft Press. ISBN 0-7356-1879-8.
- Andrew Stellman and Jennifer Greene (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.
