Ing de Requerimientos Elicitacion de Requerimientos

Ingeniería de
Requerimientos
Elicitación de requerimientos
Elicitación de Requerimientos
■ “La carencia de buenos requisitos ha sido la causa

del fracaso de proyectos con presupuestos de
millones de dólares, ha impedido el desarrollo
productivo, y ha sido el mayor contribuyente de los
costes elevados del mantenimiento del software”
■ Necesidad de la Ingeniería de Requisitos:

o Para construir algo, antes hay que entender qué es ese “algo”.
o Si la aplicación “funciona”, pero no satisface las necesidades del
cliente... ¿de qué sirve?
2
I.T.E.S. SANTA ROSA - TECNICATURA SUPERIOR EN DESARROLLO DE SOFTWARE – INGENERIA DE REQUERIMIENTOS – AÑO 2015
■ Por qué es necesario escribir los requisitos:
■ Tarea descuidada durante mucho tiempo: trivial, “literaria”, poco

tecnológica
■ ¿No quedan bien expresados en el código fuente? No, no funciona.
■ Sin requisitos escritos, el equipo de desarrollo:
■ No sabe cuál es su objetivo.
■ No puede inspeccionar su trabajo.
■ No puede probarlo (¡y las pruebas sí se consideran
esenciales!).
■ No puede analizar su productividad.
■ No puede predecir el tamaño y esfuerzo del siguiente trabajo.
■ No puede satisfacer a sus clientes.
■ En resumen, no hay ingeniería profesional sin requisitos
escritos.
3
■ Diferentes puntos de vista – Diferentes documentos
4
Obtención y descripción de requisitos del usuario
Las fuentes de los requisitos

Plan de trabajo para obtener los requisitos.
Identificación de stakeholders
 ¿Quiénes tienen interés en el producto?
 ¿Quién es el cliente?
 Intereses contrapuestos, requisitos contradictorios
 Negociar el equilibrio
Cómo llevar adelante una entrevista

 Antes, durante, después...
5
Procesos de la Ingeniería de Requerimientos.
■ El estudio de factibilidad, que evalúa si el sistema es

útil para el negocio.
■ Obtención y análisis de requerimientos.
■ Especificación de requerimientos: transformación de

los requerimientos en formularios estándar.
■ Validación: verificar que los requerimientos realmente

definen el sistema que quiere el cliente.
6
7
“El estudio de Factibilidad”
Estudio corto y orientado a resolver las siguientes preguntas:
1.¿El sistema contribuye a los objetivos generales de la organización o

empresa?
2.¿El sistema se puede implantar utilizando tecnología actual dentro de las

restricciones de tiempo y presupuesto?
3.¿El sistema puede integrarse a otros sistemas existentes en la empresa?
El estudio de viabilidad no debe requerir más de dos o tres semanas.
El resultado de este estudio es un informe que recomiende si vale o no la pena

seguir con la ingeniería de requerimientos y proceso de desarrollo del sistema.
Se pueden proponer cambios en el alcance, el presupuesto o sugerir
requerimientos adicionales de alto nivel.
8
“El estudio de Factibilidad”
Para ayudar a responder las preguntas del estudio de viabilidad, se tienen

algunos ejemplos de preguntas posibles:
• ¿Cómo se las arreglaría la organización o empresa si no se implantara el sistema?
• ¿Cuáles son los problemas con los procesos actuales y como ayudaría un sistema
nuevo a aliviarlos?
• ¿Cuál es la contribución directa que hará el sistema a los objetivos y requerimientos

del negocio?
• ¿Se puede obtener y transferir la información a otros sistemas de la organización?
• ¿El sistema requiere tecnología que no se ha utilizado previamente en la

organización?
• ¿A que debe ayudar el sistema y a qué no necesita ayudar?
9
Procesos de la Ing. de Requerimientos.
“Obtención y análisis de requerimientos”
 En esta actividad, los ingenieros de software trabajan con los clientes y

los usuarios finales del sistema para determinar el dominio de la
aplicación, qué servicios debe proporcionar el sistema, el rendimiento
requerido del sistema, las restricciones hardware, etcétera.
 Revisar la situación actual.

 Trabajar en el ámbito del usuario para comprender el contexto, los
problemas y las relaciones.
 Entrevistar a los usuarios actuales y potenciales.
 Realizar un video para mostrar como podría funcionar el nuevo sistema.
 Investigar en documentos existentes.
 Conducir tormentas de ideas con los usuarios actuales y potenciales.
 Observar las estructuras y los patrones.
10
11
El descubrimiento de requerimientos es el proceso de recoger

información sobre el sistema propuesto y los existentes extrayendo esta
información del usuario y del sistema.
Las fuentes de información durante la fase del descubrimiento de

requerimientos incluyen la documentación, los stakeholders del sistema
y la especificación de sistemas similares.
Las técnicas de descubrimiento de requerimientos, son varias, pueden

