ACTIVIDAD EVALUATIVA EJE 2

Especificación de Requerimientos de Software

Ana Carolina Cabrera Blandón

José Gildardo Gutiérrez
Juan David Castrillón Gómez

PRESENTADO A
ANGEL ALBERTO VARON QUIMBAYO

MATERIA

INGENIERÍA DE SOFTWARE I

Fundación Universitaria del Área Andina

Facultad de Ingenierías y Ciencias Básicas

Ingeniería de sistemas - Virtual

Bogotá, Colombia

2020
 CONTENIDO

OBJETIVOS 3
OBJETIVO GENERAL 3
OBJETIVOS ESPECÍFICOS 3
DESARROLLO DE LA ACTIVIDAD 4
1. INTRODUCCIÓN 5
1.1. PROPÓSITO 5
1.2. ÁMBITO DEL SISTEMA 5
1.3. REFERENCIAS 6
2. DESCRIPCIÓN GENERAL 6
2.1. PERSPECTIVA DEL PRODUCTO 6
2.2. CARACTERÍSTICAS DE LOS USUARIOS 6
3. REQUERIMIENTOS ESPECÍFICOS 7
3.1. FUNCIONES 7
3.1.1. GESTIÓN DE ESTUDIANTE 7
3.1.1.1. Gestión de Aspirante 8
3.1.1.1.1. Crear Usuario 9
3.1.1.1.2. Modificar Usuario 10
3.1.1.1.3. Verificar Requisitos 10
3.1.1.2. Matricula Estudiante 12
3.1.1.3. Generar horario 13
3.1.2. GESTIÓN DE FACULTADES. 14
3.1.4. GESTIÓN HORARIO DEL PROFESOR 17
CONCLUSIÓN 22
LISTA DE REFERENCIAS 23

2
 OBJETIVOS

OBJETIVO GENERAL

Realizar la especificación de requerimientos funcionales y no funcionales de un software

utilizando los parámetros establecidos en el eje 2, de la asignatura Ingeniería de software I.

OBJETIVOS ESPECÍFICOS

✔ Describir detalladamente los requerimientos de un software que facilite los procesos de

admisión, registro, selección de horario y consulta del mismo en una institución de
educación superior.
✔ Identificar los requerimientos funcionales y no funciones en cada una de las etapas de
utilización del software.

3
 DESARROLLO DE LA ACTIVIDAD

Señores estudiantes por ser de los mejores de esta asignatura, han sido seleccionado por una
empresa de desarrollo de software, con el objetivo de que analicen la situación, consideren
los aspectos que se mencionan, propongan la solución más adecuada para este problema, en
la parte inferior encontrarán un formato para generar la propuesta:

En el proceso de registro académico de una institución de educación superior, existe pérdida

de información, debido a que se tiene una aplicación que fue desarrollada por los estudiantes
y no se tiene la documentación necesaria que permita realizar un proceso que permita corregir
los errores, replantear procedimientos de ingeniería para mejorarla o en su efecto actualizarla.

Por tal motivo los directivos tomaron la decisión de crear un software nuevo conlleve a
solucionar parte de los inconvenientes que se presentan, a continuación, mencionamos
algunos de los aspectos que debe cumplir:

El ciudadano al momento de matricularse debe cumplir con los siguientes aspectos:

o Haber terminado el bachillerato
o Aprobar examen de admisión
o Prueba de estado debe ser superior a 240 puntos
o Cancelar el valor de la matrícula

Hay que tener en cuenta que el estudiante y el docente pertenecen a un programa y el

programa a una facultad.
Cada programa se divide en tres niveles, nivel técnico, tecnológico y profesional.
Cuando se emite el horario de un estudiante, este debe tener identificación del estudiante,
nombre del estudiante, código de la asignatura, nombre de la asignatura, aula de clase, sede
hora de inicio y hora de finalización, día en que se imparte la clase y número de créditos.
Cuando se emite el horario del docente este debe tener identificación del docente, nombre del
docente, código de la asignatura, nombre de la asignatura, aula de clase, sede, hora de inicio y
hora de finalización, día en que se imparte la clase y número de créditos, cada crédito
equivale a una hora académica presencial es decir 45 minutos.
Las notas del estudiante se dividen de la siguiente forma:
corte 1 vale el 25%
corte 2 valor 30 %
corte 3 equivale al 45%
La institución cuenta con 12 programas aprobados y cuenta con 8 sede y 4 decanaturas.

