CODIGO DEL CURSO:

Alumno(s) Nota

Yaguno Huamaní Ángel Eduardo

Grupo B
Ciclo III
Fecha de entrega 17/09/2023

DISEÑO Y DESARROLLO DE SOFTWARE

PROGRAMA DE FORMACIÓN REGULAR
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 1 de 3

I.- OBJETIVOS:
● Revisar el documento ERS (Especificaciones de Requerimientos del Software) en formato IEEE.
● Elaborar el documento de Requerimientos.
● Elaborar un ERS a partir de un caso práctico puesto en clase.
II.- SEGURIDAD:
Advertencia:
En este laboratorio está prohibida la manipulación del hardware,
conexiones eléctricas o de red; así como la ingestión de
alimentos o bebidas.

III.- FUNDAMENTO TEÓRICO:

● Revisar las presentaciones vistas en Clase.

IV.- NORMAS EMPLEADAS:

● No aplica

V.- RECURSOS:
● En este laboratorio cada alumno trabajará con un equipo con Windows 8.
● En caso de usar un software para este laboratorio, la instalación del mismo se realizará en un equipo Virtual.
● Plantilla desarrollada de ERS según IEEE.

VI.- METODOLOGÍA PARA EL DESARROLLO DE LA TAREA:

● El desarrollo del laboratorio es Individual.

VII.- PROCEDIMIENTO:
Nota:
Las secciones en cursivas son demostrativas, pero sirven para que usted pueda instalar las herramientas de desarrollo en un
equipo externo.

ENUNCIADO DE CASO PRÁCTICO

Una empresa informática de desarrollo de software quiere desarrollar una herramienta de gestión de tareas para poder
organizar mejor el trabajo entre sus empleados. Como primer paso, se ha decidido diseñar e implementar una base de datos que
utilizará finalmente dicha aplicación. En esta empresa se trabaja en diferentes proyectos. Para cada uno de esos proyectos se
van creando tareas que se asignan a los desarrolladores. Un desarrollador puede tener asignadas muchas tareas de diferentes
proyectos a la vez. Un proyecto tiene siempre asignado un responsable que se encargará de llevar el seguimiento de las tareas
del mismo. Las tareas tendrán un asunto, que será un resumen breve de la tarea, y un cuerpo con el contenido detallado de la
misma. Es necesario registrar la fecha y hora de creación de la tarea. Las tareas tienen un estado. En principio los estados
posibles son ‘abierto’, ‘asignado’, ‘en proceso’, ‘finalizado’, ‘cerrado’. En cualquier caso, el administrador de la aplicación
podrá crear nuevos estados o modificar los existentes si lo creyera necesario. Dentro del conjunto de estados habrá siempre
un único estado inicial (ej. abierto) y un único estado final (ej. cerrado). Dependiendo del estado en que esté una tarea, deberán
cuantificarse las horas que ha permanecido la tarea en ese estado (ver más abajo) Las tareas las puede crear cualquier
desarrollador y debe ser registrado como el creador de la tarea. Por defecto la tarea se asigna al responsable del proyecto, en el
estado inicial. Cada tarea tiene una prioridad. Por defecto las tareas se crean con la prioridad mayor. La prioridad se identifica
con un número, de forma que la mayor prioridad es el número 1, la siguiente el 2… A parte de este número, la prioridad se
expresa también con una descripción. Las prioridades disponibles las configura el administrador. Las tareas también se
clasifican en categorías: ‘error’, ‘nueva funcionalidad’, ‘mejora’. El administrador podrá crear y modificar las distintas
categorías. Dentro de cada proyecto, se pueden definir una serie de áreas y cada tarea debe estar siempre asignada a alguna de
esas áreas. El responsable del proyecto podrá modificar, crear o eliminar las áreas que crea necesarias para su proyecto. Las
tareas irán sufriendo una serie de cambios a lo largo de su existencia: cambiarán de dueño, cambiarán de estado, puede que de
categoría, puede variar su prioridad, su descripción, su asunto… Cada uno de estos cambios debe registrarse para poder tener
un historial de los cambios sufridos por la tarea. Debe darse la posibilidad de guardar
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 2 de 3

un comentario explicativo referente a ese cambio en concreto. Además, siempre debe registrarse la fecha en que se produjo el
cambio. El nuevo sistema, se encargará de la notificación vía e-mail de los eventos ocurridos. Por ejemplo, al serle asignada
una tarea a un desarrollador, éste recibirá notificación vía e-mail. Siempre recibirá notificaciones de los cambios producidos
sobre una tarea, tanto el creador de la tarea como el responsable del proyecto. Se desean almacenar dichas notificaciones de
forma que un proceso periódico las lea y envíe los e-mails correspondientes. De alguna manera debe controlarse que no
se envíen las notificaciones más de una vez.

