1. Instituto universitario politécnico
“Santiago Mariño”
Extensión Porlamar
Escuela de ingeniería de sistemas
Sistemas II
INGENIERÍA DE REQUISITOS E INGENIERÍA DE
REQUERIMIENTOS
Bachiller:
PlacencioJohana
C.I:19.909.628
Ing. Diogenes Rodriguez
Porlamar, Enero 2017

2. Ingenieríade Requisitos:
Comprende todas las tareas relacionadas con la determinación de las
necesidades o de las condiciones a satisfacer para un software nuevo o
modificado, tomando en cuenta los diversos requisitos de las partes
interesadas, que pueden entrar en conflicto entre ellos.
El propósito de la ingeniería de requisitos es hacer que los mismos
alcancen un estado óptimo antes de alcanzar la fase de diseño en el
proyecto. Los buenos requisitos deben ser medibles, comprobables, sin
ambigüedades o contradicciones, etc.
En fin la Ingeniería de Requisitos, es el proceso de desarrollar una
especificación de Software. Las especificaciones pretenden comunicar las
necesidades del sistema del cliente a los desarrolladores del sistema.
Definición de Requerimientos:
Lan Sommerville define, que un requerimiento es simplemente una
declaración abstracta de alto nivel de un servicio que debe proporcionar el
sistema o una restricción de este. (sommerville, 2005:108).
En fin un requerimiento es una descripción de una condición o
capacidad que debe cumplir un sistema ya sea derivada de una
necesidad de un usuario identificada, o bien, estipulada en un contrato,
estándar, especificación u otro documento formalmente impuesto al inicio
del proceso.
Característicasde los Requerimientos:
Sus principales características son:

3.  Especificado por escrito: como todo contrato o acuerdo entre dos
partes.
 Posible de probar o verificar: si un requerimiento no se puede
comprobar, entonces ¿cómo se sabe si se cumplió con él o no?
 Conciso: un requerimiento es conciso es fácil de leer y entender. Su
redacción debe ser simple y clara para aquellos que vayan a
consultarlo en un futuro.
 Completo: un requerimiento esta completo si no necesita ampliar
detalles en su redacción, es decir, si 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. El lenguaje usado en su definición, no debe causar
confusiones al lector.
Ingeniería de Requerimientos:
La ingeniería de requerimiento sirve como una base solida en el
proceso de desarrollo de software, por lo que antes de pasar de tratar los
aspectos referentes a la administración adecuada a los requerimientos.
Técnicasprincipales aplicadas en la Ingenieríade Requisitos:
La ingeniería de requisitos puede ser un proceso largo y arduo para el

4. que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el
entorno y las relaciones entre la gente, así que es importante identificar a
todos los actores involucrados, considerar sus necesidades y asegurar que
entienden las implicaciones de los nuevos sistemas
 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.
 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.
Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente
controlado, talleres facilitados por un analista del negocio, en donde las
personas implicadas participan en discusiones para descubrir requisitos,
analizan sus detalles y las implicaciones cruzadas.
.
Fases de la Ingeniería de requerimientos:
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.

5.  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
requisitos.
 Validar los requisitos: comprobar que los requisitos implementados
sean funcionales para lo que inicialmente se construyó el producto.
Requerimientos de software de la Ingeniería de
Requerimientos:
Una especificación de requisitos del software es una descripción completa
del comportamiento del sistema a desarrollar. Incluye un conjunto de casos
de uso que describen todas las interacciones que se prevén que los usuarios
tendrán con el software. También contiene requisitos no funcionales (o
suplementarios). Los requisitos no funcionales son los requisitos que
imponen restricciones al diseño o funcionamiento del sistema (tal como
requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).
Los requisitos se dividen en tres:
 Funcionales: son los que el usuario necesita que efectúe el software.
 No funcionales: son los "recursos" para que trabaje el sistema de
información (redes, tecnología).
 Empresariales u Organizacionales: son el marco contextual en el cual
se implantará el sistema para conseguir un objetivo macro.
Actividades de la Ingeniería de Requerimientos:
Actividades cíclicas que cumplen una buena práctica de ingeniería de
requisitos.

6.  Extracción: Esta fase representa el comienzo de cada ciclo.
 Estudio de viabilidad: En esta fase se estima si el problema del
usuario se podrá resolver con la tecnología disponible y si el sistema
será rentable según el presupuesto del que se dispone.
 Análisis: Sobre la base de la extracción realizada previamente,
comienza esta fase en la cual se interactúa con clientes o usuarios
para determinar los requisitos funcionales y funcionales del sistema,
además del dominio de la aplicación.
 Especificación: En esta fase se documentan los requisitos con mayor
detalle y precisión, de manera que sirva de base para un contrato
entre el desarrollador y el cliente.
 Validación: La validación es la etapa final de la IR. Su objetivo es,
ratificar los requisitos, es decir, verificar todos los requisitos que
aparecen en el documento especificado para asegurarse de que son
aceptados por el cliente.
Dificultades para definir los Requerimientos:
Durante la etapa de especificación de requerimientos se pueden
presentar muchos inconvenientes los cuales son importantes de identificar y
prevenir. A continuación se presenta un listado con los problemas más
comunes en este proceso:
• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• La cantidad de requerimientos en un proyecto pueden ser difícil de
manejar.

7. • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• El usuario no puede explicar lo que hace.
• Tiende a recordar lo excepcional y olvidar lo rutinario.
• Hablan de lo que no funciona.
• Los usuarios tienen distinto vocabulario que los desarrolladores.
Usan el mismo término con distinto significado
Técnicas y herramientas utilizadas en la Ingeniería de
Requerimientos:
• Técnicas utilizadas en las actividades de IR: existen varias técnicas
para IR propuesta para ingeniería de requerimientos (Herrera, 2003:
12), y de las cuales en este artículo solo se abarcaran 5 de ellas.
• 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 del sistema.
• Sistemas existentes: Esta técnica consiste en analizar distintos
sistemas ya desarrollados que estén relacionados con el sistema a ser
construido.
• Lluvias de ideas: este es un modelo que se usa para generar ideas.
La intensión en su aplicación es la de generar la máxima cantidad
posible de requerimientos para el sistema.
• Prototipos: durante la actividad de extracción de requerimientos,
puede ocurrir que algunos requerimientos no estén demasiados claros

8. o que no se esté muy seguro de haber entendido correctamente los
requerimientos obtenidos hasta el momento todo lo cual puede llevar a
un desarrollo no eficaz del sistema final.
• Caso de uso: son una técnica para especificar el comportamiento de
un sistema.
http://es.slideshare.net/jakiu/presentacin1-71306310

9. Mapa mental
http://es.slideshare.net/jakiu/presentacin1-71306310