PA1

Gestionar la información para la elaboración de diagramas de clases, de casos de uso, de un proyecto con la notación orientada a objetos.

Diagrama de caso de uso.

Diagrama de clase.

PA3

Aplicar los instrumentos de recopilación de información (encuesta, entrevista, observación, registros) pertinentes para obtener y especificar los requisitos del componente de negocio seleccionado para su desarrollo

PA2

 Tareas de ingeniería de Requisitos

Extracción

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 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. Consiste en 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. 

Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificación de requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos.

Técnicas de la Ingeniería de Requisitos

Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema. El éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma.

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de información que se maneja y cómo es manejada, por otro lado, también es útil analizar las distintas salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas.

Lluvia de ideas

Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea eso no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas.

Prototipos

Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no estén demasiado claros o que no se esté muy seguro de haber entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final. Entonces, para validar los requerimientos se construyen    prototipos.

Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.

El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se eeúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario.

Casos de Uso

Los casos de uso son una técnica para especificar el comportamiento de un sistema. Los casos de uso permiten describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema.

Especificación de requisitos del software

Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).

Las estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.

Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efectúe el software. Ej: el sistema debe emitir un comprobante al asentar la entrega de mercadería.

No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL.

Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedición.

PA1

 Características de los requisitos del Software

La recogida de requisitos de software es la fundación de la totalidad del proyecto de desarrollo software. Por ello, debe de ser clara, correcta y bien definida.

Una completa especificación de requisitos Software debe ser:

• Correcta

• No ambigua

• Completa

• Consistente

• Calificada de acuerdo a la importancia y/o estabilidad

• Verificable

• Modificable

• Rastreable

  Correcta

Una SRS es correcta, sí y solo sí, cada requisito especificado es un requisito que el software debe cumplir.   

  No ambigua

Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.

  Completa

Una SRS es completa, sí y solo sí, incluye los siguientes elementos:

o Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificación del sistema                    debe ser reconocido y tratado.

o Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada                    válidos como inválidos.

o Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS así como la definición de todos los términos y unidades de medida.

  Consistente

Una SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningunos subconjuntos de requisitos ahí descritos se contradicen o entran en conflicto.

  Jerarquizada de acuerdo a la importancia y/o estabilidad

Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito tiene un identificador que indique la importancia o estabilidad del requisito.

  Verificable

Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable.

  Modificable

Una SRS es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la estructura y el estilo. La modificabilidad generalmente requiere que una SRS:

o Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas.

o No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en la SRS).

o Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos.

  Rastreable

Una SRS es rastreable si el origen de cada uno de sus requisitos es claro y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación. Se recomiendan los siguientes dos tipos de rastreabilidad:                                                                                                 

o Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito tiene referencias explícitas a sus fuentes en documentos anteriores. 

o Rastreabilidad hacia enfrente (esto es, a todos los documentos derivados del SRS). Depende de que cada requisito en la SRS tenga un nombre único o número de referencia. Es particularmente importante cuando el software entra en                  operación y mantenimiento. Cuando el código y los documentos de diseño son modificados, es esencial contar con la capacidad para conocer el conjunto completo de requisitos que pueden ser afectados por esas modificaciones.

Requisitos de Software

Debemos intentar entender qué tipo de requisitos pueden aparecer en la fase de educción de requisitos y qué tipo de requisitos se esperan del sistema de software.

En líneas generales los requisitos de software se deben caracterizar en dos categorías:

Requisitos funcionales

Requisitos que se relacionan a aspectos funcionales del software irían en esta categoría. Definen las funciones y la funcionalidad en y desde el sistema de software.

Ejemplos:

• Buscar una opción dada al usuario para buscar desde varias facturas.

• El usuario debe ser capaz de enviar por correo electrónico cualquier informe a la Dirección.

• Los usuarios se pueden dividir en grupos y los grupos pueden tener derechos diferentes.

• Debe cumplir reglas empresariales y funciones administrativas.

• El Software se desarrolla manteniendo intacta la compatibilidad en descenso.

Requisitos no funcionales

Los requisitos, los cuales no están relacionados con aspectos funcionales del software, están en esta categoría. Son características del software implícitas o esperadas, asumidas por los usuarios.

Los requisitos no funcionales incluyen:

• Seguridad

• Acceso

• Almacenaje

• Configuración

• Actuación

• Coste

• Interoperabilidad

• Flexibilidad

• Recuperación de desastre

• Accesibilidad

Los requisitos se categorizan de forma lógica como

• Tienen que tener: El Software no puede ser operacional sin ellos.

• Deben tener: Motivando la funcionalidad del software.

• Pueden tener: El Software aún puede funcionar bien con estos requisitos.

• Lista de deseo: Estos requisitos no contienen ningún objetivo de software.

PA4

 Diagrama de modelo de negocios