UNIVERSIDAD NACIONAL EXPERIMENTAL

DE LOS LLANOS OCCIDENTALES

“EZEQUIEL ZAMORA”

UNELLEZ

INGENIERÍA DE REQUISITOS

 PROFESOR :  ESTUDIANTE :
Guillermo Certad.  Yulianny Rodriguez.
 CARRERA: Ingeniería Informática 6to semestre.  C.I: 27.960.705
 SUB-PROYECTO: Principios de ingeniería del software.

Barrancas, 2022

ÍNDICE
Introducción……………………………………………………………………………………….....3

Definición, objetivos e importancia de los requisitos de software…………………………………..4

Requisitos funcionales y no funcionales: Definición y características……………………………...5

Requisitos del usuario: Definición y características…………………………………………………7

Requisitos del sistema: Definición y características………………………………………………...7

Obtención y análisis de requisitos: uso de entrevistas, escenarios y casos de uso…………………..8

Técnicas estructuradas para el modelado y la representación de requisitos: diagramas de flujo…....9

Diagramas de control……………………………………………………………………………….10

Diagramas de contexto……………………………………………………………………………..11

Diagramas de transición de estados………………………………………………………………...12

Diagramas de entidad – relación….………………………………………………………………..14

Diccionario de datos………………………………………………………………………………..15

Conclusión………………………………………………………………………………………….16

INTRODUCCIÓN
 Se especifica que para la producción de un software, se requiere primero de los requisitos

que tiene el cliente para el proyecto ¿Con que finalidad? Para poder implementar sus

requerimientos y así hacer los pasos de extracción, análisis, especificación y validación, todo esto

conlleva una importancia y objetivos presentes.

En este Módulo III de requisitos del software, se pondrá en desarrollo todo lo relacionado a

él, como los requisitos que necesita el usuario, los sistemas y aquellas que sean funcionales y no

funcionales, sin embargo, el primer paso para obtener esos requisitos seria el entrevistar al cliente,

luego de eso se hace un escenario para ver si el sistema es funcional, después sería lo del caso de

uso ¿Qué hace? Se encarga de saber el comportamiento del sistema. Existen diversas técnicas

estructuradas para los sistemas y en este desarrollo se encontraran las siguientes:

 Diagramas de control.

 Diagramas de contexto.

 Diagramas de estado.

 Diagramas de transición de estados.

 Diagramas de entidad – relación.

 Diccionario de datos.

Definición, objetivos e importancia de los requisitos de software.

 Es una condición o necesidad de que tiene el usuario para resolver un problema o alcanzar

un objetivo o también puede ser una condición o capacidad que debe estar presente en un sistema o

componentes de sistema para satisfacer un contrato, estándar y su especificación.

Objetivos

 Introducir los conceptos de requerimientos del usuario y sistema.

 Describir los requerimientos funcionales y no funcionales.

 Explicar la forma en que los requerimientos de software pueden ser organizados en

un documento de requerimientos de software.

Importancia

 Permite gestionar las necesidades del proyecto en forma estructurada: Cada

actividad de la IR (registro de instrucción) radica de una serie de pasos organizados y bien

definidos.

 Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados:

La IR provee 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 confirmado que

reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro.

 Mejora la comunicación entre equipos: La especificación de requerimientos

representa una forma de consentimiento entre clientes y desarrolladores. Si esta aprobación no

ocurre, el proyecto no será exitoso.

 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.).

  Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente

a considerar sus requerimientos cuidadosamente e inspeccionarlo dentro del marco del

problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Requisitos funcionales y no funcionales: Definición y características

Los requerimientos funcionales son los que definen las funciones que el sistema será

capaz de efectuar, detallan las transformaciones que el sistema realiza sobre las entradas para

causar salidas. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en

los algoritmos, la lógica y gran parte del código del sistema.

Sus características son las siguientes:

 Interoperabilidad: El requisito describe si un sistema de software es

