UNIDAD 4 ANALISIS DE LOS REQUERIMIENTOS

4.1 REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES. PAG. 4

4.2 CASO DE USO..PAG. 8

4.3 DISEO DE INTERFAZ DE USUARIOPAG. 9 4.3.1 REGLAS EN EL DISEO DE INTERFAZ DEL USUARIOPAG. 10 4.3.2 INTEGRACION DE LA INTERFAZ AL CASO DE USOPAG. 11

UNIDAD 4 Anlisis de Requerimientos

La coleccin y anlisis de requerimientos se inicia a partir de la especificacin de los objetivos de informacin geogrfica, establecidos por cada una de las partes que forman la organizacin y que intervendrn en la aplicacin de la base de datos. La primera actividad en el diseo es determinar el alcance del proceso de diseo de la aplicacin de la base de datos. Esto incluye el establecimiento de las funciones de la organizacin y la formulacin de una lista de los ambientes que actualmente incluyen No se encuentran entradas de ndice.las vistas de sus funciones, usando textos en lenguaje natural. La descripcin de las operaciones deben contener:

cul es el fin de la operacin, cules son las condiciones que habilitan una operacin, cmo se desarrolla la operacin, si las operaciones se comportan en forma regular, y si no, cules son las condiciones.

En seguida se realiza un filtrado de la recoleccin de requerimientos con el propsito de reducir expresiones sinnimas, resolver homnimos -introduciendo sustitutos apropiados-, eliminar repeticiones, etc. Por ltimo, se clasifican las sentencias en los siguientes formatos especiales: formas de requerimientos de datos, de operaciones y de eventos.

4.1 REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Qu son Requerimientos?

Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuacin se presenta la definicin que aparece en el glosario de la IEEE . Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que 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 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.

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

A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. 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. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.

Dificultades para definir los requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

A continuacin se darn algunas definiciones para ingeniera de requerimientos. "Ingeniera de Requerimientos es la disciplinapara desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema" Boehm 1979. "Ingeniera de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987. "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987.

"Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software Importancia de la Ingeniera de Requerimientos Los principales beneficios que se obtienen de la Ingeniera de Requerimientos son:

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 estimacin de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin 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 ingeniera 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.

Personal involucrado en la Ingeniera 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 especficos dentro de la planificacin del proyecto; el conocimientode cada papel desempeado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. No conocer estos intereses puede ocasionar una comunicacin poco efectiva entre clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo como en presupuesto. Los roles ms importantes pueden clasificarse como sigue:

Usuario final: Son las personas que usarn el sistema desarrollado. Ellos estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn familiarizados con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y los manuales de usuario.

Usuario Lder: Son los individuos que comprenden el ambiente del sistema o el dominiodel problema en donde ser empleado el software desarrollado. Ellos proporcionan al equipo tcnico los detalles y requerimientos de las interfaces del sistema. Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, stas personas son las responsables de la administracinde cambios, de la implementacin y resolucin de anomalas. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.

Analistas y programadores: Son los responsables del desarrollo del producto en s; ellos interactan directamente con el cliente.

Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseadores de base de datos, entre otros. Puntos a considerar durante la Ingeniera de Requerimientos Aunque la lista no est completa, se enumeran los puntos ms importantes. Objetivos del negocio y ambiente de trabajo Aunque los objetivos del negocio estn definidos frecuentemente en trminos generales, son usados para descomponer el trabajo en tareas especficas. En ciertas situaciones IR se enfoca en la descripcinde las tareas y en el anlisis de sistemas similares. Esta informacin proporciona la base para especificar el sistema que ser construido; aunque frecuentemente se aadan al sistema tareas que no encajan con el ambiente de trabajo planificado.

4.2 CASO DE USO

Cuando empezamos a analizar un problema con el propsito de implementar una solucin en software podemos usar los casos de uso como una herramienta de anlisis de los requerimientos. Los casos de uso contestan las preguntas: Quines son los diferentes usuarios del sistema y qu papeles desempean? Qu necesita cada usuario que realice el sistema? Cules son los pasos que deben seguirse para que el sistema satisfaga las necesidades de cada usuario?

