UNIVERSIDAD DE CARTAGENA

TRABAJO COLABORATIVO CONTEXTUALIZADO

ESTUDIANTES
Elías Miguel Martínez Márquez
Juan Esteban Ramos
Diego Arias

CARRERA
Ingeniería De Software

MATERIA
Ingeniería De Requerimientos

DOCENTE
Juan Carlos Cuesta

EL CARMEN DE BOLIVAR
 INTRODUCCIÓN
En este trabajo hablamos sobre los requerimientos, y todo lo que se relacionan a ellos, sus
metodologías y demás. Los requisitos son la especificación de lo que debe hacer el
software, son descripciones del comportamiento, propiedades y restricciones del software
que hay que desarrollar. Un requisito del software es una característica que debe exhibir
para solucionar cierto problema del mundo real.

En este encontramos lo que es la metodología XP, Esta metodología se basa en la idea de

que existen cuatro variables que guían el desarrollo de sistemas: Costo, Tiempo, Calidad y
Alcance. La manera de encarar los desarrollos avalados por este modelo de desarrollo es
permitir a las fuerzas externas (gerencia, clientes) manejar hasta tres de estas variables,
quedando el control de la restante en manos del equipo de desarrollo.
 OBJETIVO
 Dar a conocer la importancia que tienen los requerimientos
funcionales y no funcionales, donde cada uno tiene una modalidad
interesante e importancia.

 Reconocer las ventajas y desventajas de los requisitos, donde las

nuevas herramientas tecnológicas cambian al mundo y hay que
acoplarse a ellas al nuevo camino y aprender cada uso de los
requerimientos.

 Conocer el Caso American AIRLINE.

 TRABAJO COLABORATIVO CONTEXTUALIZADO
INGENIERÍA DE REQUERIMIENTOS

Algunas consideraciones: ciertos ejercicios que se plantean a continuación requieren la

elaboración por parte del alumno. En teoría se brinda el conocimiento base necesario el cual
ampliado desde Internet o generando discusiones entre los compañeros de CIPA, permitirá llegar a
la resolución de cada problema.

1. En cada uno de los siguientes casos determine las ventajas y/o desventajas que puede traer una
metodología JAD para la toma inicial de requerimientos

a) Desarrollo de un software de gestión que por su contenido para su grupo de trabajo resulta
novedoso.

R/ta: Ventajas:
 Generar mayor eficiencia.
 Estimula la moral de los empleados.
 Ofrece reconocimiento internacional.
 Mejora la gestión de procesos.
 Ofrece niveles más altos de satisfacción del cliente

Desventajas:
 Mayor costo de implantación, en relación con un solo sistema particular de gestión.
 Mayor esfuerzo en materia de formación, de organización y de cambio de la cultura
empresarial.
 Déficit de personal capacitado para la realización de auditorías de los sistemas de
gestión existentes.

b) Desarrollo de un software de gestión clásico (facturación por ej.) teniendo en cuenta que su
grupo de trabajo desarrolló varios problemas parecidos.

R/ta: Ventajas

 Serie de factura correlativa y automática: que le permite olvidarse de cuál era el último
número de factura que emitió.
 Localización y búsqueda: tendrá todas sus facturas en un mismo lugar y fáciles de localizar
con criterios de búsqueda que ofrece los programas de facturación.
 Automatización de tareas: los programas de facturación ofrecen funcionalidades para
enviar correos automáticamente a varios clientes, generar facturas periódicas, etc. Que le
ahorrarán mucho tiempo a la hora de gestionar la facturación.
 Control de cobros y pagos: podrá saber las fechas de vencimiento de sus cobros, controlar
los impagados, previsión de sus pagos etc.

Desventajas:
  Debe existir compatibilidad entre los formatos de la empresa emisora y la destinataria.
 Puede provocar retrasos si los trabajadores no conocen el sistema.
 Robos, si la facturación se ve afectada por caso de robo y no se realizaron los debidos
respaldos de la información, entonces una vez más hay pérdida de contenido.

c) Desarrollo de un software de control automático, donde UD es parte del equipo de desarrollo,

pero su experiencia más amplia fue en el área de gestión.