interoperable entre diferentes sistemas.

 Seguridad: El funcional requisito describe el aspecto de seguridad de los

requisitos de software.

 Precisión: La precisión detalla que los datos ingresados en el sistema son

calculados y utilizados correctamente por el sistema y que la salida es correcta.

 Cumplimiento: Los requisitos funcionales de cumplimiento validan que el

sistema desarrollado cumple con los estándares industriales.

Por otra parte, los requerimientos no funcionales tienen que ver con características que de
una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo),
mantenimiento, seguridad, portabilidad, estándares, entre otros.

 Rendimiento: Un tipo de atributo de rendimiento de requisito no funcional

mide el rendimiento del sistema.

  Usabilidad: La usabilidad mide la usabilidad del sistema de software que se

está desarrollando.

 Mantenibilidad: La capacidad de mantenimiento de un sistema de software es

la facilidad con la que se puede mantener el sistema. Si el tiempo medio entre fallos es bajo

o el tiempo medio de reparación es alto para el sistema que se está desarrollando, entonces

la capacidad de mantenimiento del sistema se considera baja.

 Fiabilidad: La confiabilidad es otro aspecto del recurso. Este atributo de

calidad enfatiza la disponibilidad de un sistema bajo ciertas condiciones.

 Portabilidad: Portabilidad significa la capacidad de un sistema de software

para funcionar en un entorno diferente si el marco dependiente subyacente permanece igual.

 Compatibilidad: La capacidad de servicio de un sistema de software es la

capacidad de un experto técnico / de servicio para instalar el sistema de software en un

entorno en tiempo real, monitorear el sistema mientras está en ejecución, identificar

cualquier problema técnico en el sistema y brindar una solución para resolver el problema.

 Adaptabilidad: La adaptabilidad de un sistema se define como la capacidad

de un sistema de software para adaptarse al cambio en un entorno sin ningún cambio en su

comportamiento.

Requisitos del usuario

Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el

sistema provea y de las restricciones bajo las cuales debe operar.

 Características:

 Al usuario se le proveerá con los recursos para definir el tipo de archivos

externos

 Cada tipo de archivo externo tendrá una herramienta asociada que será

aplicada al archivo

 Cada tipo de archivo externo se representará como un icono específico sobre

la pantalla del usuario.

 Se proveerán recursos para que el usuario defina el icono que representa un

tipo de archivo externo

Requisitos del sistema.

Forman con detalle los servicios y restricciones del sistema. El documento de

requerimientos del sistema, algunas veces denominado especificación funcional, debe ser exacto.

Éste sirve como un contrato entre el comprador del sistema y el desarrollador de software.

Características:

Los requisitos bien formulados deben satisfacer varias características. Si no lo hacen, deben

ser reformulados hasta hacerlo.

 No ambiguo: El texto debe ser claro, preciso y tener una única interpretación

posible.

 Conciso: Debe redactarse en un lenguaje entendible por los inversores en

lugar de uno de tipo técnico y especializado, aunque aun así debe referenciar los aspectos

importantes.
  Consistente: Ningún requisito debe entrar en problema con otro requisito

diferente, ni con parte de otro. De este modo, el lenguaje empleado entre los distintos

requisitos debe ser consistente también.

 Completo: Los requisitos deben contener en sí mismos toda la información

necesaria, y no despachar a otras fuentes externas que los expliquen con más detalle.

 Alcanzable: Un requisito debe ser un objetivo realista, posible de ser

alcanzado con el dinero, el tiempo y los recursos disponibles.

 Verificable: Se debe poder verificar con absoluta certeza, si el requisito fue

satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis y

demostración.

Obtención y análisis de requisitos: uso de entrevistas, escenarios y casos de uso.

Las entrevistas y cuestionarios se emplean para juntar información proveniente de personas

o de grupos. Durante la entrevista, el analista charla con el encuestado; el cuestionario consiste en

una serie de preguntas relacionadas con varios aspectos de un sistema.

