Tipos de Requerimientos.
Requerimientos Funcionales:
· Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar.
· 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.
Ej. En el caso de un Sistema para un centro Clínico.
El sistema deberá almacenar la información personal de los pacientes.
El sistema deberá poder desplegar la historia clínica en cualquiera de los nodos de acceso.
El sistema deberá registrar cualquier acceso o modificación sobre una historia clínica.
Requerimientos no funcionales:
· Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones.
· 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.
Clasificación de los requerimientos no funcionales.
Requerimientos del Producto:
Requerimientos que especifican que el producto deba comportarse de una determinada manera.
Requerimientos Organizacionales:
Requerimientos que surgen de políticas y procedimientos de la organización (Creadora o Usuaria).
Requerimientos Externos:
Requerimientos surgidos por factores externos al proyecto de desarrollo como tal.
Requerimientos del Dominio.
Un requerimiento del domino captura los tipos más importantes de objetos en el contexto del sistema. Los objetos del dominio representan las "cosas" que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Muchos de los objetos del dominio o clases pueden obtenerse de una especificación de requisitos o mediante la entrevista con los expertos del dominio.
El objetivo de modelar un requerimiento de dominio es comprender y describir las clases más importantes dentro del contexto del sistema.
Para una mayor comprensión del contexto en que se desarrolla el sistema se definen los principales conceptos relacionados con el entorno del problema.
Se debe considerar:
Definición de los objetos y los conceptos principales.
Representación del Modelo de Objetos del Dominio.
Reglas del negocio a considerar.
Requerimientos del Usuario.
Están definidos en lenguaje natural que esbozan los servicios y restricciones del sistema. Escrito para consumidores.
Los requerimientos se especifican en un lenguaje entendible por los usuarios del sistema que no tienen conocimientos técnicos.
Generalmente se expresan usando lenguaje natural, tablas y diagramas que todos puedan entender.
Son suficientes para que los usuarios entiendan o sepan que esperar del sistema en desarrollo.
Los lectores del requerimiento del usuario:
Clientes Administradores y los Usuarios finales del Sistema.
Problemas de los Requerimientos de usuario.
Para hacer un documento fácil de leer, se eliminan detalles que deterioran el detalle y la precisión de los requerimientos.
No hay una completa división entre requerimientos funcionales y no funcionales.
Muchos requerimientos tienen de ser expresados juntos.
Tips para requerimientos de Usuario.
Construir un formato estándar para expresar todos los requerimientos.
Use el lenguaje de una manera consistente, que permitan diferenciar claramente entre requerimientos obligatorios y requerimientos deseables.
Resaltar aspectos importante del requerimientos (Con negrilla, subrayado, etc.).
Evitar en lo posible el lenguaje informático.
Requerimientos del Sistema.
Están definidos de una manera estructurada, y además de los servicios y restricciones del sistema, da nociones concisas de cómo debería ser implementado.
Los requerimientos del sistema proveen una definición mucho más completa y detallada, de tal manera que sirva como un esbozo inicial de la aplicación.
No se limita a especificar qué debe hacer el sistema, sino que además debe especificar cómo lo debe hacer.
Los lectores del Requerimiento del Sistema:
Arquitectos del sistema.
Desarrolladores del Software.
Usuarios Finales del sistema.
Datos Básicos de un Requerimiento de Sistema.
Función.
Descripción.
Entradas.
Fuente de la Entradas.
Salidas.
Destino de las Salidas.
Acción.
Requisito.
Precondición, Postcondición.
Efectos Colaterales.
Especificación de Requerimientos.
Un documento estructurado con descripción o detalle de los servicios del sistema. Escrito como un contrato entre el cliente y el creador del software.
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será aplicada para el archivo.
1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al
usuario.
1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo
externo será definido por el usuario.
1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el
efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo externo
al archivo representado por la selección del icono.
Las notaciones de los requerimientos deben contemplar:
Especificación de la conducta externa del sistema.
Especificar los límites de la implementación.
Fácil de cambiar.
Sirve como una herramienta de referencia para mantenimiento.
Recuerda el ciclo de vida del sistema, esto es, predice cambios.
Proporciona respuestas características a un evento no esperado.
Diagrama de Caso de uso. Para requerimientos
REQUERIMIENTOS
Diagrama de actividad para requerimientos
Estándares de la documentación de los requerimientos.
Introducción.
Describe la necesidad de crear el sistema y cuáles son sus objetivos.
Glosario.
Define los términos técnicos usados.
Modelos del Sistema.
Define los modelos que muestran los componentes del sistema y las relaciones entre ellos.
Definición de Requerimientos Funcionales.
Define los servicios que serán proporcionados.
Definición de Requerimientos No-funcionales.
Definir las limitantes del sistema y el proceso de desarrollo.
Evolución del Sistema.
Definir las suposiciones fundamentales en las cuales el sistema se basa y se anticipan los cambios.
Especificación de Requerimientos.
Especificación detallada de los requerimientos funcionales del sistema.
Apéndices.
Descripción de la plataforma de Hardware del Sistema.
Requerimientos de la base de Datos.
Índice.
Como obtener requerimientos de alta calidad.
Validación de Requerimientos:
Demostración de que los requerimientos que definen el sistema son lo que el cliente realmente quiere.
Los costos de errores en los requerimientos son altos, por lo cual, la validación es muy importante.
Fijar un error de requerimiento después del desarrollo puede resultar en un costo 100 veces mayor que fijar un error en la implementación.
El Prototipado es una técnica importante de la validación de requerimientos.
Chequeando Requerimientos:
Validación. Provee al sistema las funciones que mejor soporten las necesidades del cliente?
Consistencia. Existe cualquier conflicto en los requerimientos?
Completo. Están incluidas todas las funciones requeridas por el cliente?
Realismo. Pueden los requerimientos ser implementados con la tecnología y el presupuesto Disponible?
Revisión de Requerimientos:
Una revisión regular puede ayudar mientras la definición de requerimientos está siendo hecha.
Tanto el cliente como el staff de creadores deben estar involucrados en la revisión.
La revisión debe ser formal (con los documentos completos) o informal. Una buena comunicación entre desarrolladores, clientes y usuarios puede resolver problemas en las primeras etapas.
Chequeo de la Revisión:
Verificabilidad. Es el Requerimiento realmente probable?
Entendibilidad. Es el requerimiento comprendido propiamente?
Probabilidad. Es el origen de los requerimientos claramente establecido?
Adaptabilidad. Puede el requerimiento ser cambiado sin causar un gran impacto en otros requerimientos?
Resumen:
Los errores en los requerimientos son usualmente muy caros de corregir una vez desarrollado el sistema.
La revisión debe involucrar al cliente y al creador del software para validar los requerimientos del sistema.
El establecer requerimientos está relacionado con las actividades del cliente para el Software.
Los requerimientos volátiles dependen del contexto en que se use el sistema.
No hay comentarios:
Publicar un comentario