en este trabajo se agrupan conceptos de la ingeniería de requerimientos la cual comprende todas las tareas relacionadas Con las condiciones a satisfacer para un software nuevo o modificado tomado en cuenta lo diferentes requisitos de las partes relacionadas, si propósito es hacer que los requisitos o requerimientos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto.

1. CENTRO BIOTECNOLÓGICO DEL CARIBE SENA
INGENIERIA DE REQUERIMIENTO
EVAN HERNÁNDEZ
LESLY VALLEJO
CATALINA BERMÚDEZ
ESLEIDER VARGAS
FICHA: 1751818
A.D.S.I
INSTRUCTOR: FRANCISCO JEREZ
VALLEDUPAR-CESAR
2018

2. 1. ¿Qué es un requerimiento/requisito?
Una condición o capacidad que debe cumplir o poseer un sistema o componente
de sistema para satisfacer un contrato, estándar, especificación, o cualquier otro
documento impuesto formalmente. Requerimiento, por lo tanto, es una cosa que
se exige o que se le reclama a alguien. En el ámbito de la informática, un
requerimiento es una exigencia que tiene un software para poder funcionar de
manera correcta. El sistema operativo Windows 7, por citar un caso, cuenta con
los siguientes requerimientos: microprocesador de 1 GHz, 16 GB de espacio
disponible en el disco rígido (también conocido como disco duro), placa de vídeo
(tarjeta gráfica) con capacidad para DirectX 9c y una memoria RAM de 1 GB. Una
computadora (ordenador) que no disponga de este hardware básico, no podrá
ejecutar Windows 7 de manera fluida. requisitos deben ser medibles,
comprobables, sin ambigüedades o contradicciones, etc.
2. En una tabla favor decir los tipos de requisitos
Requisitos de usuario Son frases en lenguaje natural
o descripciones gráficas
(diagramas) de los servicios
que se espera que ofrezca el
sistema y de sus restricciones.
Requisitos de sistema Una descripción más detallada de los
servicios exactos que se
proporcionarán y sus restricciones.
Estos requisitos sirven como contrato
con el cliente. A su vez los requisitos
de sistema pueden dividirse en
requisitos funcionales, no funcionales
y de dominio.
Requisitos funcionales: Especifican lo que debe hacer o los
servicios que debe proporcionar el
sistema. Ejemplo: en un software de
gestión de una biblioteca podrían ser
requisitos funcionales dar de alta un
cliente, alquilar un libro, devolver un
libro, comprar un libro, etc. Los
requisitos funcionales deben
describir también cómo responderá
el sistema ante estas distintas
entradas, y su comportamiento frente
a situaciones particulares

3. Requisitos no funcionales Son restricciones de los servicios del
sistema o funciones que ofrece.
Ejemplo: en un software de gestión
de compras de una tienda podrían
ser requisitos no funcionales un tpv
para pagar con tarjeta, un PC con
memoria y espacio en disco para
almacenar la base de datos de
ventas, que sea capaz de atender a
la vez a varios clientes, que no tarde
más de X tiempo en gestionar una
venta, etc.
Requisitos de dominio Estos requisitos reflejan
características del dominio de
la aplicación. Ejemplo: la
forma en la que se
comunicarán distintas partes
de la aplicación, el tipo de
datos con los que trabajará,
etc.
3. Hacer un diagrama con la clasificación de los requisitos no funcionales.

4. 4.¿Qué se entiende por Ingeniería de Requisitos (IR)?
La ingeniería de requisitos o de requerimiento comprende todas las tareas
relacionadas
Con las condiciones a satisfacer para un software nuevo o modificado tomado en
cuenta lo diferentes requisitos de las partes relacionadas, si propósito es hacer
que los requisitos o requerimientos alcancen un estado óptimo antes de alcanzar
la face de diseño en el proyecto.
5. Mencione las actividades de la Ingeniería de Requerimientos.
La ingeniería de requisitos es el conjunto de actividades y tareas del proceso de
desarrollo de sistemas software que tiene como objetivos:
Definir, con la mejor calidad posible, las características de un sistema software
que satisfaga las necesidades de negocio de clientes y usuarios y que se integre
con éxito en el entorno en el que se explote. La definición de dicho sistema se
realiza mediante lo que se conoce como una especificación de requisitos.
Gestionar las líneas base y las peticiones de cambios que se vayan produciendo
en la especificación de requisitos, manteniendo la trazabilidad entre los requisitos
y otros productos del desarrollo.
6. Cuáles son las personas involucradas en la Ingeniería de
Requerimientos.
Personal involucrado en la Ingeniería de Requerimientos
Son muchas las personas involucradas en el desarrollo de los requerimientos de
un sistema. Es importante saber que cada una de esas personas tienen diversos
intereses y juegan roles específicos dentro de la planificación del proyecto; el
conocimiento de cada papel desempeñado, asegura que se involucren a las
personas correctas en las diferentes fases del ciclo de vida, y en las diferentes
actividades de la IR(ingeniería de requerimiento).

