1

-Alumno:

Escobar Torres, Ricardo D.

-Profesores:

Prof. Lic. María Del Rosario Zorrilla A., Mg.

Prof. Lic. Juan Benito Torres

-Tercer Año Sexto Semestre

LA INGENIERIA DE REQUERIMIENTOS

2

TABLA DE CONTENIDO

Introducción ................................................................................................................................................. 3

LA INGENIERIA DE REQUERIMIENTOS ............................................................................................... 4

Concepto de Requerimientos ...................................................................................................................... 4

Características de los Requerimientos ....................................................................................................... 4

Dificultades para definir los requerimientos ............................................................................................. 4

Importancia de la Ingeniería de Requerimientos....................................................................................... 4

Personal involucrado en la Ingeniería de Requerimientos ....................................................................... 4

Documentación de requerimientos, tipos .................................................................................................. 4

Especificación de Requisitos de Software (SRS) ...................................................................................... 5

Tipos de requisitos ...................................................................................................................................... 5

Validación de Requisitos ............................................................................................................................ 5

Técnicas y herramientas utilizadas en la Ingeniería de Requerimientos, concepto, características. ......... 5

Entrevistas.................................................................................................................................................... 5

Brainstorming .............................................................................................................................................. 6

Casos de Uso ............................................................................................................................................... 6

Prototipos ..................................................................................................................................................... 6

Proceso de Análisis Jerárquico (AHP) ....................................................................................................... 6

Cuadro Comparativo de ventajas y desventajas de cinco técnicas y herramientas utilizadas en la

Ingeniería de Requerimientos .......................................................................................................................... 7

Conclusión ............................................................................................................................................. 8

Bibliografía y Webgrafía ....................................................................................................................... 9

3

Entender los requerimientos de un problema es una de las tareas más difíciles que enfrenta el ingeniero

de software. Muchas veces se comete el error de que cuando se empieza por primera vez, se piensa que

no parece tan difícil desarrollar un entendimiento claro de los requerimientos. ¿Y por qué no pensar de

esa manera? o ¿acaso el cliente no sabe lo que necesita? La respuesta a estas preguntas es que no, en

muchas de las ocasiones el cliente no sabe corresponder sus necesidades, y esto dificulta la labor del

ingeniero del software.

Es tan importante el estudio de la ingeniería del software para realizar un buen sistema de software,

debido a que ella es la encargada de validar la calidad del mismo software. Y unos de los campos que

abarca esta importante materia es la Ingeniería de Requisitos que es la encargada de establecer lo que el

cliente desea de una manera técnica y precisa para los desarrolladores de software.

En este proyecto daremos a entender algunos conceptos básicos, pero que nos servirán como fuente de

entendimiento para las recolecciones de datos y la documentación de las mismas. Sin más que

molestarlos, los invito a leer el contenido del mismo.

4

LA INGENIERIA DE REQUERIMIENTOS

CONCEPTO DE REQUERIMIENTOS

Son descripciones de lo que el sistema debe hacer: el servicio que ofrece y las restricciones en su

operación. La ingeniería de requerimientos proporciona el mecanismo apropiado para entender lo que

desea el cliente.

CARACTERÍSTICAS DE LOS REQUERIMIENTOS

Necesario: su omisión provoca una deficiencia en el sistema a construir, y además no pueden ser

reemplazados por otras capacidades del producto o del proceso.

Conciso: fácil de leer y entender.

Completo: no necesita ampliar detalles en su redacción.

Consistente: es contradictorio con otro requerimiento.

No ambiguo: tiene una sola interpretación.

Verificable: puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de

verificación: inspección, análisis, demostración o pruebas.

DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS

Problemas de alcance: La frontera de los sistemas está mal definida o los clientes o usuarios finales

especifican detalles técnicos innecesarios que confunden.

Problemas de entendimiento: Los clientes o usuarios no están completamente seguros de lo que se

necesita.

Problemas de volatilidad: Los requerimientos cambian con el tiempo.

IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS

La ingeniería de requerimientos establece una base sólida para el diseño y la construcción. Sin ésta, el

software resultante tiene alta probabilidad de no satisfacer las necesidades del cliente.

PERSONAL INVOLUCRADO EN LA INGENIERÍA DE

REQUERIMIENTOS

Un participante es cualquier persona que tenga interés directo o que se beneficie del sistema que se va a

desarrollar. Los roles más importantes pueden clasificarse como sigue:

Usuario final: Son las personas que usarán el sistema desarrollado.

Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema

en donde será empleado el software desarrollado.

Personal de Mantenimiento: Su trabajo consiste en revisar y mejorar los procesos del producto ya

finalizado.

Analistas y programadores: Son los responsables del desarrollo del producto en sí.

Personal de pruebas: Son quienes van a validar si los requerimientos satisfacen las necesidades del

cliente.

DOCUMENTACIÓN DE REQUERIMIENTOS, TIPOS

Requerimientos normales: Objetivos y metas que se establecen para un producto o sistema durante las