R/ta: Ventajas:

 Favorece que los sistemas trabajen sin interrupciones, satisfaciendo la demanda de los
departamentos de TI y de los sistemas informáticos.
 Mayor eficiencia operativa.
 Puntualidad en la entrega de flujos de trabajo.
 Mayor control sobre todos los procesos de TI.
 Aumento de la productividad de la empresa.

Desventajas:

 Pérdida en la flexibilidad.
 Modificar los flujos de trabajo de las tareas y procesos puede implicar cierta rigidez. Esto
se minimiza con un proceso previo de consultoría y planificación. El mismo, debe
ofrecértelo el proveedor de la solución.

2. Los desarrolladores trabajan con los clientes y los usuarios para definir los requerimientos y
especificar lo que el sistema propuesto debe hacer. Si una vez construido, el sistema trabaja de
acuerdo con su especificación, pero perjudica a alguien física o financieramente, ¿quién es el
responsable?

R/ta:  El desarrollador, por tanto, adquiriría responsabilidades sobre los posibles fallos que un mal
funcionamiento de su producto pudiese provocar.

3. ¿Qué diferencia existe entre requerimientos funcionales y no funcionales? Mediante un ejemplo

presente los requerimientos de estas dos clases.

R/ta: Los requisitos funcionales son aquellos que están relacionados con la funcionalidad técnica
del sistema. el requisito no funcional es un requisito que especifica criterios que pueden utilizarse
para juzgar el funcionamiento de un sistema en condiciones particulares, en lugar de
comportamientos específicos.

El requisito funcional es describir el comportamiento del sistema en relación con la funcionalidad

del sistema. El requisito no funcional elabora una característica de rendimiento del sistema.
Un ejemplo claro sería Los requisitos funcionales es lo que se supone que debe lograr un sistema.
Puede ser Cálculos Detalles técnicos Manipulación de datos Procesamiento de datos Otra
funcionalidad específica

Creo que el requisito funcional es del lado del cliente al desarrollador que se refiere a la
funcionalidad para el usuario por parte del software y el requisito no funcional es del
desarrollador al cliente, es decir, el cliente no proporciona el requisito, pero el desarrollador
lo proporciona para que el sistema funcione sin problemas, por ejemplo, seguridad,
flexibilidad, escalabilidad, disponibilidad, etc.

Un ejemplo de un requisito funcional sería: Un sistema debe enviar un correo electrónico

cada vez que se cumpla una determinada condición (por ejemplo, se realiza un pedido, un
cliente se registra, etc.).

4. “Me junto con el cliente un par de veces, y si él me deja charlo con los usuarios unos minutos y
con eso tengo una idea clara de lo que tengo que hacer”. ¿Puede lo anterior considerarse un mito?
¿Se aplica normalmente esa forma de pensar? Tiene algo que ver con lo que se plantea como
TOMA DE REQUERIMIENTOS.

R/ta: No se aplica normalmente en la toma de requerimientos, la toma de requerimientos es entre

el cliente y el prodcut owner y no se tendría que ir donde el usuario para ver qué hacer y que no,
también es parte del cliente (del que quiere el equipo, producto) que quiere hacer y qué no.

5. Los aspectos relacionados con los requerimientos puede considerarse como: ambiente físico,
interfaces, usuarios y factores humanos, funcionalidad, documentación, recursos, datos, seguridad
y aseguramiento de calidad. A continuación, se plantean una serie de preguntas, donde sus
respuestas determinarán requerimientos. Para cada pregunta indicar a que aspecto de la lista
anterior se acerca más:

a) ¿debe controlarse el acceso al sistema o la información? - Seguridad

