TEMA 4: ANÁLISIS DE REQUISITOS

1.- Requisitos
Han sido definidos por IEEE como:

• Condición/capacidad requerida para resolver un problema o alcanzar un objetivo.

• Condición/capacidad que debe poseer un sistema o una componente de un sistema para satisfacer
un contrato, estándar, una especificación u otro documento formal.
• Representación documentada de una condición o capacidad como en 1 o 2.

La Ingeniería de Requisitos ha sido definida por Boehm como:

La disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como
base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que
realizará el sistema.

Cuando estamos al frente de un proyecto es importante hay que dejar claramente definidos los requisitos
del software, de forma consistente y compacta.

Tarea difícil: traducir ideas vagas del software en funciones y restricciones.

2.- La Entrevista.
Las ENTREVISTAS sirven para:

▪ Conocer, clarificar, o limitar el problema a resolver.

▪ Identificar a los actores involucrados.
▪ Construir la confianza cliente-desarrollador.
▪ Establecer los requisitos del sistema sin ambigüedades.
▪ Validar el trabajo ya hecho.
▪ Dar visibilidad al trabajo realizado.
▪ Las entrevistas son el primer paso, en el desarrollo de un proyecto de software.
2.1.- Perfiles del cliente
2.2.- Cinco pasos para preparar una entrevista
 2.3.- Como colocar las preguntas en una secuencia lógica

2.- TFEA (Técnica para Facilitar la Especificación de Aplicaciones).

Primero hay una reunión cliente/equipo como primera toma de contacto.

Es aconsejable evitar cualquier tipo de grabación de la conversación, ya que generalmente suele provocar
desconfianza. Se formulan cuestiones generales del proyecto sin entrar en detalles de implementación del
mismo (salvo en caso necesario). La reunión no debería ser muy extensa, procurando que ésta sea amena y
generando la confianza de nuestros clientes.

Finalizada la primera reunión, cada ingeniero elabora una

especificación preliminar individual, que resume (a modo de
acta) la reunión. Estos informes son facilitados al Jefe de
Proyectos, que se encarga posteriormente de unificarlos
generando una única especificación. Esta especificación se
distribuye luego entre el equipo de ingenieros del proyecto.

Cada miembro del equipo de ingenieros analiza por separado la especificación, estudiando sus
características, puntos oscuros, incongruencias, aportes, dudas, ….
Pasado el plazo establecido para el estudio individual de la especificación, el Jefe de Proyectos reúne al
equipo para debatir las características del proyecto y los diversos puntos de vista.

En la reunión se detectan los posibles procesos para el desarrollo del proyecto, posibles recursos que puede
consumir, tipo de desarrollo (metodología), los posibles perfiles para entrevistar, etc.

Para el transcurso de la reunión se suele hacer uso de proyectores, pizarras, y diverso material preparado. El
objetivo de la reunión es elaborar los cuestionarios (uno para cada perfil de usuario/cliente).
 TEMA 5: EVALUACIÓN DEL SISTEMA. ESTUDIO DE VIABILIDAD.

1.- ¿Cómo se inicia un proyecto?

La idea de un proyecto puede partir de:

➢ El software ha quedado desfasado.

➢ Petición de un nuevo software en la empresa.
➢ Incorporación de nuevos módulos al software que ya está funcionando.

Todos los proyectos son realizables con recursos ilimitados y un tiempo infinito. Como esto no es real, antes
de pasar a desarrollar un proyecto, debe evaluarse su viabilidad: Posibilidad de realización con unos recursos
y un tiempo adecuados y disponibles.

Un proyecto siempre tiene como objetivo un beneficio (económico o no).

1.1.- Recursos que intervienen en el desarrollo de un proyecto software

Cada recurso queda especificado con:

➢ Descripción del recurso.
➢ Informes de disponibilidad.
➢ Fecha cronológica en la que se requiere el recurso.
➢ Tiempo durante el que será aplicado el recurso.

1.1.1.- Recursos Humanos

Para cada persona hay que identificar su posición en la organización (Nivel de toma de
responsabilidad) y su especialidad (Conocimientos y experiencia). Tipos:
• Responsables (Directores de Proyectos): Se dedican a la organización y planificación
• Técnicos senior (Analistas): Análisis, Visión global/abstracta
• Técnicos junior (Programadores): Programación/Diseño detallado
• Colaboradores (Representantes de los usuarios):Fuente de datos, Evaluación
 1.1.2.- Componentes Software Reutilizables

La ingeniería del software basada en componentes destaca la reutilización: creación y reutilización

de componentes. En planificación tenemos cuatro tipos de componentes:
• Ya desarrolladas, componente validado, listo para utilizarse.
• Ya experimentadas, componentes similares a los requeridos.
• Con experiencia parcial, requieren una modificación sustancial.
• Nuevas, componentes a construir.

1.1.3.- Herramientas Hardware/Software