Los casos de uso son una técnica para detallar el comportamiento de un sistema. Los casos

de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o

más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un

conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el

sistema.

Técnicas estructuradas para el modelado y la representación de requisitos:

Diagramas de flujo
 El diagrama de flujo de datos (DFD) es una técnica que figura el flujo de la información y

las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida; ya que

adopta un punto de vista del tipo entrada-proceso-salida para el sistema.

Se puede usar el diagrama de flujo de datos para representar un sistema o un software a

cualquier nivel de abstracción. De hecho, los diagramas de flujo pueden ser divididos en niveles

que representen un mayor flujo de información y un mayor detalle funcional.

Sus requisitos:

 Flujo de información que es recogido o producido de forma constante en el

tiempo.

 Información de control que pasa por el sistema y el procesamiento de control

asociado.

 Ocurrencias múltiples de la misma transformación que se encuentran a

menudo en situaciones de multitarea.

 Estados del sistema y mecanismos que producen transición de estados en el

sistema

Ejemplo de DFD de contexto

Entidad Entrada A
Externa 1
0
Entidad
Nombre Externa 3
de
Entidad Entrada B Sistema
Externa 2

Diagrama de control

Lo que se pretende con este tipo de análisis es controlar los procesos para asegurarse de que

funcionan correctamente. Si la gran mayoría de los puntos mostrados de la gráfica están dentro de
los límites se considera que el proceso está controlado. En el momento en el que uno o varios

puntos aparecen fuera de los límites establecidos, se considera que el proceso está descontrolado y

comienza la búsqueda de la causa de su mal funcionamiento. Evaluar todos los casos de uso para

entender por completo la secuencia de interacción dentro del sistema.

Crear una gráfica de control requiere los siguientes pasos:

 Elegir la característica a estudio: Debe medir la variable que queremos

controlar: la longitud de una pieza, la temperatura de una máquina, etc.

 Tomar los datos: Deberemos recoger los valores durante un periodo de

tiempo suficiente que nos permita obtener una visión representativa del desarrollo del

proceso.

 Introducir los datos en la hoja de cálculo, y calcular la cuál es la línea central

(valor medio de los datos) y los límites superior e inferior.

 Representar los datos en la gráfica, y estudiar si el funcionamiento es el

correcto: Si no fuera por estar el proceso descentrado (la media de los datos no es la medida

que nos pide las especificaciones) habría que recalibrar las máquinas.

 Volver a realizar el estudio cada cierto tiempo para comprobar que el

funcionamiento sigue siendo el correcto.

El siguiente diagrama esquemático muestra los criterios a considerar para seleccionar el

gráfico de control adecuado:
Inicio

Tipo de
datos
 Variables Atributos
(Medidos) (Contados)

Tamaño Defectos o
grupo -n Defectuoso
Defectuoso s Defecto
NO SI s

Rango o Desv. Igual tamaño Igual tamaño

Estándar de muestra de muestra

Rango Desv. Estándar NO SI NO SI

→ →
X -S X-MR. P NP U C
X -R

Diagrama de contexto

El diagrama de contexto muestra al sistema interactuando con uno o más agentes externos.

En el objeto sistema es útil identificar los sensores y actuadores a través de los que los agentes

externos operan con el sistema.

A continuación, la representación del sistema en el diagrama de flujo:

Percepción/Acción
Sensores/Actuadores Status y Control
GUI
Interfaces (Controlador)
 Sistema
Altavoz Alarma
(Planta) Altavoz
(Controlador) Personal
LAN Servicio
Indicador de
planta Indicador de
Llegada Software de planta (Cabina)
Ascensor control de
Botón de ascensor
Req. (Planta) Indicador de
Localización y planta (Cabina) Requiere Planta
RS-232
dirección
Altavoz Localizació
Puerta Puerta Planta
(Cabina) n
Requiere
Llegada
ascensor Sensores Puerta

