Técnica para facilitar la toma de Requerimientos

Durante la etapa de recopilación de requerimientos debemos de obtener el mayor contexto posible,
para lo cual, durante la entrevista con los Stakeholder deberemos de guiarlos a explicarse correctamente.

La técnica es realizar una serie de preguntas que lleven a obtener la información con mayor valor, para ello se clasifican por tipo se explica de manera  breve de porque la pregunta y se da un ejemplo que puede aplicar para lograr mejor entendimiento del requerimiento

Tipo	Explicación	Ejemplo
Analizar	Para Expresar un entendimiento personal de conceptos, hechos y causas	Podrías de favor indicarme en que contexto se requiere, con ello puedo tener más claro la idea
Comprobar	Para comprobar que se no se mal entendió	Podrías por favor resumirme cual fue tú entendimiento de lo que acabamos de platicar
Clasificar	Para organizar los hechos relevantes	Sería de mucha ayuda para organizar mis ideas, si de favor puedes clasificarme estos puntos
Comparar	Para revelar el conocimiento y entendimiento de hechos similares y echos diferentes	Podemos comparar el requerimiento con uno que tomamos anteriormente
Definir	Para entender la interpretación de los términos	Para que todos entendamos lo mismo, podrás ayudarme a definir este termino
Describir	Para seleccionar y definir características que proporciona una condición o una sitiación del proceso	Puedes describirme una situación típica donde podría aplicar
Argumentar	Para examinar un evento y extender sus implicaciones	Revisemos las implicaciones de esta acción y revisemos sus implicaciones
Explicar	Aclarar mediante demostración el entendimiento	Podrías decirnos como es que llegas a esa conclusión
Ejemplificar	Clarificar mediante ejemplo el entendimiento	Podrás darnos uno o dos ejemplo de como trabaja esto
Incitar	Para obtener mas información	Que otra cosa pasa a parte de ello Que mas pasa
Ondar	Para obtener mejor calidad	A que te refieres con...
Redireccionar	Para cambiar el tema al punto de discusión	Muy buen punto, podemos ponerlo en la lista, sin embargo el caso es...
Re-plantear	Para demostrar lo que se ha entendido	En otras palabras lo que tú quieres decir es...
Revisar	Recapitular o cuestionar	Podemos revisar los puntos que acabamos de platicar
Verificar	Proveer información para sustentar el requerimiento	Como podemos verificar que se ha cumplido el requerimiento

fuente: http://www.iag.biz/                                        

Las 4 fases del Analista de Negocio (Como son descubiertos)

Los Analistas de Negocio (Business Analysts BA’s) pasan por 4 fases hasta que son vistos con claridad por la organización.

La primera fase, la organización se encuentran con los ojos cerrados, los BA’s son imperceptibles a la organización descontrolada, esto se da por el ambiente actual donde cada sistema siembra su propio deterioro y destrucción.

La segunda fase, Los ojos empiezan abrirse, los BA´s son percibidos en blanco y negro, existen procesos declarados, plantillas y lista de requerimientos aislados y sin estructura alguna; ellos son detectados y los proyectos susurran acerca de ellos, ellos no tienen voz en los proyectos o sus comentarios son escuchados pero no se les entienden, el cliente no entiende para que están ahí, solo se percibe que quieren cargar más el costo del proyecto.

La tercera fase, en el movimiento del mundo externo, hace que la organización los identifique y los señale como recurso con habilidades y metodologías, que colaboran para converger las prácticas y tendencias, se ven en color tanto por la organización como por los clientes, se empiezan a trabajar con herramientas más sofisticadas que Excel y Word.

Ellos realizan sorprendentes estructuras para entender las necesidades del cliente, ayudan a entender en base a diferentes modelos la necesidad clave, haciendo más efectivo el trabajo de los demás, se ubican como una comunidad que participa dentro del proyecto.

La cuarta fase, Los BA´s son la fortaleza y los músculos de la organización, su habilidad de abstracción, analítica y creativa facilita las planeaciones y ejecuciones de los proyectos, son colaborativos con otras disciplinas y buscan el bien común, sobre cualquier interés personal, establecen un ambiente de comunicación continuo y de agilidad para alcanzar los objetivos.

Los BA´s son claramente vistos por toda la organización y tienen color, forma y nombre por el cual se les ubica, son entes que tienen presencia y sus sugerencias son seguidas por mejorar la eficiencia de los proyectos.

Cono de Incertidumbre

El cono de incertidumbre en las estimaciones

Podemos definir el proyecto en términos del esfuerzo limitado de tiempo que es requerido para lograr un objetivo. El cono de incertidumbre es la herramienta que utilizamos, consiente o inconsciente, para realizar nuestras estimaciones, llamada en ocasiones margen de error o colchón de tiempo.

La incertidumbre se encuentra en función del nivel de definición de las fases del proyecto, y tiene una repercusión directa en la estimación de costos y plazo de ejecución; estos costos pueden variar desde 0.25x hasta 4x, siendo la “x” el costo real final que solo se conoce con certeza al final del proyecto.

La incertidumbre no beneficia a ninguna de las partes y no hace más que transferir el riesgo de una parte (Cliente) a las otra (Proveedor). Un proyecto que se excede en tiempo y costo solo perjudicará a la parte que asume el riesgo.

La figura muestra el cono de incertidumbre que se tiene a la hora de generar una estimación de desarrollo; en donde el eje horizontal contiene los entregables comunes en el desarrollo, dados en función de los requerimientos

En el eje vertical se muestra el grado de error (o incertidumbre) que puede tener una estimación, creada por personas con habilidades para ello. La estimación representa el alcance en términos del esfuerzo, costo y tamaño del proyecto.

Estrechez del cono de la incertidumbre

Unas de las preguntas frecuentes de los Managers y Clientes es: “¿Si te doy algunos días más para trabajar en la estimación, puede disminuir la incertidumbre?”, lo cual es una petición razonable, sin embargo, no será posible cumplirla; varios estudios han encontrado que la precisión en la estimación de software depende del nivel de refinamiento de los requerimientos del Cliente, así como la efectividad de transmitirlos. Entre más refinados los requerimientos y su contexto, se puede obtener mayor precisión en la estimación.

Los desarrollos de software por naturaleza contienen una variabilidad alta y la única manera de bajar la variabilidad es realizando un proceso de Ingeniería de Requerimientos que controle o disminuya dicha variabilidad, con el objetivo que se tenga mejor certidumbre de las expectativas del cliente.

