Ingeniera de requerimientos. ............................................................................................................. 3
Introduccin .................................................................................................................................... 3 1. Anlisis de requerimientos. ......................................................................................................... 3 1.1 Qu es un requerimiento? ..................................................................................................... 3 1.2 Qu es un anlisis de requerimiento? .................................................................................... 4 1.3 Tipos de Requerimientos .......................................................................................................... 5 1.4 Caractersticas de un Requerimiento ........................................................................................ 6 1.5 Requerimientos C y requerimientos D ...................................................................................... 6 1.6 Por qu deben escribirse los requerimientos ........................................................................... 7 1.7 Dificultades para definir los requerimientos ............................................................................ 8 2. Interaccin con el cliente ............................................................................................................ 8 2.1 Identificacin de interesados .................................................................................................... 8 2.2 Proceso de entrevista y documentacin. .................................................................................. 9 3. Descripcin de los requerimientos C (o del cliente) ................................................................ 10 3.1 Conceptos de operacin.................................................................................................... 10 3.2 Casos de uso ............................................................................................................................ 11 3.3 Diagramas de flujo de datos para la comunicacin con el cliente .......................................... 12 3.4 Diagrama de transiciones de estado para la comunicacin con el cliente ............................. 12 3.5 Diseo preliminar de interfaces de usuarios y otras ............................................................... 13 3.5.1 Pasos para desarrollar interfaces de usuario ................................................................... 14 4. Requerimientos D. ......................................................................................................................... 16 4.1 Tipos de Requerimientos D ..................................................................................................... 16 5. Propiedades Deseadas de los Requerimientos D .......................................................................... 17 5.1 Rastreabilidad ......................................................................................................................... 17 5.2 Comprobacin y no ambigedad ............................................................................................ 18 5.3 Prioridad .................................................................................................................................. 18 5.4 Completos ............................................................................................................................... 18 5.5 Condiciones de error ............................................................................................................... 19 5.6 Consistencia ............................................................................................................................ 19 5.7 Resumen del proceso de escribir un requerimiento detallado ............................................... 19 6. Organizacin de los Requerimientos D ......................................................................................... 20 6.1 Organizacin de requerimientos por clase ............................................................................. 20 6.2 Identificacin de clases ........................................................................................................... 20 6.3 Mtodos para organizar los requerimientos especficos ........................................................ 21 6.4 Clasificacin de Entidades ....................................................................................................... 21 7. Calidad los requerimientos especficos ......................................................................................... 22 7.1 Intervencin del aseguramiento de la calidad (QA) en el anlisis de los requerimientos D... 22 7.2 Mtricas para el anlisis de requerimientos D ........................................................................ 22 7.3 Inspeccin del anlisis de requerimientos D ........................................................................... 24 8. Uso de herramientas e internet para el anlisis de requerimientos. ........................................... 24 9. Mtodos formales para especificaciones de requerimientos ....................................................... 25 9.1 Introduccin a las especificaciones formales .......................................................................... 25 9.2 Cundo debe usarse especificacin formal? ........................................................................ 25 9.3 Precondiciones y pos condiciones ........................................................................................... 25 Bibliografa ........................................................................................................................................ 26
Ingeniera de requerimientos. Introduccin
A travs de los aos se ha podido constatar que los requerimientos o requisitos son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeacin, bsicamente en lo que se refiere a las estimaciones de tiempos y costos, as como la definicin de recursos necesarios y la elaboracin de cronogramas que ser uno de los principales mecanismos de control con los que se contar durante la etapa de desarrollo. Adems la especificacin de requerimientos es la base que permite verificar si se alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo detallado de las necesidades de los clientes o usuarios del sistema y es contra lo que se va a estar verificando si se estn cumpliendo las metas trazadas.
1. Anlisis de requerimientos. El anlisis de requerimientos es una de las tareas ms importantes en el ciclo de vida del desarrollo de software, puesto que en ella se determinan los planos de la nueva aplicacin.
En cualquier proyecto software los requisitos son las necesidades del producto que se debe desarrollar. Por ello, en la fase de anlisis de requisitos se deben identificar claramente estas necesidades y documentarlas. 1.1 Qu es un requerimiento?
Se presenta a continuacin la definicin existente en el glosario de la IEEE de lo que es un Requerimiento: Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (Std 610.12-1900, IEEE: 62). Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (Std 610.12-1900, IEEE: 62) Tambin, Ian Sommerville presenta una definicin acerca de lo que es un Requerimiento: Un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste. (Sommerville, 2005: 108) Analizando las definiciones anteriores, un requerimiento es una descripcin de una condicin o capacidad que debe cumplir un sistema, ya sea derivada de una necesidad de usuario identificada, o bien, estipulada en un contrato, estndar, especificacin u otro documento formalmente impuesto al inicio del proceso.
1.2 Qu es un anlisis de requerimiento?
Para Construir algo primero debe entenderse lo que debe ser ese algo. El proceso de entender y documentar este algo se llama anlisis de requerimientos. En general, los requerimientos expresan qu se supone debe hacer una aplicacin: por lo comn, no intentan expresar cmo lograr estas funciones. Por ejemplo, la siguiente afirmacin es un requerimiento para una aplicacin de contabilidad. El sistema debe permitir a los usuarios, acceso a su saldos. En trminos generales, la siguiente afirmacin no es un requerimiento para una aplicacin. Los estados de cuenta del cliente se almacenaran en una tabla llamada saldos en una base de datos Access. Esta ltima afirmacin de refiere a cmo debe construirse la aplicacin y no a que debe hacer la aplicacin. Un requerimiento en un nivel con frecuencia se traduce en ms de un requerimiento especfico en el siguiente nivel ms detallado. Para entender esto imagine que su requerimiento para una casa es que tenga una vista de 180 a la montaa. Esto podra traducirse como la afirmacin de que tenga una terraza en el lado derecho con dimensiones de 20 por 50 pies. Este es un requerimiento ms especfico a un nivel ms detallado. De manera similar, la segunda afirmacin puede en realidad ser un requerimiento en un nivel subsecuente dentro del proceso de desarrollo. Adems, existen excepciones a la regla de que en los requerimientos se evite especificar como debe hacerse algo. Por ejemplo, el cliente del ejemplo anterior podra, por alguna razn, querer que los estados de cuenta se almacenen en una base de datos de Access con el nombre indicado. En ese caso la segunda afirmacin sera un requerimiento. 1.3 Tipos de Requerimientos
Los requerimientos de software pueden dividirse en 2 categoras: requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales son los que definen las funciones que el sistema ser capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el Qu? y no el Cmo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema. A continuacin se presenta un ejemplo de requerimientos funcionales para un mdulo de matrcula. Matriculacin La matrcula ser realizada de forma interactiva. Se le preguntar al alumno cules el plan de estudios en que desea matricularse (pueden ser varios). Se podr generar una copia impresa de la matrcula (sin valor oficial) en el ordenador desde donde se realice el proceso de matriculacin. Se podr generar el impreso de pago debidamente cumplimentado. Para la matriculacin se consultarn los datos del expediente y se realizarn las validaciones necesarias, descritas a continuacin Pago de matrcula: La aplicacin generar un impreso para que el alumno realice el pago correspondiente a la matrcula en 1 2 plazos (segn las fechas establecidas). Si el alumno tiene matrculas de honor de cursos anteriores o disfruta de algn tipo de beca, la aplicacin deber calcular automticamente los descuentos correspondientes
Por otra parte los requerimientos no funcionales tienen que ver con caractersticas 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, estndares, etc. A continuacin un ejemplo de los requerimientos NO funcionales del ejemplo anterior sobre el mdulo de matrcula.
Interfaces Hardware: El sistema se debe implementar sobre la infraestructura existente en las aulas de prcticas de la E.T.S. Ingeniera Informtica. Software: No existe posibilidad de adquirir licencias de software. La aplicacin deber funcionar sobre Oracle. 1.4 Caractersticas de un Requerimiento
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 cmo se sabe si se cumpli con l o no? Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin 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 redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector.
1.5 Requerimientos C y requerimientos D
Durante algn tiempo se ha discutido quien es el dueo de los requerimientos: el cliente o el desarrollador. Para manejar este aspecto, el anlisis de requerimientos 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 requerimiento del cliente o requerimiento C. La audiencia primaria para los requerimientos C es la comunidad del cliente y la secundaria es la comunidad del desarrollador. El segundo nivel documenta los requerimientos de manera especfica y estructurada. Estos se llaman requerimientos del desarrollador o requerimientos D. La audiencia primordial de estos es la comunidad del desarrollo y la secundaria la del cliente.
1.6 Por qu deben escribirse los requerimientos
Aun para las personas sin experiencia puede ser evidente la necesidad de escribir lo que se supone debe hacer un programa cuando est terminado. De cualquier forma, este proceso de escribir suele ignorarse o se deja morir. En estas situaciones, se cree que el cdigo fuente expresa todos los requerimientos: como el cdigo fuente es imprescindible, Por qu no reducir el proceso completo a este documento esencial? La respuesta es que no funciona. Sin ellos el equipo no sabe en realidad cuales son las metas que intenta lograr, no puede inspeccionar y probar su trabajo de manera adecuada, no puede controlar su productividad, no tiene datos adecuados de sus prcticas, no puede predecir el tamao y esfuerzo de su siguiente trabajo y no puede satisfacer a sus clientes. Cada requerimiento debe Expresarse de modo adecuado Ser de acceso sencillo Numerarse Acompaarse con pruebas que lo verifiquen Tomarse en cuenta en el diseo Tomarse en cuenta en el cdigo Probarse aislado Probarse junto con los otros requerimientos Validarse con las pruebas despus de construir la aplicacin Un ejemplo de un requerimiento documentado es el siguiente: La aplicacin debe desplegar la longitud del gene X12345 en la ventana del sistema (requerimiento 7824) Considere el caso que resultara si el requerimiento 7824 no estuviera escrito, muy pocos de los pasos dados anteriormente se podran llevar acabo de modo apropiado. No sera de sorprender que la aplicacin en cuestin no fuera apropiable. Cuando se completan todos los pasos anteriormente mencionados para todos y cada uno de los requerimientos se obtiene una idea del porque los ingenieros de software manejan de forma extensa los requerimientos individuales: son el acervo bsico ms importante de la profesin. 1.7 Dificultades para definir los requerimientos
Durante la etapa de especificacin de requerimientos se pueden presentar muchos inconvenientes los cuales son importantes de identificar y prevenir, a continuacin se presenta un listado con los problemas ms comunes en este proceso: Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. El usuario no puede explicar lo que hace Tiende a recordar lo excepcional y olvidar lo rutinario Hablan de lo que no funciona Los usuarios tienen distinto vocabulario que los desarrolladores. Usan el mismo trmino con distinto significado
2. Interaccin con el cliente Una de las actividades ms importantes que se realiza a la hora de hacer un anlisis de requerimientos es la interaccin con el cliente, en este captulo tocaremos puntos importantes que son necesarios para lograr tener xito en este punto.
2.1 Identificacin de interesados
Las personas que tienen intereses en los resultados del producto se llaman Interesados. Como grupo constituyen el Cliente de la aplicacin. Para ilustrar considere la creacin de un sitio de comercio electrnico en internet. Un conjunto de interesados consiste en los visitantes as sitio: su requerimiento principal es la facilidad para encontrar y comprar los artculos que necesitan. Los dueos de la compaa tambin son interesados, su requerimiento ms importante puede ser la puede ser la ganancia a corto o largo plazo. Por esta razn pueden querer que el sitio resalte los artculos con altos mrgenes. Los administradores, otro grupo de interesados, tal vez requieran que la aplicacin de seguimiento a los visitantes. Los desarrolladores de la aplicacin tambin son parte de los interesados, quiz deseen usar la nueva tecnologa de desarrollo para seguir actualizados. Por lo general los diseadores ponen mayor atencin en la aceptacin de la aplicacin por el mayor nmero de usuarios posibles. Aunque este puede ser un problema de mercadotecnia difcil, es claro que los usuarios son los interesados ms significativos. Sin embargo en el desarrollo de proyectos grandes la identificacin de los interesados ms significativos es compleja. Es fcil que los interesados en conflicto den como resultado requerimientos inconsistentes. Un ejemplo es el de dos grupos diferentes con motivaciones distintas dentro de una compaa, que en apariencia quieren la misma aplicacin. La consecuencia es que los requerimientos no son consistentes. Los desarrolladores estn sujetos a las responsabilidades profesionales que pueden afectar de manera profunda los requerimientos. Suponga, por ejemplo, que se pide a los desarrolladores que construyan un software para un dispositivo medico con un presupuesto fijo, pero ellos determinan que las caractersticas requeridas no pueden aprobarse de manera adecuada dentro del presupuesto. A menos que este cambie, tendran que eliminar requerimientos. Incluso cuando las vidas no estn en peligro, los ingenieros de software tienen la responsabilidad social de crear productos que satisfagan ampliamente sus requerimientos. Un buen lder de proyecto supera estas dificultades, proceso que necesita aptitudes gerenciales, personales, de negocio y polticas (Braunde, 2003).
2.2 Proceso de entrevista y documentacin.
Gran parte del anlisis de requerimientos es una actividad de persona a persona, organizada con cuidado para producir la mejor aplicacin. Lo primero es decidir a quin entrevistar. En lugar de intentar que se dedique el mismo tiempo a todos, lo cual poder resultar en requerimientos contradictorios y esfuerzo desperdiciado se recomienda seleccionar uno o quiz dos individuos principales, entrevistarlos y despus solicitar comentarios de otros interesados clave. Es preferible que haya dos entrevistadores en cada sesin, pues un entrevistador tpico tiende a perder puntos. Traer una cinta de grabacin suele ayudar, pero debe pedirse permiso de antemano. Aunque es importante escuchar con cuidado al cliente en las entrevistas no se pueden obtener requerimientos con solo escuchar. En general el cliente formula requerimientos conforme avanza y necesita ayuda. Se hace hincapi en los casos de uso como manera efectiva de obtener requerimientos para una amplia variedad de aplicaciones. Algunos requerimientos necesitan un diagrama, para validar los requerimientos escritos el entrevistador les da seguimiento va correo electrnico y convoca a una reunin si es necesario. Despus de la junta, se escribe un borrador de los requerimientos C y en un formato como el estndar del IEEE, el borrador se enva por correo electrnico a la comunidad de clientes para obtener sus comentarios, y se realizan entrevistas sucesivas hasta que se logra la satisfaccin con los requerimientos C. Una manera de manejar las entrevistas Antes de la entrevista: 1. Enumere y de prioridades a los clientes que se va a entrevistar Para determinar el xito del proyecto 2. Programe una entrevista con tiempos de inicio y terminacin fijos Deben ir al menos dos miembros del equipo de desarrollo Preprese para grabar (si los entrevistados lo autorizan) En la Entrevista: 3. Concntrese en escuchar No sea pasivo: investigue y anime Persista en entender deseos y explorar necesidades Examines casos de uso; flujo de datos y/o diagramas de estado Tome notas exhaustivas 4. Programe una reunin de seguimiento Despus de la entrevista: 5. Bosqueje los requerimientos C del ERS usando un estndar 6. Envi correos electrnicos a los clientes para obtener sus comentarios
3. Descripcin de los requerimientos C (o del cliente) Uno de los grandes retos al que uno se enfrenta, es expresar con claridad lo que los clientes desean y necesitan. Las palabras solas pueden ser apropiadas, pero para muchas aplicaciones, el texto redactado necesita completarse con figuras de varios tipos.
3.1 Conceptos de operacin
Los clientes desarrollan una visin -con frecuencia inconsistente e incompleta- de cmo debe operar su aplicacin. Esta visin en ocasiones se conoce como el modelo o concepto de operacin de la aplicacin. Por ejemplo el modelo de operacin para un sistema puede ser uno de los siguientes Un sistema para convertir la informacin cruda del clima en forma grfica. Un sistema de tiempo real para pronosticar el clima. Una aplicacin para advertir a los usuarios acerca de las anomalas del clima. Estos conceptos de operacin llevan a aplicaciones muy distintas. El administrador de proyectos o ingeniero de requerimientos ayuda al cliente a aclarar su concepto de operaciones.
3.2 Casos de uso
Con frecuencia los requerimientos se expresan de manera natural como una interaccin entre la aplicacin y una agencia externa a ella, como el usuario. El caso de uso, es una forma muy til de esas interacciones. Un caso de uso se identifica primero por su nombre y por el tipo de usuario de la aplicacin, llamado actor. Consiste en una interaccin tpica entre un actor y una aplicacin. Por ejemplo abrir un archivo sera un caso de uso tipo para un procesador de palabras, con el usuario como actor y podra consistir en la siguiente secuencia de pasos. EL usuario selecciona el meno de Archivo. El sistema despliega las opciones nuevo y abrir. El usuario hace clic en abrir. El sistema despliega la ventana de archivo. El usuario introduce el directorio y el nombre de archivo. El usuario oprime el botn abrir. El sistema trae el archivo nombrado a la ventana del procesador de palabras. Dado que los casos de usos son como historias, son efectivos para producir informacin a partir de los clientes, y proporcionan un panorama excelente de las aplicaciones, los casos de uso se Figura 3.1 Ejemplo de un caso de uso de un cajero Automatico pueden expresar en diferentes niveles de generalidad. Es evidente que casos de uso similares no llevan a un gran valor adicional. Relativos entre s, los casos de uso deben ser secuenciales u ortogonales. Dos casos de uso son secuenciales si uno sigue directamente al otro. Los casos de uso ortogonales toman puntos de vista u opciones opuestas. 3.3 Diagramas de flujo de datos para la comunicacin con el cliente
Suponga que el cliente intenta explicar el tipo de aplicacin bancaria que desea, comenzando con el depsito a una cuenta. Las funciones de depsito pueden ser obtener el depsito del usuario y verificar la transaccin del depsito para asegurar que sea licita. Despus en la figura se resalta el tipo de datos que fluye en estas funciones: nmero de cuenta y cantidad del depsito. El usuario tambin est involucrado y debe representarse. Una funcin para crear el sumen de las cuentas, digamos, requiere la entrada desde un almacn. En la figura 3.2 se muestra un ejemplo de un diagrama de flujo, es fcil notar como los usuarios son representados por un rectngulo, los procesos son encerrados en un crculo, los almacenes de datos en un rectngulo sin cerrar y el flujo de la informacin con flechas, cada una de ellas con la direccin que debe de seguir la informacin en caso de que se ejecute una determinada funcin. Cada flecha lleva escrito los datos de salida que arroja el mtodo del cual proviene, los cuales servirn como datos de entrada para el siguiente mtodo o incluso servirn de salida para un almacn de datos o para el usuario final
3.4 Diagrama de transiciones de estado para la comunicacin con el cliente
En ocasiones una aplicacin aparte de ellase interpreta mejor si se piensa en uno de varios estados. EL estado de una aplicacin es su situacin o condiciones. Algunas veces los estados se llaman etapas o fases. La idea es dividir la aplicacin en estados de Figura 3.2 ejemplo de un diagrama de flujo manera que siempre este junto en uno de ellos. Por ejemplo, en la figura 3.3 se muestra un diagrama de estados para la cancelacin de un prstamo de un cliente a una determinada compaa. Se puede observar los diferentes estados que este proceso tiene, como solicitado que procesa la solicitud, una vez revisada pasa al siguiente estado En revision, donde el proceso puede dividirse y pasar a dos distintos estados dependiendo si la solicitud es aceptada o rechazada, en el primer caso la aplicacin cambiaria su estado a Autorizado la cual haria un deposito al cliente y se cambiaria al estado Entregado donde si el monto es igual al adeudado la aplicacin pasa al ultimo estado de Pagado y finalizaria, por otro lado su la revision es rechazada, la aplicacin pasaria al estado de Cancelado y finalizaria seguidamente. Despues de identificar los estados, se agregan las tarnsiciones de estado. Las transiciones se denotan por flechas, cada una etiquetada con el nombre del evento que provoca que las aplicaciones cambien de un estado a otro. Algunas veces cuando un objeto esta en un estado dado y ocurre un evento, el objeto puede hacer una transicion de uno a varios estados dependiendo de la condicion. Cabe destacar que en UML, las condiciones se denotan por parentesis cuadrados. 3.5 Diseo preliminar de interfaces de usuarios y otras
El diseo de la interfaz de usuarios se incluye en la etapa de diseo del desarrollo del software, pero tambin puede considerarse para la parte de la etapa de requerimientos, es cuestin de preferencia. En general los clientes comprenden una aplicacin al visualizar su (GUI, grafic user interface), por lo que una buena manera de ayudar a describir la aplicacin es desarrollar el diseo preliminar de la GUI. Al desarrollar las interfaces de usuario para las aplicaciones, los afortunados tal vez trabajen con un diseador profesional, o al menos obtengan la ayuda de uno, sin embargo para muchos proyectos, en especial los pequeos, Figura 3.3 Ejemplo de diagrama de transicin de estados de un prstamo los ingenieros de software deben disear por si mismos las interfaces de usuarios. As, se enumeran algunas guas para ese diseo. 3.5.1 Pasos para desarrollar interfaces de usuario
En [Ga2], Galitz proporciona 11 pasos para desarrollar interfaces de usuario. El autor adapto estos pasos como se muestra ms adelante. Cada uno de ellos se aplica al proceso de requerimientos de cliente y/o en los procesos de requerimientos detallados. Paso 1: conocer al usuario (C) Paso 2: entender la funcin de negocios en cuestin (C) Paso 3: aplicar los principios del buen diseado de pantallas (C, D) Paso 4: Seleccionar el tipo adecuado de ventanas (C, D) Paso 5: Desarrollar los mens del sistema (C, D) Paso 6: seleccionar los controles adecuados basados en los dispositivos (C) Paso 7: elegir los controles adecuados basados en las pantallas (C) Paso 8: organizar y distribuir la pantalla (C, D) Paso 9: elegir los colores adecuados (D) Paso 10: crear iconos significativos (C, D) Paso 11: proporcionar mensajes, retroalimentacin y gua efectivos (D)
Paso 1 (conocer al usuario). Este paso recomienda reconocer la naturaleza de los usuarios posibles de la aplicacin. En general el usuario con menor nivel educativo, capacitacin, aptitudes y motivacin requiere mayor sencillez, ms explicaciones y ms ayuda. Tal vez tenga que hacer un trueque entre esto y la eficiencia y la velocidad. Con frecuencia es deseable proporcionar varios niveles de interfaz de usuario, dependiendo del nivel del mismo usuario. Paso 2 (comprensin de la funcin de negocios). Este paso pide al diseador que entienda el propsito de la interfaz de usuario y trminos del propsito global de la aplicacin. Por ejemplo, si el propsito del negocio es el inventario en un almacn, entonces tal vez se desee una interfaz de usuario para reflejar la distribucin del rea del almacn. La secuencia de las pantallas que aparecen pueden reflejar la manera normal en que los usuarios llevan a cabo sus tareas para el negocio en cuestin. Paso 3 (entender los principios del buen diseo de pantallas). La figura 3.4 enumera algunos elementos importantes del buen diseo de pantallas, la figura incluye varios factores que con frecuencia se aplican al proceso de hacer una interfaz atractiva. Aunque esto solo sirve para introducir el aspecto de efectos visuales, de cualquier manera son tiles a este nivel. Paso 4 (seleccionar el tipo adecuado de ventana). El propsito de cada interfaz de usuario puede cumplirse con ms efectividad con uno o dos tipos especficos de ventanas, las figuras 3.5 y 3.6 enumeran cinco propsitos de las GUI y un tipo de ventana que satisface cada uno. Los tipos de ventanas emplean la terminologa de Windows, pero son tpicos. Paso 5 (desarrollar mens del sistema). Algunas reglas para la creacin de los mens principales, proporcionadas por Galitz, se muestran en el cuadro 3.2. Los usuarios requieren un ancla estable y comprensible para las aplicaciones. Esto puede proporcionarse con el men principal constante. En general, el nmero de opciones en este men debe ser entre cinco y nueve, ya que la mayora nos sentimos a gusto con esta cantidad. Proporcionar un men Desplegar todas las alternativas relevantes (y slo stas) Amoldar la estructura del men con la estructura de la tarea de la aplicacin Minimizar el nmero de niveles del men
Cuadro 3.2 Algunas reglas para la creacin de los mens principales, proporcionadas por Galitz
Paso 6 (seleccionar los controles basados en dispositivos adecuados). Los controles basados en los dispositivos son los medios fsicos por los que el usuario comunican sus deseos respecto a la aplicacin. Incluyen joystick, trackballs, tabletas de grfica, pantalla de contacto, ratones, micrfonos, teclados. Paso 7 (seleccionar los controles en la pantalla adecuados). Los controles basados en la pantalla son smbolos que aparecen en el monitor, mediante los cuales el usuario notifica a la aplicacin de su entrada o intencin. Estos incluye iconos, botones, cajas de texto, botones de seleccin y cuadros de activacin. Paso 8 (organizar y distribuir ventanas). Las reglas para colocar ventanas multiples son las mismas que para colocar una ventana individual (que incluyen simetra, proporcin, etctera) Paso 9 (elegir los colores adecuados). Cuando se usa con aptitud y buen gusto el color puede resaltar las pantallas. Sin embargo, los colores no hacen, de manera automtica que la interfaz de usuario sea ms til o atractiva y es fcil que la empeoren.
4. Requerimientos D. Los Requerimientos D son una lista completa de las propiedades especficas y la funcionalidad que debe tener la aplicacin, expresada con todo detalle. Cada uno de estos requerimientos de numera, etiqueta y rastrea durante toda la implantacin. Son consistentes con, y son una refinamientos de los requerimientos C. En esencia se supone que los desarrolladores leern los requerimientos D. los clientes tambin interesados en ellos y casi siempre pueden comprender y comentar muchos de ellos. Recuerde que la audiencia principal de los Requerimientos C son los clientes. 4.1 Tipos de Requerimientos D
Requerimientos Funcionales: especifica los servicios que debe proporcionar la aplicacin, por ejemplo: la aplicacin debe calcular el valor del portafolio de inversin del usuario. Por otro lado, un requerimiento como la aplicacin debe terminar el clculo del valor de cada portafolio en menos de un segundo eso no es un requerimiento funcional Requerimientos no funcionales: requerimientos de desempeo; Los requerimientos de desempeo especifican las restricciones de tiempo que debe observar la aplicacin. Los clientes y desarrolladores negocian las restricciones del tiempo transcurrido para los clculos, el uso de RAM, el almacenamiento secundario, etc. Ejemplo: para cualquiera viga el analizador de tensin debe producir un informe del tipo cinco en menos de un minuto. Requerimientos no funcionales: Confiabilidad y disponibilidad; Especifican la confiabilidad en trminos cuantificados, por ejemplo: la aplicacin de radar del aeropuerto (ARA) debe experimentar no ms de dos fallas de nivel uno por mes. La disponibilidad tiene una estrecha relacin con la confiabilidad, cuantifica el grado en el que la aplicacin debe estar disponible para los usuarios, por ejemplo: ARA debe estar disponible a nivel uno o dos en la computadora primaria o en la de respaldo en todo momento. ARA podr estar no disponible en una de estas computadoras a nivel uno o dos, no ms de 2% del tiempo en cualquier periodo de 30 das. Requerimientos no funcionales: manejo de errores; esta categora explica cmo debe responder la aplicacin a los errores en su entorno. Por ejemplo, Qu debe hacer la aplicacin si recibe un mensaje de otra que no est en el formato que se acord? Estos no son errores generados por la aplicacin. Requerimientos no funcionales: Requerimientos de interfaz; Describen el formato con el que la aplicacin se comunica con su entorno. Por ejemplo: el costo de enviar el artculo de una fuente a un destino debe desplegarse en todo momento en el cuadro de costo. Requerimiento no funcionales: Restricciones; Las restricciones de diseo o implantacin describen los limites o condiciones para disear o implementar la aplicacin. Estos Requerimientos no pretenden sustituir el proceso de diseo, solo especifican las condiciones que el cliente impone el proyecto, el entorno u otras circunstancias, e incluyen la exactitud, por ejemplo: los clculos de daos de la Automobile Impact Facility (AEF) deben tener una exactitud de un centmetro. Requerimientos Inversos: Los requerimientos inversos establecen que no debe hacer el software, es lgico que haya un nmero infinito de requerimientos inversos: se seleccionan los que aclaran los requerimientos verdadero y los que eliminan posibles malos entendidos, Por ejemplo: no que requiere que AEF analice los datos de choque.
5. Propiedades Deseadas de los Requerimientos D 5.1 Rastreabilidad
Capacidad de hacer corresponder (mapear) cada requerimiento con sus partes relevantes del diseo e implementacin. Rastreo de Requerimientos Funcionales:
Se Desea que cada requerimiento D sea rastreable hacia adelante y hacia atrs. Por rastreabilidad hacia delante de los requerimientos D se refiere a la implementacin. La rastreabilidad hacia atrs significa que el requerimiento es una consecuencia clara de uno o ms requerimientos C. Por ejemplo, el requerimiento D, los personajes extraos deben moverse de una rea a otra en intervalos de 5 segundos en promedio. Se puede rastrear el siguiente requerimiento C, el resto (de los personajes), llamados personajes (extraos) deben estar bajo el control de la aplicacin La rastreabilidad hacia atrs es una base para la inspeccin de los requerimientos D.
Rastro de Requerimientos No Funcionales: Una meta de la etapa de diseo es aislar cada requerimiento no funcional en un elemento de diseo separado. En el caso de los requerimientos de desempeo se intenta aislar las unidades de procesamiento ms lentas. Cada Funcin que afecta a los requerimientos de desempeo se acompaa por los comentarios no funcionales que se pueden inspeccionar. De preferencia, estos requerimientos son cuantitativos, como debe terminar en menos de un milisegundo en el peor caso. De manera similar, al especificar las restricciones de almacenamiento se identifican las funciones que generan el mayor almacenamiento. As que para validar los requerimientos no funcionales cada uno se liga a un plan de pruebas, de preferencia en el momento de escribir el requerimiento.
5.2 Comprobacin y no ambigedad
Debe ser posible validar un requerimiento cuando se prueba que se ha implementado de manera apropiada. Los requerimientos que se pueden probar se llaman comprobables. Los requerimientos no comprobables tienen poco valor practico. 5.3 Prioridad
Este proceso de realiza de manera planeada. Una tcnica es asignar prioridades a los requerimientos especficos, jerarquizar todos los requerimientos casi siempre es una prdida de tiempo; en su lugar, muchas organizaciones clasificar los requerimientos en tres categoras. Se llamaran esenciales, deseables y opcionales. El proyecto deber incluir los requerimientos esenciales. Asignar prioridades a los requerimientos tiene impacto en el diseo en el diseo porque con frecuencia los requerimientos deseables y opcionales indican hacia donde se dirige la aplicacin.
5.4 Completos
Se hace un esfuerzo para que cada requerimiento detallado sea auto contenido pero pocas veces es posible en la prctica, donde los requerimientos con frecuencia se refieren a otros requerimientos. Que un conjunto de requerimientos est completo asegura que no hay omisiones que comprometan los requerimientos establecidos. Con respecto al ejemplo anterior del juego, una buena manera de revisar e inventario actual de los requerimientos es revisarlo mediante los casos de uso. Se establecen las cualidades del personaje del jugador en el rea de vestidores. Se puede confirmar que toda la funcionalidad requerida este presente para especificarlas y que todos los datos e imgenes requeridos tambin estn presentes Se mueve el personaje a un area adyacente. Se verifica que toda la funcionalidad requerida para hacerlo este presente. Se encuentra un personaje extrao. Se asegura que se dan todos los detalles.
5.5 Condiciones de error
Para cada requerimiento se pregunta qu pasara si ocurriera en las circunstancias equivocadas. Una falta de condiciones de error en las especificaciones de los requerimientos resalta de manera especial cuando se prueba la funcin, ya que quien realiza la prueba fuerza las condiciones de error y debe saber que salida del requerimiento se espera. Se recomienda imponer la captura de datos incorrectos en muchos puntos posibles, si no en todos, esta es una prctica equivalente a una muy antigua en ingeniera, donde se acostumbra la redundancia con el fin de promover la seguridad.
5.6 Consistencia
Un conjunto de requerimientos D es consistente si no hay contradicciones entre ellos, cuando el nmero de requerimientos D crece, la consistencia se puede volver algo difcil de lograr. La organizacin orientada a objetos de los requerimientos ayuda a evitar inconsistencias mediante la agrupacin de los requerimientos D de clases, como el caso de estudio, y con su descomposicin en formas muy sencillas. Sin embargo, esto no es una garanta de consistencia y por ello las inspecciones de los requerimientos la verifican junto con las otras cualidades mencionadas.
5.7 Resumen del proceso de escribir un requerimiento detallado
Evaluar si un requerimiento es rastreable o no significa imaginar un diseo para la aplicacin e imaginar cmo tendra el diseo que satisfacer los requerimientos, esta es la forma ms sencilla si el requerimiento corresponde directamente a un mtodo. Ayuda a delinear una prueba para un requerimiento al mismo tiempo que se escribe. Esto no solo aclara los requerimientos, tambin establece si se puede probar. Muchos requerimientos depende de datos especficos y es necesario indicar como debe operar el requerimiento en caso de que el dato est equivocado o sea inconsistente. Para requerimientos crticos, esto debe incluir errores debidos a un diseo malo o a la programacin (los requerimientos de rutina pueden no ser responsables de un diseo o una programacin defectuosos de la aplicacin.) Por ejemplo, un requerimiento aceptable: cuando se presiona el botn de inicio, el rayo X de alta densidad debe encenderse si los parmetros satisfacen las siguientes condiciones. Por otra lado, un requerimiento no aceptable: las posiciones deben desplegarse siempre y cuando ningn jugador haya movido dos veces ms que algn otro jugador.
6. Organizacin de los Requerimientos D Dentro de las los imprevistos que se pueden presentar sino se maneja una adecuada organizacin de los requerimientos D, se vuelve inmanejable cuando crece: 1. Su propio tamao hace difcil de entenderla como un evento unitario antes de que crezca a cientos, si no a miles 2. Los requerimientos son de tipo mixtos: por ejemplo, los requerimientos de desempeo deben de tratarse de manera diferente de los requerimientos de comportamiento. 3. Algunos requerimientos van junto a otras relaciones de manera natural. 4. Es difcil localizar un requerimiento especfico. 6.1 Organizacin de requerimientos por clase
La atencin se centra en un estilo orientado a objetos para organizar los requerimientos, donde primero se identifica una clasificacin --- el equivalente a seleccionar las clases--- y despus se colocan los requerimientos individuales en las categoras o clases obtenidas. Existen dos enfoques para hacerlo. Uno ve las clases como una herramienta para organizar los requerimientos, pero no necesariamente considera que se pueden usar para el diseo real. Otro enfoque, que sigue el caso de estudio, usa las clases desarrolladas para los requerimientos en el diseo (y la implementacin orientada a objetos reales). Este ltimo enfoque fomenta una rastreabilidad uno a uno de los requerimientos D a los mtodos donde cada requerimiento D funcional debe corresponder a una funcin en el lenguaje que se usa. Una desventaja de este mtodo es el riesgo de cambiar ms adelante las clases usadas, con lo que se destruye la correspondencia entre los requerimientos y la seleccin de clases.
6.2 Identificacin de clases
Las clases que se usaran como principio de organizacin se identifican con cuidado y de forma conservadora. Para esto se identifica las clases de dominio de la aplicacin, es decir, las que pertenecen a la aplicacin. Por ejemplo, el dominio de una aplicacin que simula un banco puede contener las clases cliente Banco y Cajero pero no Archivo o Base Datos tampoco Cliente o Transaccin. Los ltimos no son especiales para la aplicacin en cuestin. El uso de clases de dominio es una manera de organizar, reflexionar y rastrear los requerimientos.
6.3 Mtodos para organizar los requerimientos especficos Los requerimientos D se pueden organizar de acuerdo con varios esquemas, entre ellos: 1. Por Caracterstica (servicio deseado percibido en el exterior, casi siempre se definen por los pares estimulo-respuesta). Esta organizacin que se conoce como requerimientos; a saber, los requerimientos se agrupan segn las caractersticas observables de la aplicacin. 2. Por Modo (por ejemplo, los sistemas de radar tienen modos de capacitacin, normal y emergencia.) 3. Por caso de uso (en ocasiones llamada por escenario). Esta organizacin, preferida por el USDP, se explica despus con ms detalle, la idea es que la mayora de los requerimientos detallados son parte de un caso de uso. 4. Por clase. Este es un estilo orientado a objetos que se explica ampliamente ms adelante. En esta organizacin los requerimientos se agrupan en clases. Esta manera de organizar los requerimientos se usa en el caso de estudio. 5. Por jerarqua de funcin(es decir, descomponiendo la aplicacin en un conjunto de funciones de alto nivel y, despus, estas en sub-funciones etc.) por ejemplo, los requerimientos para un programa de presupuestos domestico se pueden descomponer en chequeras, conciliacin e informes, etc. Esta es una manera tradicional de poner en orden los requerimientos detallados. 6. Por estado (indicando los requerimientos especficos aplicados a cada estado). Por ejemplo, la mejor forma de clasificar los requerimientos para una aplicacin que controla un proceso qumico puede ser por los estados en los que el proceso se puede encontrar (inicio, reaccin, enfriamiento, entre otros).
6.4 Clasificacin de Entidades
Corresponde a las aplicaciones que requieren la existencia de entidades (instancias u objetos, al contrario de clases) especificas. Una desventaja de este enfoque es que quiz cambie la decisin acerca de que objeto crea el objeto requerido y por ello los requerimientos tendran que moverse. Tambin debe observarse que otros objetos, aunque no crean el objeto requerido, pueden hacer referencia al ms a menudo que el objeto creador.
7. Calidad los requerimientos especficos Hoy en da entre ms claros, precisos y concisos sean los requerimientos puede marcar la diferencia entre el xito del desarrollo de los software, bebido a que la realidad nos sigue diciendo que uno de los principales motivos del fracaso de los proyectos est en los requisitos (inadecuados, incompletos, etc.). Hay que tener muy claro que no especificar los requerimientos detalladamente puede traer consecuencias muy desastrosas, por lo que se debe intentar clasificar la calidad de los requerimientos de la manera ms cuantitativa posible. 7.1 Intervencin del aseguramiento de la calidad (QA) en el anlisis de los requerimientos D
La organizacin de aseguramiento de calidad revisa los requerimientos, por lo tanto creo un estndar el (730-1995) que establece: Que se debe identificar o hacer referencia a las prcticas estndares, convenciones y mtricas que se usarn durante la etapa de requerimientos. Menciona los estndares con los pasos a seguir y rastreabilidad de los requerimientos deben cumplir. Se utilizan lenguajes formales para establecer requerimientos, en la medida de lo posible. Debe preverse un esquema que identifique de manera nica cada requerimiento. En las organizaciones grandes suele seguirse guas como estas, el problema est en las pequeas o de mediano tamao donde muchas introducen el aseguramiento de calidad, solo despus determinado los requerimientos. Algunas veces se pide QA despus de todos los hechos para verificar que esto se haya construido conformes a las especificaciones. Las quejas tpicas de QA son que no existen requerimientos adecuados en contra los cuales verificar la aplicacin.
7.2 Mtricas para el anlisis de requerimientos D
Cuando se utiliza mtricas de forma selectiva se maximiza la inversin en inspeccin al enfocarse el proceso de inspeccin en resultados tiles y cuantificados. Hay que tener en cuenta que cada mtrica proporciona beneficios pero cuesta dinero y tiempo para recolectar, almacenar, analizar e informar. La razn de aplicar mtricas es por optimizar la razn costo/beneficio. Esta depende de la cultura de la organizacin, el estado del proyecto, la naturaleza del mismo, etc. Cuando se recolecta mtricas hay que tener el cuidado que sea realmente til para la empresa y no solo porque en un futuro se pueden utilizar siendo una prctica dudosa. Debido a que esto puede generar habitaciones llenas de mtricas sin ningn uso ya que se almacenaron pensando en que iban a ser tiles pero no fue as, adems que no se especific cul sera su utilidad. La siguiente lista de mtricas de aseguramientos de la calidad incluye las mtricas del anlisis de requerimientos en el estndar IEEE (982.2-1998): Medidas de qu tambin escrito estn los requerimientos Porcentaje de requerimientos especficos no ambiguos (IEEE mtrica 6) Grado en que est completo (IEEE mtrica 23 y 35) Porcentaje de requerimientos D mal clasificados (en el estilo orientado a objetos esto mide el porcentaje asignado a la clase equivocada) Porcentajes de requerimientos especficos que no son Comprobables Rastreables (IEEE mtrica 7) Con prioridades Atmico (indivisibles en partes pequeas) Consistente con el resto de requerimientos (IEEE mtrica 12 y 13) Medidas de efectividad de la inspeccin de requerimientos Porcentajes de requerimientos faltantes o defectuosos encontrados por hora de inspeccin Medidas de efectividad del proceso de anlisis de requerimientos Costo por requerimientos D Costos brutos (tiempo total dedicado / nmero de requerimientos D) Costo marginal (costo de obtener uno ms) Tasa a la que los requerimientos especficos se Modifican Eliminan Agregan Medidas del grado en que un requerimientos est completo Esto se puede estimar, despus del fin oficial de la recoleccin de los requerimientos D, a partir de la tasa a la que los requerimientos especficos se Modifican Agregan
7.3 Inspeccin del anlisis de requerimientos D
La inspeccin tambin es conocida como revisin tcnica formal, y es el punto de vista ms efectivo desde el punto de vista de aseguramiento de calidad, y es dirigida por los ingenieros de software u otras personas. Para los ingenieros la inspeccin es un medio efectivo para descubrir errores y mejorar la calidad del software Los requerimiento especficos (o requerimientos D) constituyen los primeros de software que se puede inspeccionar contra los documentos anteriores (requerimientos C). Los inspectores se preparan para la inspeccin leyendo de nuevo los requerimientos C y comparndolos los requerimientos especficos de ellos.
8. Uso de herramientas e internet para el anlisis de requerimientos. El uso de herramientas permiten ayudar al proceso de captura y administrar los requerimientos; por ejemplo, ordenado, asignado prioridades y rastreando. Unos de los beneficios de esta herramienta es saber quin trabaja en qu requerimiento y cundo, adems puede permitir el arrastre de las caractersticas, es decir el proceso mediante el cual las caractersticas que no son necesarias se agregan a la aplicacin. Con las herramientas adecuadas es ms fcil para un lder de proyectos evaluar el estado del anlisis de requerimientos. De este modo se puede saber qu porcentaje de los requerimientos D esenciales se han implementado y que QA ha probado por completo. Por ejemplo la siguiente tabla:
9. Mtodos formales para especificaciones de requerimientos 9.1 Introduccin a las especificaciones formales
Las matemticas son buenas para expresa el estado; en otras palabras, lo que es. Esto difiere de los procedimientos y algoritmos para el cmo. Dado que las especificaciones de los requerimientos en su mayor parte describen el estado de la aplicacin antes y despus de la acciones, la notacin matemtica puede ser ms adecuada que el lenguaje natural para especificar los requerimientos detallados.
9.2 Cundo debe usarse especificacin formal?
La mejor forma de comunicar los requerimientos es la efectividad, siendo la mejor prueba para cundo usar requerimientos formales e informales, la mayor parte del tiempo es mejor expresar los requerimientos en un lenguaje natural y algunas veces es preferible hacerlo mediante una especificacin formal. Las especificaciones formales se requieren para implementar las especificaciones ejecutables. Estas especificaciones se pueden traducir de manera automtica en cdigo objeto, por tanto es necesario que sean precisas.
9.3 Precondiciones y poscondiciones
Estas son descripciones del estado requerido de la aplicacin antes y despus de un clculo. En general, las precondiciones y pos condiciones usan seudocdigo, al igual que partes del lenguaje de implementacin (java, c++, etc.), en lugar de solo matemtica. Precondicin: Relacin lgica que deben de cumplir los valores de entrada para que la operacin se pueda aplicar con garantas de producir una ejecucin correcta. Poscondicin: Relacin lgica que se cumple con los valores de salida despus de ejecutar la operacin, siempre que se cumpliera la precondicin. Bibliografa Braunde. (2003). Ingenera de sotfware, una perspectiva orientada a objetos. Mexico D.F: Alfaomega. IEEE - 830. (14 de Marzo de 2000). Facultad de Informtica Universidad Complutense de Madrid. Recuperado el 15 de Abril de 2012, de http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf J., L. J. (7 de Diciembre de 2011). Monografias. Recuperado el Abril de A de 2012, de 20 Pressman, R. S. (2002). Ingeniera del software, un enfoque practico. Mexico, DF: Mcgraw-Hill Interamericana editores, S.A de C.V. Senn, J. A. (1992). Anlisis y diseo de sistemas de informacin. Mexico. Universidad de Granada, DECSAI. (2008). Especificacion de requerimientos. Granada, Espaa. Wikipedia. (10 de Marzo de 2012). Wikipedia. Recuperado el 15 de Abril de 2012, de http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos