Universidad Autónoma de Nuevo León

Facultad de Ingeniería Mecánica y Eléctrica

Taller de Programación Orientada a Objetos

Ing. Antonio Juárez Covarrubias

Actividad 3

Victor Hugo Flores Rangel

1663221 IAS

M5- M6 2-301

Requerimientos de un proyecto
Para tener una buena definición de requerimientos es necesario realizar una buena identificación
de los mismos, posterior a esto es importante definirlos de manera detallada, donde se involucre la
información aportada por los usuarios

Para realizar una correcta definición de los requerimientos del proyecto y que éstos satisfagan las
necesidades verdaderas del cliente, se deben tener en cuenta las siguientes actividades:

 Definición de requerimientos
 Verificación de requerimientos
 Revisión de requerimientos vs especificaciones

Para realizar con éxito la definición de los requerimientos es importante conseguir que los
requerimientos sean claramente definidos para minimizar la ambigüedad de los requerimientos,
para esto es importante tener en cuenta lo siguiente:

 Definir los requerimientos teniendo en cuenta la información identificada con la perspectiva

del usuario

 Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen material

potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un
requisito ha sido especificado satisfactoriamente para un producto y que el producto ha
tenido éxito, el requerimiento no tendrá que volverse a inventar, podrá ser utilizado las
veces que se desee teniendo en cuenta los derechos de autor. 

 Se debe documentar los requerimientos de una forma clara y correcta. En la mayoría de

los proyectos se observa que la documentación de los requerimientos puede parecer una
tarea tediosa, pero es la única manera de asegurar que la esencia de los requisitos ha sido
capturada correctamente, y que esto pueda ser probado.

Clasificación de requerimientos

Requerimientos Funcionales: 

Estos requerimientos se utilizan para determinar que hará el Software, definiendo las relaciones de
su operación y su implementación, sin olvidar que deben ser explícitos también en lo que el
sistema no debe hacer y que validaciones se deben realizar, teniendo en cuenta cual será el
comportamiento del sistema.

Los Requerimientos funcionales se pueden dividir en dos puntos de vista: El primero tiene relación
con el usuario, donde se identifica la relación del usuario con el sistema desde el punto de vista del
mismo; El segundo tiene relación con el sistema dando respuesta al usuario, es decir desde el
punto de vista de lo que realiza el sistema. 

Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con

el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se
tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la
entrega de éste e incrementando el costo. En principio, la especificación de requerimientos
funcionales de un sistema debe estar completa y ser consistente con lo solicitado por el usuario.

Requerimientos no funcionales
Estos requerimientos se basan en las restricciones de los servicios o funciones ofrecidos por el
sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, usabilidad,
portabilidad, entre otros. 

Los Requerimientos funcionales son los requerimientos que no se refieren directamente a las
funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la
fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones
en el presupuesto, a las herramientas utilizadas, a las políticas de la organización, a la necesidad
de interoperabilidad con otros sistemas de software o hardware o a factores externos como los
reglamentos de seguridad, las políticas de privacidad, etcétera.

Los dos tipos de requerimientos especificados son de gran importancia para el desarrollo de una
aplicación en software, por lo tanto siempre deben ser escritos con claridad, contener la mayor
especificación de las necesidades expuestas por el cliente, esto con el fin de tener un soporte base
desde el cual se trabajaran y no presentar ambigüedades en la definición y el resultado del
producto. La figura a continuación muestra los inconvenientes que se pueden presentar cunado no
se hace una identificación correcta de los requerimientos.  

Verificación de Requisitos

Para la verificación de requisitos se deben añadir  criterios de aceptación por cada requisito, una
tarea de la calidad es asegurarse de que cada requisito cumple con los criterios asignados, este
criterio es una medida del requisito que lo hace entendible y con capacidad de ser probado.

Revisión de Requisitos Vs Especificación

Una vez ya identificado los requerimientos, documentados y verificados se procede a realizar la

revisión de los mismos con base a la información recolectada con los usuarios del sistema, en esta
revisión participa los analistas del equipo de trabajo y los usuarios necesarios  para esta revisión
de debe chequear.

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 puede ser difícil de manejar.
 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.

Ingeniería de requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es
llamado ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar
una especificación de requisitos de software correcta y completa. Algunos otros conceptos de
ingeniería de requerimientos son:

“Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en

cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el
impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los
usuarios finales con el software”.
“La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las
especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores
del sistema”.

