Anlisis de Requerimientos

Parte 1

Por Qu Modelamos ?.
Una empresa de software con xito es aqulla que produce de una manera consistente software de calidad que satisface las necesidades de sus usuarios. Una empresa que puede desarrollar este software de forma predecible y puntual, con un uso eficiente y efectivo de recursos, tanto humanos como materiales, tiene un negocio sostenible.

Este mensaje conlleva una importante consecuencia: el producto principal de un equipo de desarrollo no son bonitos documentos, reuniones muy importantes, grandes lemas o lneas de cdigo fuente merecedoras del premio Pulitzer. Ms bien, es un buen software que satisfaga las necesidades cambiantes de sus usuarios y la empresa. Todo lo dems es secundario.

Desafortunadamente, muchas empresas de software confunden "secundario" con "irrelevante". Para producir software que cumpla su propsito, hay que conocer e involucrar a los usuarios de forma disciplinada con el fin de extraer los requisitos reales del sistema. Para desarrollar software de calidad duradera, hay que idear una slida base arquitectnica que sea flexible al cambio. Para desarrollar software rpida, eficiente y efectivamente, con el mnimo de desechos software y de trabajo repetido, hay que tener la gente apropiada, las herramientas apropiadas y el enfoque apropiado. Para hacer todo esto de forma consistente y predecible, con una estimacin de los costos del sistema en cada etapa de su vida, hay que disponer de un proceso de desarrollo slido que pueda adaptarse a las necesidades cambiantes del problema en cuestin y de la tecnologa.

El modelado es una parte central de todas las actividades que conducen a la produccin de buen software. Construimos modelos para comunicar la estructura deseada y el comportamiento de nuestro sistema. Construimos modelos para visualizar y controlar la arquitectura del sistema. Construimos modelos para comprender mejor el sistema que estamos construyendo, muchas veces descubriendo oportunidades para la simplificacin y la reutilizacin. Construirnos modelos para controlar el riesgo. Qu es un Requerimiento ? Es un aspecto del contenido o comportamiento del producto, requerido o deseado por el cliente. Requerimientos funcionales. (Lo que debe hacer) Requerimientos no funcionales. (Lo que debe tener) Una restriccin es un requerimiento que afecta a todo el producto. Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y adems contienen mltiples relaciones entre s. El anlisis de requerimientos consiste brevemente en los siguientes pasos: Obtener informacin acerca de lo que los usuarios desean Clasificar esos deseos para comenzar a estructurar requerimientos Identificar los niveles de jerarqua del sistema y empezar a ubicar los ya clasificados requerimientos en cada nivel. Especificar formalmente los requerimientos. Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente.

 Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lgico que para recabarlos haya que obtener la informacin de primera mano. Esto es, mediante entrevistas con el cliente o recabando documentacin que describa la manera que el cliente desea que funcione el sistema de software. Las necesidades y/o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentacin original del cliente, as como cada revisin o cambio que se haga a esta documentacin. Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuales de ellas sern satisfechas por el software y cuales por algn otro producto del sistema. Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, en ellos se basan muchos participantes del proyecto para: Planear el proyecto y los recursos que se usarn en l. Los lideres de proyecto usan los requerimientos como una base para la estimacin del esfuerzo necesario en un proyecto. Especificar el tipo de verificaciones que se habrn de realizar al sistema. Por ejemplo: cuando s esta tratando de alinearse a cierta norma oficial o estndar. Planear la estrategia de prueba a la que habr de ser sometido el sistema. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no. Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados documentacin del sistema son la base para crear la

De ah su importancia y la importancia de que deban de ser definidos y manejados de la forma mas adecuada posible.

 Ya que visualizamos la importancia de los requerimientos en un sistema de software entonces debemos de definir que caractersticas deben de poseer los requerimientos adecuadamente formulados: Especificados por escrito. Como todo contrato o acuerdo entre dos partes Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces cmo sabemos si cumplimos con l o no? Descritos como una caracterstica del sistema a entregar. Esto es: que es lo que el sistema debe de hacer (y no como debe de hacerlo) Lo ms abstracto y conciso posible. Para evitar malas interpretaciones. El clasificar requerimientos es una forma de organizarlos, hay requerimientos que por sus caractersticas no pueden ser tratados iguales. Por ejemplo, los requerimientos de entrenamiento de personal no son tratados de la misma manera que los requerimientos de una conexin a Internet. El anlisis de requerimientos solicita entendimiento, coleccin de requerimientos, clasificacin, organizacin, priorizacin y validacin

Esfuerzo de Mantenimiento

Anlisis de Requerimientos

Parte 2

El anlisis de requerimientos solicita entendimiento, coleccin de requerimientos, clasificacin, organizacin, priorizacin y validacin Los lmites entre el sistema y su ambiente deben ser definidos Influyen los factores organizacionales y sociales en los requerimientos del sistema Involucra trabajo tcnico de grupo con los clientes para averiguar el dominio de la aplicacin, los servicios que el sistema debe proporcionar y las restricciones operacionales propias del sistema Especificar los requerimientos de acuerdo a la audiencia a los cuales va dirigido. Una vez que ya han sido recopilados, clasificados y alojados en el nivel de jerarqua que les corresponde, hay que poner por escrito los requerimientos del sistema. Sin embargo, Hasta donde llegar esta especificacin?. La habilidad de comunicarse con una audiencia debe de ser balanceada con la necesidad de especificar los requerimientos precisamente y sin ambigedad alguna. El UML (El Lenguaje de Modelamiento Unificado) incorpora en sus estructuras los casos de uso. Esta estructura maneja especificaciones formales y abstractas y se acompaa de una descripcin textual y estructurada de los requerimientos del sistema. De acuerdo con el "Capability Maturity Model" (CMM), el manejo de requerimientos involucra: "Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto de software. Este acuerdo son los requerimientos del sistema" "Este acuerdo cubre requerimientos tcnicos y no tcnicos (como fechas de entrega). El acuerdo forma las bases para estimar, planear, ejecutar y monitorear el proyecto de desarrollo de software a travs de todo su ciclo de vida." "Bajo las restricciones del proyecto, el grupo de manejo de requerimientos toma las medidas necesarias para que los requerimientos que estn bajo su responsabilidad estn documentados y controlados" De que manera podemos controlar los requerimientos de software si estos siempre evolucionan con el tiempo?. El CMM nos proporciona las guas para lograrlo. "Para lograr el control de los requerimientos, el grupo de requerimientos revisa los requerimientos antes de que estos sean incorporados al proyecto de software y cada vez que los requerimientos cambian, los planes, productos, y actividades son ajustadas para quedar en lnea con los nuevos requerimientos de software".

 En otras palabras, para obtener el nivel que requiere el CMM en manejo de requerimientos dbenos de tomar en cuenta dos cosas. Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos, y no son impuestos por presiones externas ajenas al proyecto. El requerimiento tcnico podr ser impuesto por el mercado o presiones de la competencia, pero entonces los requerimientos no tcnicos (Calidad, Costo y Tiempo de entrega) debern estar especificados de comn acuerdo con el grupo de requerimientos del proyecto de software. Los requerimientos tcnicos y no tcnicos forman un conjunto entre s, si cambia uno forzosamente debern cambiar los dems. Esto es: ms contenido tcnico implica o ms costo, o menos calidad o ms tiempo estimado de entrega. De modo que los cambios tcnicos debern ser aprobados por el grupo de requerimientos y este grupo estimar los impactos en tiempo, costo, calidad. El resultado de la estimacin es la entrada a los lderes del proyecto para decidir si el cambio se acepta o no.

Anlisis de Requerimientos

Parte 3

La siguiente es una recomendacin de como pueden ser clasificados los requerimientos aunque cada proyecto de software pueda usar sus propias clasificaciones: Requerimientos del "entorno" El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto tipo de requerimientos que se clasifican en esta categora. El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que funcione. Ejemplos del entorno podemos mencionar: sistemas operativos, sistema de archivos, bases de datos. El sistema debe tolerar los errores que puedan ocurrir en el entorno, tales como congestin en los dispositivos y errores de entrada de datos, por lo tanto el entorno se debe de considerar dentro de los requerimientos. Requerimientos "ergonmicos" El mas conocido de los requerimientos ergonmicos es la interface con el usuario o GUI (Graphic User Interface). En otras palabras, los requerimientos ergonmicos son la forma en que el ser humano interacta con el sistema. Requerimientos de Interface La interface es como interacta el sistema con el ser humano o con otros sistemas. La interface es la especificacin formal de los datos que el sistema recibe o manda al exterior. Usualmente se especifica el tipo de informacin, el medio para comunicarse y el formato de los datos que se van a comunicar. Requerimientos funcionales Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa el Qu? y no el Cmo?. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema. Requerimientos de desempeo Estos requerimientos nos informan las caractersticas de desempeo que deben de tener el sistema. Qu tan rpido?, Qu tan seguido?, Cuantos recursos?, Cuantas transacciones? .

 Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el desempeo de un sistema es tan crtico como su funcionamiento. Requerimientos de disponibilidad (en un determinado periodo de tiempo) Este tipo de requerimientos es tambin muy importante en sistemas de tiempo real puesto que estos sistemas manejan aplicaciones crticas que no deben de estar fuera de servicio por periodos prolongados de tiempo. Requerimientos de entrenamiento Este tipo de requerimientos se enfoca a las personas que van usar el sistema. Qu tipo de usuarios son?, Qu tipo de operadores?, Qu manuales se entregarn y en que idioma? Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de cdigo dentro de el sistema, son muy importantes en el proceso de diseo ya que facilitan la introduccin y aceptacin de el sistema en donde ser implementado. Restricciones de diseo Muchas veces las soluciones de un sistema de software son normadas por leyes o estndares, este tipo de normas caen como "restricciones de diseo". Materiales Aqu se especifica en que medio se entregar el sistema y como esta empaquetado. Es importante para definir los costos de industrializacin del sistema.