El cono representa la incertidumbre, que se tiene por naturaleza al realizar la estimación por las personas con habilidades para ello, por lo que es muy factible que el cono sea peor (ver Figura anterior) cuando las personas que realizan las estimaciones no tienen las habilidades adecuadas para ello. Es imposible tener mejor exactitud solo es posible tener mejor suerte

La estrechez del cono puede eliminar variabilidad en función de la metodología y prácticas que se sigan, por ejemplo; definir el Documento de Visión, Modelo de contexto, Prototipos (o Wireframes), entre otros, pueden ayudar a estrechar la incertidumbre del cono, ya que ayudan a disminuir los riesgos causados por un pobre nivel de detalle de los requerimientos que entran.

Es importante mencionar, que no se intenta detallar el producto entero, sino lo mínimo necesario para reducir la estrechez

Relación entre el cono y el compromiso

Las compañías de software inapropiadamente sabotean sus propios proyectos al comprometerlos al inicio del cono de la incertidumbre. Si una organización se compromete en la etapa de concepto inicial o durante la definición del producto el factor de error está estimado entre 2x y 4x.

El comprometerlo al principio del cono, hace que el proyecto tenga una predictibilidad indeterminada, incrementando el riesgo, la ineficiencia del proyecto, el deterioro de la administración y el éxito del proyecto.

Por lo que se recomienda que el compromiso no se realice en dichas etapas, donde la amplitud del cono hace que las organizaciones sean ineficientes y absorban los riesgos de ello.

Un buen punto para realizar compromisos puede ser, donde la incertidumbre del proyecto esté cerca del 30% (1.3x), en dicho punto se tiene un mejor control y monitoreo de los entregables y avances del proyecto, mejora sustancialmente la eficiencia de los equipos involucrados en el desarrollo

Referencias


http://www.construx.com/Page.aspx?hid=1648


http://www.measurecontrol.com/cono-de-incertidumbre/

The Role of Architecture in Business Analysis

