Business Case

<Nombre empresa>
<Nombre del proyecto>
Business Case
Versión <1.0>
[Nota: Esta plantilla se proporciona para que se use como parte del Proceso Unificado de Rational. El
texto que aparece entre corchetes y que aparece en letra cursiva azul (estilo=InfoBlue) se incluye para
guiar al autor y debería borrarse antes de publicar el documento. Un párrafo que se haya introducido
siguiendo este estilo se cambiará a normal (estilo=Body Text)]
[Para adaptar los campos automáticos (los que aparecen con un fondo gris cuando se seleccionan) de
Microsoft Word, selecciona Archivo>Propiedades (en inglés: File>Properties) y sustituye los campos
título, asunto y organización con la información apropiada para este documento. Después de cerrar el
diálogo, los campos automáticos se pueden actualizar en todo el documento seleccionando
Edición>Seleccionar todo (o Ctrl-E) y pulsando F9, o simplemente haciendo clic en un campo y pulsando
F9. Esto debe hacerse de manera separada para los encabezamientos y pies de página. Alt-F9 cambiará
entre mostrar los nombres de los campos y el contenido de los mismos. Si quieres más información sobre el
trabajo sobre campos, consulta la ayuda de Word].
<Nombre del proyecto>
Business Case
<identificador del documento>
Versión:
<1.0>
Fecha: <dd/mmm/yy>
Historia de revisiones
Fecha
<dd/mmm/yy>
Confidencial
Versión
<x.x>
Descripción
<detalles>
<Nombre empresa>, 2017
Autor
<nombre>
Page 2 of 5
<Nombre del proyecto>
Business Case
<identificador del documento>
Versión:
<1.0>
Fecha: <dd/mmm/yy>
Tabla de contenidos
1.
Introducción
4
1.1
1.2
1.3
1.4
1.5
4
4
4
4
4
Propósito
Ámbito
Definiciones, acrónimos, y abreviaturas
Referencias
Visión general
2.
Descripción del producto
4
3.
Contexto de negocio
4
4.
Objetivos del producto
4
5.
Previsión financiera
4
6.
Restricciones
5
Confidencial
<Nombre empresa>, 2017
Page 3 of 5
<Nombre del proyecto>
Business Case
<identificador del documento>
Versión:
<1.0>
Fecha: <dd/mmm/yy>
Business Case
1.
Introducción
[La introducción de la especificación del sistema ofrece una visión general de todo este documento. En
ella se incluye el propósito, el ámbito, definiciones, los acrónimos, abreviaturas, referencias y una visión
general de esta especificación del sistema].
1.1
Propósito
[Especificar el propósito de esta especificación del sistema].
1.2
Ámbito
[Una breve descripción de esta especificación del sistema; con qué proyectos están asociadas y cualquier
otra cosa que se vea afectada o influenciada por este documento].
1.3
Definiciones, acrónimos, y abreviaturas
[Este subapartado ofrece las definiciones de todos los términos, acrónimos y abreviaturas que se necesiten
para interpretar adecuadamente la especificación del sistema. Esta información se puede proporcionar
haciendo una referencia al glosario del proyecto].
1.4
Referencias
[En este subapartado se debería proporcionar una lista completa de todos los documentos a los que se
hace referencia en el documento de especificación del sistema. Identifica cada documento por su título y
número de informe si fuese aplicable, fecha y entidad editora. Especifique las fuentes mediante las cuales
se pueden obtener las referencias. Esta información se puede proporcionar mediante una referencia a un
apéndice u otro documento].
1.5
Visión general
[Este subapartado describe lo que contiene el resto del documento de especificación del sistema y explica
cómo está organizado el documento].
2.
Descripción del producto
[Para darle al lector un contexto, describe brevemente el producto que se está desarrollando. Incluye el
nombre del sistema y quizás el acrónimo, si es que se usa uno. Explica qué problema resuelve y por qué
vale la pena el desarrollo del mismo. Haz referencias al documento de Visión].
3.
Contexto de negocio
[Define el contexto de negocio para el producto. ¿En qué dominio va a funcionar (por ejemplo,
telecomunicaciones o banca)? Y en qué mercado –¿Quiénes son los usuarios? Indica si es producto se
desarrolla para cumplir con un contrato o se trata de un producto comercial. También debería
mencionarse si es la continuación de un proyecto existente].
4.
Objetivos del producto
[Indica los objetivos del desarrollo del producto –las razones que hacen que valga la pena su desarrollo.
En este apartado se debería incluir un plan tentativo y algún tipo de evaluación de los riesgos de dicho
plan. Unos objetivos definidos y expresados de manera clara ofrecen una buena base para establecer hitos
y gestionar riesgos; es decir, para mantener el proyecto encarrilado y asegurar su éxito].
5.
Previsión financiera
[Para un producto de software comercial, este documento debería incluir un conjunto de suposiciones
Confidencial
<Nombre empresa>, 2017
Page 4 of 5
<Nombre del proyecto>
Business Case
<identificador del documento>
Versión:
<1.0>
Fecha: <dd/mmm/yy>
acerca del proyecto y el orden de magnitud del retorno de la inversión (Return Of Investment –ROI) si es
que se cumplen las previsiones. Por ejemplo, el ROI tendrá una magnitud 5 si finaliza en un año, 2 si lo
hace en dos y un número negativo si se hace más tarde. Estas suposiciones se comprueban de nuevo al
final de la fase de elaboración, cuando el ámbito y el plan son conocidos con más precisión. El retorno se
basa en la estimación de costo y la estimación de los beneficios potenciales.
La estimación de recursos rodea todo el proyecto, hasta el envío al cliente. Esta estimación se actualiza en
cada fase y en cada iteración, y se hace más precisa a medida que se completan iteraciones.
Se debe incluir una explicación de la base de las estimaciones].
6.
Restricciones
[Expresa las restricciones sobre las que se ha comprometido el proyecto. Estas restricciones tienen
impacto en los riesgos y el coste. Podrían ser cosas como interfaces externas a las que el sistema se tenga
que adherir, certificaciones o aproximaciones técnicas empleadas por razones estratégicas, tales como
usar una cierta tecnología de bases de datos o un mecanismo de distribución].
Confidencial
<Nombre empresa>, 2017
Page 5 of 5