Descripción
Es el proceso de estudiar las necesidades de los usuarios con la idea de llegar a la determinación de los requisitos de un sistema, hardware o software (IEEE). También según del IEEE, requisito es una condición o capacidad que necesita un usuario para resolver un problema o alcanzar un objetivo
El análisis de requisitos ha sido una fuente de conflicto permanente en los proyectos de desarrollo de sistemas de información o de implantación de SE. Por un lado, es casi imposible planificar y organizar un proyecto si no se sabe lo que se da por descontado que se debe entregar. Por otro lado, si el usuario no entiende los requisitos, o no es capaz de articularlos, ¿cómo se justifica el perder tiempo y energías documentándolos?
La reacción ante este problema ha dado lugar a dos escuelas de pensamiento: la de aquellos que defienden que la mejor manera de dar buenos resultados es definir exhaustivamente los requisitos utilizando todas la herramientas y metodologías existentes, y la de los que defienden que cualquier trabajo en este sentido es tiempo perdido.
Contexto
En la implantación de un SE las actividades de análisis se concentran en seleccionar las partes del software estándar a implantar, y en determinar la forma en que dichos módulos se van a ajustar para resolver las necesidades de la organización. El equipo de trabajo debe entender tanto los procesos de negocio AS-IS como lo TO-BE y las capacidades del paquete de software.
Características
En el proceso de análisis de requisitos se diferencia tres subprocesos:
extracción, documentación y gestión de los requisitos.
La extraccion de requisitos se caracteriza por una conversación no trivial entres dos culturas: los usuarios que no son especialistas en TI y los profesionales de las TI que no dominan el aspecto del negocio que se va a automatizar. Tambien entra en juego otros aspectos como los derivados del personal afectado por una reingeniería de procesos. Entre las técnicas de extracción se pueden nombrar: entrevistas, cuestionarios, brainstorming, storyboarding, prototyping, Joint Application Development (JAD) y modelización
La documentación es un aspecto conflictivo por las posiciones extremas que genera. Lo importante es descubrir el equilibrio óptimo. Además de los requisitos funcionales y de datos hay que documentar los no-funcionales (fiabilidad y escalabilidad). Los modelos visuales (object models, diagramas UML o diagramas flujo)
La gestión de requisitos se centra en evaluar la prioridad, riesgos y esfuerzo de cada uno de ellos. Entre los Requirement Management tools (RM) más utilizados se encuentran DO-ORS, Caliber-RM o Requisite Pro.
Tipologías / Clasificación
Los requisitos funcionales especifican una función que un sistema o componente de sistema debe ser capaz de desarrollar. Los requisitos no-funcionales, como el throughput del sistema la amigabilidad de la interfaz de usuario, la escalabilidad o la fiabilidad, son cruciales en la aceptación del sistema.
Los interface requirements especifican un ítem externo con el cual debe interactuar un sistema o componente de sistema, o estableen las restricciones de formato, tiempo u otros factores causados por dicha interacción
Los design requirements especifican o restringen el diseño de un sistema o de uno de sus componentes.
Los implementation requirements especifican o restringen la codificación o construcción de un sistema o de uno de sus componentes.
Los performances requirements imponen condiciones en un requisito funcional; un requisito que especifica la velocidad, precisión o cantidad de memoria utilizada con la cual se debe ejecutar una función determinada
Gráfico ilustrativo
No hay comentarios.:
Publicar un comentario