DESARROLLO:

A continuación, se propone las Especificaciones de Requerimientos del Software solicitado.

4
 Proceso SAYRE
Actividades SAYRE
SAYRE Tarea SAYRE

Producto Especificación de Requerimientos de Software Versión 1.0

Emitido por Ana Carolina Cabrera Blandón Estado: En Fecha: 08/03/2020

José Gildardo Gutiérrez construcción
Juan David Castrillón Gómez

1. INTRODUCCIÓN

Este es un documento de Especificación de Requerimientos de Software sirve para el

desarrollo del sistema software SAYRE (Sistema de Admisiones y Registro) que brinda el
servicio de gestión de matrículas, horarios y asignación de grupos para estudiantes y
profesores de la institución educativa ANDINA, cuyas características se detallan a
continuación.

1.1. PROPÓSITO

El propósito de este documento de Especificación de Requerimientos de Software (ERS), es

presentar las funcionalidades realizables para el software SAYRE aplicable a la institución
educativa ANDINA. El sistema permitirá matricular estudiantes que cumplan con requisitos
básicos exigidos por la institución, así mismo, facilitará la creación de módulos para gestión
de facultades, programas, materias, docentes y horarios.

El sistema no contará entre sus funciones, con la capacidad de recibir pagos, generar
certificados, realizar procesos de homologación entre otros que no estén contemplados en los
propósitos iniciales a continuación plasmados.

1.2. ÁMBITO DEL SISTEMA

El sistema se desarrolla en un ambiente web, siendo así, desarrollado en lenguaje de

programación PHP, complementos en JavaScript y haciendo uso del motor de base datos
MySQL. Se plantea inicialmente que la herramienta SAYRE, estará alojada en los servidores
propios de la empresa contratante (ANDINA).

5
 ERS Documento de especificación de
Requerimientos del software

BD Bases de datos

HTTPS Protocolo de Transferencia de Hipertexto

Seguro

HTML5 Lenguaje de marcado de Hipertexto que se

utiliza para el desarrollo de páginas web.
Versión 5

MySQL Sistema de gestión de base de datos, de

código abierto y relacional.

SAYRE Sistema de admisión y registro (Nombre del

software.)

Tabla. (Definición de acrónimos y abreviaturas).

1.3. REFERENCIAS
# TÍTULO NÚMERO FECHA

IEEE Guide for Software Requirements Specification IEEE Std 830-84 1994

OMG Unified Modeling Language Specification Versión 1.4 Formal 2001-09-67 2001

2. DESCRIPCIÓN GENERAL
El sistema SAYRE, tiene entre sus requerimientos, La gestión de usuarios, facultades,
programas y sedes. De la misma manera, el sistema permite asignar horarios para docentes y
alumnos. Sus requerimientos se detallan en este documento.

2.1. PERSPECTIVA DEL PRODUCTO

El software sirve para poder realizar el proceso de registro, admisión, matrícula de aspirantes
y el registro de horarios de estudiantes de la institución educativa ANDINA. Adicionalmente
permite visualizar la estructura académica de la institución, en el cual se identifican las
facultades, programas académicos, la planta docente, la infraestructura de aulas de clase,
programación académica, entre otros.
Permite al profesor de cualquier programa consulta de horario de clases.

2.2. CARACTERÍSTICAS DE LOS USUARIOS

Los usuarios de este software, no serán expertos en informática, aunque deben tener
conocimiento en aplicaciones ofimáticas e internet.

6
3. REQUERIMIENTOS ESPECÍFICOS
Esta subsección describe los requisitos (funcionales y no funcionales) del sistema software SAYRE.

3.1. FUNCIONES

El software SAYRE incluye las siguientes funciones:

Incluye la gestión de estudiantes, registro de horario para estudiantes y consulta de horario

del profesor de la institución educativa ANDINA, donde arrojará los resultados de las
respuestas de cada instrumento diligenciado:

Figura 1. Diagrama de descomposición de requerimientos del software SAYRE

Cada requerimiento funcional contendrá la siguiente información:

✔ Introducción
✔ Entradas de datos
✔ Procesos
✔ Salidas
✔ Requerimientos específicos no Funcionales

3.1.1. GESTIÓN DE ESTUDIANTE

La institución educativa ANDINA quiere tener información de los estudiantes que después de
hacer el registro como aspirantes al programa de su preferencia, cumplan los requisitos para
inscribirse a dicho programa y puedan culminar su proceso de admisión con la generación del
recibo de matrícula. Para posteriormente hacer su registro de horario.