Embarca Desembarca
Puerta cabina
Pasajero

Análisis de requisitos
Pasajero Potencial

Diagrama de transición de estados

También conocido como DTE, muestra los estados que puede tomar el componente de una

aplicación, así como los eventos que implican el cambio de un estado a otro. Los elementos

principales de este tipo de diagrama son el estado y la transición. • Estado: hace referencia al

comportamiento del sistema en un determinado período de tiempo y los atributos que lo

caracterizan. • Transición: es el cambio de estado generado por algún evento, muestra el camino

del estado inicial al estado final. De un estado pueden generarse diversas transiciones sobre la base

de un evento que desencadena el cambio. Entonces, el diagrama iniciará con un estado inicial como

parte del flujo; posteriormente, producto de los eventos se generarán transiciones de otros estados.

El estado final será aquel que deje de tener alguna actividad. Cabe mencionar que el diagrama
puede tener varios estados finales como parte del flujo, los mismos que se dan a través de las

transiciones.

Notación del diagrama de estado:

Representación Grafica Descripción

Nombre de estado Estado

Estado Inicial

Estado final

Transición

A continuación, se mostrara un ejemplo de un diagrama de estados de la revisión de documento:

Aprobar Completo
Aprobado

Pendiente Finalizado

Rechazar Completo
Rechazado

Diagrama de entidad-relación
 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.

Para asimilar fácilmente un diseño de datos cuando se emplea el modelo E/R se utilizan los
siguientes elementos gráficos:

Entidad

NOM-ENTIDAD

Relación 1-1

Relación 1-n

Relación n-n

La utilizacion de estos elementos dará como resultado lo que se denomina el esquema

entidad-relacion de la base de datos. El ejemplo que se incluye en el apartado anterior,

gráficamente quedarian de la siguiente forma:

MATRIMONIO

HOMBRE MUJER
 TRABAJAR- EN

EMPRESA TRABAJADOR

MATRICULA

ALUMNO ASIGNATURA

Diccionario de datos.

El diccionario de datos es un listado organizado de todos los datos acertados al sistema, con

definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un

entendimiento común de todas las entradas, salidas, componentes de los almacenes y cálculos

intermedios.

Tiene como finalidad:

 Contener las características lógicas de los sitios donde se almacenan los

datos del sistema, incluyendo nombre, descripción, alias, contenido y organización.

 También identifica los procesos donde se emplean los datos y los sitios

donde se necesita el acceso inmediato a la información; se desarrolla durante el análisis de

flujo de datos y auxilia a los analistas que participan en la determinación de los

requerimientos del sistema, su contenido también se emplea durante el diseño.

 Sirve como punto de partida para identificar los requerimientos de las bases

de datos durante el diseño de sistemas.

Conclusión
 En vista a todo lo que se pudo describir pudimos detallar lo fundamental que es saber este

tipo de información, si algún tipo de persona (cliente), organización o empresa requiere un sistema

que sea funcional en su ámbito de trabajo, debemos primero hacer el uso de la entrevista ¿Con que

propósito? Saber qué tipo de requisitos necesita y ponerlo en práctica es lo que hace el

desarrollador, la importancia que tiene esto es que mejora la comunicación entre equipos y hasta

mejorar la calidad del software.

En las técnicas estructuradas para el modelado se pudo descubrir que el diagrama de flujo

es una técnica que representa el flujo de la información y las transformaciones que se aplican a los

datos al moverse desde la entrada hasta la salida, en el diagrama de control lo que se pretende con

este tipo de análisis es controlar los procesos para asegurarse de que funcionan correctamente, el

diagrama de contexto muestra al sistema interactuando con uno o más agentes externos, el

diagrama de transición de estado muestra los estados que puede tomar el componente de una

aplicación, así como los eventos que implican el cambio de un estado a otro y los diagramas de

entidad-relación 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.

Con todo esto presente se pudo concluir este módulo de requisitos del software.