1. República Bolivariana de Venezuela
Universidad Dr. Rafael Belloso Chacín
Maestría Informática Educativa
Evaluación de los Aprendizajes en
Entornos Tecnológicos
Diseño de una
unidad de clase
Autor: Thamara Hernández
Docente: MSc.Franklin Araujo

2. Descripción de la unidad de clase
Programa Nacional de Formación en Informática
Trayecto: III
Unidad Curricular: Ingeniería del Software II
Unidad de Clase: Fundamentos de Ingeniería de Requisitos
Duración: 3 horas presenciales y 2 de estudios independientes
Objetivos:
Comprender que son los requisitos y conocer
los tipos de requisitos del software, lo cual
permitirá reconocer la importancia que juegan
en el desarrollo de software.
Contenidos:
• Definición de Requisitos.
• Propiedades de los Requisitos
• Tipos de Requisitos
• Requisitos Funcionales
• Requisitos no Funcionales
Actividades
Inicio
Desarrollo
Cierre
Tormenta de ideas para
introducir una definición de
requisito hasta lograr
construirla en el contexto de
desarrollo de software, se
utilizará el software
FreeMind para construir
mapa mental
Revisión de diferentes definiciones
de requisitos.
Discusión socializada de las
propiedades de los requisitos.
Presentación de un caso de
estudio para identificar de forma
general requisitos.
Presentación de los tipos de
requisitos y deducir de acuerdo al
caso planteado ejemplos.
(Presentación en power point)
Identificar a través de lista
preliminar los requisitos en base
a levantamiento de información
en la comunidad seleccionada
para Proyecto Sociotecnológico
III (unidad curricular transversal
en el currículo)
Actividad formativa en la
plataforma moodle de la
institución.

3. Evaluación de la unidad de clase
Unidad de Clase: Fundamentos de Ingeniería de Requisitos
Tipos de Evaluación: Evaluación diagnóstica puntual para indagar sobre conocimientos previos a la
sesión de clase, evaluación formativa de regulación interactiva y evaluación continua
Enfoque de Evaluación: Enfoque de carácter cualicuantitativo
Competencias
Criterio/Indicadores
Conocer: Capacidad para
definir y calificar requisitos
funcionales y no
funcionales.
Reconoce requisitos:
Identifica propiedades de
requisitos
Identifica requisitos
funcionales
Identifica requisitos no
funcionales
Hacer: Identificar requisitos
a través de caso de estudio
Interpreta requisitos:
Ejemplifica los requisitos
del caso
Argumenta los requisitos
que propone
Reconoce requisitos:
Elabora lista preliminar de
requisitos
Clasifica los requisitos de la
comunidad abordada
Reconocer los requisitos de
software de una
organización (comunidad)
Escala(criterio)
Técnicas e instrumentos
Verdadero o falso
Encuesta: cuestionario
Online (Moodle)
adecuado… inadecuado
Adecuación:
Observación: Registro
anecdótico
Calidad:
Prueba de ejecución
sobre situación real:
Prueba Práctica
excelente…deficiente

4. Evaluación de la unidad de clase
Unidad de Clase: Fundamentos de Ingeniería de Requisitos
Tipos de Evaluación: Evaluación diagnóstica puntual para indagar sobre conocimientos previos a la
sesión de clase, evaluación formativa de regulación interactiva y evaluación continua
Enfoque de Evaluación: Enfoque de carácter cualicuantitativo
Competencias
Criterio/Indicadores
Escala(criterio)
Técnicas e instrumentos
Ser: Capacidad de
abstracción y razonamiento
crítico
Toma decisiones valorando la
necesidad de la organización
Adecuación al contexto:
Participa activamente
Realiza aportes
significativos
Analiza adecuadamente
la información
Notas de
hechos
significativos,
actitudes
Presencia o
ausencia
Observación:
Registro Anecdótico (en
el desarrollo de la clase)
Convivir: Capacidad para
trabajar en equipo
multidisciplinario (entre pares,
comunidad, docentes)
Trabajo colaborativo:
Participa activamente en
el equipo
Aporta sugerencias
significativas
Coopera adecuadamente
Presencia o
ausencia
Lista de cotejo (en base a
prueba práctica)
Lista de cotejo

5. Evaluación de la unidad
Inicio
Desarrollo
Cierre
Evaluación
diagnóstica
Evaluación
formativa
Evaluación
sumativa
Tormenta
de ideas
Discusión
socializada
Lista preliminar
requisitos
Mapa
conceptual
Caso de
estudio
Prueba práctica
Registro
Anecdótico
Registro
Anecdótico
Cuestionario
online
Presencial
Evaluación
formativa
Coevaluación
Lista de cotejo
Autoevaluación

6. Desarrollo de la
clase

7. Ingeniería de
Requisitos
Prof. Thamara Hernández
Ingeniería del Software II

8. Contenido
Definiciones de Requisitos
Ingeniería
de
Requisitos
Propiedades de los Requisitos
Tipos de Requisitos
Funcionales y no Funcionales

9. ¿Qué es un requisito?
 Partiendo de la experiencia previa en las unidades
curriculares Ingeniería del software I y Proyecto
sociotecnológico II, por medio de una tormenta de ideas
deduzcamos:
Link a software FreeMind para construir mapa conceptual

10. Definición de Requisito
Perspectiva
del usuario
Una condición o capacidad (del
sistema) que necesita un usuario
para resolver un problema o alcanzar
un objetivo
Definir, organizar, supervisar,
documentar y comunicar los
procesos técnicos de pruebas de
software
Según, IEEE (1990)
Perspectiva del
Desarrollador

11. Otras definiciones…
“Es una propiedad que debe exhibir [cumplir o satisfacer]
un sistema desarrollado o adaptado para resolver un
problema particular “ [Sawyer y Kotonya, 2001]
“ Los requisitos expresan qué se supone debe hacer
una aplicación …no intentan expresar cómo lograr
estas funciones” [Braude, 2003]
Los requisitos expresan lo que una aplicación o
sistema debe hacer para satisfacer las necesidades
de sus clientes o usuarios.

12. Propiedades de los Requisitos
 Cada requisito debe expresarse de forma sencilla, clara y sin
ambigüedades, usando:
 lenguaje natural (español)
 lenguaje gráfico (Ej. UML)
 lenguaje formal (Ej. Notación Z).
 Debe expresarse preferiblemente de manera cuantitativa
 Uso de métricas que faciliten la verificación
 Debe identificarse de manera única e inequívoca
 Uso de sistema de numeración para facilitar su búsqueda y
manejo
 Debe ser correcto
 Deben describir con precisión la funcionalidad que especifica
 Debe estar validado por el cliente

13. Propiedades de los Requisitos
 Los requisitos deben ser consistentes entre sí
 No debe haber conflictos o incompatibilidad entre requisitos
 Deben ser completos
 Deben describir toda la funcionalidad que el sistema deberá
implementar
 Cada requisito debe ser factible
 Realista o alcanzable
 Debe describir algo que el cliente o usuario necesita
 Debe ser verificable
 Se le puede hacer un seguimiento a través de todo el desarrollo del
sistema.

14. Tipos de Requisitos
REQUISITOS FUNCIONALES
• Establecen:
• Los objetivos del negocio con
respecto al sistema
• Los servicios que el sistema debe
proporcionar al negocio
• Determinan la funcionalidad del
sistema
• Describen lo que el sistema
deberá hacer, esto es:
• Su comportamiento
• Su interacción con los usuarios y su
dominio de aplicación (negocio)
• Sus respuestas a eventos
REQUISITOS NO FUNCIONALES
• No están relacionados con la
funcionalidad o comportamiento
del sistema
• Restringen el diseño del sistema
(la solución)
• Describen:
• Las restricciones que se le imponen
al sistema
• Las cualidades o atributos de
calidad que el sistema debe
satisfacer
• Las reglas del negocio que el
sistema debe respetar o
implementar
• Las interfaces con otros sistemas

