Araceli Aguilar Hernández

Grupo: SCO10SB105 Grado: 10mo Cuatrimestre Materia: Ingeniería del Software Tema: Resumen Unidad 3

ANALISIS DE REQUERIMIENTOS
1 INTRODUCCION AL ANALISIS DE REQUERIMIENTO 1.1 Significado de análisis de requerimiento El proceso de entender y documentar este algo se llama “análisis de requerimiento”. En general, los requerimientos expresan que se supone debe hacer una aplicación, por lo común no intentan expresar como lograr estas funciones. Un requerimiento en un nivel con frecuencia se traduce en más de un requerimiento específico en el siguiente nivel más detallado. La salida del análisis de requerimientos es un documento que se conoce como especificación de requerimientos o especificación de requerimientos de software. 1.2 Requerimiento C y requerimiento D El análisis de requerimiento se divide en dos niveles, el primer nivel documenta los deseos y necesidades del cliente y se expresa en lenguaje claro para él, los resultados suelen llamarse “requerimientos del cliente” o “requerimientos C”, la audiencia primaria para los requerimientos C es la comunicación del cliente y la secundaria es la comunicación del desarrollador. El segundo nivel documenta los requerimientos de manera específica y estructurada, esto se llama “requerimientos del desarrollador” o “requerimientos D”, la audiencia primordial de estos es la comunicación del desarrollador y la secundaria la del cliente. Aunque las audiencias principales para los requerimientos C y D son diferentes, los clientes y desarrolladores trabajan juntos para crear productos exitosos. Una manera de asegurar una buena comunicación es hacer que representantes de los clientes trabajen junto con los desarrolladores 1.3 porque deben escribirse los requerimientos Algunos escriben esto para saber qué es lo que hace un programa cuando esté terminado, de cualquier esta parte se ha dejado de hacer, y se preguntan el por qué no reducir el proceso completo a ese documento y la respuesta es que no funcionara. Cada requerimiento debe:  Expresarse de modo adecuado  Ser de acceso sencillo  Numerarse  Acompañarse con pruebas que lo verifiquen  Tomarse en cuenta en el diseño  Tomarse en cuenta en el diseño  Tomarse en cuenta en el código  Probarse aislado  Probarse junto con otros requerimientos  Validarse con las pruebas después de construir la aplicación 1.4 mapa conceptual del proceso de análisis de requerimientos Este tipo de mapas se consulta durante cada iteración. El último paso del mapa reúne los requerimientos D detallados, el equipo recolecta las mediciones delas etapas de este proceso para facilitar la estimación de iteraciones y aplicaciones futuras. IEEE 830-1993 también es un estándar ANSI. La sección 3 del estándar, los “requerimientos específicos” 1.5 retos y beneficios del análisis de requerimientos Un requerimiento defectuoso es muy costoso, se estima que repararlo es entre 20 y 50 veces más costoso si se permite que pase durante todo el proceso de desarrollo. El daño que resulta de una mala experiencia del cliente con la aplicación es un factor por completo adicional al gasto involucrado. El análisis de requerimiento es una necesidad, no un lujo, considere sus efectos sobre las pruebas. La mayor parte de las organizaciones de desarrollo considera las pruebas una necesidad absoluta. Muchas organizaciones no escriben los requerimientos, esto no significa que no los usen, solo quiere decir que los requerimientos existen en la mente de ciertos ingenieros de software

HERRAMIENTAS E INTERNET PARA LOS REQUERIMIOENTOS C El análisis estructurado formaliza el flujo de datos y la descomposición funcional. 2. como bases de datos se denotan por un par de líneas horizontales arriba y debajo de nombre de almacén de datos. su requerimiento principal es la facilidad para encontrar y comprar los artículos que necesitan. Cuanto menos restringido este el problema más requerimientos se obtienen de las personas. Un conjunto desinteresados consiste en los visitantes al sitio. SADT describe el problema más alto nivel funcional como un rectángulo con entradas.1 concepto de operaciones Los clientes desarrollan una visión con frecuencia inconsciente e incompleta de cómo debe operar su aplicación.3 diagrama de flujo de datos para la comunicación con el cliente En un diagrama de flujo de datos. su requerimiento más importante puede ser la ganancia a corto o largo plazo. El administrador del proyecto o el ingeniero ayudan al cliente a aclarar su concepto de operación 3. existen varios tipos de aplicaciones para ilustrar el grado en que los requerimientos se obtienen de las personas y no de otras fuentes.2 caso de uso Concepto creado por Jacobson. Un caso de uso se identifica primero por su nombre y por el tipo de usuario de la aplicación. USO DE METODOLOFIAS. los nodos mostrados como círculos o rectángulos representan unidades de procesamiento. Éste se descompone del siguiente nivel de diagrama de flujo. 2. 2. organizada con cuidado para producir la mejor aplicación. la técnica de análisis y diseño estructurado (SADT) es un enfoque sistemático para manejar las especificaciones del sistema. esto es análogo a la etapa de recolección de necesidades entre un arquitecto y cliente.1 Fuentes de requerimientos Las personas no son la única fuente de requerimientos. Los almacenes de datos lugares donde residen los datos. Esta visión en ocasiones se conoce como el modelo o concepto de operación de la aplicación. De hecho se llevara la idea del caso de uso mucho más allá de los requerimientos C. Consiste en una interacción típica entre un actor y una aplicación. Se hace hincapié en los casos de uso como una manera efectiva de obtener y expresar requerimientos para una amplia variedad de aplicaciones. llamado actor.Araceli Aguilar Hernández Grupo: SCO10SB105 Grado: 10mo Cuatrimestre Materia: Ingeniería del Software Tema: Resumen Unidad 3 2 INTERACCION CON EL CLIENTE 2. como material escrito. Como son fáciles de entender. 3. que a su vez se descompone más. los casos de uso son un medio de comunicación en especial útil con los clientes. Las necesidades del cliente son un poco más sutiles para clasificar que sus deseos. los dueños de la compañía también son interesados.4 proceso de entrevista y documentación Gran parte del análisis de requerimiento es una actividad de persona a persona. Las flechas entre ellos denotan el flujo de los datos y se etiquetan con el tipo de datos. Esto produce una jerarquía de DFD . 3 DESCRIPCION DE LOS REQUERIMIENTOS C (DEL CLIENTE) 3.3 ejemplos de deseos de los clientes Cuando la comunidad de desarrollo inicia el análisis de requerimiento es común que el cliente todavía se encuentre formando los conceptos de lo que quiere y necesita. que es una lista de bancos para la respuesta a una petición para desplegar los detalles de una cuenta 4. restricciones y salidas (diagrama de contexto). El proceso de entrevista a un cliente suele ser costoso ya que consume una cantidad significativa de tiempo de más de una persona. El diagrama completo incluye el almacén de datos “bancos miembros”. En particular. el autor del programa solo selecciona a uno o quizás dos individuos principales para que den sugerencias para el desarrollo. es una forma muy útil de esas interacciones.2 identificación de interesados Las personas que tienen intereses en los resultados de los productos e llaman interesados (stakeholders).