5. No conocer estos intereses puede ocasionar una comunicación poco efectiva
entre clientes y desarrolladores, que a la vez traería impactos negativos tanto en
tiempo como en presupuesto. Los papeles o roles más importantes pueden
clasificarse en:
Usuario final: Son las personas que utilizarán el sistema desarrollado. Ellos están
relacionados con la disponibilidad y la fiabilidad del sistema; están familiarizados
con los procesos específicos que debe realizar el software, dentro de los
parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los
manuales de usuario.
Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el
dominio del problema en donde será empleado el software desarrollado. Ellos
proporcionan al equipo técnico los detalles y requerimientos de las interfaces del
sistema.
Personal de Mantenimiento: Para proyectos que requieran un mantenimiento
eventual, estas personas son las responsables de la administración de cambios,
de la implementación y resolución de anomalías. 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í; ellos interactúan directamente con el cliente.
Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para
asegurar que las condiciones presentadas por el sistema son las adecuadas. Son
quienes van a validar si los requerimientos satisfacen las necesidades del cliente.
Otras personas que pueden estar involucradas, dependiendo de la magnitud del
proyecto, pueden ser:
• Administradores de proyecto: Responsable de administrar los procesos
internos del desarrollo de sistemas, para este cargo es necesario contar con
habilidades de administración para evadir las diferentes situaciones que se
presenten y además garantizar el cumplimiento de los objetivos dentro de los
tiempos estipulados. Estas habilidades van desde la definición del proyecto, hasta
la administración de las medidas de avance del mismo.
• Documentadores: Es el encargado de evidenciar la información generada a lo
largo del desarrollo del producto hasta el lanzamiento, algunas de los informes que
debe de realizar son la prototipificación3(especificaciones, etc.), recopilación de
información (análisis), creación de un documento a partir de las notas recopiladas

6. (borradores), validación del manual (pruebas de uso) y distribución (por ejemplo.
documentación impresa en papel). Cada etapa del proceso afecta a todas las
demás etapas y debiera ser creada en conjunto con todas las otras etapas de
desarrollo.
• Diseñadores de base de datos: Es el encargado de desglosar el problema en
diferentes subsistemas, identificar la concurrencia inherente al problema, asignar
los subsistemas a los procesadores y tareas, seleccionar los almacenes de datos,
manejar el acceso a recursos globales, implementar el control del software.
7. Análisis comparativo de las técnicas de Ingeniería de
Requerimientos
Comparación entre algunas de las técnicas:
Entrevistas vs. Casos de Uso: Un alto porcentaje de la información recolectada
durante una entrevista, puede ser usada para construir casos de uso. Mediante
esto, el equipo de desarrollo puede entender mejor el ambiente de trabajo de los
involucrados. Cuando el analista sienta que tiene dificultades para entender una
tarea, pueden recurrir al uso de un cuestionario y mostrar los detalles recavados
en un caso de uso. De hecho, durante las entrevistas cualquier usuario puede
utilizar diagramas de casos de uso para explicar su entorno de trabajo.
Entrevistas vs. Lluvia de Ideas: Muchas de las ideas planteadas en el grupo,
provienen información recopilada en entrevistas o cuestionarios previos.
Realmente la lluvia de ideas trata de encontrar las dificultades que existen para la
comprensión de términos y conceptos por parte de los participantes; de esta forma
se llega a un consenso.
Casos de Uso vs. Lluvia de Ideas: La lista de ideas proveniente del brainstorm
puede ser representada gráficamente mediante casos de uso. La tabla 3 muestra
las técnicas que pueden ser utilizadas en las diferentes actividades de la IR.

7. Análisis del
Problema
Evaluación y
negociación
Especificación
de Requisitos
Validación Evolución
Entrevistas y
Cuestionarios
X X
Lluvia de
Ideas
X X
Prototipos X
Análisis
Jerárquico
X X
Casos de Uso X X X
Tabla 3. Actividades en dónde pueden ser utilizadas las técnicas de la IR.
8. Importancia de la Ingeniería de Requerimientos
Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son
• Permite gestionar las necesidades del proyecto en forma estructurada: Cada
actividad de la IR consiste de una serie de pasos organizados y bien definidos.
• Mejora la capacidad de predecir cronogramas de proyectos, así como sus
resultados: La IR proporciona un punto de partida para controles subsecuentes y
actividades de mantenimiento, tales como estimación de costos, tiempo y recursos
necesarios.
• Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado
que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente
caro.
• Mejora la calidad del software: La calidad en el software tiene que ver con
cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso,
confiabilidad, desempeño, etc..

