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