Las tareas tendrán una previsión de horas de desarrollo que estimará el creador de la tarea. Debe ser posible calcular el número
de horas reales invertidas en cada tarea. Para ello se tendrán en cuenta las horas transcurridas mientras la tarea estuviera en
algún estado en el que se deban cuantificar las horas. Un ejemplo podría ser: el estado ‘en proceso’ requerirá cuantificación de
horas y el resto no. Los estados cuantificables en horas de desarrollo los determinará el administrador. Cuando la tarea llegue
al estado final, debe mantenerse las horas reales invertidas en ella. Cada desarrollador puede tener o no asignado algún
proyecto. De la misma forma, cada desarrollador puede ser o no administrador. Simplemente se desea guardar esta
información para poder aplicar las restricciones desde el programa. No se va a usar seguridad en la BD. No se desea
implementar un sistema de permisos que indique a qué funcionalidades o datos tiene acceso cada usuario. Simplemente se
quiere poder saber si un usuario es administrador o no lo es.

PROCEDIMIENTO:

Revisa el documento compartido de plantilla de Especificación de Requerimientos de Software (ERS).

En base a este documento, desarrolla únicamente lo correspondiente a Requerimientos Funcionales y no Funcionales (tablas).
Adjunta los resultados a continuación.

Requerimientos Funcionales:

Identificación del RF01

requerimiento

Nombre del Gestión de proyectos

requerimiento

Características El encargado podrá crear proyectos y asignar responsables a cada proyecto

Descripción del Los proyectos sólo podrán ser asignados por el encargado.
requerimiento

Requerimiento NO RNF01
Funcional RNF05

Prioridad del requerimiento: Alta

Identificación del RF02

requerimiento

Nombre del Gestión de tareas

requerimiento:

Características Cambiar el estado de las tareas (abierto asignado, en proceso, finalizado, cerrado)

Descripción del Los responsables deben poder cambiar el estado de las tareas entre las opciones disponibles
requerimiento
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 3 de 3

Requerimiento NO RNF02
Funcional

Prioridad del requerimiento: Media

Identificación del RF03

requerimiento

Nombre del Registro de tiempo

requerimiento:

Características Registra el tiempo en estados específicos

Descripción del La aplicación debe permitir el registro de tiempo en estados específicos para calcular las horas
requerimiento invertidas en cada tarea.

Requerimiento NO RNF03
Funcional

Prioridad del requerimiento: Media

Identificación del RF04

requerimiento

Nombre del Historial en cambio de tareas

requerimiento:

Características Mantiene un historial de los cambios en las tareas y almacena comentarios explicativos

Descripción del La aplicación debe mantener un historial de cambios en las tareas y permitir almacenar
requerimiento comentarios explicativos para cada cambio.

Requerimiento NO RNF04
Funcional

Prioridad del requerimiento: Alta

Identificación del RF05

requerimiento

Nombre del Notificaciones por correo electrónico

requerimiento:

Características Envía notificaciones a los desarrolladores y almacena notificaciones

Descripción del La aplicación debe permitir enviar notificaciones por correo electrónico a los desarrolladores y
requerimiento almacenarlas para envío posterior a un proceso periodico.

Requerimiento NO RNF05
Funcional

Prioridad del requerimiento: Alta

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 4 de 3

Identificación del RF06

requerimiento

Nombre del Configuración de prioridades y categorías

requerimiento:

Características Configura prioridades de tareas y categoría de tareas

Descripción del Los administradores deben poder configurar las prioridades y categorías de las tareas
requerimiento

Requerimiento NO RNF06
Funcional

Prioridad del requerimiento: Media

Identificación del RF07

requerimiento

Nombre del Usuarios y Roles

requerimiento:

Características Registra la información de los desarrolladores e indica si un usuario es administrador

Descripción del La aplicación debe permitir registrar información de usuarios y determinar si son
requerimiento administradores o no

Requerimiento NO RNF05
Funcional RNF06

Prioridad del requerimiento: Baja

Requerimientos no Funcionales:

Identificación del RNF01

requerimiento

Nombre del Seguridad

requerimiento:

Características No se implementará un sistema de seguridad en la base de datos.

Descripción del La aplicación no incluirá un sistema de seguridad en la base de datos para controlar el acceso a
requerimiento funcionalidades o datos.

Prioridad del requerimiento: Alta

Identificación del RNF02

requerimiento

Nombre del Auditoría y Registro de Cambios

requerimiento:

Características Mantener un registro de cambios y eventos en el sistema.

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 5 de 3

Descripción del La aplicación debe mantener un registro de todos los cambios y eventos relevantes en el sistema
requerimiento para futuras auditorías y análisis.

Prioridad del requerimiento: Alta

