Análisis de requisitos y estudio de
viabilidad
1º DAI. IES Azarquiel.
1. Introducción
Todo proyecto tiene un punto de partida



Análisis de las necesidades cliente/usuario del sistema.
Establecer objetivos.
Una vez obtenida una idea clara de los objetivos que se
desean conseguir, se debe evaluar la viabilidad del
proyecto desde el punto de vista técnico, económico y
legal.
Técnicas de recogida de información para análisis de
necesidades y estudio de requisitos.


2
2. Cómo comienza un proyecto
Para cada proyecto de desarrollo software existen dos
puntos de partida:



A nivel de Empresa.
A nivel de Proyecto.
El primero precede al segundo.

3
4
Inicio a nivel de empresa
Los principales elementos que marcan el inicio de un
proyecto a nivel de empresa son:


La decisión de emprender el proyecto.

Desarrollos internos (demanda interna). RFS, Request For Service:








5
Indentificación
Nombre
Prioridad
Plazo de terminación
Breve descripción
Fecha de recepción
Desarrollos contratados (demanda de un cliente).
La selección del director o jefe del proyecto, que es el
responsable de establecer el entorno de inicio del
proyecto.
Estudio de viabilidad
Antes de comenzar un proyecto se realizará un estudio
de viabilidad. Recogerá:
1. Análisis de alternativas
2. Evaluación de cada una de las alternativas, incluyendo su
viabilidad técnica, legal, operativa, etc.
3. Especificación detallada de la alternativa escogida.
4. Establecimiento de fechas y compromisos de trabajo
por parte de las personas y departamentos implicados.
Se llevará a cabo el PLAN DEL PROYECTO

Análisis de alternativas




Comprar un producto SW comercial ya construido que
cumpla los requisitos marcados.
Desarrollar el producto internamente.
Desarrollar el producto externamente mediante un
contrato.
Automatizar sólo parcialmente el sistema para no tener
que afrontar grandes gastos.
Selección del Jefe de proyecto









Liderazgo  sabe motivar.
Capacidad de relación  con equipo, clientes,…
Visión de negocio  conocimiento, negociación.
Compresión técnica  decisiones técnicas.
Competencia en la gestión  planificar y controlar.
Presteza y decisión  capacidad analítica.
Versatilidad y flexibilidad  imprevistos, anticipación
Integridad  reclutar personal adecuado.
Previsión  anticipación y aporte de soluciones.
Inicio a nivel de proyecto
El Jefe de proyecto debería establecer el entorno inicial
de trabajo del proyecto (incluso antes de verificarse la
viabilidad).
Esta tarea incluye:











9
Identificación de las áreas de riesgo
Establecimiento de presupuestos
Calendarios
Planes de trabajo del personal
Asignaciones de tareas
Definir el soporte necesario para el equipo del proyecto
Definir las técnicas de comunicación
Requisitos de posibles subcontratas
Interacción con los clientes
Inicio a nivel de proyecto

Los resultados de estas actividades se incluyen en la 1ª
versión del Plan del Proyecto  da respuestas a:


10
Qué hay que hacer, cómo, quién lo hará, cuándo
Qué herramientas y técnicas de gestión y desarrollo se
utilizarán.
3. Estudios de viabilidad: económica,
técnica y legal …

Los estudios de viabilidad deberían abordar los siguientes
aspectos:





11
Económico: Determina si el beneficio obtenido compensa los
costes.
Técnico: Estudia si la funcionalidad, el rendimiento y las
restricciones marcadas son realizables.
Plazos y calendarios: ¿El plazo propuesto es realista? ¿Las fechas
elegidas son apropiadas?
Legal: Discutir si los requisitos atentan contra alguna ley (Ej
LOPD) o reglamento o a disposiciones legales de contratos,
responsabilidad civil.
Operativo: Determina si se puede implantar de manera
efectiva en la empresa. ¿Encaja en la filosofía de la empresa?
4. Análisis de necesidades. Técnicas de
comunicación y recopilación de datos.

Técnicas de recogida de información, pasos del proceso
de análisis:





12
Identificar fuentes de información.
Realizar preguntas apropiadas.
Analizar la información.
Confirmar con los usuarios.
Sintetizar los requisitos.
4. Análisis de necesidades. Técnicas de
comunicación y recopilación de datos.

Técnicas de recogida de información:







13
Entrevistas.
Desarrollo conjunto de aplicaciones (JAD).
Prototipado.
Observación.
Estudio de documentación.
Cuestionarios.
Tormenta de ideas (Brainstorming).
5. Ingeniería de requisitos





