Identificación de Requerimientos funcionales

Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de
la manera en que éste reaccionará a entradas particulares. En algunos casos, los
requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema
no debe hacer.

Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la

especificación de requerimientos. Para un desarrollador de sistemas es natural dar
interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin
embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos
requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e
incrementando el costo.

En principio, la especificación de requerimientos funcionales de un sistema debe estar

completa y ser consistente. La compleción significa que todos los servicios solicitados por el
usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones
contradictorias.

En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de

consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente
del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades
inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por
primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se
hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se
deben corregir en el documento de requerimientos.

La frase anterior resume la importancia de la etapa de análisis dentro del proceso

de solución de problemas. Si no entendemos bien el problema que queremos
resolver, el riesgo de perder nuestro tiempo es muy alto

Problema en
requisitos

Cualquier circunstancia que afecta negativamente a los requisitos del sistema y que debe ser resuelta para
evitar problemas posteriores en el desarrollo. Los tipos de problemas más habituales en los requisitos son los
defectos y las no aceptaciones:

 Defecto: uno o más requisitos no son conformes al modelo de calidadde requisitos de MADEJA. Se pueden
clasificar en:
o No conformidad: uno o más requisitos no cumplen las especificaciones descritas en MADEJA sobre el
contenido, estructura, formato, etc. de la ERS. Los defectos de este tipo se detectan durante la verificación de
Definición la calidad de los requisitos del sistema y no suele ser necesario conocer el dominio del problema para
detectarlos, ya que son de un carácter más sintáctico que semántico.
o Falta de información: uno o más requisitos necesitan más información para definir correctamente alguna
característica del sistema. Los defectos de este tipo se detectan principalmente durante el análisis de requisitos
del sistema.
o Conflicto: dos o más requisitos contienen información contradictoria entre sí.Los defectos de este tipo se
detectan principalmente durante el análisis de requisitos del sistema
 No aceptación: uno o más requisitos no son aceptados por clientes y usuarios durante una sesión
de validación de requisitos.
Ejemplo

Sistema de seguimiento de problemas

 Sistema de seguimiento de problemas

También denominado sistema de seguimiento de errores (Bug Tracking System en inglés) es una
aplicación informática para registrar y gestionar la evolución de los problemas que surgen durante el
Definición desarrollo de software. Inicialmente concebidos para gestionar los errores en el código fuente,
actualmente se usan también para gestionar otros tipos problemas, incluso como sistemas de
seguimiento de incidencias.