Entorno: donde se apoya el proyecto software, incorpora hardware y software.

• Determinar la ventana temporal requerida para el hardware y el software.

• Constatar que no hay problemas con el software de desarrollo.
• Planificar el acceso al hardware o recursos específicos.

2.- Estudio y evaluación de situaciones.

2.1.- Estudio de alternativas (EVS4)

Lo primero que necesitamos es una vez estudiado el problema, tanto situación actual como las
necesidades de la empresa, habrá que proponer alternativas para solucionar el problema.

2.2.- Valoración de las alternativas (EVS5)

Un estudio de viabilidad es un estudio corto y orientado a resolver preguntas (objetivos, problemas,

integración, realizable,…), garantiza que el proyecto es factible y la mejor solución.

Un estudio de viabilidad es un estudio corto y orientado a confirmar el valor real del sistema, es decir, si
contribuye a los objetivos generales, si resuelve problemas con los procesos actuales, si se puede
integrar en otros sistemas de la empresa, si se puede implementar en plazo y coste, etc…
El objetivo del estudio de Viabilidad del Sistema es el análisis de un conjunto concreto de necesidades
para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas,
legales y operativas.

Los recursos se analizan desde la perspectiva de cuatro áreas de viabilidad:

• Económico: Determinar si el beneficio compensa los costes.
• Técnico: Estudio de la funcionalidad, rendimiento y restricciones
• Legal: Determinar si los requisitos violan o atentan ante alguna ley o reglamento.
• Operativo o Social: Grado de aceptación de los posibles usuarios.

2.3.- Viabilidad económica

Análisis de Coste/Beneficio: Proporciona una medida de los costes de la realización de un proyecto y

compararlos con los beneficios esperados de dicho proyecto. Conceptos:

• Punto de amortización (Break-Even Point): momento en que los beneficios obtenidos igualan a
los costes. A partir de este punto, el sistema da beneficios netos.
• Periodo de amortización (PayBack): periodo que transcurre desde que los costes son máximos
hasta que se alcanza el punto de amortización, en cuanto el sistema empieza a aportar
beneficios. Cuanto menor sea, más atractivo será para la organización.
• Retorno de la Inversión, ROI (Return of Investment): Rendimiento de la inversión expresada en
términos de porcentaje.

2.3.1.- Beneficios

Tangibles, se miden en términos de ahorro, o ganancias de la empresa.

➢ Ahorro en recursos humanos por reducción de personal, o evitar nuevas contrataciones.
➢ Reducir costes de mala calidad, errores, repetición de trabajos, etc.
➢ Reducir o evitar otros recursos.

Intangibles o difícilmente cuantificables:

➢ Mejora de competitividad.
➢ Mayor satisfacción de empleados.
➢ Mayor satisfacción del cliente.
 2.3.2.- Costes

- Adquisición de hardware y software: El que sea preciso para el desarrollo, implantación y

normal funcionamiento del sistema. Se debe considerar la saturación de máquinas o
sistemas actuales como consecuencia de la entrada en vigor del nuevo sistema.
- Gastos de mantenimiento de hardware y software anteriores.
- Gastos de comunicaciones: Líneas, teléfono, correo, etc.
- Gastos de instalación: Cableado, recursos humanos y materiales, gastos de viaje, etc.
- Coste de desarrollo del sistema y su mantenimiento (anual).
- Gastos de consultoría: En caso de requerirse algún consultor externo.
- Gastos de formación: De todo tipo (Desarrolladores, Operadores, Usuario Final, etc.).
- Gastos de material: Papel, tóner, etc.
- Costes derivados de la curva de aprendizaje: De todo el personal involucrado:
Desarrolladores, Técnicos de Sistemas, Operadores, y desde luego, Usuarios.
- Costes financieros, de publicidad, etc.

2.4.- Viabilidad técnica

Es el factor más difícil para el analista, ya que los objetivos, funciones y rendimientos son difusos y casi
todo puede parecer correcto. Aspectos a tener en cuenta:

- Riesgo de desarrollo: Comprobar si los elementos del sistema que han de desarrollarse se pueden
construir de forma que se cumplan las funciones y rendimientos dentro de las restricciones del análisis.

- Disponibilidad de recursos humanos: ¿Suficiente nº de personas, con cualificación adecuada?

- Disponibilidad de recursos informáticos: ¿Tenemos los recursos hardware y software necesarios?

- Tecnología actual:¿Qué tecnologías se requieren para conseguirlos requisitos? ¿Qué nuevos

métodos/algoritmos/técnicas son necesarios? ¿Cuál es el riesgo?

2.5.- Viabilidad legal

Suele ser el factor más desconocido por el analista de sistemas. Respetar la normativa legal.
• Específica de la TI.
• Comercial y general.

