Unidad 2

I N S T I T U T O T E C N O L O G I C O D E

C H I L P A N C I N G O

I N V E S T I G A C I O N 2 U N I D A D :

“ C A P T U R A D E R E Q U I S I T O S ”

I N T E G R A N T E S D E L E Q U I P O :

B E L L O S A L V A D O R B E N I T O

C A S T R O M A R T I N E Z J O R G E L U I S

R O S A S E V A N G E L I S T A L U I S A N G E L

V A Z Q U E Z M O R A N I D I A L I Z Z E T H

V E L A M O R Q U E C H O D I E G O A R M A N D O

1

INDICE

INTRODUCCION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 TIPOS DE REQUISITOS. . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 FUENTES Y DATOS PARA EL ANALISIS DEL SISTEMA. . . . . . . . . . . 7

2.3 SELECCIÓN Y DISEÑO DE INSTRUMENTOS PARA . . . . . . . . . . . 9

LA RECOPILACION DE INFORMACION.

2.4 CAPTURA DE REQUISITOS DE CANDIDATOS . . . . . . . . . . . . . . 11

2.5 SELECCIÓN DE METODOLOGIA DE DESARROLLO . . . . . . . . . . . 13

2.6 MODELO DEL NEGOCIO . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7 MODELO DEL DOMINIO. . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.8 VALIDACION DE REQUERIMIENTOS . . . . . . . . . . . . . . . . . . . 18

2.9 DEFINICION DE PROPUESTA DE SOLUCION . . . . . . . . . . . . . . . 21

CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

BIBLIOGRAFIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2

INTRODUCCION

La captura de requisitos se refiere al acto de descubrir o averiguar en circunstancias difíciles lo que se debe construir. De hecho es tan difícil para los equipos de proyecto que estos empiezan a a escribir código antes de determinar lo que este código debe hacer.

A pesar de las numerosas técnicas existentes en la ingeniería del software, los fracasos en los proyectos de desarrollo de sistemas software se pueden considerar comunes. Con demasiada frecuencia los sistemas se entregan más tarde de lo esperado, con mayor coste del previsto, y no cumplen con las necesidades reales de los usuarios del sistema o de la organización en la que se han de implantar. En la mayoría de los casos, los fracasos no se deben a que las personas que participan en el desarrollo del sistema no sean competentes o a una mala práctica de ingeniería de software, sino que son consecuencia de problemas relacionados con los requisitos del sistema.

Antes de desarrollar cualquier sistema software es necesario comprender qué deberá hacer y cómo dará soporte a las metas. Esta necesidad implica la comprensión del dominio de aplicación, de las restricciones operacionales del sistema, de la funcionalidad y de las características no funcionales del sistema.

La principal medida del éxito y de la calidad de un sistema software es el grado en el que cumple con el propósito para el que fue ideado, es decir, sus requisitos.

3

2.1 TIPOS DE REQUISITOS

FUNCIONALES:

La técnica inmediata para identificar los requisitos del sistema se basa en los caso de uso, estos casos de uso capturan los requisitos funcionales como los no funcionales.

Cada usuario quiere que el sistema haga algo para él es decir lleve a cabo ciertos casos de uso

Para el usuario un caso de uso es un modo de usar el sistema.

En consecuencia si los analistas pueden describir todos los casos de uso que necesita el usuario sabrán lo que debe hacer el sistema.

La captura de los casos de uso realmente necesarios, como aquellos que soportan el negocio y que le permitirá al usuario realizar más cómodamente su trabajo requiere conocer en profundidad las necesidades de los usuarios y clientes, para lo cual se debe conocer el contexto del sistema

NO FUNCIONALES:

Los requisitos no funcionales especifican propiedades del sistema como restricciones de entorno, o implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, extensibilidad, fiabilidad.

Ej. Requisitos especiales para el caso de uso Pagar Factura.

4

Requisito de Rendimiento: Cuando un comprador envía una factura para su pago, el sistema deberá responder con una

Verificación de la solicitud a menos de 0.1 seg. En el 90% de los casos. La duración de esta verificación nunca deberá excederlos 10 seg. A menos que la conexión de red no funcione, en cuyo caso se deberá informar al usuario.

CARACTERISTICAS DE LOS REQUISITOS

Es importante no perder de vista que un requerimiento debe ser:

Especificado por escrito: Como todo contrato o acuerdo entre dos partes.

Posible de probar o verificar: Si un requerimiento no se puede

comprobar, entonces ¿cómo se sabe si se cumplió con él o no?

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su

redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

Completo: Un requerimiento está completo si no necesita ampliar detalles

en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

Consistente: Un requerimiento es consistente si no es contradictorio con

otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola

interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector

Para llevar a cabo las actividades de los requisitos deben de pasar por 4 etapas o fases para que se lleven a cabo para a completar los procesos:

Extracción

5

Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc.

Es importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuan bien éste satisfaga las necesidades del cliente.

Análisis

Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento.

Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.

Especificación

En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle.

En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientos.

Validación

La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.

6

2.2 FUENTES DE DATOS PARA EL ANALISIS DEL SISTEMA:

Los objetivos específicos de la gestión de datos son:

Obtener los datos y prepararlos para el análisis

El sistema de gestión de datos incluye la supervisión del flujo de datos desde los sujetos de investigación a los analistas de datos. Antes de poder analizarlos, los datos deben ser recogidos, revisados, codificados, computarizados, verificados, confirmados y convertidos a formularios adecuados para llevar a cabo el análisis. El proceso debe ser adecuadamente documentado para fundamentar el análisis e interpretación.

Mantener el control de calidad y la seguridad de los datos

Las amenazas con respecto a la calidad de los datos surgen en todos los puntos en que se obtienen y/o modifican datos. El valor de la investigación se verá muy afectado por el control de calidad, pero lograr y mantener la calidad requiere actividades que a menudo son banales y difíciles de motivar. El control de calidad incluye:

Prevenir y detectar errores en los datos a través de procedimientos escritos,

entrenamiento, procedimientos de verificación, y evitando complejidades innecesarias.

Evitar o eliminar las inconsistencias, errores, y datos faltantes a través de la

revisión de los formularios de recolección de datos (en forma ideal cuando el acceso a las fuentes de los datos aún está disponible para permitir

7

resolver las dudas) y los conjuntos de datos.

Evaluar la calidad de los datos a través de los apuntes de los

entrevistadores, codificadores, editores de datos, a través del interrogatorio de los sujetos, y a través de revisiones o repeticiones de la recolección de datos para sub-muestras

“Sentir” los datos, evitar interpretaciones equivocadas y descuidos

importantes.

Permitir las solicitudes de información, revisión, reconstrucción, y archivo

En cualquier momento durante y hasta después de que se completa el proyecto puede surgir la solicitud de los instrumentos y/o de los datos o preguntas sobre los mismos. La agencia financiadora requerirá un informe final.

8

2.3 SELECCIÓN Y DISEÑO DE INSTRUMENTOS PARA LA RECOPILACION DE INFORMACION.

Herramientas para Análisis:

Estas herramientas ayudan a los especialistas en sistemas a documentar un sistema existente, ya sea éste manual o automatizado, u a determinar los requerimientos de una nueva aplicación.

9

Herramientas para la recolección de datos:

Capturan detalles que describen los sistemas y procedimientos en uso. Documentan procesos y actividades de decisión. Se utilizan para apoyar la tarea de identificar requerimientos.

Herramientas para la diagramación:

Crean representaciones gráficas de sistemas y actividades. Apoyan el dibujo y revisión de diagramas de flujo de datos e iconos asociados con el análisis estructurado. Asimismo incluyen programas para representación en diagramas de flujo.

Herramientas para el diccionario:

Registran y mantienes descripciones de los elementos del sistema tales como grupos de datos, procesos y almacenamiento de datos. Con frecuencia proporcionan la capacidad de examinar las descripciones del sistema para decidir si son incompletas o inconsistentes.

MÉTODOS PARA LA OBTENCIÓN DE INFORMACIÓN:

Todo análisis y diseño de un sistema implica la búsqueda y obtención de información relevante para la estructuración y definición de problemas, generación de soluciones, validación de soluciones, etc.La información en una organización no siempre es fácil de obtener, más bien es un proceso lento y costoso, que exige tiempo y dedicación por parte del analista de sistemas. Las fases de búsqueda de información en cualquier proyecto, suelen ser grandes consumidoras de tiempo, y el éxito de los resultados depende en gran medida de la calidad de la información.Es muy común que la información requerida no se encuentre escrita, o inclusive que ésta no se conozca. Esto hace necesaria la interacción del analista con las personas del sistema para identificar y/o generar la información faltante.

