Está en la página 1de 13

Universidad Anlisis de Sistemas de Informacin Vision

Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] [To customize automatic fields (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

Revision History
Date <dd/mmm/yy> Version <x.x> <details> Description <name> Author

Confidential

Universidad, 2008

Page 2

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

Table of Contents
1. Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones, Acrnimos y Abreviaciones 1.4 Referencias 1.5 Overview 2. Posicionamiento 2.1 Oportunidad del negocio 2.2 Problemas 2.3 Posicin del producto 3. Descripcin del usuario y Stakeholder 3.1 Market Demographics 3.2 Resumen de Stakeholder 3.3 Resumen del usuario 3.4 Entorno del usuario 3.5 Perfil del Stakeholder 3.5.1 <Nombre del Stakeholder> 3.6 Perfil del Usuario 3.6.1 <Nombre del usuario> 3.7 Necesidades clave del Stakeholder / Usuario 3.8 Alternativas y competencias 3.8.1 <aCompetitor> 3.8.2 <anotherCompetitor> 4. Overview del Producto 4.1 Perspectiva del Producto 4.2 Resumen de capacidades 4.3 Assumptions and Dependencies 4.4 Costo y Precio 4.5 Licencias e Instalacin 5. Caractersticas del Producto 5.1 <aFeature> 5.2 <anotherFeature> 6. Restricciones 7. Rangos de Calidad 8. Precedencia y Prioridad 9. Otros requerimientos del producto 9.1 Estndares aplicables 9.2 Requerimientos del sistema 9.3 Performance Requirements Confidential Universidad, 2008 5 5 5 5 5 5 5 5 5 5 6 6 6 6 7 7 7 7 7 8 8 8 8 8 9 9 9 9 10 10 10 10 10 10 10 10 11 11 11 Page 3

Anlisis de Sistemas de Informacin Vision <identificador del documento> 9.4 Environmental Requirements 10. Requerimientos de Documentacin 10.1 Manuales de usuario 10.2 Ayuda en Lnea 10.3 Guas de instalacin, Configuracin, Archivo Read Me 10.4 Labeling and Packaging 11. Apendice 1 Caractersticas 11.1 Stado 11.2 Beneficio 11.3 Esfuerzo 11.4 Riesgo 11.5 Estabilidad 11.6 Objetivo del Release 11.7 Asignado a 11.8 Razn

Version: <1.0> Date: <dd/mmm/yy>

11 11 11 11 11 11 12 12 12 12 12 13 13 13 13

Confidential

Universidad, 2008

Page 4

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

Vision
1. Introduccin
El propsito de este documento es colectar, analizar y definir las necesidades de alto nivel y caractersticas del <<System Name>>. Se enfoca en las capacidades necesarias de los stakeholders, y los usuarios objetivo, y porque existen estas necesidades. Los detalles de cmo el <<System Name>> cubre estas necesidades son descritos en los casos de uso y especificaciones suplementarias. 1.1 Propsito [Specify the purpose of this Vision.] 1.2 Alcance [Una breve descripcin del alcance de esta Vision; con que est asociado el proyecto y cualquier otro elemento que afecte o influencie contenido de este documento.] 1.3 Definiciones, Acrnimos y Abreviaciones [This subsection should provide the definitions of all terms, acronyms, and abbreviations required to interpret properly the Vision. This information may be provided by reference to the project Glossary.] 1.4 Referencias

1.5 Overview [This subsection should describe what the rest of the Vision contains and explain how the document is organized.]

2.

Posicionamiento
2.1 Oportunidad del negocio [Descripcin breve de las oportunidades del negocio que se lograran con este proyecto.] 2.2 Problemas [Proporcionar un resumen del problema que esta siendo resuelto por este proyecto. Se puede usar el siguiente formato:] El problema Afecta Impacto La solucin podra (describir el problema) (los stakeholders afectados por el problema). (cual es el impacto del problema). (listar algunos beneficios clave de una solucin exitosa).

2.3 Posicin del producto [Proporcionar una perspectiva de resumen al mas alto nivel, la posicin que el producto intenta cubrir en el Mercado. El formato siguiente puede servir de gua:]

Confidential

Universidad, 2008

Page 5

Anlisis de Sistemas de Informacin Vision <identificador del documento> Para Quien El (nombre del producto) Que A diferencia de Nuestro producto (cliente objetivo) (Necesidad u Oportunidad) Es un (categora de producto)

Version: <1.0> Date: <dd/mmm/yy>

(declaracin de los beneficios claves) (Principal alternativa de competencia) (declaracin de diferenciacin principal)

[La posicin del producto comunica la intencin de la aplicacin y la importancia del proyecto para todo el personal relacionado con el.]

3.

Descripcin del usuario y Stakeholder


[Para proveer efectivamente los productos y servicios que cubren las necesidades de los stakeholders y usuarios ,es necesario identificar e involucrar a todos los stakeholders como parte del proceso de modelado de requerimientos. Debe tambin identificar a los usuarios del sistema y asegurar que la comunidad de stakeholders los representa adecuadamente. Esta seccin proporciona un perfil de los stakeholders y usuarios involucrados en el proyecto y los problemas clave que sern resueltos por la solucin propuesta. No describe las necesidades especficas o requerimientos (Estos son capturados en un artefacto de requisitos del stakeholder). En vez de ellos proporciona el background y justificacin del porque se necesitan los requerimientos.] 3.1 Market Demographics [Resume los elementos clave del Mercado que motivan sus decisiones sobre el producto. Describe y posiciona los segmentos de Mercado objetivo. Estima el tamao y crecimiento del Mercado utilizando el nmero potencial de usuarios, o la cantidad de dinero que sus clientes gastan tratando de cubrir sus necesidades que su producto/mejora podra realizar. Revisa las principales tendencias y tecnologas de la industria . Responde a preguntas estratgicas: Cual es la reputacin de su organizacin en este mercado? Que deseara ser? Como este servicio o producto soporta sus objetivos?] 3.2 Resumen de Stakeholder [Presenta una lista resumen de los stackeholders identificados] Name Nombre del tipo de stakeholder. Represents Descripcin breve de lo que representa con respecto al desarrollo. Role Describe brevemente el rol que juegan en el desarrollo. Por ejem. Asegurar que.

3.3 Resumen del usuario [Present a summary list of all the identified users:] Name Nombre de usuario Description Descripcin breve de los que representa con respecto al sistema. Stakeholder Lista como el usuario es representado por los stakeholders. i.e. Represented by Stakeholder1

Confidential

Universidad, 2008

Page 6

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

3.4 Entorno del usuario [Detalla el entorno de trabajo del usuario objetivo. Aqu algunas sugerencias: Numero de personas involucradas en llevar a cabo la tarea? Es cambiante? Que tan largo es un ciclo de tarea? Cantidad de tiempo gastado en cada actividad? Es cambiante? Cualquier restriccin ambiental: mvil , externa, in-flight, etc.? Cuales plataformas de sistemas estn en uso? Plataformas futuras? Que otras aplicaciones estn en uso? Necesita que su aplicacin est integradas a ellas?

Aqu se extrae desde el modelo del negocio lo que podra incluirse como el resumen de las tareas y trabajadores involucrados en ellas etc] 3.5 Perfil del Stakeholder [Describe cada stakeholder en el sistema llenando en la siguiente tabla para cada stakeholder. Recuerde que los tipos de stakeholder pueden ser tan divergentes como usuarios, departamentos estratgicos y desarrolladores tcnicos. Un perfil debiera cubrir los siguientes tpicos para cada tipo de stakeholder:] 3.5.1 <Nombre del Stakeholder> Quien es el stakeholder representativo para el proyecto (opcional si est documentado en otro lugar). Lo que se quiere aqu son nombres! Breve descripcin del tipo de stakeholder Califique la experiencia del stakeholder i.e. GURU, EXPERTO DEL NEGOCIO, USUARIO CASUAL etc i.e. Background tcnico y nivel de sofisticacin Lista las responsabilidades clave del stakeholder con respecto al sistema que se est desarrollado (i.e. sus intereses como un stakeholder). Como define al xito el stakeholder? Como es recompensado el stakeholder ? Como est involucrado en el proyecto el stakeholder relacionado donde sea posible con los trabajadores del RUP (i.e. Revisores de requerimientos etc.) Cualquier entregable adicional requerido por el stakeholder. These could be project deliverables or output from the system under development. Problemas que interfieren con el xito y cualquier otra informacin relevante.

Representative Descripcin Tipo

Responsabilidades Criterio de xito Involucramiento Entregables Comentarios / Issues

3.6 Perfil del Usuario [Describe cada usuario del sistema en la siguiente tabla. Recuerde que los usuarios pueden ser tan divergentes como gurus y novatos. Por ejemplo, un guru podra necesitar una herramienta flexible y sofisticada con soporte multiplataforma, mientras que un Novato podra necesitar un herramienta que sea amigable y fcil de usar. Un perfil de usuario debera cubrir los siguientes tpicos para tipo de usuario:] 3.6.1 <Nombre del usuario> Quien es el usuario representativo para el proyecto (opcional si est documentado en otro lugar). Frecuentemente se refiere al Stakeholder que representa el conjunto de usuarios (i.e. Stakeholder: Stakeholder1). Breve descripcin del tipo de usuario Califica la experiencia del usuario p. e. GURU, USUARIO CASUAL etc Universidad, 2008 Page 7

Representative

Descripcin Tipo Confidential

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

Responsabilidades Criterio de xito Involvement Deliverables Comments / Issues

i.e. Technical background and degree of sophistication List the key responsibilities of the user with respect to the system (i.e. captures customer details, produces reports, co-ordinates work). How does the user define success? How is the user rewarded? How the user is involved in the project - relate where possible to RUP workers (i.e. Requirements Reviewer etc.) Deliverables the user produces, and for whom.. Problems that interfere with success and any other relevant information. Trends that make the users job easier or harder

3.7 Necesidades clave del Stakeholder / Usuario [Lista los problemas principales con la soluciones tal como es percibida por el stakeholder. Clarifique los siguientes elementos de cada problema: Cuales son las razones de este problema? Como se ha resuelto? Que solucin desea el stakeholder?

Es importante comprender la importancia relativa que el stakeholder le d a resolver el problema. Las tcnicas de clasificacin en Ranking indicarn los problemas que deben ser resueltos versus los elementos que debieran ser atendidos. Llene la siguiente tabla Si est usando ReqPro para capturar las necesidades esto podra ser extrado desde una herramienta de extraccin y reporte..] Necesidad Broadcast messages Prioridad Concerns Solucin actual Soluciones propuestas

3.8 Alternativas y competencias [Identifique las alternativas que el stakeholder percibe como viables. Estas pueden incluir comprar un producto de la competencia, construir una solucin propia o simplemente mantener el status quo. Liste cualquier posibilidad competitiva que exista, o pueda estar disponible. Incluir las principales fortalezas y debilidades de cada competidor tal como lo percibe el stakeholder.] 3.8.1 3.8.2 <aCompetitor> <anotherCompetitor>

4.

Overview del Producto


[Esta seccin proporciona una vista de alto nivel de las capacidades del producto, interfaces hacia otras aplicaciones y configuraciones de sistemas. Esta seccin usualmente consiste de tres subsecciones, como sigue: Perspectiva del producto Funciones del producto Assumptions and dependencies]

Confidential

Universidad, 2008

Page 8

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

4.1 Perspectiva del Producto [Esta subseccin del documento de Visin debera poner al producto en la perspectiva con respecto a otros productos relacionados y entornos de usuario. Si el producto es independiente y totalmente auto contenido, descrbalo aqu. Si el producto es un componente de un sistema mas grande, entonces esta subseccin debera decir como los sistemas interactan y debera identificar las interfaces relevantes entre los sistemas. Una forma sencilla de mostrar los componentes, interconexiones e interfaces de un sistema mas grande es va diagramas de bloques.] 4.2 Resumen de capacidades [Resuma los principales beneficios y caractersticas que el producto proporcionar. Por ejemplo, un documento de Visin para un sistema de soporte al cliente puede usar esta parte para manejar el problema de la documentacin, ruteo y estado de reportes sin mencionar la cantidad de detalle que cada una de estas funciones necesita. Organice las funciones de modo que la lista sea comprensible al cliente o cualquiera que lea el documento por primera vez. Puede ser suficiente una tabla que liste los beneficios clave y sus caractersticas de soporte. Por ejemplo:] Sistema de Soporte al Cliente Beneficio del Cliente Supporting Features New support staff can quickly get up Knowledge base assists support personnel to speed. in quickly identifying known fixes and workarounds Customer satisfaction is improved Problems are uniquely itemized, classified because nothing falls through the and tracked throughout the resolution cracks. process. Automatic notification occurs for any aging issues. Management can identify problem Trend and distribution reports allow high areas and gauge staff workload. level review of problem status. Distributed support teams can work Replication server allows current database together to solve problems. information to be shared across the enterprise Customers can help themselves, Knowledge base can be made available lowering support costs and improving over the Internet. Includes hypertext response time. search capabilities and graphical query engine 4.3 Assumptions and Dependencies [Liste cada uno de los factores que afectan las caractersticas establecidas en el documento de Visin. Liste los supuestos que, si son cambiados, Alteraran el documento de visin. Por ejemplo, un supuesto puede establecer que un sistema operativo especfico estar disponible para el hardware asignado al producto de software. Si el Sistema operativo no est disponible, el documento de visin cambiar.] 4.4 Costo y Precio [Para los productos vendidos a clientes externos y muchas aplicaciones desarrolladas internamente, los elementos de costo y precios pueden impactar directamente en la definicin de la aplicacin e implementacin. En esta seccin, register cualquier restriccin de costo y precio que sean relevantes. Por ejemplo, costos de distribucin, (# of diskettes, # CD-ROMs, CD mastering) u otros restricciones de bienes vendidos (manuales, empque) pueden ser fundamental para el xito del proyecto, o irrelevante dependiendo de la naturaleza de la aplicacin.]

Confidential

Universidad, 2008

Page 9

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

4.5 Licencias e Instalacin [Licensing and installation issues can also directly impact the development effort. For example, the need to support serializing, password security or network licensing will create additional requirements of the system that must be considered in the development effort. Installation requirements may also affect coding, or create the need for separate installation software.]

5.

Caractersticas del Producto


[Liste y describa brevemente las caractersticas del producto. Caractersticas son las capacidades del alto nivel del sistema que son necesarias para entregar beneficios a los usuarios. Cada caracterstica es un servicio externo deseado que tpicamente requiere una serie de entradas para lograr el resultado deseado. Por ejemplo, una caracterstica de un sistema de seguimiento de problemas podra ser la capacidad de proveer repotes de tendencias. A medida que el modelo de casos de uso toma forma, actualice las descripciones que se refieran a dicho caso de uso. Debido a que el documento de visin es revisado por una amplia variedad de personal involucradas, el nivel de detalle debera ser suficientemente general para que todos comprendan. Sin embrago, suficiente detalle debera estar disponible al equipo con la informacin que ellos necesitan para crear un modelo de casos de uso. Para administrar efectivamente la complejidad de la aplicacin, recomendamos para cualquier sistema Nuevo, o incremento a un sistema existente,las capacidades son desde un alto nivel. Estas caractersticas proporcionan la base fundamental para definicin del producto,gestin del alcance y gestin del proyecto. Cada caracterstica ser expandida en mayor detalle en el modelo de casos de uso. Throughout this section, each feature should be externally perceivable by users, operators or other external systems. These features should include a description of functionality and any relevant usability issues that must be addressed. The following guidelines apply: Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why, (not how) they should be implemented. If you are using the Requisite toolkit, all should be selected as requirements of type for easy reference and tracking] 5.1 <aFeature>

5.2

<anotherFeature>

6. 7.

Restricciones
[Anote cualquier restriccin de d iseo, externo, u otras dependencias.]

Rangos de Calidad
[Defina los rangos de calidad para rendimiento, robustez, tolerancia a fallas, facilidad de uso, y caractersticas similares que no son capturadas en el conjunto de caractersticas.]

8. 9.

Precedencia y Prioridad
[Define the priority of the different system features.]

Otros requerimientos del producto


[At a high-level, list applicable standards, hardware or platform requirements, performance requirements Universidad, 2008 Page 10

Confidential

Anlisis de Sistemas de Informacin Vision <identificador del documento> and environmental requirements.]

Version: <1.0> Date: <dd/mmm/yy>

9.1 Estndares aplicables [List all standards the product must comply with. These can include legal and regulatory (FDA, UCC) communications standards (TCP/IP, ISDN), platform compliance standards (Windows, Unix, etc), quality and safety standards (UL, ISO, CMM).] 9.2 Requerimientos del sistema [Define any system requirements necessary to support the application. These can include the supported host operating systems and network platforms, configurations, memory, peripherals and companion software.] 9.3 Performance Requirements [Use this section to detail performance requirements. Performance issues can include such items as user load factors, bandwidth or communication capacity, throughput, accuracy, reliability or response times under a variety of loading conditions.] 9.4 Environmental Requirements [Detail environmental requirements as needed. For hardware based systems, environmental issues can include temperature, shock, humidity, radiation, etc. For software applications, environmental factors can include usage conditions, user environment, resource availability, maintenance issues, error handling and recovery.]

10.

Requerimientos de Documentacin
[This section describes the documentation that must be developed to support successful application deployment.] 10.1 Manuales de usuario [Describe the purpose and contents of the User Manual. Discuss desired length, level of detail, need for index, glossary of terms, tutorial vs. reference manual strategy, etc. Formatting and printing constraints should also be identified.] 10.2 Ayuda en Lnea [Many applications provide an on-line help system to assist the user. The nature of these systems is unique to application development as they combine aspects of programming (hyperlinks, etc) with aspects of technical writing (organization, presentation). Many have found the development of on-line help system is a project within a project that benefits from up front scope management and planning activity.] 10.3 Guas de instalacin, Configuracin, Archivo Read Me [A document that includes installation instructions and configuration guidelines is important to a full solution offering. Also, a Read Me file is typically included as a standard component. The Read Me can include a "What's New With This Release Section," and a discussion of compatibility issues with earlier releases. Most users also appreciate documentation defining any known bugs and workarounds in the Read Me file.] 10.4 Labeling and Packaging [Today's state of the art applications provide a consistent look and feel that begins with product packaging and manifests through installation menus, splash screens, help systems, GUI dialogs, etc. This section defines the needs and types of labeling to be incorporated into the code. Examples include copyright and patent notices, corporate logos, standardized icons and other graphic elements, etc.]

Confidential

Universidad, 2008

Page 11

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

11.

Apendice 1 Caractersticas
[Features should be given attributes that can be used to evaluate, track, prioritize and manage the product items proposed for implementation. All requirement types and attributes should be outlined in the Requirements Management Plan, however you may wish to list and briefly describes the attributes for features that have been chosen. Following subsections represent a set of suggested feature attributes.] 11.1 Stado [Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.] Proposed Used to describe features that are under discussion but have not yet been reviewed and accepted by the "official channel," such as a working group consisting of representatives from the project team, product management and user or customer community. Capabilities that are deemed useful and feasible and have been approved for implementation by the official channel. Features incorporated into the product baseline at a specific point in time.

Approved Incorporated

11.2 Beneficio [Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking requirements by their relative benefit to the end user opens a dialogue with customers, analysts and members of the development team. Used in managing scope and determining development priority.] Critical Essential features. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip. Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature. Features that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.

Important

Useful

11.3 Esfuerzo [Set by the development team. Because some features require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.] 11.4 Riesgo [Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects teams schedule estimate.] Confidential Universidad, 2008 Page 12

Anlisis de Sistemas de Informacin Vision <identificador del documento>

Version: <1.0> Date: <dd/mmm/yy>

11.5 Estabilidad [Set by analyst and development team based on the probability the feature will change or the teams understanding of the feature will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.] 11.6 Objetivo del Release [Records the intended product version in which the feature will first appear. This field can be used to allocate features from a Vision document into a particular baseline release. When combined with the status field, your team can propose, record and discuss various features of the release without committing them to development. Only features whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.] 11.7 Asignado a [In many projects, features will be assigned to "feature teams" responsible for further elicitation, writing the software requirements and implementation. This simple pull down list will help everyone on the project team better understand responsibilities.] 11.8 Razn [This text field is used to track the source of the requested feature. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.]

Confidential

Universidad, 2008

Page 13