Aunque el proceso de análisis de requerimientos puede tener interacciones durante toda la vida del proyecto.1 Prototipos rápidos. . La construcción de un prototipo rápido es una manera útil de extraer los requerimientos del cliente e identificar y eliminar las partes riesgosas de un proyecto. PROTOTIPOS RÁPIDOS.2 Estudios de factibilidad Algunas veces existe incertidumbre respecto a si los requerimientos propuestos se pueden llevar a la práctica. Esta actualización ocurre durante el ciclo de vida de una aplicación. Se pueden hacer estimaciones más completas de puntos de función. Es una implantación parcial de la aplicación final. El análisis estructural ve la aplicación desde la perspectiva funcional. Algunas personas piensan que muchos requerimientos se pueden constituir a partir de bibliotecas de casos de uso existentes. 6. Un estudio de implantación puede consistir en establecer una simulación del envío de mensajes a la tasa prevista con cierto número de jugadores. Estos estudios son implantaciones parciales o simulaciones de aplicación. existen límites prácticos a esas interacciones. TENDENCIAS FUTURAS Y RESUMEN DE REQUERIMIENTOS C 7. 6. pero también que los desarrolladores se comprometan con un precio sólo después que se congelan los requerimientos.2 Efectos del análisis de requerimientos C en el plan del proyecto Una vez reunidos los requerimientos C se puede actualizar el PAPS. ha sido movido de investigación durante años. Los sistemas en tiempo real pueden describirse de modo efectivo con los diagramas de transición de estados. el cliente necesita conocer el costo del trabajo al principio del proceso. que en general incluye una componente de interfaz gráfica de usuario (GUI) significativa.Araceli Aguilar Hernández Grupo: SCO10SB105 Grado: 10mo Cuatrimestre Materia: Ingeniería del Software Tema: Resumen Unidad 3 cada vez más detallados. Las estimaciones de costo se pueden mejorar una vez analizados los requerimientos C. Esto limita la cantidad de iteraciones para los requerimientos. al igual que las estimaciones derivadas para la programación y mano de obra 7. Después esta se realiza mediante una jerarquía de funciones. y del alcance y naturaleza de la aplicación. se afecta a varios documentos. Por lo común. ACTUALIZACION DEL PROYECTO PARA REFLEJAR EL ANÀLISIS DEE REQUERIMIENTOS C. el proceso de analizar los requerimientos del cliente es bastante formal y garantizado. 5. Una línea de investigación. En general cuando se ejecuta una etapa. El conjunto de documentos es una entidad con vida: debe alimentarse y cuidarse en intervalos regulares durante toda la vida del proyecto. las especificaciones ejecutables necesitan un proceso que convierte los enunciados declarativos en comandos de computadora.1 Requerimientos C y escalas del proyecto Para proyectos grandes. 5. pero con un contenido ficticio. La mejora principal surge de la mayor comprensión de los desarrolladores.1 Tendencias futuras Como el análisis de requerimientos es crucial para la ingeniería de software. Dado que el estilo de los requerimientos es declarativo (enunciando hechos). y se ha usado en muchas aplicaciones. 6. existe un riesgo para todo el proyecto en un lugar de riesgos centrados en los requerimientos específicos. Cuando simplemente no se puede decir si valdría la pena un concepto de aplicación visualizado. la de “especificaciones ejecutables” incluye la especificación de requerimientos de manera que se puedan traducir en forma automática en un código ejecutable. Si aumenta la comprensión se puede ahorrar el costoso re trabajó y eliminar obstáculos futuros en el avance. ESTUDIOS DE FACTIBILIDAD Y PRUEBAS DE CONCEPTO 5. Esta es una implementación parcial o un programa similar al concepto de aplicación. En otras palabras. El lenguaje de programación Prolog es declarativo y ejecutable. Además el proyecto no sería factible. con o sin la orientación a objetos. a veces es posible construir una PRUEBA DE CONCEPTO.