Problemas del anlisis de requerimientos Los especialistas no saben realmente lo que quieren stos expresan requerimientos en sus trminos propios Diferentes especialistas pueden tener requerimientos en conflicto Los factores polticos y organizacionales pueden influir en los requerimientos del sistema Los requerimientos cambian durante el proceso de anlisis y pueden surgir nuevos especialistas Resistencia organizacional. Los directivos intermedios quienes sern consultados pueden proporcionar deliberadamente informacin incompleta equivocada, as que el sistema puede fallar.

Anlisis de Requerimientos

Parte 4

Mtodos para la recoleccin de requerimientos Aprendiz: El desarrollador se vuelve en el aprendiz de usuario, aprende su trabajo por observacin y preguntando. La gente no siempre esta consciente de todas las tareas que realiza "Nadie describe mejor lo que hace y por qu lo hace, que cuando lo esta haciendo." El aprendiz demuestra lo aprendido hacindolo bajo la supervisin del usuario. El usuario generalmente no tiene tiempo para entrevistas El aprendiz ve la misma tarea repetidamente Captura de eventos en tiempo real Retroalimentacin inmediata Establece una relacin con los usuarios y clientes Entrevistas Ir a ellos para entrevistarlos en su lugar de trabajo Explicar la razn de la entrevista Entrevistar primero al usuario ms experimentado Preguntar, escuchar la respuesta y retroalimentar lo entendido Dibujar modelos, utilizar la terminologa del usuario Guardar ejemplares de documentos/artefactos Agradecer al usuario su tiempo Bsqueda de fallas potenciales: el requerimiento es la falla establecida de forma positiva. Brainstorming El grupo de desarrolladores se renen para una lluvia de ideas Muchas ideas, ideas nuevas, toda idea es buena No deben evaluarse, debatir ni criticar No limitarse. Luego la lista de ideas es evaluada, ordenada 60 ideas locas pueden contener 5 ideas geniales.

(votacin).

Identificacin de eventos y Casos de uso Los eventos se identifican por las entradas y salidas del trabajo Los eventos son algo que sucede fuera del trabajo y a lo que el trabajo debe responder. Importante y Reconocible. Uso de Video

 Grabar en video a los participantes y desarrolladores durante las sesiones de brainstorming y talleres de casos de uso. Grabar las entrevistas y observaciones en el trabajo. Grabar a los usuarios durante su trabajo (ellos describen cmo lo realizan). Registro detallado de las prcticas de los usuarios. Grabar cada evento/caso de uso. Los videos son una ayuda en la bsqueda de requerimientos.

Registro de los requerimientos. Una vez que el requerimiento ha sido plasmado, deber de tener una identificacin nica. Esto es con el fin de facilitar el manejo de requerimientos. Para manejar los requerimientos, estos deben tener: Un nmero nico de ID Tipo Lista de los eventos y casos de uso que lo contienen. Descripcin: una frase que describe la intencin del requerimiento. Propsito: Por qu se considera importante? Fuente: Quin determin este requerimiento Registro de los requerimientos (cont.) Criterio de evaluacin: Prueba no ambigua que indica si una solucin cumple este requerimiento Satisfaccin del cliente: Grado de satisfaccin si el criterio se cumple exitosamente (1=no importa mucho-5=muy satisfecho) Insatisfaccin del cliente: Grado de insatisfaccin si el criterio no se cumple (1=no importa mucho-5=muy molesto) Dependencias: requerimientos que usan la misma informacin o que ocasionan cambios. Conflictos: requerimientos que estn en conflicto con este Materiales de apoyo: Indicacin a las definiciones y documentos que lo ilustran. Historia: Creacin, cambios y eliminacin