Si se cuenta con información escrita formal y adecuada utilícelas, le ahorraría tiempo y le facilitaría la comprensión del sistema.Existen métodos básicos para recopilar información dentro de una organización o sistema social.

10

Estos incluyen

a) Cuestionariosb) Entrevistasc) Sondeosd) Encuestase) Collagef) Dibujosg) Diagramas de flujo de datosh) Tablas de Organizacióni) Descripción de puestosj) Manuales Operativos.k) Representación física de las Organizaciones.

2.4 CAPTURA DE REQUISITOS CANDIDATOS

Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un modelo del negocio o partimos de uno ya desarrollado. En otros casos si es un sistema acotado que no da soporte al negocio podemos partir de un modelo de objetos sencillo como un modelo del dominio. En otros casos el cliente puede ya haber desarrollado una especificación

11

completa de requisitos no basada en objetos, de la cual podemos partir. En forma típica, el flujo de trabajo de requisitos incluye los siguientes pasos:

Enumerar los requisitos candidatos. Comprender el contexto del sistema. Capturar requisitos funcionales. Capturar requisitos no funcionales

Enumerar los requisitos candidatos

La lista de características deseadas del sistema constituyen los requisitos candidatos. De cada característica se registra:

Nombre corto Descripción Estado (propuesto, aprobado, incluido, o validado) Coste estimado de implementación (en término de tipos de recursos y

horas- hombre) Prioridad (crítico, importante, o secundario) Nivel de riesgo asociado a la implementación de la característica (crítico,

significativo, ordinario)

Estos valores se utilizan para estimar el tamaño del proyecto y decidir cómo dividirlo en secuencia de iteraciones. La prioridad y nivel de riesgo asociados por ejemplo, se utiliza para decidir en qué iteración se implementará la característica.

Comprender el contexto del sistema

Hay por lo menos dos aproximaciones para expresar el contexto de un sistema: modelado del dominio y modelado del negocio. Un modelo del dominio describe los conceptos importantes del contexto como objetos del dominio relacionados entre sí. Un modelo del negocio es más amplio. Describe los procesos con el objetivo de comprenderlos. El modelado del negocio especifica que procesos de negocio soportará el sistema

Capturar requisitos funcionalesLos requisitos funcionales son capturados por medio de casos de uso, que conforman el modelo de casos de uso. Los casos de uso también capturan requisitos no funcionales específicos de un caso de uso determinado

Capturar requisitos no funcionales

12

Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementación, rendimientos, etc. Hay requisitos no funcionales específicos para un caso de uso y otros genéricos para la aplicación. Los que son específicos para un caso de uso, pueden documentarse junto con el caso de uso correspondiente. Los que son más genéricos se documentan por medio de una lista de requisitos adicionales.

2.5 SELECCIÓN DE METODOLOGIA DE DESARROLLO

La buena selección metodologías; y también el buen desarrollo software; es producto o resultado de una buena selección de estándares y normas para trabajar mediante una Metodología de Desarrollo de Software fija. En la actualidad, la experiencia en el área de la Informática me ha permitido comprender que el diseño y el desarrollo de software no es una tarea sencilla, por mucho tiempo esta labor se ha llevado adelante sin una metodología definida.

13

Sabemos por conocimiento puramente profesional que las metodologías tradicionales se basan en normas provenientes de estándares seguidos por el entorno de desarrollo; con una fuerte y cierta resistencia a los cambios donde todo se encuentra impuesto externamente y poseen un proceso muy controlado, con numerosas normas. Pero eso no es todo, dichas metodologías tradicionales necesitan un contrato prefijado donde el cliente interactúa con el equipo de desarrollo mediante reuniones con grupos grandes los cuales requieren de más artefactos y el resultado final se basa en la arquitectura del software es esencial.

Las metodologías agiles son todo lo contario. Se basan en heurísticas provenientes de prácticas de producción de código; total y completamente preparados para cambios durante el proyecto las cuales son impuestas internamente por el equipo con proceso menos controlado, con pocos principios. Así como también con un contrato flexible e incluso inexistente, donde el cliente es parte del desarrollo y los grupos son pequeños por lo que se incluyen pocos artefactos y existe un menor énfasis en la arquitectura del software.

