Tema específico

Tema 29. Estrategias de determinación de requerimientos: entrevistas, derivación de sistemas existentes, análisis y prototipos. La especificación de requisitos de software.

Estrategias de determinación de requerimientos: entrevistas, derivación de sistemas existentes, análisis y prototipos 🎯 Idea clave Las estrategias de determinación de requerimientos permiten identific…

AGE07 A2 03/07/2026

Gestion de Sistemas e Informatica eleva la rama tecnica de OPOAGE a un cuerpo A2 con un primer ejercicio de 100 preguntas tipo test.

Lectura pública del tema

1. Estrategias de determinación de requerimientos: entrevistas, derivación de sistemas existentes, análisis y prototipos

1. Estrategias de determinación de requerimientos: entrevistas, derivación de sistemas existentes, análisis y prototipos

🎯 Idea clave

  • Las estrategias de determinación de requerimientos permiten identificar las necesidades funcionales y no funcionales de un sistema de información.
  • Las entrevistas estructuradas son una técnica clave para recopilar información directamente de los stakeholders.
  • La derivación de sistemas existentes facilita la reutilización de requisitos ya validados en otros proyectos.
  • El análisis de documentación y procesos existentes ayuda a contextualizar los requisitos dentro del marco operativo de la Administración.
  • Los prototipos permiten validar requisitos de forma temprana con los usuarios finales.
  • La combinación de estas estrategias mejora la precisión y la alineación de los requisitos con los objetivos institucionales.

📚 Desarrollo

Entrevistas como técnica fundamental. Las entrevistas son una de las estrategias más utilizadas para la elicitación de requisitos en la Administración General del Estado. Se realizan de manera estructurada, con preguntas predefinidas que abordan tanto aspectos funcionales como no funcionales del sistema. Este enfoque garantiza que se recopile información relevante de los distintos actores involucrados, como usuarios finales, responsables de área y técnicos. La preparación previa de las entrevistas, incluyendo la selección de participantes y la definición de objetivos, es esencial para su eficacia.

Derivación de sistemas existentes. Esta estrategia consiste en extraer requisitos a partir de sistemas ya implementados, ya sea dentro de la propia Administración o en otras organizaciones. En el contexto de la AGE, se prioriza la reutilización de componentes y requisitos validados en proyectos anteriores, lo que reduce riesgos y acelera el desarrollo. La derivación es especialmente útil cuando se migran sistemas legacy o se integran soluciones del Catálogo de Servicios Comunes (CTT), ya que permite aprovechar experiencias previas y evitar redundancias.

Análisis de documentación y procesos. El análisis de documentos internos, normativas y procedimientos administrativos es una estrategia complementaria para identificar requisitos. En la AGE, este análisis incluye la revisión de manuales de usuario, normativas como la Ley 39/2015 o el Esquema Nacional de Interoperabilidad (ENI), y flujos de trabajo existentes. Esta técnica ayuda a contextualizar los requisitos dentro del marco legal y operativo de la Administración, asegurando que el sistema cumpla con los estándares y regulaciones vigentes.

Prototipado para validación temprana. Los prototipos son herramientas clave para validar requisitos con los usuarios finales antes de la implementación definitiva. En la AGE, se utilizan prototipos evolutivos o desechables, dependiendo de la complejidad del sistema. Los prototipos evolutivos se refinan progresivamente hasta convertirse en el producto final, mientras que los desechables se emplean para probar conceptos específicos y se descartan una vez cumplido su objetivo. Esta estrategia reduce la ambigüedad en los requisitos y mejora la satisfacción del usuario.

Integración de estrategias. La combinación de entrevistas, derivación, análisis y prototipado permite abordar la determinación de requisitos desde múltiples perspectivas. En la AGE, esta integración es fundamental para garantizar que los sistemas desarrollados sean funcionales, seguros y alineados con las necesidades institucionales. Cada estrategia aporta información valiosa que, al complementarse, reduce la probabilidad de errores y omisiones en la fase de especificación.