En síntesis, el proceso de ingeniería de requerimientos se utiliza para definir todas las actividades
involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un
producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la
IR vendrá a ayudar a determinar la viabilidad de llevar a cabo el software (si es factible llevarlo a
cabo o no), pasando posteriormente por un subproceso de obtención y análisis de requerimientos,
su especificación formal, para finalizar con el subproceso de validación donde se verifica que los
requerimientos realmente definen el sistema que quiere el cliente.

Importancia de la ingeniería de requerimientos

Según la autora Lizka Johany Herrera en su documento 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: es sabido que reparar errores por un mal desarrollo
no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante
la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de
las primeras en llevarse a cabo.
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.).

Preparar plan de revisión:

En la preparación del plan de reunión de debe planear quienes deben asistir que se va a hablar y
cuánto tiempo se va a gastar. 

Documentos de requisitos a revisar:

Identificar cuáles son los documentos de especificación de requisitos que se va a revisar.

Preparar reunión:

Se debe confirmar el lugar en el cual realizará la reunión y se deben prepara       los materiales
necesarios para la reunión (lápices, hojas, elementos visuales… etc).

Realizar reunión:

Se revisa el entendimiento de la especificación por parte de los interesados y se valida que lo

especificado si cumple con la necesidad del cliente y con lo solicitado.

Identificar de defectos de la especificación:

Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna especificación
requerida.

Realización de correcciones a los documentos:

Si en la etapa anterior se encuentran defectos en la especificación el analista del sistema debe

realizan las debidas correcciones al documento.

Informar modificaciones a los interesados:

Una vez los defectos en la especificación han sido subsanados, se debe enviar un breve resumen
informando las tareas realizadas para la corrección de los documentos especificados junto con los
documentos corregidos a los participantes en la reunión para dar su aprobación.

Cierre de los requerimientos:

Por último se da por cerrado y entendido la el requerimiento se firma la aprobación por parte de los
interesados y se procede a enviarse un correo con la aprobación del requerimiento.

Diagrama entidad-relación
Un diagrama entidad-relación, también conocido como modelo entidad relación o ERD, es un tipo
de diagrama de flujo que ilustra cómo las "entidades", como personas, objetos o conceptos, se
relacionan entre sí dentro de un sistema.

Los diagramas ER se usan a menudo para diseñar o depurar bases de datos relacionales en los
campos de ingeniería de software, sistemas de información empresarial, educación e investigación.
También conocidos como los ERD o modelos ER, emplean un conjunto definido de símbolos, tales
como rectángulos, diamantes, óvalos y líneas de conexión para representar la interconexión de
entidades, relaciones y sus atributos. Son un reflejo de la estructura gramatical y emplean
entidades como sustantivos y relaciones como verbos.

Los diagramas de ER se relacionan con los diagramas de estructura de datos (DSD), que se
centran en las relaciones de los elementos dentro de las entidades, en lugar de las relaciones entre
las entidades mismas. Los diagramas ER a menudo se combinan con los diagramas de flujo de
datos (DFD), que trazan el flujo de la información para procesos o sistemas.

 Diseño de bases de datos: los diagramas ER se usan para modelar y diseñar bases de

datos relacionales, en términos de reglas de negocio y lógicas (en un modelo de datos
lógicos) y en términos de la tecnología específica que se implementará (en un modelo de
datos físicos). En ingeniería de software, un diagrama ER a menudo es un primer paso
para determinar los requisitos de un proyecto de sistemas de información. También se usa
más adelante para modelar una base de datos en particular o varias. Una base de datos
relacional tiene una tabla relacional equivalente y puede expresarse así potencialmente,
según sea necesario.

 Solución de problemas de bases de datos: los diagramas ER se usan para analizar las

bases de datos existentes con el fin de hallar y resolver problemas de lógica o
implementación. Al dibujar un diagrama se debería descubrir dónde está el problema.

 Sistemas de información empresarial: los diagramas se usan para diseñar o analizar las

bases de datos relacionales empleadas en procesos de negocio. Cualquier proceso de
negocio que utilice datos de campo relacionados con entidades, acciones e interacción
puede beneficiarse potencialmente de una base de datos relacional. Puede simplificar
procesos, revelar información de forma más sencilla y mejorar los resultados.

 Reingeniería de procesos de negocio (BPR): Los diagramas ER ayudan a analizar las

bases de datos empleadas en la reingeniería de procesos de negocio y en el modelado de
la configuración de una nueva base de datos.
  Educación: las bases de datos son el método actual de almacenamiento de información
relacional para propósitos educativos y la posterior recuperación. Así, los diagramas ER
pueden ser útiles para la planificación de esas estructuras de datos.

 Investigación: como hay muchas investigaciones centradas en los datos estructurados,

