Documentación técnica:

Especificación
de requisitos funcionales
2 de 19
Índice

1. Introducción …………………………………………………………………………………………………………………… 5

2. Definición ……………………………………………………………………………………………………………………… 6

3. Análisis y especificación de requisitos …………………………………………………………… 8

4. Casos de uso ………………………………………………………………………………………………………………… 11

5. Diagramas UML ………………………………………………………………………………………………………… 14

4 de 19
1. Introducción

Un lenguaje de programación es un lenguaje formal que permite escribir una serie

de instrucciones con el fin de conseguir que el sistema informático haga lo que
queremos. Las instrucciones son las secuencias de órdenes que ejecutará la
computadora. A veces estas órdenes se refieren a la ejecución de determinadas
tareas y, otras veces, se referirán al manejo de datos según el proceso establecido.

Una de las mejores formas de aprender a programar y facilitar a los estudiantes la

inmersión en el proceso de resolución de problemas, es empezar por aprender a
utilizar diagramas de flujo y pseudocódigo. Los diagramas de flujo representan de
forma gráfica los procedimientos y el pseudocódigo es una forma de expresar con
lenguaje natural los distintos pasos que va a realizar un programa.

5 de 20
2. Definición

La acción de programar no es, ni más ni menos, que indicar a una máquina lo que
tiene que hacer, siguiendo un conjunto ordenado de instrucciones. En realidad, las
personas realizamos muchas programaciones a lo largo del día sin darnos cuenta
de ello:

• Seguimos una receta de cocina.

• Revisamos los mensajes recibidos en el móvil y los contestamos uno a uno.

• Configuramos una alarma del reloj para que suene a una hora determinada.

• Fijamos una cita o tarea en el calendario con un avisador temporizado.

Por tanto, una secuencia simple de instrucciones es la estructura de programación

más natural, pues consiste solamente en colocar las instrucciones en un orden
secuencial, lógico y preciso. Las instrucciones se ejecutan una única vez, una
después de la otra, sin cambio en el flujo de ejecución, salvo que se indique otra
cosa, como pueden ser los bucles.

El pseudocódigo es una forma de expresar los distintos pasos que van a realizar
en un programa, utilizando palabras del lenguaje de las personas, pero forzando la
estructura requerida por un lenguaje de programación. De esta forma se pueden
representar los pasos que dan la solución a un problema o algoritmo, de la forma
más detallada posible, utilizando un lenguaje cercano al mismo tiempo a la
programación y a las personas.

A continuación, se muestra el ejemplo del pseudocódigo de un programa que lee 3

números de la consola e indica cuál es el mayor de todos ellos.

PSEUDOCÓDIGO CÓDIGO JAVASCRIPT

Inicio <script type=“text/javascript” >
Variables a, b,c = enteros.
Imprimir en consola “Introduce los 3
números a comparar: ”
Leer a,b,c a=parseFloat(prompt(“numero 1”));
b=parseFloat(prompt(“numero 2”));
c=parseFloat(prompt(“numero 3”));

6 de 20
2. Definición

Si a<b y a<c entonces if(a>b && a>c){

Imprime “El mayor es: ”, a alert(a);
Sino }
Si b<a y b<c entonces else{
Imprime “El mayor es: ”,b if(b>c)
sino alert(b);
Imprime “El mayor es: ”, c }
else{
alert(c);
}
Fin. </script>

El pseudocódigo no puede ejecutarse en un sistema informático. Es un código

escrito para que lo entienda el ser humano y no la máquina. Por tanto, luego hay
que escribirlo en el lenguaje que queramos. En el ejemplo anterior, se puede ver el
código equivalente en JavaScript (columna de la derecha).

7 de 20
3. Análisis y especificación de requisitos

La especificación de requisitos de software es la descripción completa del

comportamiento del sistema que se va a desarrollar. También denominados
requerimientos, describen no solo los servicios que ha de ofrecer el sistema, sino
también las restricciones asociadas a su funcionamiento.

Hay una clasificación sencilla:

• Requerimientos funcionales: definen la naturaleza del funcionamiento del

sistema (cómo interacciona el sistema con su entorno y cuáles van a ser su
estado y funcionamiento).

• Requerimientos no funcionales: restricciones que no se refieren al

funcionamiento. Por ejemplo:

o Rendimiento del sistema: margen de fiabilidad, tiempos de respuesta,

disponibilidad horaria.
o Interfaces: dispositivos de E/S que va a tener conectados, aspectos de
usabilidad o grafismo, interoperabilidad con todo tipo de plataformas.
o Proceso de desarrollo: estándares que hay que utilizar, plazos de
entrega de la aplicación.

Los requisitos funcionales Los requisitos no funcionales

describen qué debe hacer un describen cómo debe ser un
sistema sistema

Pero no siempre la distinción entre requerimientos funcionales y no funcionales

es tan evidente. Por ejemplo, los aspectos de seguridad de una aplicación o de un
portal web pueden considerarse requerimientos no funcionales al principio, y en
cambio, para lograr alcanzarlos, se pueden definir nuevos requerimientos
funcionales, como puede ser la necesidad de incluir un proceso de autenticación
de usuarios del sistema (el típico registro de usuarios).

8 de 20
3. Análisis y especificación de requisitos

En cualquier caso, independientemente de a qué tipo pertenezcan, lo importante

es que estén bien detallados. Los requerimientos se especifican en lenguaje
natural, de forma individual, utilizando esquemas y diagramas, y se podrán
organizan de forma jerárquica marcando según su importancia o su nivel de
criticidad. Los requerimientos deben ser claros y concretos, hay que evitar
imprecisiones y ambigüedades al redactarlos, concisos (sin rodeos ni figuras
retóricas), y por supuesto, completos y consistentes.

En resumen, los requerimientos funcionales:

 Deben estar redactados de tal forma que sean comprensibles para

usuarios sin conocimientos técnicos avanzados (de Informática, se
entiende),

 Deben especificar el comportamiento externo del sistema y evitar, en la

medida de lo posible, establecer características de su diseño,

 Deben priorizarse (al menos, se ha de distinguir entre requisitos

obligatorios y requisitos deseables).

A continuación, se presenta un ejemplo de descripción de requisitos funcionales y

no funcionales.

9 de 20
3. Análisis y especificación de requisitos

Ejemplo: Matriculación de un curso on-line

REQUERIMIENTOS FUNCIONALES

1. La matrícula será realizada de forma interactiva. El usuario seleccionará del

buscador de cursos aquél en el que desea matricularse (solo se admite uno).

2. Se podrá generar una copia de la matrícula (pdf).

3. Para la matriculación se consultarán los datos del expediente y se realizarán

las validaciones necesarias.

4. Pago de matrícula:

 La aplicación activará una pasarela de pago con tarjeta bancaria o

PayPal.
 Si el usuario dispone de un bono descuento, la aplicación le pedirá la
referencia y calculará automáticamente los descuentos
correspondientes.
 Se generará un impreso del pago realizado (pdf).

REQUERIMIENTOS NO FUNCIONALES

 Hardware: el sistema funcionará sobre PCs o teléfonos móviles.

 Software: la aplicación deberá funcionar sobre cualquier navegador o
sistema operativo móvil.
 Disponibilidad: 24x7.
 Periféricos: impresoras.

10 de 20
4. Casos de uso

Los casos de uso también son una forma de describir los requisitos funcionales y
describen el modo en que un usuario interactúa con el sistema (en lenguaje
natural). Los casos de uso resultan muy útiles para explicar el funcionamiento de
los sistemas informáticos, priorizando los requerimientos cuando el sistema se
desarrolla de forma incremental (por ejemplo, en base a prototipos que se van
mejorando), también son muy útiles a la hora de elaborar manuales de usuario, así
como a la hora de especificar las pruebas de validación.