8. • Mejora la comunicación entre equipos: La especificación de requerimientos
representa una forma de consenso entre clientes y desarrolladores, si este
consenso no ocurre, el proyecto no será exitoso.
• Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al
cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del
marco del problema, por lo que se le involucra durante todo el desarrollo del
proyecto.
9. Gestión de Requisitos y Principales características
Es un conjunto de actividades que ayudan al equipo de trabajo a identificar,
controlar y seguir los requisitos y los cambios en cualquier momento. Muchas de
estas actividades son idénticas a las técnicas de gestión de configuración del
software.
Como en la Gestión de Configuración del Software (GCS), la gestión la gestión de
requisitos comienza con la actividad de identificación. A cada requisito se le asigna
un único identificador , que puede tomar la forma:
<tipo de requisito><requisito n,o>
Pueden dividirse en dos categorías: requerimientos de negocio y requerimientos
técnicos. Los primeros definen las necesidades y deseos de la organización en
relación a la consecución el proyecto, mientras que los segundos se centran en las
soluciones que harán posible la consecución de dichas metas. Todos son igual de
importantes de satisfacer y todos imprescindibles para finalizar el proyecto con
éxito.
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. A continuación se presentan
las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia
en el sistema a construir, y además su capacidad, características físicas o factor
de calidad no pueden ser reemplazados por otras capacidades del producto o del
proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción
debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

9. Completo: Un requerimiento está 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.
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, demostración o pruebas.
RF- <id del requisito> < nom bre del requisito funcional>
Versión <num ero de versión y fecha>
Autores <autor>
Fuentes <fuente de la versión actual>
O bjetivos asociados <nom bre del objetivo>
Descripción El sistem a deberá com portarse tal com o se describe en el
siguiente caso de uso { concreto cuando < evento de
activación> , abstracto durante la realización de los
casos de uso < lista de casos de uso>}
Precondición <precondición del caso de uso>
Secuencia
Norm al
Paso Acción
1 {El < actor> , El sistem a} < acción realizada por el actor
o sistem a>, se realiza el caso de uso
< caso de uso RF-x>
2 Si <condición>, {el < actor> , el sistem a} < acción
realizada por el actor o sistem a>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n
Postcondición <postcondición del caso de uso>
Excepciones Paso Acción
1 Si <condición de excepción>,{el < actor> , el
sistem a} }< acción realizada por el actor o
sistem a>>, se realiza el caso de uso
< caso de uso RF-x>, a continuación este caso de
uso {continua, aborta}
2
3

10. Rendim iento Paso Cota de tiem po
1 n segundos
2 n segundos
Frecuencia esperada <nº de veces> veces / < unidad de tiem po>
Im portancia {sin im portancia, im portante, vital}
Urgencia {puede esperar, hay presión, inm ediatam ente}
Com entarios <com entarios adicionales>
10. Mencionar y explicar con sus propias palabras las
Herramientas de Gestión de Requisitos
Existen herramientas que han sido desarrolladas específicamente para utilizarlas
en las técnicas de gestión de requisitos y dominar cualquier tarea asociada con los
requisitos.
El uso de este tipo de herramientas permite mejorar la calidad del desarrollo de un
proyecto, automatizar procesos de la Ingeniería de Requisitos, proporcionar un
mayor control en el mantenimiento de los requisitos y añadir un beneficio
significativo reduciendo posibles errores durante el desarrollo de un proyecto, lo
que implica en una reducción de costes.
Las herramientas de Gestión de Requisitos se caracterizan por tener las
siguientes propiedades:
 Gestión de requisitos y atributos basados en los modelos de información
 Organización de requisitos
 Configuración y gestión de versión en los requisitos
 Definición de línea base de los requisitos
 Acceso y gestión multiusuario
 Gestión de la trazabilidad
 Consolidación de los requisitos obtenidos
 Gestión de cambios
 Análisis de impacto

11. En general, las herramientas de gestión de requisitos tienen una interfaz de usuario que puede
ser utilizada para acceder a todas las funciones necesarias para llevar a cabo las diversas
tareas de la gestión de requisitos, almacenando los datos gestionados en una base de datos,
permitiendo su visualización y edición por medio de un editor integrado.
Se muestra una breve lista de herramientas de gestión de requisitos que pueden ser de ayuda
para documentar, analizar, rastrear, priorizar y trazar los requisitos.
Bibliografía,
https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos
http://lsi.ugr.es/~mvega/docis/requeintro.pdf
http://www.ie.inf.uc3m.es/grupo/docencia/reglada/psi/unidad6-DOC.pdf
https://es.wikiversity.org/wiki/Ingenier%C3%ADa_de_requisitos_software
http://www-306.ibm.com/software/rational/oifferings/reqanalysis.html
[http://brainstorming.co.uk/tutorials/brainstormingprinciples.html
http://www.brainstorming.co.uk/tutorials/preparingforbrainstorming.html
http://www.overti.es/tecnologia/296-herramientas-de-gestion-de-requisitos