Un factor importante al crear casos de uso es que se hace sin especificar cmo el caso de uso se implementa. Por ejemplo, se puede especificar cmo un sistema de cajero bancario debera comportarse al enunciar en casos de uso de la manera en que los usuarios interactan con el sistema. No se necesita saber nada acerca de los aspectos internos del cajero. Los casos de uso especifican el comportamiento deseado, no dictan cmo debe llevarse a cabo el comportamiento. Lo importante de este enfoque es que permite (al usuario final y experto del dominio) comunicarse con los desarrolladores (quienes construyen sistemas para satisfacer tus requerimientos) sin quedar atrapado en detalles. Esos detalles llegarn, pero los casos de uso permiten enfocarse en aspectos de alto riesgo para desarrollar el sistema.. En el Lenguaje de Modelado Unificado (UML), todo este comportamiento se modela como casos de uso que pueden ser especificado independientemente de su cmo se implementarn en cdigo. Un caso de uso es una descripcin de un conjunto de secuencias de acciones, incluyendo variaciones, que un sistema realiza para lograr un resultado observable de valor para un actor. En esta definicin, existe un nmero importante de partes. Un caso de uso describe un conjunto de secuencias, en las cuales cada secuencia representa la interaccin de cosas fuera del sistema (actores) con el sistema (y sus abstracciones clave). Estos comportamientos son funciones a nivel del sistema que acostumbra visualizar, especificar, construir y documentar en la fase de obtencin y anlisis de los requerimientos. Un caso de uso representa un (o ms) requerimiento funcional completo del sistema. Por ejemplo, un caso de uso central de un banco es procesar prstamos. Un caso de uso involucra la interaccin de actores con el sistema. Un actor representa un conjunto de roles coherente que los usuarios del caso de uso juegan cuando interactan con el sistema. Los actores pueden ser personas o sistemas automatizados. Por ejemplo, en el modelado bancario, el procesamiento de un prstamo involucra, entre otras cosas, la interaccin entre un cliente y el ejecutivo de prstamos. Un caso de uso puede tener variaciones. En todos los sistemas interesantes, se encuentran casos de uso que son versiones especializadas de otros casos de uso, casos de uso que son incluidos como parte de otros casos de uso y casos de uso que extienden el comportamiento de otros casos de uso centrales. Se puede separar el comportamiento reutilizable y comn de un conjunto de casos de uso al organizarlos de acuerdo a estas tres clases de relaciones:

generalizacin, inclusin y extensin. Por ejemplo, en el modelado del banco, se encuentran muchas variaciones entre el caso de uso bsico para procesar un prstamo, as como la diferencia entre procesar una gran hipoteca contra un prstamo para un pequeo comercio. En cada caso, sin embargo, estos casos de uso comparten en algn grado comportamiento comn, tal como la calificacin del cliente para el prstamo, un comportamiento que es una parte del procesamiento de cada clase de prstamo. Un caso de uso lleva a cabo alguna cantidad de trabajo tangible. Desde la perspectiva de un actor dado, un caso de uso hace algo que es de valor para el actor, tal como calcular un resultado, generar un nuevo objeto o cambiar el estado de otro objeto. Por ejemplo, en el modelo del banco, el procesamiento de un prstamo resulta en la entrega de un prstamo aprobado, manifestado por el dinero en las manos del cliente. Los casos de uso se pueden aplicar al sistema completo, pero tambin a una parte del sistema, incluyendo subsistemas y an clases individuales e interfaces. En cada caso, estos casos de uso no slo representan el comportamiento deseado de estos elementos, sino que tambin pueden ser usados como una base para casos de prueba de estos elementos conforme evolucionan en el desarrollo. Los casos de uso aplicados a subsistemas son fuentes excelentes de pruebas de regresin. Los casos de uso aplicados a los subsistemas son fuentes excelentes de pruebas de integracin y de sistema. El UML, proporciona una representacin grfica de un caso de uso y un actor, como lo muestra la figura 1. Esta notacin permite visualizar un caso de uso independiente de su implementacin y en el contexto de otros casos de uso.

4.3 Diseo de interfaz de usuario

El diseo de interfaz de usuario o ingeniera de la interfaz es el diseo de computadoras, aplicaciones, mquinas, dispositivos de comunicacin mvil, aplicaciones de software, y sitios web enfocado en la experiencia de usuario y la interaccin. Normalmente es una actividad multidisciplinar que involucra a varias ramas del diseo y el conocimiento como el diseo grfico, industrial, web, de software y la ergonoma; y est implicado en un amplio rango de proyectos, desde sistemas para computadoras, vehculos hasta aviones comerciales. Su objetivo es que las aplicaciones o los objetos sean ms atractivos y adems, hacer que la interaccin con el usuario sea lo ms intuitiva posible, conocido como el diseo centrado en el usuario. En este sentido las disciplinas del diseo industrial y grfico se encargan de que la actividad a desarrollar se comunique y aprenda lo ms rpidamente, a travs de recursos como la grfica, los pictogramas, los estereotipos y la simbologa, todo sin afectar el funcionamiento tcnico eficiente.