Cada caso de uso se centra en describir cómo alcanzar una única meta o una tarea
del programa. Desde una perspectiva tradicional de la ingeniería de software, un
caso de uso describe una característica del sistema. En la mayoría de los
proyectos de software, este es un trabajo muy extenso ya que puede significar
que el analista deba especificar decenas o hasta cerca de cien casos de uso, hasta
definir completamente todo lo que hace el sistema.

Un caso de uso contiene una descripción textual de todas las maneras que los
actores previstos podrían trabajar con el software o el sistema. Los casos de uso
no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni
explican cómo se implementará. Simplemente muestran los pasos que el actor
sigue para realizar una tarea.

Siguiendo el ejemplo anterior, así quedaría la especificación textual de un caso de

uso:

• El usuario ejecuta el programa de matrícula del curso.

• Al iniciar se le solicita su registro, con el identificativo (login) y la
contraseña (password).
• El sistema verifica la identificación del usuario.
• Si la identificación es positiva, se le presenta una lista con los cursos
disponibles.
• Una vez que el usuario ha seleccionado el curso, el programa presenta los
datos correspondientes a la matrícula, desglosando las fechas de ejecución
y el precio total.
• El usuario accede a la pasarela de pago.
• Si no desea matricularse en otro curso, la aplicación se termina.

Y la especificación detallada, de la siguiente manera:

11 de 20
4. Casos de uso

Actor Usuario

Caso de uso Matricularse de un curso

Nombre Matrícula de curso

Descripción Esta aplicación permite a un usuario del sistema, seleccionar

un curso y proceder con la matrícula on-line

Dependencias Autenticación de usuarios.

Aplicación de e-commerce

Actores Usuario

Pre-condiciones

Post-condiciones

USUARIO SISTEMA

1. El usuario se identifica.

2. El sistema autentifica al
Escenario principal usuario.

3. Si es correcto le ofrece la
lista de cursos disponibles.

12 de 20
4. Casos de uso

El usuario selecciona el
curso deseado.

El sistema le presenta un
resumen de las
características del curso,
fechas y precio.

Si lo desea, el usuario
paga.

El sistema genera una

factura.

2. Si al tercer intento no se
realiza con éxito, se guarda
la incidencia en un registro.
Se inhabilita durante 15 min.
Alternativas El acceso desde la misma IP

3. Si la autenticación no es
correcta se muestra la
página de Inicio

-
Observaciones

El sistema debe estar preparado para aceptar 100

Requisitos no sesiones simultáneas de usuarios queriendo
funcionales matricularse, sin degradar el rendimiento más del 40%
con respecto al caso de un usuario único.

Ejercicio para desarrollar

Se pide realizar el caso de uso para una solicitud de préstamo de un libro en una
biblioteca.

13 de 20
5. Diagramas UML

Los casos de uso pueden ser descritos de forma gráfica y visual, aunque con
menos detalle que de la forma textual descrita en el apartado anterior. El Lenguaje
de Modelado Unificado (UML), define una notación gráfica, para representar casos
de uso, llamada modelo de casos de uso. UML no define estándares para que el
formato escrito describa los casos de uso, y así mucha gente no entiende que esta
notación gráfica define la naturaleza de un caso de uso; sin embargo, una notación
gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de
casos de uso.

Como se ha mencionado antes, un caso de uso es una secuencia de interacciones

que se desarrollarán entre un sistema y sus actores en respuesta a un evento que
inicia un actor principal sobre el propio sistema. Por tanto, los diagramas de
casos de uso sirven para especificar la comunicación y el comportamiento de un
sistema mediante su interacción con los usuarios y/u otros sistemas. Se utilizan
para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos
que se producen en su ámbito o en él mismo.

Siguiendo con el ejemplo anterior, el diagrama que representa el caso de uso

matricularse en un curso sería:

Figura 1. Ejemplo de diagrama de casos de uso

