SISTEMA DE GESTION DE REQUISITOS
En la ingeniería de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software.
En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.
La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requerimientos de los inversores, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.
¿Que es un requerimiento?
Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
Una condición o capacidad que debe ser conformada por el sistema (RUP).
Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).
Requerimientos en ingeniería de software y sistemas
En ingeniería de sistemas existen tres tipos de requerimientos.
Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento especifica algo que el sistema entregado debe ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto
Una colección de requerimientos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.
En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.
Características
Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.
Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.
Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema. Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de algún modo, pueden sustituir o mapear con esta lista de características.
Análisis de requerimientos
Artículo principal: Ingeniería de requerimientos
La etapa en que se estudian los requerimientos para verificar que estén correctamente adecuados a las características mencionadas es conocida como Análisis de Requerimientos. En la misma se enfocan e intentan solucionar las deficiencias que los requerimientos puedan tener.
ALGO MAS RELACIONADO CON EL TEMA:
En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.
Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
Implicaciones
La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:
La elicitación de los requisitos de usuario
Al análisis y negociación de requisitos para derivar requisitos adicionales
A la documentación de los requisitos como especificación
A la validación de los requisitos documentados contra las necesidades de usuario
Así como los procesos que apoyan estas actividades.
Fases de implementación
Desde un punto de vista conceptual, las actividades son de cinco clases.
Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados.
Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicación.
Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.
Técnicas principales
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. 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 técnicas 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.
Entrevistas
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallos.
Las entrevistas pueden ser personales o grupales.
Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.
Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.
Objetivos medibles
Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.
Prototipos
Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.
Casos de uso
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.
A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.
Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.
Especificación de requisitos del software
Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).
Las estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.
Los requisitos se dividen en tres:
Funcionales: son los que el usuario necesita que efectúe el software. Ej: el sistema debe emitir un comprobante al asentar la entrega de mercadería.
No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL.
Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedición.
Identificación de las personas involucradas
Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más de un tipo de usuario, los analistas de requisitos han de tomar en consideración a todos los implicados para que se obtengan y depuren sus requisitos de la forma más fidedigna posible. Entre las personas implicadas hay que considerar:
Organizaciones que integran la organización del analista que está diseñando el sistema
Organizaciones o sistemas de respaldo
Dirección
Usuarios
Problemas
Relacionados con las personas involucradas
Vías que pueden dificultar la determinación de los requisitos son:
Los usuarios no tienen claro lo que desean
Los usuarios no se involucran en la elaboración de requisitos escritos
Los usuarios insisten en nuevos requisitos después de que el coste y la programación se hayan fijado.
La comunicación con los usuarios es lenta
Los usuarios no participan en revisiones o son incapaces de hacerlo.
Los usuarios no comprenden los problemas técnicos
Los usuarios no entienden el proceso del desarrollo
Esto puede conducir a la situación donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya está en marcha.
Relacionados con los analistas
La correcta redacción de las Especificaciones de requisitos Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redacción hay que evitar:
Uso de terminología ambigua en la redacción de los documentos de requisitos
Sobreespecificación de los requisitos
Escritura poco legible, voz pasiva, abuso de negaciones
Uso de verbos en condicional, expresiones subjetivas
Ausencia de términos y verbos del dominio de la aplicación
Relacionados con los desarrolladores
Los problemas posibles causados por los desarrolladores durante análisis de requisitos son:
El personal técnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que están de acuerdo, no dándose cuenta del desacuerdo hasta que se provee el producto final.
Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente.
El análisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en vez de personal con las habilidades de relación con la gente y el conocimiento apropiados para entender las necesidades de un cliente correctamente.
Soluciones aplicadas
Una solución aplicada en los problemas de comunicaciones ha sido emplear a especialistas en análisis del negocio o del sistema.
Las técnicas introducidas en los años 90 tienden al uso de prototipos, lenguaje unificado de modelado, casos de uso, y el desarrollo ágil de software.
Otros tipos de herramientas aplicadas para salvar las diferencias entre los usuarios y las organizaciones de tecnología de la información y que permiten la comprobación de las aplicaciones son:
pizarras electrónicas para bosquejar los algoritmos y para probar alternativas
capacidad de capturar la lógica del negocio y los datos necesarios
capacidad de generar los prototipos que imitan fielmente el producto final
interactividad
la capacidad para agregar requisitos contextuales y otro comentarios
capacidad para que usuarios remotos y distribuidos operen con el prototipo
Por último, se requieren herramientas que permitan medir, de forma objetiva, la calidad de una especificación de requisitos.
No hay comentarios:
Publicar un comentario