antes de desarrollar un producto software, necesitamos comprender la visión del producto, la cual podemos obtenerla en base a la vinculación con el cliente, y un previo establecimiento del modelo de ciclo de vida del software, así como la gestión de los requisitos, el plan de desarrollo y también la parte de la integración del proyecto. Esto nos permitirá tener un amplio panorama donde podremos ver las medidas de progreso del proyecto, así como las métricas para evaluar la calidad, las maneras de medir el riesgo, y saber con ello como gestionar los cambios y así establecer una línea de meta; lo que nos ayuda para poder seleccionar una metodología de desarrollo de software; pues al ver lo que realmente necesitamos, podremos ver que es lo que nos proporciona una metodología tradicional y una ágil, independientemente de cuál seleccionemos para llevar a cabo el desarrollo de nuestro software, ya que tenemos variedades de metodologías tanto tradicionales como agiles. Lo que se debe tener claro es que, para tener una selección optima de metodología, este aspecto no ha sido tratado de manera adecuada, sobre todo en el ámbito de las metodologías tradicionales, y en el caso de las ágiles no existe un criterio unificado para poder llevar una debida selección de la metodología a tratar para poder desarrollar un software de calidad. Ahora bien por lo anteriormente mencionado podemos tener una guía de orientación, o una formulación inicial para la debía selección, el cual puede llenar las expectativas base del cliente, que es un coste del desarrollo inicial relativamente bajo, con un software fácil de mantener, portable a nuevo hardware

14

y sobre todo que haga lo que el cliente quiere, ya que en base a la información existente a la fecha y a la experiencia personal, puedo decir que la formulación para poder seleccionar una buena metodología se basa en una buena selección por criterios de expertos y por conocimiento de desarrollo en la rama de los analistas y diseñadores que nos guie a la pura necesidad del cliente y la metodología que se acople a dicha necesidad.

2.6 MODELO DEL NEGOCIO

 Un modelo de negocio, también conocido como diseño de negocio, es la planificación que realiza una empresa respecto a los ingresos y beneficios que intenta obtener. En un modelo de negocio, se establecen las pautas a seguir para atraer clientes, definir ofertas de producto e implementar estrategias publicitarias, entre muchas otras cuestiones vinculadas a la configuración de los recursos de la compañía.Se propone un marco formado de los siguientes bloques:

Segmento de clientes.

15

Propuesta de Valor. 

Canales de distribución. 

Relaciones con clientes.

Flujos de ingresos.

Recursos claves.

Actividades claves. 

Red de proveedores. 

Costo de la estructura.

Existen distintos tipos de modelo de negocio. El más básico y antiguo es conocido como el modelo del tendero, que consiste en instalar un negocio en el lugar donde deberían encontrarse los clientes potenciales, y allí desplegar la oferta de productos y servicios.

El modelo del cebo y el anzuelo, desarrollado a comienzos del siglo XX, supone la oferta de un producto básico a bajo precio, incluso soportando pérdidas (el cebo), para después cobrar precios excesivos por los recambios o insumos asociados (el anzuelo). Este modelo de negocio es muy común en el negocio de las impresoras,

16

que tienen un costo muy bajo en comparación al de los cartuchos de tinta.

Las innovaciones en los modelos de negocios son cada vez más frecuentes en la economía actual, donde todos los sectores son muy dinámicos. Encontrar el modelo de negocio adecuado resulta una ventaja competitiva para las empresas.

En algunos casos, las empresas parecen funcionar con éxito pero, en realidad, no está claro su modelo de negocio. Por lo tanto, no se define con precisión cómo esas empresas van a obtener sus ingresos y ser rentables. Ese es el caso de muchos sitios de Internet, que consiguen millones de visitantes y se vuelven muy populares, pero que no tienen el modelo necesario para garantizar su éxito financiero.

2.7 MODELO DEL DOMINIO

Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con

las reglas de UML durante la fase de concepción, en la tarea construcción del

modelo de dominio, presentado como uno o más diagramas de clases y que

contiene, no conceptos propios de un sistema de software sino de la propia

realidad física.

Los modelos de dominio pueden utilizarse para capturar y expresar el 17

entendimiento ganado en un área bajo análisis como paso previo al diseño de un