Normativas de referencia. Las estrategias de determinación de requisitos en la AGE se enmarcan en estándares como la norma IEEE 29148:2018 y IEEE 830-1998, que establecen buenas prácticas para la ingeniería de requisitos. Estos estándares guían la aplicación de técnicas como las entrevistas o el prototipado, asegurando que los procesos sean rigurosos y trazables. El cumplimiento de estas normativas es obligatorio en los proyectos de desarrollo de sistemas de la Administración.

Enfoque colaborativo. La participación activa de los stakeholders es un principio básico en la determinación de requisitos. En la AGE, se fomenta la colaboración entre técnicos, usuarios y responsables de área mediante técnicas como las sesiones JAD (Joint Application Development), donde se discuten y priorizan los requisitos de manera conjunta. Este enfoque mejora la comunicación y reduce los conflictos durante el desarrollo del sistema.

🧩 Elementos esenciales

  • Entrevistas estructuradas: Técnica para recopilar requisitos mediante preguntas predefinidas a stakeholders, garantizando información precisa y relevante.
  • Derivación de sistemas existentes: Estrategia que aprovecha requisitos ya validados en otros proyectos para reducir riesgos y acelerar el desarrollo.
  • Análisis de documentación: Revisión de manuales, normativas y procedimientos para contextualizar los requisitos dentro del marco legal y operativo.
  • Prototipado evolutivo: Prototipo que se refina progresivamente hasta convertirse en el sistema final, útil para validar requisitos complejos.
  • Prototipado desechable: Prototipo utilizado para probar conceptos específicos y descartado tras su uso, ideal para validaciones rápidas.
  • JAD (Joint Application Development): Sesiones colaborativas donde stakeholders discuten y priorizan requisitos, mejorando la comunicación y reduciendo conflictos.
  • Norma IEEE 29148:2018: Estándar que establece buenas prácticas para la ingeniería de requisitos, aplicable en la AGE.
  • Norma IEEE 830-1998: Guía para la especificación de requisitos de software, utilizada como referencia en proyectos de la Administración.
  • Reutilización de componentes: Práctica que aprovecha soluciones del Catálogo de Servicios Comunes (CTT) para optimizar recursos y garantizar interoperabilidad.
  • Validación temprana: Proceso de verificación de requisitos con usuarios finales antes de la implementación, reduciendo ambigüedades y errores.
  • Trazabilidad de requisitos: Capacidad para rastrear el origen y evolución de cada requisito, asegurando su alineación con los objetivos del proyecto.
  • Stakeholders: Actores clave involucrados en el proyecto, como usuarios, técnicos y responsables de área, cuya participación es esencial para la elicitación de requisitos.

🧠 Recuerda

  • Las entrevistas estructuradas son una herramienta clave para recopilar requisitos directamente de los stakeholders.
  • La derivación de sistemas existentes permite reutilizar requisitos ya validados, reduciendo riesgos y costes.
  • El análisis de documentación y procesos ayuda a contextualizar los requisitos dentro del marco legal y operativo de la AGE.
  • Los prototipos son esenciales para validar requisitos de forma temprana y reducir ambigüedades.
  • La combinación de estrategias mejora la precisión y la alineación de los requisitos con los objetivos institucionales.
  • Las normativas IEEE 29148:2018 y IEEE 830-1998 guían la aplicación de estas estrategias en la AGE.
  • La participación activa de los stakeholders es fundamental para el éxito en la determinación de requisitos.
  • Las sesiones JAD fomentan la colaboración y reducen conflictos durante el desarrollo del sistema.
  • La trazabilidad de requisitos asegura que cada requisito esté alineado con los objetivos del proyecto.
  • La reutilización de componentes del CTT optimiza recursos y garantiza la interoperabilidad en la AGE.

