Ejemplos Unidad N°. 2.

Unidad N°2 Repuestas

Requerimientos funcionales y no funcionalesLos requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.

Los requerimientos funcionales

definen las funcionesque el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

Los requerimientos no funcionales

tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Características de los requerimientos

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo.

A continuación se presentan las más importantes.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

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.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación:

inspección, análisis, demostración o pruebas.

Requerimientos del producto

Estos son los comportamientos del producto;

• Panorama general

• Metas

• Funciones del sistema

• Atributos del sistema

Requerimientos externos Los factores anexos al sistema como la destreza de los usuarios durante su uso otros puedes ser rapidez del equipo Requerimientos del dominioSon requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio.

Éstos pueden ser funcionales o no funcionales.

Requerimientos del usuario y del sistemaAlgunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre los diferentes niveles de descripción. Esto se hace utilizando requerimientos del usuario para determinar los requisitos abstractos de alto nivel, y requisitos del sistema, para designar la descripción detallada de lo que el sistema debe hacer. De igual forma que en estos dos niveles de detalle, se puede producir una descripción más detallada para establecer un puente entre la ingeniería de requerimientos y las actividades de diseño.

Los requerimientos del usuario, los del sistema y la especificación del diseño de software se definen de la siguiente manera:

Requerimientos del usuarioSon declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar. Los requerimientos del sistemaEstablecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software. Lenguaje o notación usada en la especificación de requerimientos.El lenguaje o notación usada para la especificación de requerimientos por excelencia es el UML (Lenguaje de modelado unificado), Diagrama de caso de uso.Los diagramas de Casos de Uso describen o especifican lo que hace un sistema desde el punto de vista de un observador externo, enfatizando el qué más que el cómo. (Ver Fig. No. 1). Diagrama de Estados y Diagrama de ActividadesLos diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado.Ejemplo de especificación de requerimientos usando los diagramas de Casos de uso y actividadSe desea especificar los requerimientos de un sitio web para el intercambio y comunicación de información de la comunidad de la especialidad de informática del IUTM-UPM.

Luego de efectuar la respectiva extracción de requerimientos con entrevista a los diferentes representantes de los actores involucrados en el sistema, se obtuvo para el actor ALUMNO el siguiente caso de uso (Ver Fig. 8)

Diagrama de CASO DE USO DOCUMENTACION GRAFICA Diagrama ActividadUso Logearse como administradorNotación textual de los requerimientosEn las secciones anteriores se ha establecido los requerimientos de manera grafica con el lenguaje de modelado UML, específicamente con los diagramas de casos de uso y actividades, pero es necesario para la comunicación efectiva con los usuarios e interesados en el futuro sistema describir textualmente, lo plasmado en figuras. A continuación se muestra la notación textual para el caso de uso del actor alumno REGISTRARSE EN LA WEB.DOCUMENTACIÓN TEXTUALActor ADMINISTRADORUso Ingresar Al Sistema RFA0011. Descripción Breve A través de este caso de uso, el sistema le permite al administrador accesar al sistema en el Sitio Web

2. FLUJO DE EVENTOS

2.1 Pre condiciones El administrador se le fue asignado su clave de acceso 2.2 Flujo Principal2.2.1 Ingresar datos

2.2.2 El administrador escoge la opción “ingresar” y el sistema muestra una plantilla vacía con los campos de datos siguientes.o NOMBRE DE USUARIO (Obligatorio)o CONTRASENA (Obligatorio)

2.2.3 Luego de llenar la plantilla el Administrador procedera al seleccionar o pulsar el botón “ACCEDER”

2.2.4 Se verifica las excepciones y si no las hay se accesa al sistema

2.3 Flujo Alterno

2.3.1 Selecciona “SALIR DEL SISTEMA”, sale del sitio

2.4 Flujo de excepciones

E1 En blanco cualquier campo obligatorio

E2 Usuario existente o registrado en la Base de Datos