sistema, ya sea de software o de otro tipo. Similares a los mapas mentales

utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como

un medio para comprender el sector industrial o de negocios al cual el sistema va

a servir.

Brainstorming y refinamiento: Es una filosofía basada en las metodologías ágiles y, como éstas, propone que la conversación sea el medio de comunicación para compartir información de la forma más rápida y eficiente.

Un Modelo de Dominio borrador: En base a la conversación se puede ir construyendo un esbozo de lo que será el modelo de dominio. El experto irá corrigiendo lo que a él le parezca que no está correcto y desarrollador y experto llegarán a un acuerdo.

Un Diagrama de Clases temprano: Con este modelo de dominio borrador, podemos construir una versión early de un diagrama de clases.

Un Prototipo muy simple guiado por un framework de automatización

18

de pruebas: Esto es, sentarse y, con el esbozo del diagrama de clases y el modelo de dominio, construir un prototipo bien simple del dominio.

Feedback del Prototipo: El experto de dominio interactuará con el prototipo, revisando si las reglas de negocio son correctas, si el sistema hace lo que debe hacer y, en base al feedback recibido, el equipo corregirá el modelo de dominio, lo mejorará y lo refinará. Así, volverá a corregir el prototipo y también el modelo de dominio.

Este proceso se repetirá hasta que el modelo, el diagrama y el prototipo sean correctos.

2.8. VALIDACIÓN DE REQUERIMIENTOS.

La validación de requerimientos, trata de mostrar que estos realmente definen el

sistema que el cliente desea. Coincide prácticamente con el análisis ya que este

implica encontrar problemas con los requerimientos. La validación de

requerimientos es importante debido a que los errores en el documento de

requerimientos pueden conducir a importantes costes al repetir el trabajo cuando

son descubiertos durante el desarrollo o después de que el sistema esté en uso.

El coste de arreglar un problema en los requerimientos haciendo un cambio en el

sistema es mucho mayor que repara los errores de diseño o los de codificación. La

razón de esto es que un cambio en los requerimientos normalmente significa que

el diseño y la implementación del sistema también deben cambiar y que este debe

probarse nuevamente.

Durante el proceso de validación de requerimientos, se deben llevar a cabo

verificaciones sobre requerimientos en el documentó de requerimientos. Estas

verificaciones comprenden:

1. Verificaciones de validez. Un usuario puede pensar que se necesita un

sistema para llevar acabo ciertas funciones. Sin embargo, el razonamiento

y el análisis pueden identificar que se requieren funciones adicionales o

diferentes necesidades, y cualquier conjunto de requerimientos es

19

inevitable un compromiso en el entorno del stakeholder.

2. Verificaciones de consistencia . Los requerimientos en el documento no

deben contradecirse. Esto es, no deben haber restricciones o descripciones

contradictorias de la misma función del sistema.

3. Verificación de completitud . El documento de requerimientos debe incluir

requerimientos que definan todas las funciones y restricciones propuestas

por el usuario del sistema.

4. Verificaciones de realismo. Utilizando el conocimiento de la tecnología

existente, los requerimientos deben verificarse para asegurar que se

pueden implementar. Estas verificaciones también deben tener en cuenta el

presupuesto y la confección de agendas para el desarrollo del sistema.

5. Verificabilidad . Para reducir la posibilidad de discusiones entre el cliente y el

contratista, los requerimientos del sistema siempre deben redactarse de tal

forma que sean verificables. Esto significa que deben poder escribir un

conjunto de pruebas que demuestren que el sistema a entregar cumple

cada uno de los requerimientos especificados.

Pueden utilizarse, en conjunto o de forma individual, varias técnicas de validación

de requerimientos:

1. Revisión de requerimientos. Los requerimientos son analizados

sistemáticamente por un equipo de revisores. Este proceso se trata en la

siguiente sección.

2. Construcción de prototipos. En este enfoque de validación, se muestra un

modelo ejecutable del sistema a los usuarios finales y a los clientes. Estos

pueden experimentar con este modelo para ver si cumple sus necesidades

reales.

20

3. Generación de casos de prueba. Los requerimientos deben poder probarse.

Si las pruebas para estos se conciben como parte del proceso de

validación, a menudo revela los problemas en los requerimientos. Si una

