FUNDACIÓN UNIVERSITARIA RÉMINGTON

CENTRO DE ATENCIÓN YOPAL

INGENIERÍA DE SISTEMAS

TAREA: REQUERIMIENTOS-TUTORIA 15 MARZO

TRABAJO PRESENTADO COMO REQUERIMIENTO A LA ACTIVIDAD DE LA

TUTORÍA DEL 17 DE MARZO DE LA ASIGNATURA ARQUITECTURA DE
SOFTWARE.

PRESENTA:
JOHN FREDY BONILLA ZAMORA
CARLOS ARNULFO COGUA LA VERDE
LINA ROZO DUITAMA

TUTORA:
MARGARETH CASTAÑEDA MORENO
PROFESIONAL EN INGENIERÍA DE SISTEMAS

Marzo de 2020
Tabla de Contenido

1. FUNCIONES DE LA INGENIERÍA DE REQUERIMIENTOS. PRESSMAN (2005)..........................1

1.1 Inicio...................................................................................................................................1
1.2 Obtención..........................................................................................................................1
1.3 Elaboración........................................................................................................................1
1.5 Negociación........................................................................................................................2
1.6 Especificación.....................................................................................................................2
1.7 Validación..........................................................................................................................2
2. ESQUEMA DE CLASIFICACIÓN DE REQUISITOS......................................................................3
3. REQUISITOS FUNCIONALES Y NO FUNCIONALES..................................................................4
5. REFERENCIAS BIOGRÁFICAS..................................................................................................4
 1. FUNCIONES DE LA INGENIERÍA DE REQUERIMIENTOS. PRESSMAN
(2005)

1.1 Inicio

Esta etapa da inicio cuando se identifica una necesidad de negocios o se descubre un

nuevo mercado o servicio potencial. Durante esta etapa los ingenieros de software hacen
una serie de preguntas libres de contexto para conocer las necesidades del cliente.

1.2 Obtención

Durante esta etapa se obtienen los requisitos de manera más profunda, incluso se
pueden hacer modificaciones a los requerimientos planteados durante la etapa de inicio. En
esta etapa se llevan a cabo las entrevistas o todo lo relacionado con la comunicación con el
cliente, puesto que encontramos momentos de incertidumbre como; los usuarios no tienen
contextualizado el tema técnico o manejo de herramientas tecnológicas y la persona que
expone la solución del sistema lo explica de manera muy técnica que el usuario no lo
alcanza a percibir por lo que se recomienda tener un lenguaje claro o comunicación
asertiva.

1.3 Elaboración.

Se hace un modelado del sistema mediante diagramas de estado o funcionamiento

pues es una presentación de negocio se requiere que el cliente sepa cuál es el

Página 1|6
funcionamiento y sobre todo establecer un coste del producto a desarrollar, de esto pueden
salir mas requerimientos por que el cliente esta mas contextualizado del sistema de
información.

1.5 Negociación

Esta etapa puede estar compuesta por acuerdos con desarrolladores y clientes, donde
se realizan un cronograma de entrega de actividades, verificar que actividades se pueden
cumplir y cuales no, de la misma manera se puede llegar a un acuerdo de pago por
actividad o como se llegue a conciliar.

1.6 Especificación.

Se describe de manera sucinta la especificación del diseño del sistema que el

usuario como el desarrollador lo entiendan, básicamente un prototipo de funcionamiento
que muestre el Cord de sistema de información.

1.7 Validación

Es la prueba de calidad, la revisión final del producto que se va a lanzar al mercado

o a entregar a un cliente que se cumplan los requisitos de la demanda, donde se espera la
aceptación por parte del usuario o la demanda del producto, toda vez que se le incluyan
excelentes atributos para lograr la calidad total y que esté terminado el producto.

Página 2|6
 2. ESQUEMA DE CLASIFICACIÓN DE REQUISITOS.
Esquema de clasificación de
requisitos
Requisito de las partes
Requisitos de negocio
interesadas
Se identifican las
Son las necesidades que
necesidades de la empresa,
tienen ciertas partes
los objetivos y metas,
interesadas y que dicha
también los indicadores de
solución creara una conexión
desempeño para realizar el
entre ellas para analizar
seguimiento del proyecto.
profundamente los
requerimientos específicos.
Requisitos no
funcionales
Describe restricciones
sobre los requisitos
funcionales
Requisitos de la transición
Requisitos de la solución
Las capacidades que debe
Propone una solución que
tener la solución para
sirva para los requerimientos
facilitar la transición desde
del negocio y los de las partes
el estado actual de la
interesadas, los dividen en
empresa a un estado futuro
requisitos funcionales y no
deseado
funcionales. En específico
cuando los requisitos son para
hallar una solución de
desarrollo del software.
Requisitos funcionales
Describe los comportamientos del
sistema para interactuar con las
acciones del usuario, esta
directamente relacionado con la
interfaz grafica
Página 3|6
 3. REQUISITOS FUNCIONALES Y NO FUNCIONALES.

Unos de los requisitos funcionales que un sistema de una biblioteca debería tener es:

1. Que tenga un logan de inicio.

2. Que el sistema reciba pagos con tarjeta para los alquileres de los libros.
3. Que el sistema permita ingresar nuevos autores de libros.
4. Que se permita realizar búsquedas por ID de cada libro.

Unos de los requisitos no funcionales que un sistema de una biblioteca debería tener es:

1. Gestión de la seguridad de la aplicación mediante un logis de inicio, y la definición

de un rol para cada funcionario por niveles de clasificación implementados en el
Sistema de Gestión de Seguridad de la Información.
2. Que reciba los pagos con tarje, pero PSE, que genere un toquen con un tiempo de
espera de 10 segundos.
3. Que el sistema valide la editorial de autores.
4. Se permita realizar la clasificación del libro por autor.

5. REFERENCIAS BIOGRÁFICAS

 Manual autoformativo interactivo, análisis y requerimientos de software.

Universidad Continental.

Página 4|6