E3 Clave suministrada erradaRESUMEN DE ESPECIFICACION FUNCIONAL Uso Ingresar al sistema RFA001ID RFA-001Descripción A través de este caso de uso, el sistema le permite al administrador accesar al sistema Entrada o NOMBRE DE USUARIO (Obligatorio)o CONTRASENA (Obligatorio) Salida Mensaje de excepcionesIngreso al sistemaSalir del sistemaExcepciones

E-1 En blanco cualquier campo obligatorio.

E-2 Clave suministrada errada

E-3 Campos Nombres y Apellidos con númerosObtener o escribir requerimientos de alta calidadEn todas las técnicas involucradas descritas en la unidad I de la ingeniería de requerimientos, las actividades y características resaltantes para obtener o escribir

requerimientos de alta calidad son los siguientes.

• Ofrecer un sistema que tenga la posibilidad de crecer al igual como crecen las necesidades de los usuarios.

• Minimizar el tiempo de respuesta a los reclamos efectuados por los usuarios del servicio.

• Aproximar la celeridad de respuesta a los reclamos de acuerdo a la magnitud y naturaleza del mismo

• Optimizar y disminuir la mala utilización del recurso de agua potable.

• Ofrecer a la comunidad tranquilidad con la eficiencia del servicios de agua potables y servidasClasificar los requerimientos:En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las necesidades que tenga el negocio.En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. Un requerimiento es mandatorio si afecta una operación crítica del negocio. Si existe algún proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario.Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo deseable.

Evaluar factibilidades y riesgos:

Involucra la evaluación de factibilidades técnicas

(¿pueden implementarse los requerimientos con la tecnología actual?);

factibilidades operacionales

(¿puede ser el sistema utilizado sin alterar el organigrama actual?);

factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).

Los requerimientos cambian por diferentes razones.

Las más frecuentes son:

• Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas.

• Porque cambió el problema que se estaba resolviendo.

• Porque los usuarios cambiaron su forma de pensar o sus percepciones.

• Porque cambió el ambiente de negocios.

• Porque cambió el mercado en el cual se desenvuelve el negocio.

Ejemplo de Ing. de Requerimiento Und. N°1

Ejemplo de Caso de Uso Und. N° 1

Requerimiento de SoftWare unidad N° 1

Unidad I Requerimiento de Software.

1.Que es un Requerimiento:

R= Un requerimiento puede definirse como un atributo necesario dentro de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales. Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto, Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.Los requerimientos se pueden clasificar en:
Requerimientos Indicados: son los entregados por el usuario al comienzo del proyecto.
Requerimientos Reales: son aquellos que reflejan la satisfacción de las necesidades del usuario en un sistema en particular.

Por Ejemplo: La parte más dura en la construcción de un sistema software es decidir cómo construirlo…Ninguna parte del trabajo mutila el resultado del sistema si está hecho mal. Ninguna parte es más dificultosa para rectificarlo después. La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. Los requerimientos para un sistema de software determinan lo que hará el sistema y definen las restricciones de su operación e implementación.

2.Que es la Ingeniería de Requerimientos:

R= “La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema”. Tambien se necarga de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniería de requerimientos. Se utiliza para definir todas las actividades involucradas en el sistema, se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto de software determinado.Por Ejemplo: Requerimientos del Sistema de Producción En esta etapa la organización aborda los requerimientos del usuario, y los expresa en especificaciones viables, cubriendo las siguientes etapas.La verificación de la factibilidad del Sistema, respondiendo a las inquietudes siguientes.

•La consistencia con la política de la organización y sus objetivos.

•La importancia del producto o servicio para el futuro de la organización.

•Las posibilidades de llevarlo adelante en forma exitosa.

•La integración con otras tareas que desarrolla la organización.

•El contexto social con el que se relaciona el sistema de producción. El análisis de los requerimientos expresados en un modelo del sistema de producción. Con ello, la organización depura los planteamientos de los clientes, supera los posibles conflictos, prioriza las tareas, y está listo para elaborar los requerimientos del sistema.La especificación de los requerimientos del sistema como la base para su diseño y desarrollo.

3.Cual es la Importancia de la Ingeniería de Requerimientos:

R= La ingeniería de requerimientos es un Importante proceso que comprende todas las actividades para crear y mantener los requerimientos de un sistema.Comprende cuatro actividades de alto nivel:

1.Estudio de factibilidad

2.Obtención y análisis de requerimientos

•Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.

•Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

•Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo.

•Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, y otros)

•Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

•Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Por Ejemplo: El Documento de RequerimientosAmbos requerimientos así estudiados, pueden compendiarse en un Documento de Requerimientos, para lo cual puede ser útil un esquema como el siguiente. Alcances:

•Objeto del Documento de Requerimientos

•Producto o servicio a que se refieren los requerimientos. Requerimientos del Usuario

•Finalidad del producto

•Características del producto que son requeridas.

•Restricciones previsibles del producto. Requerimientos del Sistema

•Importancia para la organización.

•Exigencias del sistema productivo.

•Atributos viables.

•Restricciones del sistema.

4.Cuales son las Actividades:

R= Se dice que dentro de la IR existen cuatro actividades básicas que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene para el desarrollo de un proyecto de software realizar una especificación y administración adecuada de los requerimientos de los clientes o usuarios. Las cinco actividades son: extracción, análisis, especificación, validación y evolucion, y serán explicadas a continuación cada una de ellasExtracción (Análisis del problema)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 y otros. Es importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuán bien éste satisfaga las necesidades del cliente.Análisis (Evaluación y negociación de los requerimientos)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 requerimientosEspecificaciónEn 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 requerimientosValidaciónLa 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. 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. Hay muchas maneras de organizar el proceso de ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso.Evolución de los requerimientosLos requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto.

Ejemplos de la Ingeniería de Requerimientos: Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.Actividades del proceso:•

Comprensión del dominio•

Recolección de requerimientos

•Clasificación•

Resolución de conflictosEjemplos de las sesiones de interacción con el sistema. Inicia con un bosquejo y durante la obtención de agregan detalles. Un escenario incluye:

•Una descripción del estado del sistema al inicio del escenario

•Una descripción del flujo normal de eventos en el escenario

5.Cuales son las Técnicas y herramientas en la Ingeniería de Requerimientos:

R= Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.Esta técnica se enfrenta a los siguientes peligros potenciales.

•A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

•Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

•Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

•Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.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 sistemaSistemas 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, y otros.), porque siempre pueden surgir nuevas ideas sobre la base de estas.Lluvia de ideas (Brainstorm)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 es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como,

por ejemplo, "caro", "impracticable", "imposible", y otros. Las reglas básicas a seguir son:

•Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas.

•Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generación de ideas.

•Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil.

•A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva.

•Escribir las ideas sin censura.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 hallados, 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.Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.Casos de Uso: Los casos de uso son una técnica para especificar el comportamiento de un sistema. El sitio en Internet wikipedia.org, define a un caso de uso como:“Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios.Casos de uso

•Introducido en el método Objectory.

•Convertido en una característica fundamental de UML.

•Un caso de uso encapsula un conjunto de escenarios en el que cada uno es un camino único a través del caso de uso.

Ejemplos de sus usos, Casos de UsoComo mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambia datos o control con el sistema, participando de ese caso de uso.El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Ventajas:

•Reduce el tiempo de análisis o diseño, pues en una sola sesión pueden participar todos los interesados en una misma área

•Mejora las comunicaciones, pues todos los modelos derivados trazados en las sesiones de trabajo se validan con sus participantes.

•Crea sentido de consenso y participación, pues, durante las sesiones de trabajo, el usuario directo tiene la oportunidad de presentar y discutir sus puntos de vista y problemas.

•Facilita la identificación de problemas o inconsistencias, pues cualquier discrepancia entre opiniones puede aclararse en las propias reuniones de trabajo.

•Mejora la calidad de los productos, pues será posible definir en forma más completa los verdaderos requerimientos de los usuarios.

Desventajas:

•La información obtenida al principio puede ser redundante o incompleta.

•Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados

Ejemplo de Caso de Usos 1era. Clase de Laboratorio