7
 Figura 2 Diagrama de descomposición de Requerimientos Gestión de Estudiante

3.1.1.1. Gestión de Aspirante

Este requerimiento lo que permite es al aspirante hacer un registro de sus datos personales,
modificarlos si es el caso y posteriormente al usuario con perfil de administrador le permitirá
verificar la verificación de requisitos para que el aspirante cambie de estado a “estudiante”.

Su estructura es la siguiente:

Figura 3 Diagrama de descomposición de Requerimientos Gestión de Aspirante

8
 3.1.1.1.1. Crear Usuario

Introducción:
Función que consiste en crear un nuevo usuario (Aspirante al programa) en la Base de datos
del sistema SAYRE, para ello se deben ingresar los datos del nuevo registro y se almacenarán
en la Base de Datos.

Entrada de datos:

o Tipo de documento
o Número de documento
o Nombre
o Apellidos
o Programa Académico
o Género
o Dirección
o Ciudad
o Departamento
o Teléfono residencia
o Teléfono móvil
o Email
o Nacionalidad
o Acepto el tratamiento de datos

Proceso: una vez el usuario haya accedido a esta utilidad del software se introducen todos
los datos del usuario, es necesario que el usuario acepte los términos y condiciones para el
uso de la información personal, y se emitirá un mensaje de guardado en la Base de datos

Salida: creación del registro en la BD actualización de datos.

Requisitos Específicos No Funcionales:

▪ De Bases de datos el registro de los datos en la Bases de datos se realizará en un

máximo de 2 segundos.
▪ Los datos deben conservar la integridad de la BD.
▪ El sistema debe contar una interfaz que ofrezca botones, listas, ventanas que sea
amigable y fácil de entender al usuario.
▪ Toda la jerarquía de manejo de información debe ser administrada por el
Administrador de DB.
▪ El sistema debe ser diseñado en lenguaje HTML5, que sea compatible con los
diferentes navegadores disponibles en la red.

9
 3.1.1.1.2. Modificar Usuario

Introducción:
Función que consiste permitir al usuario actualizar un registro en la base de datos del sistema
SAYRE, para ello se deben ingresar los datos del registro a actualizar y este se almacenarán
en la Base de datos.

Entrada de datos:

o Dirección
o Ciudad
o Departamento
o Teléfono residencia
o Teléfono móvil
o Email
o Nivel de estudio
o Acepto el tratamiento de datos

Proceso: una vez el usuario haya accedido a esta utilidad del software se introducen todos
los datos del usuario que desea actualizar. Igualmente, es necesario que el usuario acepte los
términos y condiciones para el uso de la información personal, y se emitirá un mensaje de
guardado en la Base de datos

Salida: actualización del registro en la BD actualización de datos

Requisitos Específicos No Funcionales:

▪ De Bases de datos el registro de los datos en la Bases de datos se realizará en un

máximo de 2 segundos.
▪ Los datos deben conservar la integridad de la BD.
▪ El sistema debe contar una interfaz que ofrezca botones, listas, ventanas que sea
amigable y fácil de entender al usuario.
▪ Toda la jerarquía de manejo de información debe ser administrada por el
Administrador de DB.
▪ El sistema debe ser diseñado en lenguaje HTML5, que sea compatible con los
diferentes navegadores disponibles en la red.

10
 3.1.1.1.3. Verificar Requisitos

Introducción:
Función que consiste permitir al que tiene el perfil de administrador verificar si el aspirante
cumple con los requisitos de admisión, para ello se especifica este requerimiento en el
siguiente diagrama de descomposición de requerimientos Verificar Registro:

Figura 4 Diagrama de descomposición de Requerimientos Verificación Requisitos

RADICAR DOCUMENTOS

Entrada de datos:

o Chequeo de entrega de diploma culminación de estudios de bachillerato

o Chequeo entrega resultado pruebas de estado saber 11, con puntaje superior a 240 puntos
o Chequeo entrega de certificado de notas y contenidos programáticos, si el aspirante
ingresa a la institución por proceso de homologación.

Proceso: una vez el que tiene perfil de administrador haya accedido a esta utilidad del
software se introducen los correspondientes chequeos de documentos, se emitirá un mensaje
en el cual se programará una cita para la presentación de admisión.

Salida: citación al aspirante para presentar el examen de admisión, lo cual quedará registrado
en la BD del sistema.

