Propuesta Económica Proyecto

ANÁLISIS FUNCIONAL OTXXXXXV00
TITULO OT - PROYECTO
Índice
Análisis Funcional OTXXXXXV00.
Título OT – Proyecto.
1.OBJETIVOS...................................................................................................................................................... 6
2.PROPUESTA SOLICITADA................................................................................................................................. 7
2.1 SITUACIÓN ACTUAL................................................................................................................................................7
2.2 VENTAJAS............................................................................................................................................................ 7
3.NUEVA SITUACIÓN.......................................................................................................................................... 8
4.INFRAESTRUCTURA......................................................................................................................................... 9
5.MODELO DE DATOS...................................................................................................................................... 10
6.ACCIONES..................................................................................................................................................... 11
6.1 ACCIÓN 1..........................................................................................................................................................11
6.2 ACCIÓN 2..........................................................................................................................................................12
7.RESTRICCIONES............................................................................................................................................. 13
8.INFORME AUTO CORRECCIÓN....................................................................................................................... 14
Histórico
VERSIÓN FECHA CREACIÓN AUTOR A REVISAR POR
V00 DD-MM-AAAA
Copyright 2007 Inorme,S.L No autorizada su distribución salvo por indicaciones especiales al respecto. Versión Página 2 de 2
V02 27/02/2009 sólo válida a fecha de impresión de este documento.
Apartado de carácter obligatorio para poder llevar un control y seguimiento del documento por parte del Jefe
de Proyecto, Dirección y el Departamento de Calidad.
Referencias
En la siguiente tabla se listarán los documentos bibliográficos (internos y externos) que se utilizan como
material de soporte y los cuales se hacen referencia a lo largo del documento.
REFERENCIA DOCUMENTO UBICACIÓN
1. Objetivos
Realizar una breve descripción del presente documento. Mediante dicha descripción el usuario debe
poder hacerse una visión general del contenido y funcionalidad del documento.
2. Propuesta Solicitada
Realizar una descripción general de la propuesta solicitada por el cliente, la nueva funcionalidad
deseada, y las razones del cambio o del nuevo desarrollo.
Una descripción detallada de la funcionalidad genérica del sistema. Especificar en mayor detalle los
beneficios pertinentes, objetivos y metas que se pretenden obtener mediante la funcionalidad del
sistema.
Con ayuda de un diagrama de casos de uso ilustrar gráficamente el comportamiento genérico del
sistema.
Especificar si el producto es totalmente independiente y autónomo. En caso contrario, identificar con la