reuniones con el cliente. Ejemplos: tipos de gráficos pedidos para aparecer en la pantalla, funciones

específicas del sistema y niveles de rendimiento definidos.

5

Requerimientos esperados: Están implícitos en el producto o sistema y quizá sean tan importantes

que el cliente no los mencione de manera explícita. Ejemplos: fácil interacción humano/máquina,

operación general correcta y confiable, y facilidad para instalar el software.

Requerimientos emocionantes: Estas características van más allá de las expectativas del cliente y son

muy satisfactorias si están presentes. Por ejemplo, el software para un nuevo teléfono móvil viene con

características estándar, pero si incluye capacidades inesperadas agrada a todos los usuarios del

producto.

ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (SRS)

Los requerimientos del sistema son descripciones más detalladas de las funciones, los servicios y las

restricciones operacionales del sistema de software. El documento de requerimientos del sistema

(llamado en ocasiones especificación funcional) tiene que definir con exactitud lo que se implementará.

Puede formar parte del contrato entre el comprador del sistema y los desarrolladores del software.

TIPOS DE REQUISITOS

Requerimientos funcionales: Son enunciados acerca de servicios que el sistema debe proveer, de

cómo debería reaccionar el sistema a entradas particulares y de cómo debería comportarse el sistema en

situaciones específicas. En algunos casos, los requerimientos funcionales también explican lo que no

debe hacer el sistema.

Requerimientos no funcionales: Son limitaciones sobre servicios o funciones que ofrece el sistema.

Incluyen restricciones tanto de temporización y del proceso de desarrollo, como impuestas por los

estándares. Los requerimientos no funcionales se suelen aplicar al sistema como un todo, más que a

características o a servicios individuales del sistema.

VALIDACIÓN DE REQUISITOS

La validación es el proceso que certifica que el modelo de los requerimientos es consistente con las

intenciones de los clientes y los usuarios; ésta es una visión más general que el concepto común de

validación, pues se produce en paralelo con la elicitación y la especificación, tratando de asegurar que

tanto las ideas como los conceptos presentados en una descripción se identifican y explican con

claridad La necesidad de validación aparece cuando:

Se incorpora una nueva pieza de información al modelo actual.

Cuando diferentes piezas de información se incorporan en un todo coherente.

TÉCNICAS Y HERRAMIENTAS UTILIZADAS EN LA INGENIERÍA DE REQUERIMIENTOS,

CONCEPTO, CARACTERÍSTICAS.

ENTREVISTAS

Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente inevitables en

cualquier desarrollo. En las entrevistas se pueden identificar claramente tres fases: preparación,

realización y análisis, que se describen a continuación.

Preparación de entrevistas

Las entrevistas no deben improvisarse, por lo que conviene realizar las siguientes tareas previas:

Estudiar el dominio del problema: conocer la terminología básica del dominio del problema.

Seleccionar a las personas a las que se va a entrevistar: se debe minimizar el número de

entrevistas a realizar, por lo que es fundamental seleccionar a las personas a entrevistar.

Determinar el objetivo y contenido de las entrevistas: para minimizar el tiempo de la entrevista

Planificar las entrevistas

Realización de entrevistas

Apertura: el entrevistador debe presentarse e informar al entrevistado sobre la razón de la

entrevista.

Desarrollo: Se deben evitar los monólogos y mantener el control por parte del entrevistador,

contemplando la posibilidad de que una tercera persona tome notas durante la entrevista o

grabar la entrevista en cinta de vídeo o audio, siempre que el entrevistado esté de acuerdo

Terminación: se debe recapitular sobre la entrevista para confirmar que no ha habido

confusiones en la información recogida.

6

Análisis de las entrevistas

Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio, reorganizar la

información, contrastarla con otras entrevistas o fuentes de información, etc. Una vez elaborada la

información, se puede enviar al entrevistado para confirmar los contenidos. También es importante

evaluar la propia entrevista para determinar los aspectos mejorables.

BRAINSTORMING

El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la

generación de ideas en un ambiente libre de críticas o juicios

Las sesiones de brainstorming suelen estar formadas por un número de cuatro a diez participantes, uno

de los cuales es el jefe de la sesión, encargado más de comenzar la sesión que de controlarla.

Fases del brainstorming

En el brainstorming se distinguen las siguientes fases:

Preparación: la preparación para una sesión de brainstorming requiere que se seleccione a los

participantes y al jefe de la sesión, citarlos y preparar la sala donde se llevará a cabo la sesión.

Generación: el jefe abre la sesión exponiendo un enunciado general del problema a tratar, que

hace de semilla para que se vayan generando ideas. Los participantes aportan libremente nuevas

ideas sobre el problema semilla.

Consolidación: en esta fase se deben organizar y evaluar las ideas generadas durante la fase

anterior. Se suelen seguir tres pasos:

Revisar ideas

Descartar ideas

Priorizar ideas