(Copia Fiel de la pagina http://msdn.microsoft.com/en-us/library/bb508953.aspx) 

Michael Rosen
May 2007
Summary: Understand the architecturally significant aspects of business analysis on which a project architect should focus. (6 printed pages)

Contents

Introduction
Northwinds Trading Gets a Business Model
What Is Business Analysis?
Review
Critical-Thinking Questions
Sources
Glossary

Introduction

Imagine yourself on an assignment at Northwinds, an options-trading company. They have brought in your team to help upgrade the critical applications used day in and day out by the traders. As new kinds of options and other financial instruments are created, the old, inflexible applications are breaking under the pressure for change and integration. Today is an important day, and your trepidation peaks as you pull into an empty spot in the parking lot. As you look around, you notice that your car is the cheapest vehicle in the lot, which is dominated by BMWs, Porches, Jaguars, and the occasional Bentley. These guys make a lot of money, and they don't have a lot of time or patience for "theory," "architecture," or excuses.
Still, you know that, to meet the new regulatory and conformance requirements, and to achieve the goals of common processing and reporting, you will need to have both a business model and a technical architecture.
The business model defines the processes and entities of the business, and identifies what must be common to meet the new system requirements. The technical architecture will define patterns for implementing the business on a common technology platform. It will have to support the business architecture; but, on the Northwind project, the business model—not technology—is your focus and responsibility.

Northwinds Trading Gets a Business Model

Today is the day of the first "business-modeling" session. It will be attended by the IT group's business analysts, as well as by a few senior traders forced to attend. You kick off the meeting with an overview of the goals and a brief introduction to what a business model will look like. A prepared poster on the wall acts as a key to three concepts that will be used in the exercise; and, quickly—before any eyes can glaze over—you jump right into creating the first model on the whiteboard.
At first, the model seems to be obvious and simple, as you illustrate the basic modeling concepts. But, based on upfront preparation, you start to dig into the details with some careful prodding and questioning. Pretty soon, you hit pay dirt. Two of the senior traders are arguing over what something means or the way it works. As you facilitate a discussion to get to a common understanding, you model the solution on the whiteboard—essentially, documenting the agreement. When the main details are worked out, it's time for a coffee break and to reiterate what has been accomplished over some casual conversation. After the session, you transcribe the whiteboard contents into formal models in an appropriate tool.
So, what has been accomplished? It's much more important than the simple start of a business model. You have demonstrated two critical values of the business models themselves. First, you have exposed the fact that, although the experienced and senior people might have thought they knew how things worked, at best, they discovered that they had differing conceptions. Secondly, you have shown how a simple and easy-to-understand—but formal—model can document the business unambiguously.
Over the next few weeks, the modeling sessions increase to two mornings a week, in order to meet the deadline and expanded scope. Before each meeting, you publish the models from the previous meeting. Over time, you introduce two or three more important model concepts (with updated posters). Another interesting thing happens. More senior traders begin to participate—both to learn and to make sure that their understanding of the business gets represented in the model. People who make $500,000+ per year and have no patience for technology are willingly attending your business analysis and modeling sessions!
Fantasy? Other than the fictitious name, this is exactly what happened on my project with an options-trading company. The activity not only produced definitive models of their business, but it also provided the project team with the information and process models they needed to understand the requirements for this and future projects and optimize their implementations.
How did we make that happen?

• Well, first, never assume that business people are stupid or too dumb to understand. Financial options are among the most complicated things I've ever worked on. Those traders were really smart; they just didn't care about the technical details.
• Keep models simple, by limiting the concepts to a very few. We represented the business concepts and entities in pared-down UML class diagrams using only specialization, composition, and dependency relationships. [ISO/IEC 1996]
• Start small. Demonstrate value, and build from there. This cannot be stressed enough. You must demonstrate value—for example, by showing how the modeling activity can expose and resolve differences in understanding of the business.
• Focus on the important things. Any of you who have teenage children understand the wisdom of the saying, "Pick your battles." Architecture is no different. An architect must focus on the aspects of the business that need to be common. Do not try to create an enterprise definition of everything. I cannot think of a single enterprise-wide data-dictionary–type of project that ever worked. Instead, identify the subset needed to support the enterprise business requirements, focus on them, and forget about the rest. At Northwinds, we identified only what needed to be common to support regulatory compliance and some specific application-integration scenarios.
• Know your audience. Talk business to the business people and technology to the IT people. In our business-modeling sessions, we never once discussed how the concepts would be implemented or what technologies, platforms, or systems would be used. But, if you are going to have any credibility, you sure as heck had better be able to talk about those things to the project team.

What Is Business Analysis?

So, what is business analysis (BA), and how does it relate to the job of an architect? According to the International Institute of Business Analysis [IIBA 2006]: "A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals."
In other words, the business analyst acts as a bridge to convey requirements between the business customers and the project-development team. However, the architect is not the same as the business analyst. The architect has a different set of goals and responsibilities. Architecture is not about building a single application, but instead about establishing commonality, such as technology platforms, business entities (like customer), and business processes (like compliance) across multiple applications that are part of a bigger picture. Like the business analyst, the architect acts as a bridge to the individual projects. Those who are tasked with an individual project cannot be expected to know or care about the bigger picture. Instead, the architect has to help the project team and business analyst incorporate the big picture into the current project-analysis activities.
Wikipedia [WIKI 2006] has this to say: "Business analysis, as a discipline, has a heavy overlap with requirements analysis, but focuses on identifying requirements in the context of helping organizations to achieve strategic goals...".
While both BA and architecture are about achieving strategic goals, BA is more focused on the identification and specification of requirements within that strategic context, while architecture is more focused on identifying and specifying those things that must be common across applications to achieve the business and enterprise goals. Obviously, there is overlap, and architecture must work closely with BA in integrating the enterprise requirements into its understanding of the business as a whole. This will call on the architect's ability to talk about technology concerns in a business context.
The business analyst and architect also intersect in the areas of analysis, documentation, and communication of the requirements. Here, architects can bring their analytical skills to bear in applying separation of concerns, abstraction, and identification of roles and responsibilities to create formal, unambiguous, and implementable models of the requirements.
A business analyst is responsible for creating a business model that conveys the business requirements. Unfortunately, there is not really a universal definition of what a business model is. Some business models include goals, organization, key performance indicators, and other high-level concepts. Other models include value chains and business-context diagrams. Yet others contain use-case, business-process, and business-entity or information models. The higher-level models are important for setting the overall enterprise context and are often created by business architects, while business analysis is more project-focused and often produces the last set of models mentioned earlier. We sometimes call this set of artifacts a domain model. For example, the Rational Unified Process [RUP 2001] states: "A domain model provides 'the big picture' of a complex organization. It shows the major business entities, their functional responsibilities, and the relationships among the entities."
The architect has two important contributions to the business or domain model. First, the architect acts as a bridge between the enterprise requirements and the project-specific business requirements. Secondly, they formalize requirements into business models. The exact format of the business model is less important than what it achieves: the specification of business and enterprise requirements, independent of implementation technologies. The attributes that make for good requirements [McEwan 2004] apply also to good business models. Some important attributes of a good business model are that they are:

• Unambiguous. If anything can be interpreted in more than one way, it will be—resulting in inconsistent behavior and information.
• Complete. The model must specify the business rules, processes, and information required to build the system. The architect must ensure that this includes everything that needs to be common across applications. However, do not confuse completeness for detail. The model should contain business information, not implementation detail.
• Consistent. The business model must be consistent with both itself and the enterprise requirements. In addition, it must be kept up to date, as requirements evolve during project implementation.
• Traceable. Processes and entities in the business model should be traceable back to requirements.
• Agnostic. The business model is a statement about the business and specifies what will be implemented. The solution model is a statement about the system and specifies how it will be implemented. You must maintain this important separation of concerns.

The models that we created at Northwinds provided an unambiguous definition of the options-trading business at that company. They were complete in specifying all of the information that needed to be identified and shared to meet the business and enterprise requirements, but they were not overly detailed. We assured consistency and traceability through our analysis process that produced the models and kept them free of implementation detail. Then, we worked with the development team to help them use the models in their development activities.
Although the underlying technologies and applications have changed several times since the original project six years ago, the business models are still in use today and are still providing value. Our team of architects and business analysts worked together with the customer's subject-matter experts to produce the models. The business analysts provided the business knowledge and primary interface with the customer, and the architects provided the critical-thinking and formal-modeling skills necessary to produce the models and to interpret them for implementation across multiple projects. Never forget that an architect's job is not to create architecture, but instead to help development use the architecture to create better applications that fit within a larger context.

Review

Business analysis is the elicitation, collection, and specification of requirements. It is a critical component of the success of any project. Although the business analysts should be putting those requirements into a strategic context, their primary responsibility is for the project. The architect, on the other hand, is responsible for thinking across projects and interjecting enterprise requirements into the business-analysis activities—that is, acting as a bridge between enterprise and project concerns. In addition, an architect can help to better express requirements, in terms of formal models that can be unambiguously implemented by the project-development team.

Critical-Thinking Questions

When involved in business analysis and development of a business model, the architect should keep a few critical questions in mind.

• What information or processes must be specified to meet the cross-application requirements? How is it reflected in the model?
• What is the minimum amount of information necessary to convey the requirements? Does the model specify enough? Are all business rules, shared information, and common processes identified? Does the model try to specify too much?
• Does the model separate business from technology concerns? Is it simple enough to be understood by the business subject experts?
• Is the model internally consistent? Does it provide a consistent level of abstraction and detail? Is it the right level?
• How will the business model provide value to the project and the development team? Can it be implemented? Is the prioritization of activities correct?

Sources

• [IIBA 2006] International Institute of Business Analysis. Body of Knowledge V1.6. Accessed January 10, 2007.
• [ISO/IEC 1996] International Organization for Standardization. "Structure of Management Information: General Relationship Model." ISO/IEC 10165-7:1996.
• [McEwan 2004] McEwan, Scott. Requirements: An Introduction. IBM Developer Works. April 16, 2004. Accessed January 10, 2007.
• [RUP 2001] "Rational Unified Process." IBM Software, 2001. Accessed January 10, 2007.
• [WIKI 2006] "Business Analysis." Wikipedia, 2006. Accessed January 10, 2007.

Glossary

Abstraction—Generalization of content and/or suppression of unrelated detail to allow for a broader view, reduce complexity, or focus on a specific viewpoint.
Business analysis—Elicitation, collection, and specification of requirements to meet business, project, and strategic goals.
Business model—Defines the processes and entities of the business, and identifies what must be common to meet the new system requirements.
Domain model—Provides "the big picture" of a complex organization. Shows the major business entities, their functional responsibilities, and the relationships among the entities.
Separation of concerns—One of the most fundamental principles of architecture. Identifying and keeping independent things uncoupled and independent, so that changes in one do not affect the other adversely.

About the author

Mike Rosen has 25 years of software experience as a developer, product architect, application architect, and enterprise architect. He is a practicing architecture consultant, speaker, and author, as well as Director of Enterprise Architecture for the Cutter Consortium and Co-chair and Editorial Director of SOA Institute.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.

Evaluación del impacto por deficiencia en los requerimientos

Este articulo se basa en un reporte creado por la consultoría AIG, sobre el impacto que tienen la deficiencia en la toma de requerimientos, el reporte presenta hallazgos que fuero recopilados de las encuestas realizadas a mas de 100 grandes compañias norte-americanas en las cuales sus proyectos de desarrollos de sistemas de software son en promedio de un tamaño aproximandamente de $3 millones USD, proyectos que tienen cambios significativos para las compañias considerandose estrategicos.

De los hallazgos mas relevantes que se encontraron en este estudio se tiene:

• Hay un 60% de tiempo y costo que se agrega a los proyectos por las deficiencias en los requerimientos
• Menos de la tercera parte de las compañias estan bien equipadas para realizar una toma de requerimientos y su probabilidad de éxito es mayor en relación a las que no cuentan con este equipamientos
• La suboptimización de la toma de requerimientos cosnume aproximadamente el 41% del presupuesto de los proyectos estrategicos de la compañía

El estudio muestra básicamente dos escenarios, donde uno de ellos pertenece a un grupo de empresas que constantemente realizan más 50%  entregas de proyectos exitosos (en tiempo y costo).

El segundo escenario, son de las compañias que generalmente su probabilidad de falla supera el 50%, en los cuales sus entregables estan por encima del costo y tiempo presupuestado, además entregando funcionalidad por debajo de lo que inicialmente se especifico. Estas compañias no son buenas en la toma de requerimientos.

¿Cuál es la relación entre el Analista de Negocio (BA) y el éxito de los proyectos estratégicos?

Es generalmente implícito que la mayoría de los proyectos estratégicos de un negocio, especialmente aquellos que tienen una visión significativa de cambio operacional,  se retrasen sus entregas o que el presupuesto asignado inicialmente quede muy corto y frecuentemente se entrega con menor funcionalidad con la que se visiono.  Por otro lado hay otros proyectos que son entregados en tiempo y costo y además con las funcionalidades inicialmente indicadas.

¿Qué es lo que distingue el  “Abrumador éxito” de todos aquellos que típicamente fracasan?,  ¿cuál es el Rol que  BA realiza en la determinación del éxito del proyecto? y finalmente ¿cuál es el costo de que los requerimientos sean deficientes o poniendo de manera contraría cuál es el beneficio de tener excelentes requerimientos?

Cada Project Manager tiene su propio nivel de convicción sobre el rol del BA y el impacto que tienen en los proyectos. El dato muestra que las viejas creencias acerca de los requerimientos son incorrectas y conllevan a las compañías a tener una probabilidad de 68% de fracaso de los proyectos, aún antes de que estos sean empezados

“El 68% de las compañías simplemente no utilizan los recursos con las competencias necesarias para la realización del análisis de negocio/sistema, esto pone al descubierto que las mimas compañías son responsables de la probabilidad del fracaso del proyecto y a su vez, gastan +50%   (en costo y tiempo) en la solución que una compañía que tiene mejores recursos en el ámbito de las prácticas de BA”.

En los niveles ejecutivos hay una constante lucha por optimizar recursos y producir los resultados necesarios para lograr los cambios en la organización, la investigación muestra que los ejecutivos buscan las mejoras de procesos y abatir el problema de los pobres requerimientos de manera ineficiente. El resultado indica que el promedio de las organizaciones  consumen más del 41.5% de los proyectos nuevos en una deficiente especificación de requerimientos. Para estos ejecutivos la pregunta es: ¿cuál es el impacto generalizado de un análisis pobre sobre la eficiencia de los entregables?, ¿Cómo organizar para minimizar los gastos?, ¿Cuáles son las optimizaciones que hay que realizar en corto y largo plazo en las iniciativas para obtener mejor eficiencia en los entregables?

Para responder estas respuestas IAG lanzo una encuesta a 100 empresas en las cuales se ha realizado proyectos recientes con costos superiores a los 250,000 USD, dentro de esta encuesta se descubre una relación estrecha entre las habilidades de los BA  como factor generalizado de éxito en los proyectos.

La investigación esta soportada en cuantificables conceptos que se encuentran arraigados en varias  culturas corporativas. Por ejemplo, la mayoría de los managers intuitivamente entienden lo complicado que es recuperarse en un proyecto, si el proyecto cuenta con una deficiente toma de requerimientos (negocio y/o de sistema), sin embargo fracasan en poder obtener buenos requerimientos teniendo impactos negativos en el 66% de los proyectos analizados

Además el 20% de las compañías encuestadas han realizado algún tipo de inversión para lograr excelentes requerimientos de negocio y de software sobre una base que sea repetible y eficiente. Este dato sugiere que mientras que la persona intuitivamente reconoce la necesidad de buenos requerimientos, no asimilan el impacto de los requerimientos deficientes. Es también verdad que los recursos que realizan el tema de requerimientos son vistos como simples documentadores sin tener habilidad de analizar y elaborar modelos que permitan crear buenos requerimientos. Los hallazgos de la encuesta claramente indican que solo aquellas compañías que están comprometidas con la excelencia de los requerimientos de negocio y de sistemas a través de mejoras en sus recursos, procesos y la calidad de su documentación/información mejoran a su vez la predictibilidad de éxito en sus proyectos serán de 70% mayor que de las empresas promedios

                 

• Las compañías que mejoran más de la tercera parte de sus requerimientos del proyecto, tienen una probabilidad mayor al 70% de éxito
• Más de la mitad de sus proyectos son entregados en tiempos y presupuestos con las funcionalidades inicialmente indicadas

(Continuara ....)

Beneficios del Análisis de Negocio

Beneficios del Análisis de Negocio

Comenzare por enmarcar los los principales problemas que tenemos día a día, durante el desarrollo de un proyecto y que en un gran porcentaje, está asociado a la ausencia de las mejores prácticas de Análisis de Negocio, en el siguiente análisis de causa raíz podemos ver las principales causas de falla en los proyectos.

                      

 ¿Cuantas veces hemos sido cómplices de una estimación inadecuada, en donde generalmente se comprometen fechas o entregables, aun no teniendo claro el alcance proyecto?, Está es una de las primeras malas practicas que se tienen en el desarrollo de software y que a menudo se traduce en las largas horas laborales (re-trabajo y esfuerzo mal orientado), absorbiendo los riegos del mismo. Cuando dicho problema pudo haber sido mitigado en gran medida, si tan solo se hubiera hecho un análisis mucho más certero a las necesidades reales del negocio.

En la siguiente imagen del cono de Incertidumbre podemos observar que tanto riesgo se tiene el comprometer el proyecto si este no cuenta con los requerimientos de negocio detectados y aprobados.

"Las compañías de software inapropiadamente sabotean sus propios proyectos al comprometerlos al inicio del cono de la incertidumbre.  Si una organización se compromete en la etapa de concepto inicial o durante la definición del producto el factor de error está estimado entre 2x y 4x. El comprometerlo al principio del cono, hacen que el proyecto tenga una predictibilidad indeterminada, incrementando el riesgo de ineficiencia del proyecto, el deterioro de la administración y el éxito del proyecto. 

Por lo que se recomienda que el compromiso no se realice en dichas etapas, donde la amplitud del cono hace que las organizaciones sean ineficientes y absorban los riesgos de ello. Un buen punto para realizar compromisos puede ser, donde la incertidumbre del proyecto esté cerca del 30% (1.3x), en dicho punto se tiene un mejor control y monitoreo de los entregables y avances del proyecto, mejora sustancialmente la eficiencia de los equipos involucrados en el desarrollo"

• La probre definición de los requerimientos entre el negocio y el área de TI trae como consecuencia un 66% de probabilidad de fracaso
• Las compañías que tiene un proceso débil para la toma de requerimientos tiene tres veces mas proyectos fallidos que exitosos
• La compañías pagan un bono extra de alrededor del 60% en tiempo y presupuesto cuando sus proyectos no cuentan con prácticas de requerimientos.
• La gran mayoría de proyectos no utilizan recursos con suficientes habilidades de análisis de negocio para el desarrollo de los proyectos, trasladando el costo a fases posteriores del análisis, donde el costo se multiplica hasta por 10x para la corrección de fallas.
• Si las personas y procesos para realizar análisis de requerimientos están solamente en el promedio, más que en la excelencia, esta deficiencia de excelencia puede consumir aproximadamente el 41% del pre supuesto asignado del proyecto.
• Standish group ha reportado que los proyecto a gran escala tipicamente se pasan al rededor de 189% en su presupuesto y 222% en el tiempo de entrega, donde los principales factores se debe a las prácticas empleadas para la toma de requerimientos

"It’s a myth that the average analyst can be assigned any project. The evidence here: an average analyst will fail to achieve process reengineering objectives over 60% of the time. Average analysts do not deal well with process change objectives. Their requirements discovery process appears to be fundamentally different than that used by elite analysts. Excellence comes through a rethinking of how requirements are  done."

fuente Project Failure - Dan Galorath, Business Analysis Benchmark

Una combinación entre la mejora de las practicas de Análisis de Negocio y la mejora en los procesos de negocio (CMMi, ISO 9000) han probado, que dan enormes diferencias en la productividad del desarrollo de sistemas dando como resultado los siguientes numeros:

• 67% de reducción en el costo de re-trabajo

• del 30% al 40% de reducción en los tiempos de desarrollo

• 90% reducción en defectos

• 350% incremento de la productividad de los equipos de trabajo

funte  Getting Business Requeriments Right

Un estudio del SEI (Software Engineering Institute) encontró que el factor mas importante para mejorar el desarrollo de sistemas, es como la compañía aplica las disciplinas de Recopilación y Administración de los requerimientos.

Por o anterior y para alcanzar los beneficios, debemos de centrar los esfuerzos en el alcance del proyecto (Visión), involucrar los stakeholders correspondientes y organizar y clasificar los requerimientos con el fin de evitar las ambigüedades y las deficiencias de comunicación de las necesidades de negocio.

Los siguientes factores son vital para el éxito del proyecto

• Tener una metodología disciplinada y repetible para controlar las sesiones de recopilación de requerimientos
• Tener a los Stakeholder correctos e involucrarlos solo en las funcionalidades en los que participen (ser eficientes con los tiempos)
• Utilizar un estrategia modular que permita establecer las responsabilidades y colaboraciones de cada servicio de negocio a implementar
• Contar con herramientas para documentar los requerimientos de manera rápida y validar con los stakeholders.
• Establecer un proceso de autorización (sign-off) en el cual se acuerden los requerimientos funcionales y no funcionales de las líneas bases que serán implementadas

BA como consultor

El BA frecuentemente necesita actuar como consultor. Ser consultor significa, proveer consejos de valor hacia las necesidades o áreas de oportunidad del cliente, de tal forma que cree confianza entre los diferentes “StakeHolders”.

Es importante que durante la consultoría se muestre honestidad, franqueza, apertura, la energía de trabajo y el enfoque dedicado, combinándolo con el conocimiento y experiencia, además de saber apoyarse de los equipos de trabajo para lograr crear un consejo o propuesta que sea factible y de valor tanto para el cliente como para los equipos de trabajo.

Entre las habilidades de consultoría está la de saber escuchar. Algunos rasgos de un buen interlocutor incluye; evitar interrupciones, eliminar distracciones, tiende a preguntar al finalizar la idea de quien está hablando, solo en caso de no tener claro el mensaje, confirma el mensaje que ha recibido (parafrasea la idea), muestra un profundo interés en el tema, busca a través de las pregunta mejorar el entendimiento del mensaje. Una Competencia del BA respecto a la habilidad de escuchar es que saber controlar sus emociones evitando concluir con soluciones durante la entrevista, en lugar de ello deberá de orientar las actividades para posteriormente analizarlas y verificarlas con los equipos de trabajo, con el fin de lograr de manera conjunta la propuesta o la solución que le de valor al cliente

El BA tiene poca autoridad o control sobre los “Stakeholder” del proyecto, sin embargo a través de las propuestas bien argumentadas, podrá persuadirlos con la finalidad de lograr un mejor entendimiento y dimensionamiento del proyecto y evaluar las decisiones iníciales en función de asegurar el éxito del proyecto.

El BA deberá de tener una alta competencia para las presentaciones de información, pudiéndose dirigir a cualquier tipo de audiencia, por lo que deberá de fungir como instructor durante dicha actividad.

El BA durante la fase de evaluación colaborará con los equipos de trabajo, donde explorará las múltiples soluciones y planes que son parte de la propuesta al cliente, por lo que el BA deberá de utilizar su experiencia para identificar los riesgos que puedan tener una opción respecto de otra, un BA efectivo deberá de identificar, cuantificar y comunicar los riegos así como las incertidumbres que provenga del consejo a proveerse.

Mejores Practicas BA (Business Analysis)

Mejores Practicas de Análisis de Negocio (Business Analysis Best Practices)

Estás son el grupo de métodos y técnicas que a través de la experiencia y la investigación son utilizadas de manera consistente para obtener los mejores resultados, estás ha sido probadas y verificadas por un grupo de expertos en el dominio, estás prácticas son utilizadas como un medio de referencia para medir el desempeño así como la calidad de los entregables, sin embargo no existe mejor práctica que pueda cubrir los diferentes escenarios o situaciones, por lo hay de realizarse adaptaciones de las mismas(mejora continua).

Para el caso de las mejoras prácticas en para el Análisis de Negocio, se han publicado un sin fin de libros, artículos y ensayos coincidiendo en toda ves que hay que realizar una con junto de actividades que se enfoquen a recopilar, analizar, documentar y verificar las necesidades del Stakeholder.

El BABOK^® 2.0 (Business Analysis Body of knowledge) es una recopilación de mejores prácticas y las cuales se constituyen como estándares reconocidos a nivel global, con esté grupo de prácticas se pueden medir el nivel de conocimiento y habilidades de las personas que participan dentro del Análisis de Negocio.


Las practicas dadas en el BABOK^® se encuentran divididas en áreas de conocimiento, asociadas con las actividades y habilidades necesarias para su ejecución, en la siguiente figura se resumen las áreas de conocimiento que deben de ser aplicadas como parte de las mejores prácticas de Análisis de Negocio

Business Analysis Planing and Monitoring

Es el área de conocimiento que cubre como el analista determina cuales son las actividades necesarias para completar un esfuerzo de Análisis de Negocio. Esto cubre la identificación de los Stakeholders, la selección de técnicas, procesos y actividades para la administración de los requerimientos, las actividades que se realicen en estar área de conocimiento proporcionarán las reglas de ejecución para las siguientes actividades de análisis.

Elicitation (Recopilación de Requerimientos)

Es la actividad donde el analista deberá de recopilar y entender las necesidades claves de los stakeholder, el ambiente actual del negocio. El propósito es contar con una base de las necesidades del negocio que permitan definir el alcance de la iniciativa, asegurando que las necesidades sean las requeridas mas que las deseadas.

Requeriments Management and Comnunication

Describe como el analista deberá de manejar los conflictos, issues y controles de cambios, con el objetivo de asegurar que son comunicados todos los stakeholder y los miembros del equipo del proyecto estén en común acuerdo sobre la solución dada, además de proveer los procesos para el manejo de los requerimientos y las métricas a utilizarse para el avance de los requerimientos

Enterprises Analysis

Describe como el analista identifica las necesidades de negocio, refina y clarifica la definición de las necesidades halladas, además define, propone la solución en base a la cobertura de los requerimientos detectados, con los cuales habilitara a los equipos de proyecto la implementación de la solución.

Cabe mencionar el el análisis empresarial no es llevado a cabo por una sola persona, sino que es una colaboración multidisciplinaria (Arquitectura, Análisis, Desarrollo y Pruebas) en función que la solución que se provee sea factible y este alineada a los objetivos que busca el cliente, tiempo y esfuerzo.

Requirements Analysis

Describe las actividades a realizar durante la clasificación de los requerimientos, durante este análisis se deberá de bosquejar como los requerimientos son cumplidos o cubiertos por la propuesta de solución, para lo cual se apoyará de diferentes técnicas de modelado que permitan a los stakeholders entender, verificar y validar el cumplimiento de las necesidades claves del negocio.

Este análisis permite a los stakeholders tener una visión clara del estado actual del negocio y evaluar las recomendaciones de mejora que provee el analista en función de cubrir dichas necesidades

Underlying Competences

En esta práctica se describen las habilidades interpesonales que deberá de tener los Analistas de Negocio para poder realizar la ejecución efectiva de las prácticas anteriores.

Estas son :

Pensamiento Analítico, o lógico para abstraer el problema de dominio. (separación de responsabilidades)

Comportamiento (Confiabilidad, Efectividad, responsabilidad, Organización personal, Persuación Ética otras..)

¿Que es el Análisis de Negocio? (What is Business Analysis?)

Que es el Análisis de Negocio (What is the Business Analysis)

Es el conjunto de tareas y técnicas utilizadas para trabajar como enlace entre las necesidades de los Stakeholder, además de estructurar los requerimientos, procedimientos y políticas dentro de un a organización

así como las recomendaciones de solución que habiliten a las organización en alcázar sus objetivos y sus metas.

El Análisis de Negocio (Business Analysis) involucra el entendimiento de como la organización funciona para cumplir con su propósitos, y definir las capacidades que una organización requiere para proveer los productos y servicios hacía los Stakeholders externos. En esto se incluye la definición de las metas de la organización, como las metas se conectan a través de objetivos además determinar las acciones que deberá de emprender la organización para alcanzar las metas y objetivos, y definir como la organización interactua de manera interna tanto como externa.

El Análisis de negocio se ejecuta como parte del entendimiento de la situación actual de la organización (as is), la cual servirá como base para la posterior identificación de las necesidades de negocio. En mayor de los casos, sin embargo se ejecuta para definir y validar la solución que se provee a las necesidades, metas y/o objetivos.

El Análisis de Negocio deberá de analizar y sintetizar la información que se provee de un gran numero de personas, tales como clientes, staff, areás de TI y ejecutivos, el Análisis de Negocio es responsable de recopilar las necesidades de los stakeholder y evaluarlas conforme a las metas y objetivos que se persiguen, con ello se espera tener un orden en la implementación en función de las prioridades de la organización además de detectar la complejidad de cada una de las iniciativas que se proponen como parte de la solución.

El trabajo realizado como parte del Análisis de Negocio proveerá un medio de comunicación entre las partes involucradas, por lo que además cumple con la función de traducción entre las mismas, el Análisis de Negocio debe ser capaz de hablar en términos de dominio y términos tecnológicos.

Actividades

Análisis empresarial o Análisis de Negocio: Se enfoca a entender las necesidades claves del negocio, la estrategia así como las iniciativas que permitirán cubrir las necesidades. para lo cual colabora, como soporte a la organización, teniendo como objetivo reducir los costos, proveer información de calidad, habilitar la eficiencia de los equipos de trabajo además de ser un consejero para el cliente final. Para lo cual deberá de utilizar diferentes técnicas de modelado concentrándose en los elementos que dan mayor valor al cliente y removiendo todo aquello que no sea indispensable.

Recopilación de Requerimientos: como parte de las actividades de la Ingeniería de Requerimientos, la recopilación deberá de realizarse con alguna técnica, la finalidad es proveer las necesidades clave de los Stakeholder.

Análisis de requerimientos: esta actividad pocas veces se le da el tiempo requerido y en ocasiones ni siquiera se realiza. El análisis de requerimientos permitirá establecer la arquitectura del negocio(modelo de negocio) y como estos requerimientos serán incorporados a las operaciones de negocio, en este análisis hay que identificar los elementos que participan (entidades de negocio) sus responsabilidades y colaboraciones. Dentro de este análisis se deberá de estipular la prioridad de su implementación, es muy recomendable que dentro de este análisis se colabore con el arquitecto para identificar las características de calidad.

Comunicación de Requerimientos: Es la actividad en la que se dan a conocer los requerimientos y se acuerdan la prioridad de los requerimientos, esta comunicación se llevará en base a la metodología utilizada, la especificación de los requerimientos deberá de acompañarse de los modelos y restricciones que tienen que cumplir, en esta comunicación se provee el detalle de como este será implementado, por lo que se acompañara de las decisiones tecnológicas por parte del Arquitecto o líder técnico.

Evaluación de la solución y validación: Como parte de los acuerdos se deberá de revisar y evaluar con cada uno de los StakeHolder (en base a la matriz RACI) las especificaciones dadas por el Analista, con esta validación se establece la línea base que los equipos de trabajo utilizarán para la implementación.

Conceptos Claves

Domino : Un dominio es la área que se encuentra en análisis. Esta puede corresponder al entorno a la organización o unidades de negocio, en la cual se requiere hacer una mejora, generar eficiencia o documentar sus procesos actuales.

Solución: La solución es un cambio al estado actual de una organización que se hace con el fin de cumplir con los metas u objetivos de la organización, resuelve un problema o se toma ventaja de una área de oportunidad. El alcance de la solución mas corta que el alcance del dominio dentro del cual se requiere ser implementada, y sirve como base del alcance del proyecto (implementación de sus componentes).

Ejemplos de soluciones están: Desarrollo de aplicaciones a la medida, COTS (commercial off the shelf) productos disponibles en venta, mejora de procesos de negocio, establecer el governance del negocio (Reglas de Negocio), entre otras soluciones...

Requerimientos: 1 .- Una condición que necesita el stakeholder para resolver o alcanzar un objetivo, 2.- Una condición o capacidad que debe de proveer la solución o componente para satisfacer un contrato, estándar, especificación o cualquier otra formalidad impuesta.

El Termino "requerimiento" is uno de los que genera mas discusión dentro la comunidad de Análisis de Negocio, hay muchos debates entre lo que debe o debería de considerarse un requerimiento, y cuales son las características que debe de tener el mismo. Sin embargo en lo que todos concuerdan es que el requerimiento debe de ser bien entendido por todos los involucrados, estar libre de ambigüedad, tener un nivel de abstracción de acuerdo a la audiencia, este puede describir aspectos presentes, pasados o futuros que deben de cumplirse con el fin de lograr los objetivos.

Determinar los Objetivos de la Iniciativa

Como parte de la primer sesión de trabajo es entender la iniciativa, en relación a los objetivos de la organización, llevándose a cabo con el champion de la iniciativa

[Champion es la persona que empuja con los sponsors la iniciativa y que tiene claro la visión de la misma para con los objetivos organización]

Para obtener información de valor se recomienda apoyarse de un cuestionario.

Ejmeplo:

¿Cuáles son los objetivos organizacionales que se buscan con la iniciativa?

¿Este objetivo es parte de los objetivos estratégicos del la Organización ?

¿Qué fue lo que motivo a crear dicha iniciativa?

¿El objetivo está marcado como: Corto, Mediano o Largo plazo?

¿Cuáles son las metas del negocio necesarias para alcanzar el objetivo (puntos que se deben de cubrir)?

¿Cuál es la geografía donde aplica las metas?

¿Como esperan medir los resultados?

¿Quienes o que áreas se involucran y que nivel (Alta, media, baja)?

¿Que hace falta a los servicios actuales para alcanzar las metas del negocio?

¿Cuáles son las restricciones existentes?

¿Cuáles son las Fortalezas, Oportunidades, Debilidades y Riesgos que se tienen hoy en día (SOWT)?

Si del resultado de la entrevista hay dudas o no es claro la visión, hay que sugerir hacer un estudio de los objetivos estratégicos de la organización y utilizar una técnica diferente por ejemplo la de "Pareto" para encontrar cual es el significado de la iniciativa y el valor esperado.

de otra manera, cualquier esfuerzo aplicado será tiempo y costo mal invertido

Al empezar a entender cual es valor que tiene la iniciativa para con el negocio, sabremos como orientar las entrevistas o talleres con los siguientes stakeholder

recomiendo lean un poco sobre Objetivos Organizacionales

Caso de Uso

En la ingeniería de desarrollo de software, el Caso de uso (Use case) es la especificación por excelencia que se utiliza para comunicar los requerimientos funcionales del cliente hacia los equipos de desarrollo y pruebas, teniendo como autor de ello a los Analistas de Sistemas.

Historia

Ivar Jacobson utilizaba una técnica para capturar los escenarios de negocio; estos escenarios describen la interacción entre el actor y el sistema para cumplir un objetivo de negocio.

En 1986 con la integración de Rational Unified Process se establecieron los Casos de uso como estándar para especificación de los requerimientos funcionalidades de un sistema, eventualmente hubieron otros autores que colaboraron en la mejora de esta técnica, en los cuales se incluyen Kurt Bittner, Alistair Cockburn, Gunnar Overgaard y Geri Schneider.

Enfoque del Caso de Uso

El Caso de uso se enfoca a describir una actividad o funcionalidad del dominio(negocio), que es llevada a cabo dentro de un sistema de software.

La narrativa describe paso a paso la comunicación que tiene un actor y las respuestas que provee el sistema, con el fin de conseguir el objetivo

La actividad del dominio, también se le puede señalar como transacción de negocio, con ello se pueden establecer el alcance que deberá de especificarse en el Caso de uso.

Al narrar un escenario de negocio, es evidente que dicha narrativa deberá de estar expresada en lenguaje natural del dominio, por lo que deberá de ser entendible para el actor quien ejecuta, el caso de uso debe de estar libre de cualquier detalle de implementación, solución tecnológica o de usabilidad.

Un escenario o flujo de negocio persigue una y sola una actividad específica dentro del contexto del dominio, dentro de este flujo se incorporan los conceptos de negocio (entidades), relaciones y detalles que el propio domino establece para alcanzar el objetivo.

El flujo principal describe los pasos que el actor sigue para lograr el objetivo de una actividad, sin tener problema alguno para alcanzarlo.

Los flujos alternos serán aquellos pasos requeridos para completar la misma tarea, pero que por ciertas condiciones o restricciones, requieren de un tratamiento especial para lograr el objetivo

Los flujos de excepción son todos aquellos pasos que se realizan a consecuencia del incumplimiento de reglas de negocio, y por lo cual no permiten concluir la tarea, terminando en un punto distinto al planteado por la actividad de negocio.

El estilo con el que especifica el Caso de uso puede variar, en cuanto su redacción y terminología utilizada, esto se debe principalmente a las habilidades y destreza que tiene el analista para plasmar en el Caso de uso, como los requerimientos del negocio.

Sin embargo esta diversidad de redacción puede presentar dudosas interpretaciones a los diferentes tipos de audiencia que utiliza la información.

Por otro lado el nivel de abstracción puede variar, estando a juicio de la persona que lo especifica, sin embargo el nivel de detalle esperado, para cuando la información pase a los equipos de desarrollo y pruebas, debe de ser completa y sin ambigüedad de términos

Condiciones Inicíales

Condición previa que debe cumplirse para que pueda llevarse la ejecución del Caso de uso, recordando que el Caso de uso describe el escenario de una actividad de dominio, por lo que, las condiciones deberán de establecerse con el mismo enfoque.

Las condiciones establecen el estado previo de los conceptos de dominio que serán utilizados dentro de la narrativa de los flujos que describe el Caso de uso

Por ejemplo que el actor este autenticado en el sistema, puede quedar como parte de las guías de uso del sistema, ya que puede no tener valor respecto a la actividad de dominio que pueda describir.

Si por algún motivo no se puede establecer una condición previa desde el contexto de negocio, podrá ser valido el colocar:

"El sistema se encuentra en espera de... " (ver Ejemplo).

Condiciones Finales

Las condiciones finales, son aquellas que están delimitadas por el objetivo propio del Caso de uso, en particular la condición deberá de proveer un valor al actor que lo ejecuta, en estás se incluyen los estados finales de los conceptos de dominio.

Para el caso de los flujos que terminen en algo diferente que el objetivo, como son los flujos de excepción, se deberá indicar en la narrativa.

Flujos

Describen las posibles rutas por las cuales se logra el objetivo o se indican las excepciones

Limitaciones del Caso de uso

El caso de uso se enfoca a detallar la interacción que tiene un actor vs el sistema, desde una perspectiva de negocio, por ende, no provee de manera explícita las cualidades de servicios (Requerimientos no funcionales), además, con el nivel de abstracción que debe de tener el Caso de uso, no se espera que haya especificación de formulas, algoritmos, transformaciones, contratos de comunicación entre sistemas y otros. Para todo lo anterior el proyecto deberá de crear un documento suplementario, con el objetivo de completar los comportamientos y características del sistema esperados por el cliente.

• Plantilla de Caso de uso: la plantilla no asegura la legibilidad o entendimiento de lo que se requiere transmitir, esto tiene una dependencia directa con las habilidades de quien escribe los flujos del caso de uso, además de la mecánica para acotar la operación que se pretende describir.

• Interpretación del Caso de uso: existe una curva de aprendizaje por parte, tanto de los usuarios como de las personas que no hayan seguido un estándar; dejando a cada grupo de lectores su propia interpretación lo que dificulta el entendimiento del negocio.

• Completitud de requerimiento del sistema: El caso de uso provee un 60% de los requerimientos a implementarse, considerando que el nivel de abstracción esta orientado a la perspectiva del negocio. Debido a ello, los equipos de trabajo (Desarrollo, Pruebas) deben de complementar las funcionalidades observadas en el Caso de uso, con la información de los anexos, modelos de dominio, diagramas e información suplementaria; y con esto cumplir con las expectativas del cliente. El Caso de uso será el artefacto a utilizar para encontrar toda la información que está asocia (relacionada); esto está dado por la trazabilidad.

Ejemplo

Caso de Uso	Retirar efectivo del ATM (Automatic Teller Machine)
Objetivo	El actor retira efectivo de su cuenta de bancaria
Pre-condición	El ATM se encuentra en estado de espera de una nueva transacción
	1.- El Casos de uso inicia cuando el cliente inserta su tarjeta en la ranura del ATM. 2.- El ATM lee el código de la cinta magnética de la tarjeta del cliente. 3.- El ATM solicita al cliente que ingrese su clave de identificación. 4.- El cliente ingresa los dígitos de su clave personal. 5.- El ATM verifica que la clave del cliente es correcta 6.- El ATM solicita al cliente que seleccione la transacción de una lista dada. 7.- El cliente solicita "retirar de efectivo". 8.- El ATM solicita al cliente que escoja de una lista la cantidad que desea retirar. 9.- El cliente selecciona la cantidad desea para retirar. 10.- El cliente confirma el retiro de efectivo al ATM. 11.- El ATM verifica que la cantidad a retirar no excede a saldo de la cuenta bancaria. 12.- El ATM dispensa la cantidad del efectivo solicitada por la ranura de salida de efectivo. 13.- El ATM registra el nuevo saldo de la cuenta bancaria del cliente por disposición de efectivo. 14.- El ATM imprime el recibo de retiro al cliente. 15.- El ATM solicita al cliente la terminación de operación de una lista de opciones 16.- El cliente selecciona el cierre de operación en el ATM. 17.- EL ATM regresa la tarjeta del cliente. Fin de Caso de Uso
	Flujos Alternos 2a.- El lector del ATM, no reconoce el código de la tarjeta introducida por el cliente. (Flujo de Excepción) 2a.1 El ATM regresa la tarjeta del cliente. Fin de Flujo 5a.- El ATM detecta que el código ingresado por el cliente no es válido (Flujo de Alterno) 5a.1.- El ATM llevará la contabilidad de intentos de validación de la clave que ha ingresado el cliente. 5a.2.- El flujo continúa en el paso 3 del flujo principal. 5a.1a.- EL ATM detecta que se há realizado el tercer intento en la validación de la Clave del cliente sin exito (Flujo de Excepción) 5a.1a.1.- El ATM envía al cliente un mensaje de que la tarjeta fue retenida 5a.1a.2.- El ATM envía al cliente un mensaje con un número telefónico para seguimiento de retención de tarjeta Fin de Flujo . . . (Continúan otros flujos )

Lecturas recomendadas:

Requerimientos Arquitectónicos

Writing Good Use Case

Directriz para CU