INSTITUTO TECNOLÓGICO EN INFORMÁTICA Y COMERCIO DE

BUENAVENTURA
INCOMEB

GUIA DE CLASE

GUIA # 2
Nombre docente: Yonathan Obregón Pérez
GRADO: Once

FECHA: 1 de marzo 2021 PERIODO: 1

AREA/ ASIGNATURA: Informática

TEMA: Requerimientos funcionales y no funcionales de un sistema
OBJETIVO DE APRENDIZAJE:

 Realiza requerimientos funcionales y no funcionales de un sistema

 Reconoce la diferencia entre requerimientos y roles
PREGUNTA PROBLEMATIZADORA TIPO ICFE:
¿Cuál de estos no es un requerimiento funcional?
1. El sistema deberá permitir el ingreso de usuario por medio del login
2. El sistema deberá permitir guardar la información de cada usuario
3. El sistema deberá comunicarse con otros usuarios por medio de la plataforma
4. El sistema deberá mostrar una interfaz amigable para el usuario
ACTIVIDADES A DESARROLLAR:
REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES DE UN SISTEMA
El desarrollo de software es una de esas actividades donde tenemos nombres y categorías
para todo. Y me refiero a todo. A veces eso es redundante e inútil, pero a veces hay
conceptos que son muy buenos para conocer y diferenciar. Un ejemplo de ello es la
diferencia entre requisitos funcionales (RF) y no funcionales (RNF). Y dado que los
requisitos del sistema de software se clasifican (entre otras cosas) de esta manera, se
deben considerar las siguientes técnicas para una correcta identificación.
Requerimientos Funcionales
Los requisitos funcionales son declaraciones de los servicios que prestará el sistema, en la
forma en que reaccionará a determinados insumos. Cuando hablamos de las entradas, no
necesariamente hablamos sólo de las entradas de los usuarios. Pueden ser interacciones
con otros sistemas, respuestas automáticas, procesos predefinidos. En algunos casos, los
 INSTITUTO TECNOLÓGICO EN INFORMÁTICA Y COMERCIO DE
BUENAVENTURA
INCOMEB

GUIA DE CLASE

requisitos funcionales de los sistemas también establecen explícitamente lo que el sistema

no debe hacer. Es importante recordar esto: un RF puede ser también una declaración
negativa. Siempre y cuando el resultado de su comportamiento sea una respuesta
funcional al usuario o a otro sistema, es correcto. Y más aún, no sólo es correcto, sino que
es necesario definirlo. Y eso nos lleva al siguiente punto.
Muchos de los problemas en la ingeniería de software (hablando sobre el proceso de
desarrollo en sí mismo) comienzan con especificaciones de requisitos inexactas. Es natural
que un Analista de Negocio (o quien sea que esté definiendo y documentando los
requerimientos del sistema) tome algunas suposiciones como conocimiento universal, o
dé por sentado algún comportamiento. Pero recuerde, también es natural que un
desarrollador de sistemas interprete un requisito ambiguo de la manera más simple
posible, para simplificar su implementación.
Stakeholders

Un stakeholder es cualquier persona (empleado, socio, cliente, etc.) o empresa que de alguna
forma afecta o puede ser afectada por las acciones de una organización con respecto a un
proyecto. La gestión de las partes interesadas (Stakeholder management) es fundamental para
establecer estrategias de comunicación y determinar influencias.

Este concepto fue creado por el filósofo estadounidense Robert Edward Freeman, quien sostenía
en su teoría que el triunfo o fracaso de cualquier organización afectará no solo a sus dueños, sino
también a todos los que la rodean. Eso incluye a los trabajadores, socios, competidores, familias
de los involucrados y clientes.

Requerimientos Funcionales

Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de

software, un requisito que sabe bien y especifica criterios que pueden usarse para juzgar la
operación de un sistema en lugar de sus comportamientos específicos, ya que estos corresponden
a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que no describen
información a guardar, ni funciones a realizar, sino características de funcionamiento, por eso
suelen denominarse Atributos de calidad de un sistema. Queda entonces el requisito no funcional,
que son las restricciones o condiciones que impone el cliente al programa que necesita, por
ejemplo el tiempo de entrega del programa, el lenguaje o la cantidad de usuarios.

Actividad

Realiza los requerimientos funcionales y no funcionales de acuerdo a tu proyecto.