mayor claridad y precisión posible todos los productos relacionados con él mismo, el grado de relación y
cómo interactúan entre ellos.
Si forma parte de un producto más grande, indicar de cual relacionando los requisitos de dicho sistema
con la nueva funcionalidad e indicar las interfaces entre ese sistema y el software. Dicha descripción se
debe realizar de forma breve y concisa, en el apartado que hace referencia a la Situación Actual ya se
entrara en mayor detalle.
Determinar con la mayor claridad posible todas las situaciones en las que se puede encontrar el sistema
y el comportamiento esperado ante las mismas.
Es de vital importancia dejar bien claro que entra y que no entra, para evitar confusiones y
malentendidos futuros.
Todo ello debe ser consistente con declaraciones similares en niveles superiores.
3. Situación Actual
En caso de que exista, realizar una breve descripción de la situación actual del sistema. Con la
ayuda de un diagrama de casos de uso ilustrar gráficamente el comportamiento genérico del
sistema.
Si existe una situación actual, quiere decir que el nuevo producto forma parte de dicho sistema ya
sea por una modificación y/o ampliación del mismo. Por lo tanto, se debe especificar con el mayor
detalle posible la relación existente entre el sistema y el nuevo producto, los requisitos del sistema
que pueden verse afectados, si existen o no interfaces entre el sistema y el nuevo producto…
Determinar con la mayor claridad y precisión posible, cuales son las ventajas, mejoras… que se
obtienen como consecuencia de la ampliación y/o modificación del sistema actual.
Determinar con la mayor claridad posible todas las situaciones en las que se puede encontrar el
sistema y el comportamiento esperado ante las mismas.
Es de vital importancia dejar bien claro que entra y que no entra, para evitar confusiones y
malentendidos futuros.
Todo ello debe ser consistente con declaraciones similares en niveles superiores.
4. Ventajas
Detalle de las ventajas que aporta el nuevo desarrollo y/o modificación.
5. Nueva Situación
Realizar una descripción detallada de los cambios y/o nuevos desarrollos demandados en la propuesta.
Con ayuda de un diagrama casos de uso ilustrar gráficamente el comportamiento genérico del aplicativo
con la/s nueva/s funcionalidad/es.
Identificar todos los niveles que se han de crear y/o modificar según lo requisitos de la propuesta y el
grado en el que se ven afectados. Los diferentes niveles pueden hacer referencia a la interfaz, capa de
enlace, capa de negocio, modelo de datos, copys, procesos bacth…
Por cada nivel abrir su correspondiente punto, donde se llevara a cabo una descripción bien detallada
de las nuevas funcionalidades y/o modificaciones de las existentes que se han de llevar a cabo.
6. Infraestructura
El objetivo de dicho apartado, consiste en especificar detalladamente el entorno de trabajo bajo el cual
se llevaran a cabo el desarrollo de las funcionalidades solicitadas.
Identificar con claridad y precisión las características del entorno real de trabajo bajo el cual correrá la
aplicación. Esto será de ayuda para determinar el entorno de trabajo de los puestos de desarrollo.
Determinar con el mayor detalle y claridad posible, todos los requisitos que deben presentar los puestos
de desarrollo para poder simular, los más fielmente posible, el entorno de real.
Identificar con claridad y precisión los requisitos mínimos y necesarios tanto a nivel de software y
hardware. (Base de Datos, tecnología, servidores, sistema operativo…)
Especificar detalladamente los conocimientos mínimos necesarios, a todos los niveles, de todos los
recursos que participaran en el desarrollo de la propuesta solicitada.
7. Modelo De Datos
Mediante una breve introducción, ilustrar gráficamente cual sería el modelo de datos a través de su
correspondiente diagrama.
Especificar detalladamente cada una de las diferentes tablas que forman parte del modelo de datos,
junto con el objetivo y propósito de cada una de ellas. Los atributos que la componen, su tipología,
tamaño, descripción…
Identificar con precisión de que tablas y de cuales no es necesario mantener un histórico, relaciones con
otras tablas, triggers…
8. Acciones
Mediante una breve introducción, realizar un listado de todas las acciones necesarias para llevar a cabo
la propuesta solicitada. Junto con una breve descripción de la funcionalidad y el resultado que se espera
de cada una de ellas.
Por cada acción identificada abrir su apartado correspondiente.
No se trata de indicar como se han de implementar, esto vendrá determinado por el orgánico. Si no de
especificar que se quiere conseguir.
9. Acción 1
Realizar una descripción con el mayor detalle y claridad posible de la funcionalidad y el resultado
de la acción que se quiere llevar a cabo. Mediante su correspondiente diagrama de caso de uso,
ilustrar gráficamente el funcionamiento genérico que debería presentar.
Especificar detalladamente las posibles dependencias con otras acciones.
Identificar con claridad y precisión todos los niveles que se ven afectados por dicha acción, Interfaz,
modelo de datos, capa de enlace… Por cada nivel, abrir su correspondiente subapartado.
Recordar, que el objetivo no es indicar como se ha de implementar ya que esto vendrá

determinado por el orgánico. Si no de especificar que se quiere conseguir.
Nivel Interfaz
Mediante una breve introducción, ilustrar gráficamente cual sería el diseño de cada una de las
pantallas que se ven afectadas o como resultado de la implementación de la acción.
Especificar detalladamente, para cada una de las pantallas, cual es su funcionalidad y el resultado
de la misma. Identificar con claridad y precisión cual sería su entrada de datos, su salida de datos y
el tratamiento de los mismos. Determinar si existe o no algún tipo de dependencia y/o colaboración
con otras pantallas.
El objetivo no es indicar como se ha de implementar, ya que esto vendrá determinado por el

orgánico. Si no de especificar que se quiere conseguir.
Nivel Capa Enlace
Cumplimentar únicamente cuando exista una capa de enlace, encarga de interactuar entre la capa
de negocio y el interfaz.
Mediante una breve introducción, ilustrar gráficamente a través de su diagrama de casos de uso
cual sería la funcionalidad de la capa de enlace según los requisitos de la propuesta.
Identificar todas aquellas clases, estructuras, ficheros, módulos… necesarios para implementar la
funcionalidad de la capa de enlace. Especificar detalladamente los parámetros de entrada, de
salida y las funciones que componen cada una dichas estructuras. Junto con su funcionalidad y
resultado esperado. Identificar, también, posibles dependencias y/o colaboraciones entre ellas o
entre diferentes niveles.
El objetivo no es indicar como se ha de implementar, ya que esto vendrá determinado por el