los diagramas ER pueden desempeñar un papel fundamental en la configuración de bases
de datos útiles para analizar los datos.

Los componentes y las características de un diagrama ER

Los diagramas ER se componen de entidades, relaciones y atributos. También representan la

cardialidad, que define las relaciones en términos de números. Puedes ver un glosario a
continuación:

Entidad

Algo que se puede definir, como una persona, objeto, concepto u evento, que puede tener datos
almacenados acerca de este. Piensa en las entidades como si fueran sustantivos. Por ejemplo: un
cliente, estudiante, auto o producto. Por lo general se muestran como un rectángulo.

Tipo de entidad
Un grupo de cosas que se pueden definir, como estudiantes o atletas, mientras que la entidad sería
el estudiante o atleta específico. Otros ejemplos son clientes, autos o productos.
Conjunto de entidades: 
Es igual que un tipo de entidad, pero se define en un momento determinado, como por ejemplo
estudiantes que se inscribieron en una clase el primer día. Otros ejemplos son clientes que
realizaron una compra en el último mes o autos registrados actualmente en Florida. Un término
relacionado es una instancia, en la que una persona determinada o un auto específico podría ser
una instancia del conjunto de entidades.
Categorías de entidades:
Las entidades se clasifican en fuertes, débiles o asociativas. Una entidad fuerte se puede definir
únicamente por sus propios atributos, en cambio, una entidad débil no. Una entidad asociativa es
aquella que relaciona entidades (o elementos) dentro de un conjunto de entidades. 
Claves de entidad
Se refiere a un atributo que únicamente define una entidad en un conjunto de entidades. Las claves
de entidad se dividen en superclave, clave candidata o clave primaria. Superclave: un conjunto de
atributos (uno o más) que juntos definen una entidad en un conjunto de entidades. 

Clave candidata: es una superclave mínima, es decir, contiene el menor número posible de
atributos para seguir siendo una superclave. Un conjunto de entidades puede tener más de una
clave candidata. Clave primaria: es una clave candidata seleccionada por el diseñador de la base
de datos para identificar únicamente al conjunto de entidades. Clave extranjera: identifica la
relación entre las entidades.

Relación
Cómo las entidades interactúan o se asocian entre sí. Piensa en las relaciones como si fueran
verbos. Por ejemplo, el estudiante mencionado podría inscribirse en un curso. Las dos entidades
serían el estudiante y el curso, y la relación representada es el acto de inscribirse, que conecta
ambas entidades de ese modo. Las relaciones se muestran, por lo general, como diamantes o
etiquetas directamente en las líneas de conexión.

Relación recursiva: la misma entidad participa más de una vez en la relación.

Atributo

Una propiedad o característica de una entidad. A menudo se muestra como un óvalo o círculo.

Atributo descriptivo: una propiedad o característica de una relación (frente a una entidad).

Categorías de los atributos: los atributos se clasifican en simples, compuestos y derivados, así

como de valor único o de valores múltiples. Simples: significa que el valor del atributo es mínimo y
ya no puede dividirse, como un número de teléfono. Compuestos: los subatributos surgen de un
atributo. Derivados: los atributos se calculan o derivan de otro atributo, por ejemplo, la edad se
calcula a partir de la fecha de nacimiento.

Valores múltiples: 

Se denota más de un valor del atributo, como varios números de teléfono para una persona.

Valor único: 

Contienen solo un valor de atributo. Los tipos se pueden combinar, por ejemplo, puede haber
atributos de valor único simples o atributos de múltiples valores compuestos.

Cardinalidad

Define los atributos numéricos de la relación entre dos entidades o conjuntos de entidades. Las
tres relaciones cardinales principales son uno a uno, uno a muchos y muchos a muchos.
Un ejemplo de uno a uno sería un estudiante asociado a una dirección de correo electrónico.
Un ejemplo de uno a muchos (o muchos a uno, en función de la dirección de la relación) sería un
estudiante que se inscribe en muchos cursos, y todos esos cursos se asocian a ese estudiante en
particular. Un ejemplo de muchos a muchos sería los estudiantes en grupo están asociados a
múltiples miembros de la facultad y a su vez los miembros de la facultad están asociados a
múltiples estudiantes.

Vistas de cardinalidad: la cardinalidad puede estar del lado opuesto o del mismo, en función de
dónde se muestran los símbolos.

Restricciones de cardinalidad:

Los números máximos o mínimos que se aplican a una relación.

Creación de mapas de lenguaje natural

Los componentes ER pueden reflejar las categorías gramaticales, eso fue lo que hizo Peter Chen.
Esto muestra cómo un diagrama ER se compara con un diagrama gramatical:
Sustantivo común: tipo de entidad. Ejemplo: estudiante.