¿Qué es? el conjunto de tareas que conducen a
comprender qué es lo que el cliente quiere y cómo
interactuarán los usuarios finales con el software.
¿Quién lo hace? Los ingenieros de software, junto con
gerentes, clientes y usuarios.
¿Es importante? Construir un buen programa que
resuelve problemas incorrectos no sirve a nadie.
¿Qué pasos tiene? Inicio, obtención, elaboración,
negociación y validación.
¿Qué obtenemos? Explicación escrita del problema.
Tareas de la ingeniería de requisitos

Inicio.



Identificación de los interesados: los que se benefician del
sistema.
Reconocimiento de múltiples puntos de vista.
Formulación de las primeras preguntas:





¿Quién ha pedido el trabajo?
¿Quién usará el programa?
¿Existe otra fuente para la solución?
¿Algien más puede proporcionar información adicional?
…

Obtención.

Recopilación conjunta de requisitos.



Escenarios de usuario. Llamados frecuentemente casos de uso,
proporcionan una descripción de cómo se usará el sistema.
Posibles productos:








Reuniones más formales. Se utiliza un “mecanismo de definición”: hojas de trabajo,
gráficos, hojas adheribles, foro electrónico, etc.)
Enunciado de necesidad y factibilidad.
Enunciado limitado del ámbito del sistema o producto.
Lista de clientes, usuarios y otros interesados que participaron en la obtención de
requisitos.
Descripción del ambiente técnico del sistema.
Lista de requisitos (organizados por función) y las restricciones de d ominio.
Conjunto de escenarios de suo que proporcionen un discernimiento de la
utilización del sistema o producto en diferentes condiciones de operación.
Prototipos desarrollados para definir mejor los requisitos.
Cada uno de los productos los revisará la gente que ha participado en su
obtención.

Elaboración.

Desarrollo de casos de uso:



Identificar Actores.
Caso de uso: historia de alto nivel que describe la interacción entre
el actor y el sistema.
Se puede esfecificar de forma textual y/o gráfica:







Nombre.
Actores.
Meta en el contexto.
Condiciones previas.
Activador.
Escenario.
Excepciones.

Negociación.


El cliente y desarrollador entran en un proceso en el que se le
debe pedir al cliente un balance de la funcionalidad, el
rendimiento y otras caracteristicas del sistema frente al costo
y el tiempo de colocación en el mercado.
Especificación.

Puede ser un documento escrito, un conjunto de gráficos, un
modelo matemático formal, colección de escenarios de uso, un
prototipo o una combinación de éstos.

Validación.

Examina la especificación para asegurar que todos los
requisitos de software se han establecido de forma precisa.




Detectado inconsistencias, omisiones, errores.
Corregido.
Se siguen los estándares del proceso, proyecto o producto.
Gestión.

Tablas de rastreabilidad de características, fuente, dependencia,
subsistema o interfaz.
A01
R01
R02
…
A02
A03
…




Requisitos funcionales y no funcionales

Requisitos funcionales: describen la funcionalidad o los servicios que se espera
que el sistema proveerá, sus entradas y salidas, excepciones, etc.
Ejemplos:
1.- “El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos
o seleccionar un subconjunto de ella.”
2.- “El sistema deberá ofrecer un explorador (browser) para que el usuario lea documentos en
el almacén de documentos.”

Requisitos no funcionales: se refieren a las propiedades emergentes del sistema
como la fiabilidad, el tiempo de respuesta, la capacidad de almacenamiento, la
capacidad de los dispositivos de entrada/salida, y la representación de datos que se
utiliza en las interfaces del sistema.
Ejemplos:
1.- “Será necesario que la comunicación requerida entre el APSE y el usuario se pueda
expresar utilizando el conjunto de caracteres estándar de ADA.”
2.- “El proceso de desarrollo del sistema y los documentos a entregar estarán sujetos al
proceso y a los productos a entregar definidos en XYZCo-SP-STAN-95.”
3.- “El sistema no deberá revelar a sus operadores información personal alguna de los clientes
excepto su nombre y número de referencia.”
¿funcionales o no funcionales?









“Los participantes tendrán que ser mayores de edad”
“Los participantes tendrán que residir en la península”
“El valor de las pujas será mostrado en euros”
“El IVA aplicado a las pujas ganadoras será del 7%”
“La lista de resultados estará preparada para ser impresa
en un folio tamaño A4”
“El sistema lanzará una excepción en caso de que un
usuario quiera cargar un importe mayor que el saldo de la
cuenta”
“Los accesos a la BD deberán usar el estándar SQL-92”
“Los registros de la BD no deben ocupar más de 4 Kb”
“El sistema deberá ser capaz de interactuar con 100
usuarios concurrentes”
Descargar

analisis1daid.wikispaces.com