Normativa específica:
• Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantías de los
derechos digitales, LOPD-GDD.
• Propiedad intelectual (RDL 1/1996): software, imágenes o dibujos, contenidos, etc.
• Ley de Servicios de la Sociedad de la Información y el Correo Electrónico.
2.6.- Viabilidad operativa o social

Cada vez más importante. “Usuarios” en contra pueden pasar por alto e incluso sabotear el
sistema si no les gusta. Sistema apropiado para entorno de trabajo. Ejemplos:

➢ ¿Existe apoyo suficiente para el proyecto por parte de la dirección? ¿Y de los usuarios?
➢ ¿Los métodos actuales son aceptados por los usuarios?
➢ ¿Los usuarios han participado en la planificación y desarrollo del proyecto?
➢ El sistema propuesto, ¿causa algún perjuicio? ¿Se perderá el control en algún área?

2.7.- Evaluación de Alternativas y Selección de la Solución

Se pueden evaluar soluciones alternativas con ayuda de cuatro criterios: económico, técnico, legal y
social. ¿Cómo escoger la mejor solución? NO ES FÁCIL

➢ A menudo las cuestiones económicas y operativas están en conflicto.

➢ La decisión final se tomará optando por la mejor alternativa global.
➢ Existen algunos criterios comparativos aplicables a la evaluación de las diferentes
configuraciones alternativas al sistema, que sirven para justificar la asignación adoptada.

2.8.- Criterios comparativos para la selección de la solución

1. Consideraciones de negocio:
➢ ¿Representa la configuración la solución más ventajosa?
➢ ¿Puede ponerse en el mercado con éxito?
➢ ¿Justificarán los beneficios el riesgo de desarrollo?

2. Análisis técnico:
➢ ¿Existe la tecnología para desarrollar todos los elementos del sistema?
➢ ¿Están garantizados el funcionamiento y rendimiento?
➢ ¿Se puede mantener adecuadamente la configuración?
➢ ¿Existen recursos técnicos?
➢ ¿Cuál es el riesgo asociado con la tecnología?

3. Evaluación de fabricación:
➢ ¿Tenemos disponibles instalaciones y equipos de fabricación?
➢ ¿Hay alguna escasez de componentes necesarios?
➢ ¿Se puede llevar a cabo adecuadamente la garantía de calidad?

4. Aspectos humanos:
➢ ¿Tenemos disponible personal entrenado para el desarrollo y fabricación?
➢ ¿Existen problemas políticos?
➢ ¿Entiende el cliente qué es lo que debe hacer el sistema?
 5. Interfaces del entorno:
➢ ¿Tiene la configuración propuesta una interfaz apropiada con el entorno exterior del
sistema?
➢ ¿Se maneja de manera inteligente la comunicación entre máquinas y entre humanos y
máquinas?

6. Consideraciones legales:
➢ ¿Introduce esta configuración un riesgo indebido de obligaciones legales?
➢ ¿Se pueden proteger adecuadamente los aspectos de la propiedad?
➢ ¿Hay alguna posibilidad de infracción?

2.9.- Informe o Estudio de viabilidad

Es la conclusión del estudio de viabilidad. Distribución:

• Puede ser un documento propio del análisis de sistemas, se distribuye dentro del equipo.
• Puede ofrecérsele al cliente, para que considere las distintas alternativas adecuadamente y
tome ciertas decisiones.
• Puede ser un documento que se incluya en el documento final del análisis de sistemas
“Especificación del sistema”, bien inmerso, o bien como apéndice.

Objetivo: Tomar la decisión (Continuar / Abandonar).

3.- Acta de Constitución del Proyecto.

El Acta de Constitución del Proyecto es el documento que autoriza formalmente un proyecto.
• Confiere al director del proyecto la autoridad para asignar recursos de la organización a las
actividades del proyecto.
• El director del proyecto ha de ser nombrado cuanto antes, antes de la planificación y,
preferentemente, mientras se desarrolla el acta de constitución del proyecto.

En algunas organizaciones, un proyecto no se inicia hasta haber completado:

➢ En Una evaluación de necesidades.

➢ Un estudio de viabilidad.
➢ Un plan preliminar o forma equivalente de análisis

El Acta de Constitución es un documento que debe ser emitido al inicio de cualquier proyecto, esta no
representa un contrato como tal, solamente es una clarificación de los alcances y restricciones que se
tendrán además de especificar los niveles jerárquicos principales del proyecto.
o Es un documento, firmado por el patrocinador, que autoriza formalmente el inicio de un proyecto (o
fase ) nombrando al PM y su nivel de autoridad.
o Recoge los requisitos iniciales que satisfacen las necesidades y expectativas de los interesados.
o Se incorpora información de alto nivel.
o Permite, una vez aprobada, comenzar la planificación.
o Contenido general: dirección y autoridades, coste, tiempo, riesgos, requisitos de aprobación, entre otros.
o Establece una relación de cooperación entre la organización solicitante y la ejecutora.