UML está orientado hacia un enfoque más clásico para los lenguajes orientados a
objetos, como TypeScript, pero también se puede usar para diseñar sistemas
programados con otros lenguajes, como JavaScript. UML describe muchos tipos
de diagramas distintos. Así, los diagramas de clase pueden ser adecuados para
representar estructuras orientadas a objetos, y los diagramas de secuencia o los
diagramas de gráficos de estado muestran lo que ocurre en tiempo de ejecución.

14 de 20
5. Diagramas UML

Con respecto al uso de diagramas de clase, depende de si se diseña la aplicación

utilizando principios de diseño orientados a objetos o no. Si solo se han
programado un montón de funciones de JavaScript, los diagramas de clase quizás
no aporten mucha información. Si se usan prototipos de objetos JavaScript para
simular un tipo de clases, entonces estos diagramas serán muy útiles. A
continuación, se muestra un ejemplo de diagrama para un portal web que tiene
módulos de código escritos en HTML, utiliza hojas de estilo CSS y tiene varios
módulos de JavaScript para especificar comportamientos dinámicos.

Figura 2. Diagrama de clases de un portal web que incorpora tecnologías HTML, CSS y JS. Fuente:
https://qastack.mx/software/164958/are-uml-class-diagrams-adequate-to-design-javascript-
systems

Para las aplicaciones fabricadas con un marco como Angular, por ejemplo, se
puede describir una arquitectura de referencia, explicando sobre qué tipos de
componentes se trabaja y sus relaciones mutuas. En ese caso, el diseño técnico
puede referirse a la arquitectura de la aplicación creada de manera mucho más
concisa.

15 de 20
5. Diagramas UML

El diseño gráfico de la arquitectura es una mezcla de texto y diagramas. Para

hacer los diagramas, se puede utilizar el estándar UML. En el nivel superior, una
aplicación Angular se divide en módulos, por lo que, naturalmente, comienza el
diseño creando un diagrama que representa los módulos (ver figura 3). A medida
que avanza el proyecto, se irán agregando nuevos módulos. La figura 3 es un
ejemplo de un diagrama de paquete que muestra los módulos angulares y sus
interdependencias.

Figura 3. Diagrama que muestra los módulos angulares y sus dependencias

Habiendo visualizado la estructura general del módulo, se puede continuar con un

enfoque basado en escenarios. La secuencia de las acciones que tienen lugar en
una aplicación, a veces, es difícil de derivar del código fuente. Esto se debe a que
está muy basado en eventos y está lleno de retornos a las llamadas. Para
proporcionar información sobre este tipo de escenarios, UML ofrece los llamados

16 de 20
5. Diagramas UML

diagramas de secuencia (ver Figura 4). Los elementos de la aplicación que

participan en el escenario se representan como rectángulos de colores, que
contienen los nombres de los objetos. Los tipos de objeto se muestran como
estereotipos. El color del objeto es igual al color del módulo al que pertenece. Esto
nos da una idea de la división en módulos a primera vista.

El ejemplo de la Figura 4 se refiere a una pequeña aplicación de inicio de sesión (el

proceso de autenticación de un usuario). El usuario debe ingresar su nombre y
contraseña, hacer clic en el botón Iniciar sesión y luego, la aplicación abre una
página HTML particular que muestra la información para la cual el usuario ya está
autorizado a visualizar.

Figura 4. Diagrama de secuencia

Después de un intento exitoso de inicio de sesión, la aplicación debe enviar un

correo electrónico a una dirección de correo electrónico particular, que sirve como
una especie de libro de registro, con una lista de todos los que han iniciado sesión.

El escenario que se muestra en la Figura 4 es un inicio de sesión exitoso.

17 de 20
5. Diagramas UML

Modelos como estos proporcionan una buena idea de cómo funciona la aplicación
y, al mismo tiempo, pueden relacionarse con historias de usuarios o casos de uso
fácilmente. Es la mejor forma de unir el diseño funcional con el técnico.

18 de 20
2 de 19