usarse entrevistas, escenarios, prototipos y etnografía.
12
Técnicas para la obtención y descripción
de requisitos
 Entrevistas y Cuestionarios
 Sistemas existentes
 Lluvia de ideas (Brainstorm)
 Prototipos
 Casos de Uso
13
de requisitos
 Cómo llevar adelante una entrevista?
 La entrevista es un recurso caro

 Consume un tiempo significativo de más de una persona
 Requiere una planificación cuidadosa.
 Es importante escuchar con atención, pero no basta con
escuchar pasivamente:
 Hay que saber preguntar, el cliente necesita ayuda.
 Ganarse la confianza del cliente.
 El resultado es producto del trabajo conjunto.
 Escribir los requisitos y validarlos por escrito; continuar las
reuniones hasta lograr el acuerdo.
14
de requisitos
 Antes de la Entrevista:
 Enumerar y priorizar los entrevistados.
 Planificar la hora de comienzo y finalización de cada entrevista.
 Enumerar los puntos que es necesario tratar en la entrevista.
 Durante la entrevista:
 Asistir al menos dos personas del equipo de analistas (uno pregunta,
otro anota).
 Usar cinta grabadora (pedir permiso).
 Concentrarse y escuchar.
 No ser pasivo: preguntar y animar.
 Insistir hasta entender los deseos y las necesidades.
 Utilizar diagramas (si son útiles y según la formación de los
entrevistados).
 Tomar notas detalladas.
 Concretar la siguiente entrevista.
15
de requisitos
 Después de la Entrevista:
 Redactar el borrador de requisitos.
 Revisar entre los dos entrevistadores.
 Enviar a los clientes para comentar y aprobar.
 Las entrevistas pueden ser de dos tipos:

 Entrevistas cerradas: donde los entrevistados responden a un
conjunto predefinido de preguntas.
 Entrevistas abiertas: donde no hay un programa predefinido. El

equipo de la ingeniería de requerimientos examina una serie de
cuestiones con los involucrados con el sistema y, por lo tanto,
desarrolla una mejor comprensión de sus necesidades.
 En la práctica, las entrevistas son una mezcla de estos dos tipos.
16
de requisitos
■ Las entrevistas sirven para obtener una comprensión general de lo que

hacen los futuros usuarios del sistema, cómo podrían interactuar con el
sistema y las dificultades a las que se enfrentan con los sistemas actuales.
■ Las entrevistas, son una técnica general para obtener información.
■ Se pueden complementar las entrevistas individuales con entrevistas en

grupo o grupos de discusión. Las ventajas de utilizar grupos de discusión
es que los usuarios se estimulan entre sí para proporcionar información y
pueden terminar discutiendo diferentes formas que han desarrollado para
utilizar los sistemas.
17
Técnicas para la obtención y descripción de
requisitos
18
Procesos para la obtención de Requisitos
 Sistemas Existentes
 Esta técnica consiste en analizar distintos sistemas ya desarrollados