Documentación: después de la sesión, el jefe produce la documentación oportuna conteniendo

las ideas priorizadas y comentarios generados durante la consolidación.

CASOS DE USO

Los casos de uso son una técnica para la especificación de requerimientos funcionales propuesta

inicialmente en y que actualmente forma parte de la propuesta de UML

Los actores son personas u otros sistemas que interactúan con el sistema cuyos requerimientos se están

describiendo. Un actor puede participar en varios casos de uso y un caso de uso puede estar relacionado

con varios actores.

Los casos de uso presentan ciertas ventajas sobre la descripción meramente textual de los

requerimientos funcionales, ya que facilitan la elicitación de requerimientos y son fácilmente

comprensibles por los clientes y usuarios. Además, pueden servir de base a las pruebas del sistema y a

la documentación para los usuarios.

PROTOTIPOS

Los prototipos permiten al desarrollador crear un modelo del software que debe ser construido.

Existen principalmente dos tipos de prototipos:

Prototipo rápido: es un mecanismo para lograr la validación pre-compromiso. Se utiliza para validar

requerimientos en una etapa previa al diseño específico. .

Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser

visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de

vida está dividido en dos fases distintas: desarrollo y mantenimiento. El punto de vista evolutivo del

ciclo de vida del software considera a la primera entrega como un prototipo inicial en el campo.

Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos más maduros. Este

proceso continúa hasta que se haya desarrollado el producto final.

PROCESO DE ANÁLISIS JERÁRQUICO (AHP)

Esta técnica tiene por objetivo resolver problemas cuantitativos, para facilitar el pensamiento analítico

y las métricas. Consiste en una serie de pasos a saber:

Encontrar los requerimientos que van a ser priorizados.

Combinar los requerimientos en las filas y columnas de la matriz n x n de AHP.

7

Hacer algunas comparaciones de los requerimientos en la matriz

Sumar las columnas

Normalizar la suma de las filas

Calcular los promedios

Estos pasos pueden aplicarse fácilmente a una cantidad pequeña de requerimientos, sin embargo, para

un volumen grande, esta técnica no es la más adecuada.

CUADRO COMPARATIVO DE VENTAJAS Y DESVENTAJAS DE CINCO TÉCNICAS Y

HERRAMIENTAS UTILIZADAS EN LA INGENIERÍA DE REQUERIMIENTOS

Técnica Ventajas Desventajas

Entrevistas y Cuestionarios

Mediante ellas se obtiene una gran cantidad de información correcta a través del usuario.

Pueden ser usadas para obtener un pantallazo del dominio del problema.

Son flexibles.

Permiten combinarse con otras técnicas.

La información obtenida al principio puede ser redundante o incompleta.

Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados.

Lluvia de Ideas

Los diferentes puntos de vista y las confusiones en cuento a terminología, son aclarados por expertos.

Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto.

Es necesaria una buena compenetración del grupo participante.

Prototipos

Ayudan a validar y desarrollar nuevos requerimientos.

Permite comprender aquellos requerimientos que no estén muy claros y que sean de alta volatilidad.

El cliente puede llegar a pensar que el prototipo es una versión del software que será desarrollado.

A menudo, el desarrollador hace compromisos de implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo

Análisis Jerárquico

Permite determinar el grado de importancia de cada requerimiento.

Ayuda a identificar conflictos en los requerimientos.

Muestra el orden en que deben ser implementados los requerimientos.

Debe construirse un estándar claro de evaluación, que incluya la participación del cliente.

Casos de Uso

Representan los requerimientos desde el punto de vista del usuario.

Permiten representar más de un rol para cada afectado.

Identifica requerimientos estancados, dentro de un conjunto de requerimientos.

En sistemas grandes, toma mucho tiempo definir todos los casos de uso.

El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial.

8

Hemos dado a entender que las tareas de la ingeniería de requerimientos se realizan para establecer un

fundamento sólido para el diseño y la construcción. La ingeniería de requerimientos ocurre durante las

actividades de comunicación y modelado que se hayan definido para el proceso general del software.

Pero a pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le

preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados,

tales como la integración de requerimientos funcionales y no funcionales, la evaluación de

especificaciones alternativas, la formalización de la SRS, entre otras.

Entonces se concluye que entregar software de calidad, a tiempo y dentro del presupuesto, hará que

nuestros clientes confíen y asegurará el crecimiento y madurez de la relación de negocio.

9

Monografás.com. (2010). INGENIERIA DE REQUERIMIENTOS INGENIERÍA DE SOFTWARE.

Recuperado el 03 de Octubre de 2015 de http://www.monografias.com/trabajos6/resof/resof.shtml

Pressman, Roger S. (2010). INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO (Séptima

edición). México.

Sedici (2010). INGENIERIA DE REQUERIMIENTOS. Recuperado el 03 de Octubre de 2015 de

http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2_-

_Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4

Sommerville, Ian. (2011). INGENIERÍA DEL SOFTWARE (Novena edición). México.