15. Caso de Estudio: Un sistema de comercio electrónico
para mapas digitales en línea(mismapas.com)
MAP, C.A. es una empresa
especializada en sistemas de
información geográfica (GIS) con
más de 20 años en el mercado
Su junta directiva decidió
cambiar su modelo de
negocios tradicional por
uno basado en comercio
electrónico:
•Para ello contrató el
desarrollo de la
aplicación web:
mimapa.com
MAP, C.A. ha creado
una de las
Text
mapotecas digitales
más completas de
Latinoamérica
Su modo de operación ha
sido mediante catálogos
impresos enviados a un
grupo selecto de clientes
ubicados en
Latinoamérica:
•Los pedidos se
hacían vía correo
electrónico y los
productos eran
despechados por
correo a sus clientes

16. Identifiquemos requisitos
 Una vez presentado el caso de estudio, identifiquemos
algunos requisitos

17. Mimapa.com: Ejemplo de requisitos
 mismapas.com es una aplicación
web que comercializa mapas
digitales de y desde cualquier
parte del mundo
 La aplicación debe permitir a sus
usuarios:
 Hojear el catálogo de mapas
digitales disponibles
 Buscar un mapa de acuerdo a
diferentes criterios
 Visualizar un mapa
 Comprar un mapa digital
 Recibir información sobre los
mapas de preferencia de cada
usuario

18. Clasificación de los Requisitos
[Wiegers, 2003]
Requisito
Funcional
Requisito del
Negocio
Requisito del
Usuario
Requisito del
Sistema
Requisito de
Comportamiento
Requisito
Restricción
Requisito No
Funcional
Atributo de
Calidad
Requisito de
Interface
Regla del
Negocio

19. Requisitos Funcionales
Requisitos del Negocio
 Se expresan desde la perspectiva de la empresa:
• Describen porque la empresa o el cliente desea desarrollar el
sistema
• Expresan que objetivos, metas o necesidades la empresa espera
alcanzar con el uso del sistema
 Ejemplos:
• La empresa MAP C.A. quiere abrir su mercado a cualquier usuario
interesado en la adquisición de mapas digitales
• La aplicación mismapas.com deberá contribuir a abrir el mercado de
MAP e incrementar el volumen de ventas anuales de mapas de la
empresa

20. Requisitos Funcionales
Requisitos del Usuario
 Se expresan desde la perspectiva del usuario:
• Describen las necesidades que los usuarios tienen y las tareas que
los usuarios realizarán con el sistema o aplicación
• Expresan lo que el usuario será capaz de hacer con el sistema
 Se modelan mediante casos de uso
 Ejemplos:
• Hojear la mapoteca digital
• Visualizar un mapa
• Comprar un mapa

21. Requisitos Funcionales
Requisitos del Sistema
 Son requisitos de alto nivel para productos que tienen
componentes de hardware y software
 Se expresan desde la perspectiva del sistema H/S que
contiene la aplicación
• Asumen que la aplicación es parte de un sistema mayor
 Ejemplos:
• En mismapas.com debe tomarse en cuenta configuraciones de
hardware que permitan visualizar los mapas en alta definición
• El sistema de información de cuentas corrientes debe enviar un
mensaje electrónico a sus usuarios cada vez que el saldo de la
cuenta este sobregirado.

22. Requisitos Funcionales
Requisitos de comportamiento
 Se expresan desde la perspectiva del desarrollador:
• Describen los servicios que el sistema presta a todos sus usuarios
directos
• Expresan que hace el sistema bajo ciertos estímulos o eventos
 Ejemplos:
• El sistema debe permitirle al usuario visualizar el mapa seleccionado
por el usuario de aquellos contenidos en el catálogo de mapas
• El sistema debe permitir que el cliente efectúe el pago de su pedido
en línea usando tarjetas de crédito o un sistema de pagos en línea

23. Requisitos No Funcionales
Restricciones
 Expresan las limitaciones que se le imponen al desarrollo
del sistema
 Describen aspectos tales como:
•
•
•
•
Plataforma de desarrollo y operación
Uso de estándares, prácticas, métodos de desarrollo, herramientas
Tiempo máximo de desarrollo
Costo máximo del proyecto
 Ejemplos:
• mismapas.com es una aplicación web que debe ser desarrollada:
– Bajo una plataforma LAMP
– En un tiempo no mayor a 6 meses
– Con costo no superior a los $100.000

24. Requisitos No Funcionales
Atributos de calidad
 Expresan las cualidades o propiedades de calidad que el
sistema debe satisfacer
 Estos requisitos describen, entre otros:
• El rendimiento que la aplicación debe mostrar
• La confiabilidad que debe poseer
• La seguridad que debe proveer
 Ejemplos:
• mismapas.com debe tener una confiabilidad igual o mayor al 95%
• mismapas.com debe ser fácil de usar:
– En promedio, un mínimo de 4 puntos en una escala de 5.

25. Requisitos No Funcionales
Algunos atributos de calidad:
 Requisitos de rendimiento:
• Especifican qué tan bien o tan rápido debe el sistema ejecutar una
función dada en términos de:
–
–
–
–
Velocidad (tiempo promedio de acceso a datos)
Volumen de transacciones por minutos
Capacidad ( carga de uso concurrente)
Tiempo (demanda de tiempo real)
 Requisitos de confiabilidad:
• Expresan la probabilidad de que el sistema se ejecute sin fallar
durante un determinado periodo de tiempo
– % de fallas permitidas por unidad de tiempo
 Requisitos de disponibilidad:
• % de tiempo que la aplicación debe estar disponible a sus usuarios
por unidad de tiempo

26. Requisitos No Funcionales
Requisitos de Interfaz
 Expresan las características de la interacción usuariosistema o sistema-sistema
 Se dividen en :
• Requisitos de Interfaz Gráfica (GUI):
– Describen las propiedades generales de interfaz gráfica que permitirá la
interacción entre el usuario y la aplicación
– Ejemplo: la interfaz de mimapa.com debe ser implementada usando
tecnología Web
• Requisitos de interfaces con otros sistemas
– Describen con que o cómo la aplicación interactuará con otras
aplicaciones de software o sistemas de hardware
– Ejemplo: mismapas.com debe interactuar con el sistema de pagos en
línea paypal

27. Requisitos No Funcionales
Reglas del negocio:
 Expresan todas aquellas regulaciones que la aplicación
debe acatar
 Estas regulaciones incluyen:
• Regulaciones gubernamentales: Leyes, decretos, providencias
• Regulaciones de la empresa: Políticas, normas, procedimientos
• Regulaciones propias de la aplicación: Estándares, mejores
prácticas que deben seguirse durante el desarrollo de la aplicación
 Ejemplos:
• mimapa.com debe elaborarse siguiendo el método MERINDE
adoptado por la empresa.
• Un cliente puede descargar gratuitamente las actualizaciones de un
mapa adquirido durante los 12 primeros meses a partir de la fecha
de compra

28. Práctica en equipo
 De acuerdo al diagnóstico participativo realizado en
Proyecto Sociotecnológico, elaborar una lista preliminar
de requisitos y clasificarlos adecuadamente.
 Tiempo: 30 minutos.
 Realizar actividad formativa en la plataforma moodle de
la institución, en el curso correspondiente, la cual
consiste en un cuestionario sobre el contenido
desarrollado en clase y con los recursos adicionales del
curso.

29. Próxima clase…