que estén relacionados con el sistema a ser construido. Por un lado,
podemos analizar las interfases de usuario, observando el tipo de
información que se maneja y cómo es manejada, por otro lado también
es útil analizar las distintas salidas que los sistemas producen (listados,
consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la
base de estas.
 Lluvia de ideas (Brainstorm)
 La intención en su aplicación es la de generar la máxima cantidad
posible de requerimientos para el sistema. No hay que detenerse en
pensar si la idea es o no del todo utilizable. La intención de este
ejercicio es generar, en una primera instancia, muchas ideas. Luego, se
irán eliminando en base a distintos criterios como, por ejemplo, "caro",
"impracticable", "imposible", etc.
19
 Prototipos
 Para validar los requerimientos hallados, se construyen prototipos. Los
prototipos son simulaciones del posible producto, que luego son
utilizados por el usuario final, permitiéndonos conseguir una importante
retroalimentación en cuanto a si el sistema diseñado con base a los
requerimientos recolectados le permite al usuario realizar su trabajo de
manera eficiente y efectiva.
 El desarrollo del prototipo comienza con la captura de requerimientos.

Desarrolladores y clientes se reúnen y definen los objetivos globales del
software, identifican todos los requerimientos que son conocidos, y
señalan áreas en las que será necesaria la profundización en las
definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño
rápido se centra en una representación de aquellos aspectos del
software que serán visibles al usuario (por ejemplo, entradas y formatos
de las salidas). El diseño rápido lleva a la construcción de un prototipo.
20
 Casos de Uso
 Los casos de uso permiten entonces describir la posible secuencia de
interacciones entre el sistema y uno o más actores, en respuesta a un
estímulo inicial proveniente de un actor, es una descripción de un
conjunto de escenarios, cada uno de ellos comenzado con un evento
inicial desde un actor hacia el sistema. La mayoría de los requerimientos
funcionales, sino todos, se pueden expresar con casos de uso.
 Según el autor Sommerville, los casos de uso son una técnica que se
basa en escenarios para la obtención de requerimientos. Actualmente, se
han convertido en una característica fundamental de la notación UML
(Lenguaje de modelado unificado), que se utiliza para describir modelos
de sistemas orientados a objetos.
21
 Validación de requerimientos
 Sirve para demostrar que éstos realmente definen el sistema que el

cliente desea.
 Asegura que los requerimientos están completos, son exactos y
consistentes.
 La validación es importante porque la detección de errores durante el
proceso de análisis de requerimientos reduce mucho los costos.
 Verificación de validez. Puede identificar requerimientos adicionales
o diferentes a las que pidieron los stakeholders.
 Verificación de consistencia. No debe haber restricciones o
descripciones contradictorias en el sistema.
 Verificación de completitud. El documento de requerimientos debe
incluir requerimientos que definan todas las funciones y
restricciones propuestas por el usuario del sistema.
22
 Validación de requerimientos
 Verificación de realismo. Asegurar que los requerimientos pueden

cumplirse teniendo en cuenta la tecnología existente, el presupuesto y el
tiempo disponible.
 Verificabilidad. Para reducir la posibilidad de discusiones con el cliente, los
requerimientos del sistema siempre deben redactarse de tal forma que
sean verificables. Esto significa que se debe poder escribir un conjunto de
pruebas que demuestren que el sistema a entregar cumple cada uno de
los requerimientos especificados.
23
 Revisiones de requerimientos:
 Que el requerimiento se pueda verificar de modo realista.
 Que las personas que adquieren el sistema o los usuarios finales
comprendan correctamente el requerimiento.
 Que tan adaptable es el requerimiento? ¿puede cambiarse el
requerimiento sin causar efectos de gran escala en los otros
requerimientos del sistema?
 Construcción de prototipos: consiste en mostrar un modelo ejecutable del

sistema a los usuarios finales y a los clientes, así éstos pueden
experimentar con el modelo para ver si cumple con sus necesidades reales.
 Generación de casos de prueba: si una prueba es difícil o imposible de

diseñar, normalmente significa que los requerimientos serán difíciles de
implantar y deberían ser considerados nuevamente.
24
25

Ing de Requerimientos Elicitacion de Requerimientos

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ing de Requerimientos Elicitacion de Requerimientos

Cargado por

Copyright:

Formatos disponibles

Ingeniería de

■ “La carencia de buenos requisitos ha sido la causa

■ Necesidad de la Ingeniería de Requisitos:

■ Por qué es necesario escribir los requisitos:

■ Tarea descuidada durante mucho tiempo: trivial, “literaria”, poco

■ Diferentes puntos de vista – Diferentes documentos

Obtención y descripción de requisitos del usuario

Las fuentes de los requisitos

Cómo llevar adelante una entrevista

■ El estudio de factibilidad, que evalúa si el sistema es

■ Obtención y análisis de requerimientos.

■ Especificación de requerimientos: transformación de

■ Validación: verificar que los requerimientos realmente

Estudio corto y orientado a resolver las siguientes preguntas:

1.¿El sistema contribuye a los objetivos generales de la organización o

2.¿El sistema se puede implantar utilizando tecnología actual dentro de las

3.¿El sistema puede integrarse a otros sistemas existentes en la empresa?

El estudio de viabilidad no debe requerir más de dos o tres semanas.

El resultado de este estudio es un informe que recomiende si vale o no la pena

Para ayudar a responder las preguntas del estudio de viabilidad, se tienen

• ¿Cómo se las arreglaría la organización o empresa si no se implantara el sistema?

• ¿Cuál es la contribución directa que hará el sistema a los objetivos y requerimientos

• ¿Se puede obtener y transferir la información a otros sistemas de la organización?

• ¿El sistema requiere tecnología que no se ha utilizado previamente en la

• ¿A que debe ayudar el sistema y a qué no necesita ayudar?

 En esta actividad, los ingenieros de software trabajan con los clientes y

 Revisar la situación actual.

El descubrimiento de requerimientos es el proceso de recoger

Las fuentes de información durante la fase del descubrimiento de

Las técnicas de descubrimiento de requerimientos, son varias, pueden

 Lluvia de ideas (Brainstorm)

 Cómo llevar adelante una entrevista?

 La entrevista es un recurso caro

 Las entrevistas pueden ser de dos tipos:

 Entrevistas abiertas: donde no hay un programa predefinido. El

 En la práctica, las entrevistas son una mezcla de estos dos tipos.

■ Las entrevistas sirven para obtener una comprensión general de lo que

■ Las entrevistas, son una técnica general para obtener información.

■ Se pueden complementar las entrevistas individuales con entrevistas en

 El desarrollo del prototipo comienza con la captura de requerimientos.

 Sirve para demostrar que éstos realmente definen el sistema que el

 Verificación de realismo. Asegurar que los requerimientos pueden

 Construcción de prototipos: consiste en mostrar un modelo ejecutable del

 Generación de casos de prueba: si una prueba es difícil o imposible de

También podría gustarte