UNIDAD 4

REQUERIMIENTOS


es una condición o capacidad a la que el sistema debe conformar.
1) La condición o idoneidad necesitada por un usuario para resolver un problema o para lograr un objetivo.
2). Condición o idoneidad que debe ser lograda o que debe poseer un sistema o componente del sistema para satisfacer un acuerdo, estándar, especificación u otro documento formal aceptado. El conjunto de requerimientos forman la base para el subsecuente desarrollo de un sistema o componente de sistema”
Los requerimientos son una descripción de las necesidades a las que debe responder el producto a desarrollar.
Para extraer los requerimientos correctamente, el equipo de analistas debe estar familiarizado con el dominio de la aplicación.
Descubrir los requerimientos del cliente se denomina extracción de requerimientos (ó captura de requerimientos). Una vez que se traza el conjunto inicial de requerimientos, el proceso de detallarlos y extenderlos se denomina análisis de requerimientos.
Algunos de los problemas surgen al no hacer una separación entre los difenrentes niveles de descripción así:
Requerimientos funcionales y no funcionales
Requerimientos de usuario: Representan el conjunto completo de resultados a ser obtenidos utilizando el sistema.
Ejm. El sistema controlará los datos requeridos por las agencias que licencian los derechos de autor en Europa y en otra parte.
Requerimientos del sistema: Establecen con detalle las funciones, servicios y restricciones operativas del sistema. Debe definir exactamente que es lo que se va a implementar.Ejm. Al hacer una petición de un documento del sistema se presentará un formulario que registre los detalles de usuario y de la petición hecha.
A menudo, los requerimientos de sistemas software se clasifican en funcionales y no funcionales, o como requerimientos del dominio:
1. Requerimientos funcionales. Describen las tareas que el sistema debe realizar.
2. Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad.
3. Requerimientos del dominio. Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales o no funcionales.
Existen otros como
R. de Interfaz: Definen las interacciones del sistema con su entorno:
  • Usuarios
  • Otros sistemas
LENGUAJE UNIFICADO DE MODELADO  (UML)
Lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.
Sirve para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento.
CASOS DE USO
 Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.
PASOS PARA REALIZAR UN DIAGRAMA DE CASOS DE USO
A la hora de diseñar una aplicación más o menos compleja es muy importante hacer un buen análisis. Para que el análisis sea lo mejor posible es necesario tener hecho un buen diagrama de casos de uso UML. Estos son los pasos:
  1. Saber los requerimientos de la aplicación a desarrollar. Para ello tendremos que saber el dominio de la aplicación, por ejemplo, si la aplicación trata de la gestión de un videoclub tendremos que indagar en la administración real de un videoclub.
  2. Cuando tengamos un conocimiento amplio del dominio de la aplicación, en una hoja o en el ordenador usaremos un sistema de listas que nos ayudará a vislumbrar el diagrama de casos de uso definitivo.
  3. Hacemos una primera lista con todas los acciones posibles que se puedan llevar a cabo en la aplicación.
  4. Después hacemos una lista más específica con una selección de las acciones más relevantes que se realizarán en la aplicación. Estas acciones serán las que aparezcan en el diagrama final.
  5. Realizamos el diagrama de casos de uso UML.