Análisis
En la actualidad existen problemas para el desarrollo de sistemas en los cuales destacan un mal entendimiento de las necesidades de los usuarios y clientes, por la incapacidad de absolver nuevos cambios, insatisfacción del cliente por el bajo rendimiento del software, a pesar de la nuevas tecnologías existente y los grandes avances en materia tecnológica; a la hora de empezar un proyecto la parte más difícil es el comienzo, ¿ por dónde empezamos? y como analistas nos hemos encontrado con esa situación, establecer los primeros requisitos es la parte más dificultosa a la hora de emprender un proyecto, “Un requerimiento podría ser definido como un adjetivo necesario dentro de un sistema, que puede
representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales”.
Es aquí donde la ingeniería de los requisitos juega un papel determinante, con el fin de entender mejor el problema del cliente en cuya solución se trabajará, ir conociendo las necesidades para el cual se realizara el software, comenzar estableciendo las prioridades del mismo. Se debe entender que es lo que el cliente quiere, por lo generar los clientes no saben a ciencia cierta qué es lo que realmente desean de un sistema y la factibilidad de los que ellos piden es en ese momentos donde se le indican algunas pautas y se orienta a ir estableciendo prioridades acorde con su necesidad todo esto antes de comenzar a diseñar y construir un sistema, Debido a que los cambios que implica un sistema tienden a afectar a más de un tipo de usuario, los analistas han de tomar en consideración a todos los implicados para que se obtengan y depuren sus requisitos de la forma más manifiesta posible y Tomando en cuenta errores, de coste y tiempo, La Ingeniería de los Requerimientos trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos, de forma sistemática y repetible.
Los requerimientos pueden dividirse en funcionales y no funcionales. Los funcionales precisan las funciones que el sistema será capaz de realizar; describen el desenvolvimiento que realiza sobre las entradas para producir salidas. Los requisitos 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.
Igualmente los requisitos poseen sus características especiales las cuales son sus propiedades principales, un conjunto de exigencias en estado de criterio, deben presentar una serie de ventajas tanto individualmente como en grupo, los requerimientos deben poseer ciertas propiedades entre los que se destacan:
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. (ambiguo. Posibilidad que algo pueda entenderse de varios modos de que admita diferentes interpretaciones)
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.
En la búsqueda de los requerimientos por lo general se presentan una serie de dificultades a la hora de obtener la información o para detallar las exigencias, porque los mismos no son tan obvios, no están a simple vista como el cliente cree, los mismos provienen de muchas fuentes con diferentes puntos de vista, son difíciles de expresar en palabras, existen muchos tipos y de diferente niveles de referencia, nunca son iguales, algunos más difícil, mas importante, uno más riesgoso que otro, la cantidad de requisitos en un proyecto puede ser difícil de manejar están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades, los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas, los analistas pueden emplear varias prácticas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos y utilizan casos de uso, cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.
A partir de allí se establecen las necesidades y se justifica la realización del sistema apartando diversas maneras y posibles soluciones que se puedan aplicar, siempre y cuando se discutan en grupo con los diversos actores que participan. El objetivo es crear un una sección de discusión a desarrollar teniendo en cuenta el entorno, la diversas aéreas, temáticas como los inconvenientes que puedan surgir, el equipo tecnológico con que se cuenta estableciendo que se puede usar actualmente y sobre todo el rendimiento físico e intelectual, de esta manera poner todo en un enfoque accesible para el cliente; aunque intervienen muchos en esto como gerentes de operaciones, de negocios de productos, mercadotecnia, consultores, usuarios finales, ingenieros de software, de soporte y mantenimiento entre otros; es necesario identificar las necesidades que beneficien a todos.
Se despliegan las funciones de calidad, que no es más que vincular las necesidades del cliente con requisitos técnico para el software. Se describen tres tipos:
Normales: es lo que el cliente estableció en las reuniones a nivel de software y que estén descritas allí, entonces estará satisfecho.
Esperados: no es más que viabilidad de dicho sistemas que obvias y fundamentales como que el mismo funcione.
Estimulantes: son aquellos que el cliente no espera que sea configurado con diversas capacidades a medida de ser usado.
Dicho de otra manera se identifican y analizan los objetivos y el resultado es que dicha funciones generen un sistema factible y viable dentro del entorno. Por otra parte se exponen las características para el desarrollo del sistema sean compatibles y factible con lo que se cuenta para que sea viable y si no es optimo para dar aporte que se ajuste al entorno tratando en lo posible resolver las condiciones del cliente:
Entendible: Se encuentra el proceso bien definido y es claro
Visible: El proceso es visible al exterior
Soportable: Puede el proceso ser soportado por herramientas CASE.
Aceptable: El proceso es aceptado por aquellos involucrados en el.
Durante el proceso de levantamiento y recolección de los requisitos se emplean diferentes técnicas entre ellas las más usadas son:
Entrevistas: son preguntas directas a los interesados dentro de la organización y quienes interactúan con el sistema; estas pueden ser:
Abierta: pueden representar una opinión del entrevistado. En algunos casos pueden ayudar a recolectar algunos datos interesantes, pero también pueden alargarse y no aportar gran cantidad de información.
Cerradas: esta modalidad de pregunta restringe la respuesta del entrevistado, haciendo la entrevista más rápida y confiable, este tipo de preguntas puede aportar gran información si son bien elaboras y el analista se enfoca en lo que se desea averiguar.
Averiguaciones: son utilizada para ahondar más en un tema y conseguir ampliar la información obtenida (Ejemplo: ¿Por qué?)
Cuestionarios: son utilizados para recopilar información a través de las actitudes, características y las conductas de las personas que están relacionadas con el manejo del sistema.
La técnica denominada JAD (Joint Application Development, Desarrollo Conjunto de Aplicaciones), desarrollada por IBM en 1977, el cual comprende reuniones intensivas entre las partes, identificando las necesidades del cliente donde especifica los requisitos y tecnología más conveniente para el sistema participando los usuario de manera activa en el proceso en una única e intensa reunión en un plazo entre un día a una semana, es la metodología más utilizadas por los desarrolladores de software.
En este método intervienen de forma organizada el participante en el proyecto con asignaciones específico tales como:
El patrocinador del proyecto: es quien presupuesta, el dueño del sistema; tomando las decisiones, proporcionando los recursos, asegurando, ayudando y evaluando el sistema si es eficaz o no.
El líder del proyecto: que dirige las acciones a tomar siendo objetivo, tiene que estar en conocimiento con los requisitos y así coordinar todas las asignaciones de su equipo sin que falte nadie.
Registrador: apunta lo más importante de las discusiones resumiendo los aportes que se ven durante la reunión para ser publicadas con la previa revisión del líder y del patrocinador del proyecto.
Time keeper: son quienes organizan el tiempo y las agendas para el desarrollo eficaz.
Cliente: son los que manipularan el sistema y crearan situaciones prácticas de pruebas del mismo.
En comparación con los métodos tradicionales, JAD es más costoso y puede ser difícil si el grupo es demasiado grande relativo al tamaño del proyecto, sin embargo, el JAD permite que los usuarios más sobresalientes participen con eficacia en los requisitos que modelan el proceso. Cuando los usuarios participan en el proceso del desarrollo de los sistemas, es más probable percibir un sentido de la propiedad en los resultados, y la ayuda para el nuevo sistema. Cuando está siendo utilizado correctamente, JAD puede dar lugar a una declaración más exacta de los requisitos del sistema, a una comprensión mejor de metas comunes, y a una comisión más fuerte al éxito del nuevo sistema.
En conclusión podemos decir que los requerimientos son el material principal en el desarrollo del software, hacer una serie de investigaciones a la necesidad del cliente y donde el analistas debe delimitar el alcance real del proyecto , el pasar algunos puntos por alto, por lo general nos hace entrar en dificultad y crear retrasos en la elaboración del mismo, debido a que se tendría que corregir errores donde se generen y a su vez eso produce pérdida de tiempo y dinero, ya que se tiene un presupuesto destinado para ello y en esta época moderna el tiempo y el dinero van de la mano para lo empresarios.