orgánico. Si no de especificar que se quiere conseguir.
Copyright 2007 Inorme,S.L No autorizada su distribución salvo por indicaciones especiales al respecto. Versión Página 10 de
V02 27/02/2009 sólo válida a fecha de impresión de este documento. 10
Nivel Capa de Negocio
Cumplimentar únicamente cuando exista la capa de negocio. Capa que se encarga de interactuar
con el modelo de datos.
Mediante una breve introducción y a través de su correspondiente diagrama casos de uso, ilustrar
gráficamente cual sería la funcionalidad de la capa de enlace según los requisitos de la propuesta.
Identificar todas las clases, estructuras, ficheros, módulos… necesarios para implementar la
funcionalidad de la capa de negocio. Especificar detalladamente los parámetros de entrada, de
salida y las funciones que conforman dichos objetos junto con su funcionalidad y resultado
esperado. Identificar, también, posibles dependencias y/o colaboraciones entre ellas o entre los
diferentes niveles.
El objetivo no consiste en describir como se ha de implantar, ya que esto vendrá determinado por
el orgánico. Si no de especificar que se quiere conseguir.
Nivel Modelo de Datos
Determinar con el mayor detalle y claridad posible que vistas, procedimientos y/o paquetes son
necesarios según la acción que se pretende llevar a cabo. Junto con la funcionalidad y objetivo de
cada una de ellas.
No se trata de indicar como se ha de implementar, esto vendrá determinado por el orgánico. Si no

de especificar que se quiere conseguir.
Nivel Copys
Determinar con el mayor detalle y claridad posible las copys necesarias para la acción que se
pretende llevar a cabo. Identificar, también, la dependencia y/o colaboración entre diferentes
niveles.
Procesos Bach
Identificar con el mayor detalle y claridad posibles todos aquellos procedimientos bacth necesarios
para llevar a cabo la acción. Junto con su funcionalidad y objetivo de cada uno de ellos. Para cada
uno de ellos, ilustrar gráficamente mediante un diagrama de casos de uso su comportamiento
genérico.
Especificar detalladamente, para cada uno de los procesos, cual sería su entrada de datos, la
salida de datos y el tratamiento de los mismos. Determinar si existe o no una dependencia y/o
colaboración con otros procesos.
No se trata de indicar como se ha de implementar, esto vendrá determinado mediante el orgánico.

Si no de especificar que se quiere conseguir.
10. Acción 2
11.Restricciones
Se debe describir de manera ordenada estructurada todas las restricciones del sistema, eliminando
ambigüedades e inconsistencias de la información proporcionada.
Identificar con el mayor detalle posible todas las restricciones del sistema. Por ejemplo:
 Políticas reguladoras.
 Limitaciones del Hardware.
 Limitaciones del Software.
 Limitaciones del Sistema Operativo.
 Limitaciones del lenguaje.
 Seguridad y consideraciones de seguridad.
 Interfaces a otras aplicaciones.
 …
12.Informe Auto Corrección

Por diferentes motivos, bien porque la toma de requerimientos no es del agrado del cliente, dirección,
ausencias y/o fallos detectados…, es necesario realizar una revisión de la toma de requerimientos por la
propuesta y análisis realizado, por parte de la empresa, de los mismos. Todo ello puede implicar un
cambio en la toma de requerimientos realizada inicialmente.
Por lo tanto, con el objetivo de cumplir la normativa ISO 9001:2000 y poder llevar un control de las
correcciones, es de carácter obligatorio registrar dichos cambios. Para ello se debe cumplimentar la
siguiente tabla:
FECHA AUTOR APARTADOS REVISADO POR

DD-MM-AAAA

Propuesta Económica Proyecto

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Propuesta Económica Proyecto

Cargado por

Copyright:

Formatos disponibles

ANÁLISIS FUNCIONAL OTXXXXXV00

REFERENCIA DOCUMENTO UBICACIÓN

Especificar si el producto es totalmente independiente y autónomo. En caso contrario, identificar con la

Por cada acción identificada abrir su apartado correspondiente.

Especificar detalladamente las posibles dependencias con otras acciones.

Recordar, que el objetivo no es indicar como se ha de implementar ya que esto vendrá

El objetivo no es indicar como se ha de implementar, ya que esto vendrá determinado por el

Nivel Capa Enlace

El objetivo no es indicar como se ha de implementar, ya que esto vendrá determinado por el

Nivel Capa de Negocio

Nivel Modelo de Datos

No se trata de indicar como se ha de implementar, esto vendrá determinado por el orgánico. Si no

No se trata de indicar como se ha de implementar, esto vendrá determinado mediante el orgánico.

12.Informe Auto Corrección

FECHA AUTOR APARTADOS REVISADO POR

También podría gustarte