4.3.1 REGLAS EN EL DISEO DE INTERFAZ DEL USUARIO.

El diseo de interfaces debera ser la columna vertebral de cualquier aplicacin, porque? un buen diseo de interfaz puede ser la diferencia para ofrecerle al usuario final una excelente experiencia de usabilidad, efectividad y hacer de tu sistema un gran proyecto. A continuacin nos muestran las 8 reglas ms importantes para el diseo de la interfaz de usuario. 1 Luchar por la coherencia. Secuencias de acciones consistentes deberan ser necesarias en situaciones similares; idntica terminologa debe utilizarse en anuncios, mens y pantallas de ayuda, y los comandos consistentes deben ser empleados en todo. 2 Permite a los usuarios frecuentes utilizar accesos directos. A medida que la frecuencia de uso aumenta, tambin lo hacen los deseos del usuario para reducir el nmero de acciones y aumentar el ritmo de interaccin. Acrnimos y abreviaturas, las teclas de funcin, los comandos ocultos, y macro instalaciones son muy tiles para un usuario experto. 3 Ofrece comentarios informativos. Por cada operador de accin, debe haber algn sistema de retroalimentacin. Para acciones frecuentes y de menor uso, la respuesta puede ser modesta, mientras que para los poco frecuentes y las principales acciones, la respuesta debera ser ms sustancial. 4 Diseo de dilogo para producir la clausura. Acciones secuenciales debe organizarse en grupos con un comienzo, intermedio y final. La retroalimentacin informativa a la conclusin de un grupo de acciones da a los operadores la satisfaccin de logro, una sensacin de alivio, la seal para dejar caer los planes de contingencia y las opciones de sus mentes, y una indicacin de que la va est libre para prepararse para el siguiente grupo de acciones. 5 Ofrece una manipulacin de errores simples. En la medida de lo posible, disear el sistema para que el usuario no ocasione un grave error. Si aparece un error, el sistema debera ser capaz de detectar el error y ofrecer de manera sencilla y comprensible una manera para identificar el error. 6 Permitir un fcil retroceso de las acciones. Esta caracterstica alivia la ansiedad, ya que el usuario sabe que los errores se pueden deshacer, sino que por lo tanto, alienta la exploracin de opciones desconocidas. Las unidades de reversibilidad pueden ser una sola accin, una entrada de datos, o un grupo de acciones.

7 Apoyo interno a un enfoque de control total. Los usuarios experimentados desean el sentido de que estn a cargo del sistema y que el sistema responde a sus acciones. Disea el sistema para que los usuarios inicien las acciones en lugar de las respuestas. 8 Reducir la carga de la memoria a corto plazo. La limitacin de recursos humanos de procesamiento de la informacin en la memoria a corto plazo exige que se muestren de manera sencilla, varias pginas se muestra consolidado, ventana-motion frecuencia se reducir, y suficiente tiempo de formacin se adjudicar a los cdigos, mnemotcnicos, y secuencias de acciones.

4.3.2 INTEGRACION DE LA INTERFAZ AL CASO DE USO

Un sistema para los casos del uso del software del edificio y los diagramas de estado relacionados basados en un modelo de las actividades econmicas se proporciona. El sistema abarca el modelo de actividades econmicas y de una herramienta que modela computarizada que se utilice para componer los casos del uso y los diagramas de estado relacionados. El sistema incluye un componente de la integracin, que tras las actividades econmicas para utilizar casos, y un interfaz utilizador grfico, que ilustra las relaciones entre casos del uso y las relaciones entre los casos del uso y los requisitos del negocio. Un componente del diagrama de estado tras actividades econmicas para asistir a la preparacin de los diagramas de la actividad del estado. El modelo de las actividades econmicas enumera actividades econmicas y asocia cada actividad econmica al dominio del negocio en el cual la actividad econmica se conduce normalmente.

El componente de la integracin proporciona una lista de las actividades econmicas seleccionables al interfaz utilizador grfico de el cual componer casos del uso y diagramas de la actividad del estado.

Referencia bibliogrfica.
Monografas. (s.f.). Recuperado el 27 de julio de 2010, de http://www.monografias.com/trabajos10/diusuar/diusuar.shtml#dos

Wikipedia. (s.f.). Recuperado el 27 de julio de 2010, de http://es.wikipedia.org/wiki/Requisito_no_funcional