b) ¿Cuál será el formato de los datos tanto para la entrada como para la salida? - Recursos
c) ¿Cómo debe demostrarse las características del sistema a terceros? – Aseguramiento de la
calidad
d) ¿Existe un tiempo máximo permitido para la recuperación del sistema después del fallo? –
Aseguramiento de la calidad
e) ¿qué habilidades deben tener los desarrolladores? - Recursos
f) ¿con que frecuencia deben hacerse los Backup? – Aseguramiento de la calidad
g) ¿a qué audiencia está orientado cada tipo de información que genera el sistema? -
Documentación
h) ¿hay que entregar manual de usuario en papel necesariamente o alcanza con un hipertexto? –
Recursos
i) ¿Qué hará el sistema? - Funcionalidades
j) ¿Quién usará el sistema? – Usuarios y factores humanos
k) ¿Dónde está el equipamiento que necesita el sistema para funcionar? – Ambiente físico.
l) ¿la entrada proviene de uno o más sistemas? - Interfaz
m) ¿Cuán difícil le resultará a un usuario hacer un uso indebido del sistema? - Funcionalidades
n) ¿Cómo y cuándo puede cambiarse o mejorarse un sistema? - Funcionalidades
o) ¿Existen uno o varios emplazamientos físicos del sistema? - Funcionalidades
p) ¿Existe algún límite sobre la cantidad de dinero a gastar en el desarrollo o en hardware y
software? - Funcionalidades
q) ¿Deben tomarse precauciones contra el fuego, el daño provocado por agua o robo? - Seguridad

6. Determinar para un proyecto cualquiera cuales pueden ser las fuentes de información para
generar los requerimientos. Esto es, desde donde puede provenir la información útil para definir el
alcance del problema y todos los datos de interés.

R/ta: Desarrollar y comercializar una aplicación para móviles, una de las fuentes son las entrevistas
que se realizan con los clientes respecto a lo que quieres o desean, la necesidad que tenga dicho
cliente,

7. ¿Qué ventajas presentan las técnicas formales para la toma de requerimientos? Ejemplifique su
uso.

R/ta:

 Permite mantener una estructura en las necesidades del proyecto.

 Disminuyes costos y retrasos.
 Mejora la calidad del software.
 Mejora la comunicación.
 Evita rechazos de usuarios finales.

8. De un ejemplo concreto donde la utilización de técnicas tecnológicas sea fundamental para la

evaluación de requerimientos. Justifique.

R/ta: Estás técnicas tecnológicas se implantan para el mejor uso de los requerimientos y se pueden
implementar con el fin de aprender y evolucionar estás podemos. usarlas con las siguientes
herramientas las cueles son muy usadas:

 Plataformas Gratuitas
 Plataformas De Intercambio De Información.
 Cuestionarios

9. En el ejercicio 6 UD propuso un proyecto y sus fuentes de información para generar los

requerimientos. Una vez definidos los mismos sugiera un modelo breve para ellos.

R/ta: Es un modelo ágil, tiene la capacidad de modificar las tareas cuando se encuentran en
marcha con el objetivo de ir ajustando el producto lo más posible a la exigencia del cliente.

10. ¿Cuáles son las motivaciones fundamentales que llevan a modelar los requerimientos? ¿El DFD
es un modelo de requerimientos? ¿Por qué?
R/ta: Los requerimientos especifican qué es lo que el sistema debe hacer (o sea sus funciones) y
sus propiedades por ese motivo es requerible que se modelen, además con dicho modelaje
obtiene o pueden evitar errores que puedan causar dichos requerimientos, en caso que no
funcionen o no se lleven a cabo bien.

El DFD no es un requerimiento, el DFD son un diagrama que usan los analistas para tratar de
comprender los requerimientos de información de los usuarios de una manera gráfica.

11. ¿Cuáles son los inconvenientes que se presentarían en un sistema de gestión para llevar su
modelado en un lenguaje formal?

R/ta: No es un método o una metodología, es una notación, también UML no determina un

proceso definido (no se comporta como una receta de cocina) los procesos son racionales y
dinámicos.
 CONCLUSIÓN
Es muy importante tener en claro los requerimientos al momento de construir o trabajar
en un producto de un cliente, lo requerimientos son la base de funcionalidad del equipo,
no sólo del equipo, porque en ellos esta lo que dicho cliente desea, o quiere, si no se hace
un buen manejo de estos no podría funcionar como el cliente desea, o sino podría causar
daños si no tienen una prevención.
También hay que tener en cuenta que metodología se usará, conocemos muchas
metodologías y siempre hay una eficiente que pueda darnos la posibilidad de trabajar muy
bien.