Ingenieria de Requerimientos

1. INGENIERÍA DE REQUISITOS E
INGENIERÍA DE REQUERIMIENTOS
INSTITUTO UNIVERSITARIO
POLITECNCO SANTIAGO MARIÑO
Elaborado por: Betty Bolaños
Profesor:
Ing. María Teresa Langone

2. En la actualidad son muchos los cambios y procesos de desarrollos de software
que existe; y con el pasar de los años la Ingeniería de Software a popularizado un sin fin de
estándares para medir la calidad tanto en desarrollar sistemas como en procesos de
desarrollo. Y dentro de los avances tecnológicos la Ingeniería de requerimientos cumple un
papel primordial en el proceso de producción de software ya que se enfoca en un área
fundamental: definición de lo que se desea producir en comportamiento del sistema y
minimizar errores en el desarrollo.
Con este trabajo se pretende resaltar la importancia que tiene la ingeniería de
requerimientos dentro del ciclo del desarrollo, dar a conocer las diferentes alternativas que
existen para identificar requerimientos, características de los requerimientos dificultades y
técnicas utilizadas en la ingeniería de Requerimientos.
Introducción
Sistemas II

3. Implica todas las actividades del ciclo de vida dedicadas a:
La educción (a veces llamada "elicitación", debido a una mala traducción de
"elicitation") de los requisitos de usuario.
El análisis y negociación de requisitos para derivar requisitos adicionales.
La documentación de los requisitos como especificación.
La validación de los requisitos documentados contra las necesidades de usuario.
Así como los procesos que apoyan estas actividades.
Ingeniería de Requisitos
Sistemas II

4. Los requerimientos son declaraciones que identifican atributos, capacidades,
características y/o cualidades que necesita cumplir un sistema (o un sistema de
software) para que tenga valor y utilidad para el usuario. En otras palabras, los
requerimientos muestran qué elementos y funciones son necesarias para un
proyecto
Sistemas II
Requerimientos

5. Las características de un requerimiento son sus propiedades principales. Un conjunto de
requerimientos en estado de madurez, deben presentar una serie de características tanto
individualmente como en grupo.
Necesario: un requerimiento es necesario si su omisión
provoca una deficiencia en el sistema a construir , y además
su capacidad.
Conciso: Un requerimiento es conciso si es fácil de leer y
entender.
Completo: Un requerimiento esta completo si no necesita
ampliar detalles en su redacción, se proporciona la
información suficiente para su comprensión.
Consistente: un requerimiento es consistente si no es contradictorio
con otro requerimiento.
No ambiguo: un requerimiento no es ambiguo cuando tiene una
sola interpretación. Verificable: un requerimiento es verificable
cuando 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.
Sistemas II
Características de los Requerimientos

6. Los requerimientos son la pieza fundamental en un proyecto de desarrollo de software, es
ellos se basas muchos participantes del proyecto para planear el proyecto de los recursos
que se usaran en el. Los lideres de proyecto y los recursos que se usaran en él.
Sistemas II
Ingeniería de Requerimientos

7. La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de
habilidades psicológicas. Los nuevos sistemas cambian en el entorno y las relaciones entre
la gente así que es importante para todos los involucrados considerar su necesidad y
asegurar que entienden las implicaciones de los nuevos sistemas.
Los métodos son los siguientes:
• Entrevistas: son un método en común, normalmente no se entrevista a toda la gente
que se relaciona con el sistema, sino a un grupo seleccionado que represente a los
sectores críticos de la organización.
• Talleres: los requisitos tienen a menudo implicaciones cruzadas desconocidas para las
personas implicadas individuales y que a menudo no se descubren en las entrevistas o
quedan incompletamente definidas durante la misma.
• Forma de Contrato: en lugar de una entrevista, se pueden llenar formularios o contratos
indicando los requisitos.
• Objetivos Medibles: los requisitos 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 apreciados por el usuario.
• Prototipo y casos de uso: un prototipo es una pequeña muestra de funcionabilidad
limitada, de como seria el producto final una vez terminado. Ayudan a conocer la
opinión de los usuarios y rectificar algunos aspectos antes de llegar el producto
terminado.
Sistemas II
Técnicas Principales Aplicadas en la Ingeniería de Requisitos

8. Según Karl (2013,p,52) sostuvo que “Desde un punto de vista conceptual, las actividades
son de cinco clases.
Obtener requisitos: a través de entrevistas o comunicación con clientes o futuros usuarios,
para saber cuáles son sus expectativas.
Analizar requisitos: detectar y corregir las carencias o falencias comunicativas,
transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones
apropiadas para ser tratados en el diseño.
Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente
documentados.
Verificar los requisitos: consiste en comprobar la implementación de los requerimientos.
Validar los requisitos: comprobar que los requisitos implementados sean funcionales para
lo que inicialmente se construyó el producto”.
Sistemas II
Fases de la Ingeniería: Requerimientos

9. Según Hendrina Garcia (2011,) dice que “En este proceso de Ingeniería de
requerimientos estas actividades son aplicadas de manera continua y en orden variado,
dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado
para el ciclo de desarrollo, las actividades de la IR varían tanto en numero como en
nombres”. Podemos identificar y extraer cinco actividades principales que son:
• Análisis del Problema
• Evaluación y negociación
• Especificación
• Validación
• Evolución.
Sistemas II
Actividades de la Ingeniería de Requerimientos

10. • Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más
estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con
otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales
específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para
cada proyecto.
Sistemas II
Dificultades para Definir los Requerimientos

11. Existen varias técnicas para la IR, cada técnica puede aplicarse en una o mas actividades
de la IR; practica, la técnica mas apropiada por cada actividad dependerá del proyecto que
este desarrollándose.
Entrevistas y cuestionarios,- las entrevistas y cuestionarios se emplean para reunir
información proveniente de personas o de grupos. Durante la entrevista el analista conversa
con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con
varios aspectos de un sistema.
Por lo común los encuestados son usuarios de los sistemas existentes o usuarios en
potencia del sistema propuesto.
Las preguntas deben realizarse en esta técnica, ser preguntas de alto nivel y abstractas que
pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales
del problema del usuario y soluciones potenciales.
Sistemas II
Técnicas y Herramientas Utilizadas en la Ingeniería de Requerimientos

12. Ejemplo de preguntas abiertas del
Usuario:
¿Quién es el cliente?
¿Quién es el usuario?
¿Son sus necesidades diferentes?
¿Cuáles son sus habilidades, capacidades, ambiente?
Proceso:
¿Cuál es la razón por la que se quiere resolver este problema?
¿Cuál es el valor de una solución exitosa?
¿Cómo usted resuelve el problema actualmente?
¿Qué retrasos ocurren o pueden ocurrir?
Producto:
¿Qué problemas podría causar este producto en el negocio?
¿En qué ambiente se usará el producto?
¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento?
¿Qué obstáculos afectan la eficiencia del sistema?
Sistemas II

13. Además de:
Grabaciones de video y de audio
Brainstorming (tormenta de ideas)
Arqueología de documentos
Aprendiz.
Observación
Run Use Case WorkShop (talleres de trabajo basados en los Casos de Uso)
Prototipos
Análisis FODA (Fortalezas, Oportunidades, Debilidades y Amenazas)
Cadena de valor
Modelo de clase conceptual, Diagrama Conceptual, Diagrama de Clases Conceptual
Diagrama de pescado (Ishikawa Diagram, Cause-and-Effect o Fishbone Diagram)
Glosario
Diagrama de actividad
Documento ESRE, Casos de uso
Lista de requerimientos
Casos de uso
Casa de calidad o QFD (Quality Function Deployment)
Checklist (lista de verificación)
Sistemas II

14. En español desarrollo conjunto de aplicaciones, es una técnica exploratoria popular que
incluye a los usuarios como participantes activos en el proceso de desarrollo
La técnica más usada según nuestro criterio es la técnica de método jad, porque permite que
los usuarios dominantes participen con eficacia en los requisitos que modelan el proceso,
cuando los usuarios participan en el proceso del desarrollo de los sistemas, es más probable
percibir un sentido de la propiedad en los resultados, y la ayuda para el nuevo sistema.
Sistemas II
JAD (Joint Application Development)

15. Este método comenzó en el ámbito de las empresas, aplicándose a temas tan variados como
la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del
mercado, encontrar nuevos métodos que desarrollen el pensamiento creativo a todos los
niveles, etc. Pero pronto se extendió a otros ámbitos, incluyendo el mundo de desarrollo de
sistemas; básicamente se busca que los involucrados en un proyecto desarrollen su
creatividad, promoviendo la introducción de los principios creáticos.
Sistemas II
Lluvia de Ideas (Brainstorm)

16. Es una representación mental. Está formado por:
CONCEPTOS: Siempre dentro de un globo.
CONECTORES: Sin englobar, sobre la línea de unión.
LÍNEAS DE UNIÓN: Señalan cómo se establece la relación.
Sirve para organizar, comprender y retener la información
significativamente.
Storyboarding se utiliza en el desarrollo de software
como parte de la identificación de las especificaciones
de un software particular. Durante la fase de
especificación, pantallas que el software mostrará
provienen, ya sea en papel o con otro software
especializado, para ilustrar los pasos importantes de la
experiencia del usuario
Sistemas II
Mapas Conceptuales
Sketches y Storyboard

17. Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse
para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso
de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso
es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores
en respuesta a un evento que inicia un actor principal sobre el propio sistema.
Sistemas II
Casos de Usos

18. Dentro de este trabajo se presentaron unas series de actividades y técnicas de
requerimientos de software ya que es de suma importancia ya que permite conocer
a los clientes y usuarios así como el ambiente de trabajo, esto ayuda a establecer
una buena relación de trabajo y comunicación entre el equipo de desarrollo y los
clientes. Es necesario que para cada desarrollo los clientes y usuarios se
involucren en la definición de sus requerimientos, pues ellos son los que deciden el
destino del proyecto.
Sistemas II
Conclusiones

19. Senn, James “Análisis y Diseño de Sistemas de Información”. Segunda Edición. McGraw
Hill. 1992”
Pressman, R.R “Ingeniería del Software. Un enfoque practico”, McGraw-Hill.
Sánchez, Jose (2010). Ingeniería de requisitos: Técnicas y herramientas utilizadas en la
IR. Recuperado 20 de mayo 2015 de
http://es.slideshare.net/americoguzman/cmo-hacer-referencias-bibliogrficas-9155932
Herrera Johany (2013). Ingeniería de Requerimientos de Software: la Ingeniería de
Requerimientos y sus Principales Actividades. Recuperado 19 Mayo 2015 de
http://www.monografias.com/trabajos6/resof/resof.shtml
Sistemas II
Referencias Bibliográficas y Electrónicas