2. La especificación de requisitos de software

2. La especificación de requisitos de software

🎯 Idea clave

  • La especificación de requisitos de software es un documento formal que recoge las necesidades y condiciones que debe cumplir un sistema.
  • Su objetivo principal es servir como base para el diseño, desarrollo y validación del software en la Administración General del Estado.
  • Debe ser clara, precisa y libre de ambigüedades para evitar interpretaciones erróneas durante el ciclo de vida del proyecto.
  • Incluye tanto requisitos funcionales como no funcionales, garantizando que el sistema cumpla con los estándares técnicos y normativos.
  • La trazabilidad de los requisitos permite vincular cada necesidad con su origen y su implementación en el sistema.
  • Su validación es esencial para asegurar que el documento refleja correctamente las expectativas de los stakeholders.

📚 Desarrollo

Definición y alcance. La especificación de requisitos de software (SRS) es un documento estructurado que define las funcionalidades, restricciones y características que debe cumplir un sistema informático. En la Administración General del Estado, este documento se alinea con los principios de interoperabilidad, seguridad y reutilización establecidos en el Esquema Nacional de Interoperabilidad (ENI) y el Esquema Nacional de Seguridad (ENS).

Normativa aplicable. La elaboración de la SRS en la AGE se rige por estándares internacionales como IEEE 29148:2018 e IEEE 830-1998, que establecen directrices para la redacción, estructura y calidad de los requisitos. Estos estándares garantizan que el documento sea comprensible, verificable y modificable, adaptándose a las necesidades específicas de los proyectos públicos.

Estructura del documento. Una SRS típica incluye secciones como introducción, descripción general, requisitos funcionales, requisitos no funcionales y apéndices. Los requisitos funcionales detallan las acciones que el sistema debe realizar, mientras que los no funcionales abordan aspectos como rendimiento, seguridad, usabilidad y compatibilidad con otros sistemas. Esta estructura facilita la revisión y aprobación por parte de los distintos actores involucrados.

Requisitos funcionales. Estos describen las capacidades específicas del sistema, como la gestión de trámites electrónicos, la autenticación de usuarios o la integración con plataformas como Cl@ve. Deben ser medibles y verificables, evitando descripciones vagas que puedan generar confusión. Por ejemplo, un requisito funcional podría especificar que el sistema debe permitir la firma electrónica de documentos mediante certificados reconocidos.

Requisitos no funcionales. Abarcan aspectos técnicos y operativos que no están directamente relacionados con las funcionalidades, pero que son críticos para el éxito del sistema. Incluyen criterios de rendimiento, como tiempos de respuesta máximos, requisitos de seguridad, como el cifrado de datos sensibles, y requisitos de usabilidad, como la accesibilidad para personas con discapacidad. Estos requisitos aseguran que el sistema cumpla con los estándares de calidad y normativos de la AGE.

Trazabilidad y validación. La trazabilidad permite vincular cada requisito con su origen, ya sea una normativa, una entrevista con stakeholders o un prototipo. Esto facilita la gestión de cambios y la verificación de que todos los requisitos han sido implementados y validados correctamente. La validación, por su parte, implica revisar el documento con los usuarios finales y otros actores para confirmar que refleja sus necesidades y expectativas.

Herramientas y metodologías. En la AGE, se utilizan herramientas como JIRA o Confluence para gestionar y documentar los requisitos, así como metodologías ágiles que permiten iteraciones rápidas y feedback continuo. Estas herramientas facilitan la colaboración entre equipos técnicos y no técnicos, asegurando que la SRS sea un documento vivo y actualizado durante todo el ciclo de vida del proyecto.