prueba es difícil o imposible de diseñar, normalmente significa que los

requerimientos serán difíciles de implementar y deberían ser considerados

nuevamente. Desarrollar pruebas para los requerimientos del usuario antes

de que se escriba código es una parte fundamental de la programación

externa.

Se deben llevar a cabo diferentes tipos de verificación:

Verificación de validez

Verificación de consistencia

Verificación de integridad

Verificación de realismo

Verificabilidad

Técnicas de validación:

Revisiones de requerimientos

Construcción de prototipos

Generación de casos de prueba

Análisis de consistencia automático (CASE, BD requerimientos)

2.9 DEFINICION DE PROPUESTA DE SOLUCION

Esta fase se ocupa de la reunión y estudio a detalle de los datos del sistema en operación y la especificación de los nuevos requerimientos del sistema a desarrollar.Con la recopilación de datos se completan los datos resultantes de la fase 1, añadiendo detalles sobre el sistema actual. Son medios comunes para acometer tal recopilación: Las entrevistas, cuestionarios, encuestas a usuarios finales, así como también, las consultas a documentos y manuales que contengan

21

lineamientos de funcionamiento o normas de procedimientos de operación. Existen varias técnicas y herramientas útiles para el análisis de datos. Una de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la organización de manera gráfica. Estos diagramas sirven para desarrollar el llamado diccionario de datos, el cual contiene la definición de los datos usados en el sistema, así como sus características de tipo, tamaño, limitaciones o especificaciones especiales. La documentación de la etapa de análisis recoge la descripción del sistema de información en uso, los requerimientos para el nuevo sistema y un probable plan de desarrollo en un reporte dirigido a la gerencia. Este reporte permite tomar la decisión de proseguir o no con el proyecto. El aspecto más importante de cualquier propuesta es identificar y comprender el problema que el cliente busca resolver. Uno de los puntos del desarrollo de una propuesta de solución es presentar una noción propia del problema, así como la propuesta para resolverlo, con el fin de convencer al cliente de que tal propuesta es la mejor. Para ello, se presentara lo que implica una descripción de los problemas:

1.- La Naturaleza del problema.2.- La historia del problema.3.- Las características del problema.4.- Las soluciones alternas consideradas.5.- La solución o la técnica seleccionada.

CONCLUSION

Como ya hemos visto una correcta captura y gestión de los requisitos de las aplicaciones permite reducir el tiempo de los proyectos. Esto supone mejorar el time to market, fundamental dada la competitividad de hoy en día, y reducir costes, implicando a menos recursos en la fase de desarrollo y pruebas.

Ya comprendimos que Un requisito es una característica de un sistema De información que representa una “condición para su aceptación por parte del usuario. Una

22

administración ineficiente de los requisitos, o inconsistencias entre éstos y el diseño y la programación de las aplicaciones hace que se generen los errores más Costosos y complicados de resolver de las aplicaciones, ya que afectan a la concepción de las mismas en su conjunto.Actividades como la especificación y la gestión de requisitos del usuario deben ser consideradas como unas de las más críticas dentro de todo el proceso de desarrollo, ya que no sólo es necesario identificar y especificar correctamente esos requisitos, sino que además es necesario realizar un seguimiento de su Aplicación durante todo el ciclo de vida del proyecto.

REFERENCIAS

“Ingeniería de software: un enfoque práctico” Roger Pressman, VI edición, 

Sommerville Ian, 2005, “Ingeniería del Software”, Sétima edición, México

DF, Editorial Pearson.

http://elblogdelfrasco.blogspot.mx/2009/02/ddd-parte-1-poniendo-el-modelo-

23

de.html

http://manuelgross.bligoo.com/que-es-un-modelo-de-negocio-la-fuente-de-

tu-competitividad

http://www.itescam.edu.mx/principal/webalumnos/sylabus/asignatura.php?

clave_asig=IFF-1005&carrera=IINF-2010-220&id_d=57

http://losinformaticos213.blogspot.mx/2009/03/aplicacion-de-la-toma-de-

decicisones-en.html

http://rzamurianos.wordpress.com/2011/06/12/introduccin-al-flujo-de-

requisitos/

http://synergix.wordpress.com/2008/07/10/modelo-de-dominio/

http://gracielaresendiz04.blogspot.mx/2010_04_01_archive.html

24