ANÁLISIS
DE REQUISITOS
Análisis de requisitos del software
La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que son denominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador.
El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.
El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que son denominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador.
El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.
El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
Tareas de análisis
El análisis de requisitos del software se puede subdividir en cinco áreas de esfuerzo:
1. Reconocimiento del problema
2. Evaluación y síntesis
3. Modelado
4. Especificación
5. Revisión
Todos los métodos de análisis se relacionan por un conjunto de principios operativos:
1. Debe representarse y entenderse el dominio de la información de un problema.
2. Deben definirse las funciones que debe realizar el software.
3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos),
4. Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente).
5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación.
Además de los principios operativos mencionados anteriormente, se sugiere un conjunto de principios directrices para la ingeniería de requerimientos:
1. Entender el problema antes de empezar a crear el modelo de análisis.
2. Desarrollar prototipos que permitan al usuario entender como será la interacción hombre-máquina.
3. Registrar el orden y la razón de cada requerimiento,
4. Usar múltiples planteamientos de requerimientos.
5. Priorizar los requerimientos.
6. Trabajar para eliminar la ambigüedad.
Un ingeniero de software que se apegue a estos principios es muy probable que desarrolle una especificación de software que represente un excelente fundamento para el diseño.
El análisis de requisitos del software se puede subdividir en cinco áreas de esfuerzo:
1. Reconocimiento del problema
2. Evaluación y síntesis
3. Modelado
4. Especificación
5. Revisión
Todos los métodos de análisis se relacionan por un conjunto de principios operativos:
1. Debe representarse y entenderse el dominio de la información de un problema.
2. Deben definirse las funciones que debe realizar el software.
3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos),
4. Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente).
5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación.
Además de los principios operativos mencionados anteriormente, se sugiere un conjunto de principios directrices para la ingeniería de requerimientos:
1. Entender el problema antes de empezar a crear el modelo de análisis.
2. Desarrollar prototipos que permitan al usuario entender como será la interacción hombre-máquina.
3. Registrar el orden y la razón de cada requerimiento,
4. Usar múltiples planteamientos de requerimientos.
5. Priorizar los requerimientos.
6. Trabajar para eliminar la ambigüedad.
Un ingeniero de software que se apegue a estos principios es muy probable que desarrolle una especificación de software que represente un excelente fundamento para el diseño.
Funciones y habilidades del analista
La función principal de un analista del software (o ingeniero de requisitos es llevar a cabo las actividades necesarias para cumplir con las cinco áreas de esfuerzo descritas en la sección anterior. Para lo cual hace uso de las siguientes técnicas :
1. Entrevistas
2. Talleres
3. Observación
4. Encuestas
5. Revisión documental
6. Uso de especificaciones formales para requerimientos (formatos estándar de documentos, UML, etc.)
El ingeniero de requisitos debe poseer habilidades particulares para facilitar la comunicación con el cliente y ganar su confianza.
La función principal de un analista del software (o ingeniero de requisitos es llevar a cabo las actividades necesarias para cumplir con las cinco áreas de esfuerzo descritas en la sección anterior. Para lo cual hace uso de las siguientes técnicas :
1. Entrevistas
2. Talleres
3. Observación
4. Encuestas
5. Revisión documental
6. Uso de especificaciones formales para requerimientos (formatos estándar de documentos, UML, etc.)
El ingeniero de requisitos debe poseer habilidades particulares para facilitar la comunicación con el cliente y ganar su confianza.
El proceso de la ingeniería de requisitos
Fuente: [URJC]
Las actividades del proceso son:
1. Comprensión del dominio
2. Recolección de requisitos
3. Clasificación
4. Resolución de conflictos
5. Priorización
6. Verificación de requisitos
7. Análisis
Actividades de la Ingeniería de Requisitos. [SOMMERVILLE, 2002]
La ingeniería de requisitos incluye dos actividades principales: la obtención de requisitos, que da como resultado una especificación del sistema que el cliente comprende, y el análisis, que da como resultado un modelo de análisis que los desarrolladores pueden interpretar sin ambigüedad. [BRUEGGE, 2002]
La obtención de requisitos se enfoca en la descripción del propósito del sistema y es la que implica el reto mayor. El cliente, los desarrolladores y los usuarios identifican un área problema y definen un sistema que resuelve el problema. A tal definición se le llama especificación de los requisitos del como contrato entre el cliente y los desarrolladores. La SRS se estructura y formaliza durante el análisis para producir un modelo de análisis. Tanto la SRScomo el modelo de análisis representan la misma información. Difieren sólo en el lenguaje y notación que usan. La SRS está escrita en lenguaje natural, mientras que el modelo de análisis se expresa, por lo general, en una notación formal o semiformal. La especificación del sistema es la base de la comunicación con los stakeholders. El modelo de análisis es la base de la comunicación entre los desarrolladores.
La obtención de requisitos y el análisis se enfocan sólo en la visión del sistema que tiene el usuario.
Fuente: [URJC]
Las actividades del proceso son:
1. Comprensión del dominio
2. Recolección de requisitos
3. Clasificación
4. Resolución de conflictos
5. Priorización
6. Verificación de requisitos
7. Análisis
Actividades de la Ingeniería de Requisitos. [SOMMERVILLE, 2002]
La ingeniería de requisitos incluye dos actividades principales: la obtención de requisitos, que da como resultado una especificación del sistema que el cliente comprende, y el análisis, que da como resultado un modelo de análisis que los desarrolladores pueden interpretar sin ambigüedad. [BRUEGGE, 2002]
La obtención de requisitos se enfoca en la descripción del propósito del sistema y es la que implica el reto mayor. El cliente, los desarrolladores y los usuarios identifican un área problema y definen un sistema que resuelve el problema. A tal definición se le llama especificación de los requisitos del como contrato entre el cliente y los desarrolladores. La SRS se estructura y formaliza durante el análisis para producir un modelo de análisis. Tanto la SRScomo el modelo de análisis representan la misma información. Difieren sólo en el lenguaje y notación que usan. La SRS está escrita en lenguaje natural, mientras que el modelo de análisis se expresa, por lo general, en una notación formal o semiformal. La especificación del sistema es la base de la comunicación con los stakeholders. El modelo de análisis es la base de la comunicación entre los desarrolladores.
La obtención de requisitos y el análisis se enfocan sólo en la visión del sistema que tiene el usuario.
Tipos de requisitos
Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema.
Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)
Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema.
Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)
No hay comentarios:
Publicar un comentario