Estudiante

Caso 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 iniciaun 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 laespecializació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 puedeutilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.
Matriz de trazabilidad
La matriz de trazabilidad es una herramienta que se utiliza para saber que requerimientos quedan cubiertos por una prueba. Veámoslo con un sesillo ejemplo.
Imaginemos que tenemos un proyecto con 5 requerimientos (R1-R5) y hemos diseñado tres casos de prueba (T1-T3).
* El caso de pruebaT1 cubre los requerimientos R1 y R4
* El caso de prueba T2 cubre los requerimientos R3 y R5
* El caso de prueba T3 cubre el requerimiento R3
En este caso la matriz resultante será:
| T1 | T2 | T3 |
R1 | X | | |
R2 | | | |
R3 | | X | X |
R4 | X | | |
R5 | | X | |
Viendo la matriz podemos ver claramente dos cosas:
1. El requerimiento R3 está probado en 2 casos deprueba.
2. El requerimiento R2 no está cubierto.
Gracias a estos datos podemos ver que partes o módulos del software no están cubiertos y deberían probarse por otras pruebas o identificar los requerimientos más críticos para saber si están suficientemente cubiertos (más de un caso de prueba es diseñado y ejecutado para ese requerimiento).
También podemos identificar los casos de prueba quehan fallado y a partir de ahí ver que requerimiento esta en riesgo para poder evaluar la criticidad y el riesgo de este.

Tipos de requisitos: Funcional vs. No Funcional
Generalmente hablamos en este blog de los llamados sistemas intensivos en software, donde la funcionalidad esta provista principalmente por la presencia de software apropiadamente programado. Es decir, que las característicasde esta clase de sistema se encuentran implementadas por medio de la escritura, compilación y ejecución de líneas de código.
Cuando hablamos de una característica requerida de la cual se sabe que va a ser satisfecha por medio de la adición de un subsistema o bloque de código en el software, entonces se dice que estamos ante un requisito funcional, por cuanto es un requisito que denota unafuncionalidad del sistema.
Entonces, para el glosario:
Requisito Funcional: característica requerida del sistema que expresa una capacidad de acción del mismo – una funcionalidad; generalmente expresada en una declaración en forma verbal.
Por otra parte, no todo lo que los clientes nos van a solicitar es funcionalidad pura; por el contrario ellos desean otras cualidades, si se quieren generalidades,que no son objeto de codificación si bien es cierto que pueden llegar a afectar a esta.
Llamamos requisito no funcional a todas las exigencias de cualidades que se imponen al proyecto: exigencias de usar un cierto lenguaje de programación o plataforma tecnológica, por ejemplo. Un requisito no funcional es una característica ya sea del sistema, del proyecto o del servicio de soporte, que nos es...