Consultas

Consulta

Objetivos:

Objetivo General:

• Determinar los conceptos relevantes de requerimientos, casos de uso, caso de pruebas, y encontrar formularios de cada uno

Objetivo Específico:

• Conocer y comprender acerca de formularios de requerimientos, casos de uso y casos de pruebas

Marco Teórico:

Requerimientos

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE.

1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

2. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

3. Una representación documentada de una condición o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

Los requerimientos 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.

Características de los requerimientos

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.

• 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.

• 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.

Dificultades para definir los requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes.

• Son difíciles de expresar en palabras (el lenguaje es ambiguo).

• Existen muchos tipos de requerimientos y diferentes niveles de detalle.

• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.

• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.

• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.

Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Los requerimientos deben ser

• Especificados por escrito. Como todo contrato o acuerdo entre dos partes

Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo sabemos si cumplimos con él o no?

• Descritos como una característica del sistema a entregar. Esto es: que es lo que el sistema debe de hacer (y no como debe de hacerlo)

• Lo más abstracto y conciso posible. Para evitar malas interpretaciones.

Casos de Uso

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema.

Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.

Elementos

• Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

• Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

• Relaciones:

 Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

 Dependencia

...