Identificación del RNF03

requerimiento

Nombre del Escalabilidad

requerimiento:

Características La aplicación debe manejar un aumento en el número de tareas y usuarios.

Descripción del La aplicación debe ser capaz de manejar un incremento en la cantidad de tareas, usuarios y
requerimiento proyectos sin degradar significativamente el rendimiento.

Prioridad del requerimiento: Alta

Identificación del RNF04

requerimiento

Nombre del Configurabilidad

requerimiento:

Características La aplicación debe ser fácilmente configurable por los administradores.

Descripción del La aplicación debe permitir a los administradores configurar fácilmente estados, prioridades,
requerimiento categorías y otras opciones según sea necesario.

Prioridad del requerimiento: Alta

Identificación del RNF05

requerimiento

Nombre del Usabilidad

requerimiento:

Características La aplicación debe ser fácil de usar e intuitiva.

Descripción del La aplicación debe tener una interfaz de usuario amigable que permita a los usuarios
requerimiento interactuar de manera fácil y eficiente con la herramienta.

Prioridad del requerimiento: Alta

Identificación del RNF06

requerimiento

Nombre del Rendimiento

requerimiento:

Características La aplicación debe ser rápida y eficiente en su funcionamiento.

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 6 de 3

Descripción del La aplicación debe ejecutarse sin retrasos significativos y responder rápidamente a las
requerimiento solicitudes de los usuarios, incluso con grandes volúmenes de datos.

Prioridad del requerimiento:

TAREA:

Realiza un resumen, máximo de dos caras y con tus propias palabras, de las diapositivas compartidas de la
sesión Nro. 3 (complementario).

En las diapositivas de la sesión de esta semana se aborda la importancia de los requerimientos en un proyecto de software. Se
mencionan los objetivos de los requerimientos, que son establecer una base para el diseño y desarrollo del software,
comunicar las necesidades del cliente y servir como base para la validación y verificación del sistema. Se explica cómo se
interpretan y capturan los requerimientos, destacando la importancia de la comunicación efectiva entre los stakeholders y el
equipo de desarrollo. Se describen las características de un requerimiento, tanto funcionales como no funcionales. Los
requerimientos funcionales se refieren a las acciones que debe realizar el sistema, mientras que los requerimientos no
funcionales se refieren a las características del sistema, como la usabilidad, el rendimiento y la seguridad. Se presentan
ejemplos de requerimientos, como "El sistema debe permitir a los usuarios registrarse y acceder a su cuenta" y "El sistema
debe ser capaz de procesar al menos 1000 transacciones por segundo". Estos ejemplos ilustran la importancia de definir los
requerimientos de manera clara y específica. Se habla sobre la especificación de los requerimientos, que consiste en
documentar los requerimientos de manera detallada y precisa. Se mencionan diferentes técnicas de especificación, como el uso
de lenguajes formales y diagramas de casos de uso.

OBSERVACIONES:
● Los requerimientos funcionales describen con claridad las acciones que la aplicación debe realizar, como crear
proyectos, cambiar estados de tareas o enviar notificaciones por correo electrónico. Esto facilita la comprensión de
lo que se espera que haga el sistema.
● Los requerimientos funcionales son detallados y específicos en cuanto a las características y funcionalidades que se
deben implementar. Esto ayuda a los desarrolladores a comprender exactamente lo que se espera de ellos.
● Cada requerimiento funcional tiene una prioridad asignada, lo que permite a los equipos de desarrollo y gestión
priorizar las tareas de acuerdo con su importancia para el negocio.
● Los requerimientos funcionales destacan la interacción entre los usuarios y el sistema, lo que es esencial para
diseñar una experiencia de usuario efectiva.
● Se ha considerado la flexibilidad para futuros cambios al permitir que los administradores configuren estados,
prioridades y categorías de tareas según sea necesario.
● La inclusión de notificaciones por correo electrónico y registros de cambios en las tareas mejora la
comunicación y la trazabilidad en el sistema.

CONCLUSIONES:
● Aunque no se implementará un sistema de seguridad en la base de datos, es importante considerar la seguridad y
privacidad de los datos en futuras etapas del proyecto.
● Los requerimientos no funcionales destacan la importancia del rendimiento y la escalabilidad para
garantizar que la aplicación pueda crecer y manejar cargas de trabajo crecientes.
● La capacidad de configurar estados, prioridades y categorías por parte de los administradores se alinea con la
necesidad de adaptar la aplicación a requisitos cambiantes.
● Se ha reconocido la importancia de la usabilidad y la experiencia del usuario al enfocarse en la facilidad de uso y la
intuitividad de la aplicación.
● La inclusión de un registro de cambios y eventos en el sistema es fundamental para la auditoría y el
seguimiento de actividades.