APROBACIÓN EXAMEN DE ADMISIÓN

Entrada de datos:

o Puntaje obtenido por el aspirante

o Generación del código estudiantil siempre y cuando cumpla con el puntaje mínimo
estipulado para cada programa de las diferentes facultades.

11
Proceso: una vez el que tiene perfil de administrador haya accedido a esta utilidad del
software se introduce el puntaje de la prueba y si cumple con el puntaje requerido por el
programa al que aspira, se genera el código estudiantil y se puede proceder a generar el
recibo de pago de la matrícula.

Salida: generación del recibo de pago de matrícula, lo cual quedará registrado en la BD del
sistema.

Requisitos Específicos No Funcionales:

▪ De Bases de datos el registro de los datos en la Bases de datos se realizará en un

máximo de 2 segundos.
▪ Los datos deben conservar la integridad de la BD.
▪ El sistema debe contar una interfaz que ofrezca botones, listas, ventanas que sea
amigable y fácil de entender al usuario.
▪ Toda la jerarquía de manejo de información debe ser administrada por el
Administrador de DB.
▪ El sistema debe ser diseñado en lenguaje HTML5, que sea compatible con los
diferentes navegadores disponibles en la red.
▪ Los documentos como el diploma de bachiller y los resultados de las pruebas de
estado deben ser remitidos vía correo electrónico o radicados en la oficina de
admisiones.
▪ El resultado del examen de admisión debe ser remitido por la coordinación académica
de cada facultad.

3.1.1.2. Matricula Estudiante

Introducción:
Función que consiste permitir al estudiante a descargar su recibo de pago de matrícula y
cuyo pago se vea registro en la base de datos del sistema SAYRE, para ello se deben
conexión con el sistema de registro financiero de la institución para corroborar el pago
realizado por parte del estudiante. Toda esta información quedará almacenada en la Base de
datos.

Entrada de datos:

o Número de documento

Proceso: una vez el estudiante haya recibido la notificación de que ha cumplido con los
documentos reglamentarios y con el puntaje requerido para aprobar el examen de admisión,
podrá descargar el recibo de pago de derechos de matrícula.

12
 Salida: el recibo de pago de matrícula con las fechas de corte.

Requisitos Específicos No Funcionales:

▪ De Bases de datos el registro de los datos en la Bases de datos se realizará en un

máximo de 2 segundos.
▪ Los datos deben conservar la integridad de la BD.
▪ El sistema debe contar una interfaz que ofrezca botones, listas, ventanas que sea
amigable y fácil de entender al usuario.
▪ Toda la jerarquía de manejo de información debe ser administrada por el
Administrador de DB.
▪ El sistema debe ser diseñado en lenguaje HTML5, que sea compatible con los
diferentes navegadores disponibles en la red.

3.1.1.3. Generar horario

Introducción:
Función que consiste permitir al estudiante acceder a su horario el cual ha sido registrado y
concertado bajo el acompañamiento de profesores del programa.

Entrada de datos:

o Código estudiantil
o Código asignatura
o Nombre asignatura
o Aula
o Hora inicio
o Hora fin
o Dia
o Créditos

Proceso: una vez la institución haya recibido la notificación de que se ha registrado el

pago cumplido con los documentos reglamentarios y con el puntaje requerido para aprobar el
examen de admisión, podrá descargar el recibo de pago de derechos de matrícula.

Salida: el recibo de pago de matrícula con las fechas de corte.

Requisitos Específicos No Funcionales:

13
 ▪ De Bases de datos el registro de los datos en la Bases de datos se realizará en un
máximo de 2 segundos.
▪ Los datos deben conservar la integridad de la BD.
▪ El sistema debe contar una interfaz que ofrezca botones, listas, ventanas que sea
amigable y fácil de entender al usuario.
▪ Toda la jerarquía de manejo de información debe ser administrada por el
Administrador de DB.
▪ El sistema debe ser diseñado en lenguaje HTML5, que sea compatible con los
diferentes navegadores disponibles en la red.

3.1.2. GESTIÓN DE FACULTADES.

Introducción:

El aplicativo permitirá al perfil de administrador, crear facultades en la base de datos.

Ingresará los datos de la facultad y se realizará el registro de la información. Este módulo
además, permitirá consultar, editar y dar de baja facultades.

Entrada de datos:
● Nombre de la facultad.
● Decano.
● Coordinador.
● Persona de contacto.
● Extensión.
● Correo

14
Proceso:

El administrador del sistema ingresará al módulo de facultades y en la pantalla inicial verá un

listado de facultades creadas, desde allí podrá ver en detalle cada una y editarla o darla de
baja. En la sección crear, ingresará los datos solicitados para la creación de facultades y el
sistema devolverá un mensaje de guardado correcto.

Salida:

El sistema creará, editará, listará o dará de baja una facultad en la base de datos. Alterando en
la base de datos a través del proceso realizado.

Requerimientos específicos no funcionales:

4. El sistema presentará una interfaz de usuario sencilla, que mostrará la información por
medio de tablas.
5. El sistema devolverá alertas según el proceso realizado (Facultad creada, Facultad
editada, Facultad dada de baja).
6. La interfaz de usuario tendrá un mantenimiento mínimo.
7. En la interfaz se deben hacer validaciones mínimas de los datos ingresados.
8. La información consultada será garantizada en su integridad por el sistema.
9. Solo usuarios autorizados podrán manipular la información.
10. El sistema garantizará la protección de los datos suministrados.
11. La consulta para ingresar al módulo no tardará más de 5 segundos.
12. El registro de nuevas facultades en la base de datos, no tardará más de 2 segundos.
13. Ingresar al detalle una facultad, no tardará más de 2 segundos.
14. Editar una facultad, no tardará más de 2 segundos.
15. Dar de baja una facultad, no tardará más de 2 segundos.

3.1.3. GESTIÓN DE PROGRAMAS

15
Introducción:

El aplicativo permitirá al perfil de administrador, crear programas en la base de datos. Los

datos básicos de identificación del programa se recibirán por la interfaz gráfica y se agregaran
a la base, así mismo, se editará, consultará y eliminarán programas.

Entrada de datos:
● Nombre del programa.
● Coordinador.
● Sede.
● Persona de contacto.
● Extensión.
● Registro ICFES.
● Correo.

Proceso:

El administrador del sistema ingresará al módulo de programas, allí encontrará en la página

inicial una tabla con los programas creados y sus respectivos botones para eliminar y editar.
En la parte de superior de la tabla, estará el respectivo acceso para crear programas nuevos.

Salida:

El sistema creará, editará, listará o dará de baja un programa en la base de datos.

16
Requerimientos específicos no funcionales:

● El sistema presentará una interfaz de usuario sencilla, que mostrará la información por
medio de tablas.
● El sistema devolverá alertas según el proceso realizado. (La interfaz de usuario tendrá
un mantenimiento mínimo.
● En la interfaz se deben hacer validaciones mínimas de los datos ingresados.
● La información consultada será garantizada en su integridad por el sistema.
● Solo usuarios autorizados podrán manipular la información.
● El sistema garantizará la protección de los datos suministrados.
● La consulta para ingresar al módulo no tardará más de 5 segundos.
● El registro de nuevos programas en la base de datos, no tardará más de 2 segundos.
● Ingresar al detalle un programa, no tardará más de 2 segundos.
● Editar un programa, no tardará más de 2 segundos.
● Dar de baja un programa, no tardará más de 2 segundos.

3.1.4. GESTIÓN HORARIO DEL PROFESOR

17
Introducción:

Función que consiste permitir al profesor acceder a su horario el cual ha sido registrado y
concertado con el área de control y registro.

Entrada de datos:

● Código Profesor
● Nombre
● Apellidos
● Correo Institucional

Proceso:

La carga académica será asignada con base en la población de estudiantes registrada en el

sistema como admitido y se dividirá en grupos dependiendo de la cantidad de estudiantes
máximos por aula de clases.

Salida:

Carga académica que genera el Horario para cada profesor.

Requisitos Específicos No Funcionales:

● De Bases de datos el registro de los datos en la Bases de datos se realizará en

un máximo de 2 segundos.

● Los datos deben conservar la integridad de la BD.

● El sistema debe contar una interfaz que ofrezca botones, listas, ventanas que
sea amigable y fácil de entender al usuario.

● Toda la jerarquía de manejo de información debe ser administrada por el

Administrador de DB.

● El sistema debe ser diseñado en lenguaje HTML5, que sea compatible con los
diferentes navegadores disponibles en la red.

● Dos grupos no deben estar asignados al mismo tiempo en la misma aula.

● Dos aulas no deben estar asignadas al mismo tiempo con el mismo grupo.

● Dos grupos con el mismo profesor no pueden ser asignados a la misma hora.

18
 ● Un grupo no puede estar asignado en horas en las cuales no hay disponible un
docente.

● La cantidad de estudiantes no debe exceder al establecido en cada grupo

● El número de horas de un curso no debe exceder al número establecido

previamente en el curso.

● Las horas asignadas a un grupo deben ser consecutivas en el día asignado.

● Las horas consecutivas de grupo deben ser programadas en la misma aula.

● Las horas de laboratorio de un curso deben ser programadas para un

laboratorio.

● Las horas de práctica de un curso deben ser programadas a un aula.

● Se debe respetar los privilegios o recomendaciones de horas para los cursos.

● Dos grupos cuyos cursos son del mismo ciclo no deben ser asignados al
mismo tiempo.

3.1.5. GESTIÓN DE SEDES

Introducción:

19
El aplicativo permitirá al perfil de administrador, crear Sedes en la base de datos. Los datos
básicos de identificación de la sede se recibirán por la interfaz gráfica y se agregaran a la
base, así mismo, se editará, consultará y eliminarán las Sedes.

Entrada de datos:
● Nombre de la Sede.
● Coordinador Sede.
● Ubicación (Ciudad, Dirección)
● Persona de contacto.
● Teléfono
● Extensión.
● Correo

Proceso:

El administrador del sistema ingresará al módulo de Sedes, allí encontrará en la página inicial
una tabla con las Sedes creados y sus respectivos botones para eliminar y editar. En la parte
de superior de la tabla, estará la sede respectivo acceso para crear nuevas sedes.

Salida:

El sistema creará, editará, listará o dará de baja una sede en la base de datos.

Requerimientos específicos no funcionales:

● El sistema presentará una interfaz de usuario sencilla, que mostrará la información por
medio de tablas.
● El sistema devolverá alertas según el proceso realizado. (La interfaz de usuario tendrá
un mantenimiento mínimo.)
● En la interfaz se deben hacer validaciones mínimas de los datos ingresados.
● La información consultada será garantizada en su integridad por el sistema.
● Solo usuarios autorizados podrán manipular la información.
● El sistema garantizará la protección de los datos suministrados.
● La consulta para ingresar al módulo no tardará más de 5 segundos.
● El registro de nuevas sedes en la base de datos, no tardará más de 2 segundos.
● Ingresar al detalle una sede, no tardará más de 2 segundos.
● Editar una sede, no tardará más de 2 segundos.
● Dar de baja una sede, no tardará más de 2 segundos.

20
21
 CONCLUSIÓN

Hacer un mal levantamiento de los Requerimientos desde el inicio va a terminar en un

aumento de costos y de tiempo, e por esto que es de suma importancia la utilización de una
plantilla de requerimientos que integre todos los pasos que se deben seguir para sacar
adelante un tipo de proyecto como lo es la construcción de Requerimientos de Software.

La especificación de los requerimientos de información no es solo la actividad más

importante dentro del proceso de desarrollos de Sistemas, si no la más difícil (Vessey &
Conger 1994).

Tomando como base lo aprendido en el eje, consideramos que debemos ser muy cuidadosos
en el ofrecimiento de servicios de construcción de software, todo el equipo debe estar
comprometido desde el principio para llevar a cabo un buen levantamiento de requerimientos,
planeación y diseño del software para satisfacer las expectativas del cliente.

¿Cómo son los requerimientos aprobados por los usuarios?

Se espera que una especificación de requerimientos que fue aprobada por clientes y/o
usuarios tenga al menos las siguientes características:

● Que contenga todos los requerimientos deseados.

● Que cada requerimiento solo tenga una interpretación posible. Esto apunta a
eliminar ambigüedades.
● Que el cumplimiento de cualquier requerimiento no provoque conflictos con el
cumplimiento de otro requerimiento, es decir, que sea consistente.
● Que se definan prioridades.

22
 LISTA DE REFERENCIAS

✔ Cristiá, M. (2011). Introducción a la Ingeniería de Requerimientos. Universidad Nacional

de Rosario.
✔ Pressman, R. (2001). Ingeniería del software un enfoque práctico. Madrid: Mc-Graw Hill.
✔ Senn, J. (1997). Análisis y diseño de sistemas de información. Madrid: McGraw Hill.
✔ Sommerville, I. (2005). Requerimientos del software. Ingeniería del software, 7a ed., PEARSON
EDUCACIÓN, Madrid, SPA, 109-110.
✔ https://www.siu.edu.ar/la-importancia-de-la-gestion-de-requerimientos

23