Sustantivo propio: entidad. Ejemplo: Sally Smith.

Verbo: tipo de relación. Ejemplo: se inscribe (por ej. en un curso, que podría ser otro tipo de
entidad).

Adjetivo: atributo de una entidad. Ejemplo: principiante.

Adverbio: atributo de una relación. Ejemplo: digitalmente.

ERROL es un lenguaje de consulta de base de datos que imita las construcciones del lenguaje
natural. ERROL se basa en álgebra relacional extendida (RRA) y funciona con modelos ER,
capturando sus aspectos lingüísticos.

Crear diagramas es rápido y sencillo con Lucidchart. Inicia una prueba gratuita hoy mismo para
empezar a crear y colaborar.

Modelos de datos físicos, lógicos y conceptuales

Los modelos de datos y los modelos ER se dibujan típicamente con hasta tres niveles de detalle:

Modelo de datos conceptuales: la visualización de nivel más alto que contiene la menor cantidad
de detalle. Su valor muestra el alcance global del modelo y representa la arquitectura del sistema.
Para un sistema de menor alcance, quizás no sea necesario dibujarlo. En cambio, se comienza con
el modelo lógico.

Modelo de datos lógicos: contiene más detalle que un modelo conceptual. Ahora se definen las
entidades transaccionales y operativas más detalladas. El modelo lógico es independiente de la
tecnología en la que se implementará.

Modelo de datos físicos: uno o más modelos físicos pueden desarrollarse a partir de cada modelo
lógico. El modelo físico debe mostrar los suficientes detalles tecnológicos para producir e
implementar la base de datos en cuestión.

Ten en cuenta que existen niveles de alcance y de detalle similares en otros tipos de diagramas,
como los diagramas de flujo de datos, pero esto se contrasta con el enfoque de tres esquemas de
la ingeniería de software, que divide la información de forma diferente. En algunas ocasiones, los
ingenieros ramificarán los diagramas ER con jerarquías adicionales con el fin de agregar los
niveles de información necesarios para el diseño de la base de datos. Por ejemplo, pueden agregar
categorías mediante la ampliación hacia arriba con superclases y hacia abajo con subclases.

Limitaciones de los modelos y diagramas ER

Exclusivo para datos relacionales: comprende que el propósito es solo mostrar las relaciones. Los
diagramas ER muestran únicamente la estructura relacional.

Inadecuado para datos no estructurados: a menos que los datos se delineen claramente en
campos, filas o columnas diferentes, es probable que los diagramas ER tengan un uso limitado. Lo
mismo sucede con los datos semiestructurados, porque solo algunos datos serán útiles.
Complicaciones al realizar una integración con una base de datos existente: usar modelos ER para
realizar una integración con bases de datos existentes puede ser un desafío debido a las diferentes
arquitecturas.

Cómo dibujar un diagrama ER básico

Propósito y alcance: definen el propósito y el alcance de lo que estás analizando o modelando.

Entidades: identifican las entidades involucradas. Cuando estés listo, comienza a dibujarlas en

rectángulos (o en la figura que selecciones en tu sistema) y etiquétalas como sustantivos.

Relaciones: determinan cómo se relacionan todas las entidades. Dibuja líneas entre ellas para
indicar las relaciones y etiquétalas. Algunas entidades pueden no estar relacionadas, y eso está
bien. En diferentes sistemas de notación, la relación se puede etiquetar en un diamante, otro
rectángulo o directamente sobre la línea de conexión.

Atributos: brindan más detalles mediante la adición de atributos clave de las entidades. Los
atributos a menudo se muestran como óvalos. 

Cardinalidad: muestra si la relación es 1-1, 1-muchos o muchos a muchos.

Más consejos sobre diagramas ER

Muestra el nivel de detalle necesario para tu propósito. Tal vez desees dibujar un modelo físico,
lógico o conceptual, en función de los detalles necesarios. (Consulta más arriba las descripciones
de esos niveles).

Presta atención a las relaciones o entidades redundantes.

Si estás solucionando un problema de una base de datos, presta atención a los vacíos en las
relaciones o los atributos o entidades que faltan.

Asegúrate de que todas tus entidades y relaciones estén etiquetadas.

Puedes convertir tablas relacionales a diagramas ER, y viceversa, si eso te ayuda a alcanzar tu
objetivo.

Asegúrate de que el diagrama ER admita todos los datos que necesitas guardar.

Puede haber diferentes enfoques válidos para un diagrama ER. Mientras brinde la información
necesaria para su alcance y propósito, es apropiado.