🧩 Elementos esenciales

  • SRS (Software Requirements Specification): Documento formal que recoge los requisitos del sistema, estructurado según estándares como IEEE 29148:2018.
  • Requisitos funcionales: Describen las acciones y funcionalidades que el sistema debe realizar, como la gestión de trámites o la autenticación de usuarios.
  • Requisitos no funcionales: Incluyen aspectos técnicos como rendimiento, seguridad, usabilidad y compatibilidad, esenciales para cumplir con los estándares de la AGE.
  • Trazabilidad: Capacidad de vincular cada requisito con su origen y su implementación, facilitando la gestión de cambios y la validación.
  • Validación: Proceso de revisión con stakeholders para asegurar que la SRS refleja correctamente sus necesidades y expectativas.
  • Estándares IEEE: Normas como IEEE 29148:2018 e IEEE 830-1998 que guían la redacción y estructura de la SRS en la AGE.
  • Interoperabilidad: Principio clave en la AGE que garantiza que los sistemas puedan comunicarse y compartir datos de manera eficiente.
  • Seguridad: Requisito no funcional crítico que incluye aspectos como el cifrado de datos y la protección contra accesos no autorizados.
  • Usabilidad: Criterio que asegura que el sistema sea accesible y fácil de usar para todos los usuarios, incluyendo personas con discapacidad.
  • Herramientas de gestión: Plataformas como JIRA o Confluence utilizadas para documentar y gestionar los requisitos durante el ciclo de vida del proyecto.

🧠 Recuerda

  • La especificación de requisitos de software es un documento formal y estructurado que define las necesidades del sistema.
  • Debe ser clara, precisa y libre de ambigüedades para evitar interpretaciones erróneas.
  • Incluye tanto requisitos funcionales como no funcionales, alineados con los estándares de la AGE.
  • La trazabilidad permite vincular cada requisito con su origen y su implementación.
  • La validación es esencial para asegurar que el documento refleja las expectativas de los stakeholders.
  • Los estándares IEEE 29148:2018 e IEEE 830-1998 guían la redacción y estructura de la SRS.
  • Los requisitos no funcionales, como seguridad y rendimiento, son críticos para el éxito del sistema.
  • Herramientas como JIRA facilitan la gestión y colaboración en la elaboración de la SRS.
  • La SRS debe ser un documento vivo, actualizado durante todo el ciclo de vida del proyecto.
  • La interoperabilidad y la seguridad son principios clave en la AGE que deben reflejarse en la SRS.

Prueba la demo si quieres ver el resto

Has abierto una ruta pública de tema. La demo te deja ver cómo encajan temario, preguntas y simulacros dentro de OPOAGE.

Qué vas a probar

Una demo pensada para decidir con criterio

Formato real de estudio

Practica con preguntas justificadas y comprueba si la forma de preparar Gestion de Sistemas e Informatica del Estado encaja contigo.

Temario y simulacros

Verás cómo se integran el temario, las explicaciones y los simulacros dentro del mismo recorrido OPOAGE.

Acceso por correo

Con tu nombre, tu email y la categoría AGE, te enviamos el enlace para terminar el acceso demo.

Gratis Sin compromiso AGE01 a AGE08

Solicita ya tu acceso Demo

Sólo tu email, tu nombre y la categoría AGE. La demo es gratuita.

Acceso por email Rutas AGE activas Login real en mail.opoage.es

Si ya tienes cuenta, entra desde acceso o usa la recuperación de contraseña.

Las convocatorias y bases oficiales se consultan siempre en INAP y BOE.

Preguntas frecuentes

Preguntas clave sobre Gestion de Sistemas e Informatica del Estado y OPOAGE

¿Por que incluir GSI antes que otros cuerpos grandes?

Porque refuerza una rama ya abierta con TAI y mantiene el foco en cuerpos AGE de informatica.

¿Es igual que TAI?

No. TAI es C1 y GSI es A2, con mas profundidad tecnica y otro nivel de exigencia.

¿Encaja con test de cuatro respuestas?

Si. El estudio la incluye por su formato de cuestionarios con respuestas alternativas dentro de la convocatoria AGE.