Requerimientos

Toma de Requerimientos

Podemos definir un requerimiento como una condicion o capacidad que debe estar presente
en un sistema o componentes de este para satisfacer un contrato, estandar, especificación u otro documento formal (Std 610.12-1900, IEEE:62)

Otra definicion adoptada es que un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar un sistema.

Los requerimientos son una pieza fundamental en proyectos de Software, en base a esto se puede determinar y hacer estimaciones de tiempo, costos, definir recursos necesarios, elaborar cronogramas y cartas gantt, etc.
Permite verificar y comprobar si se obtuvieron los objetivos establecidos para el proyecto.

Muchas veces los proyectos que fracasan por que la toma de requerimientos es incompleta o por el mal manejo de los cambios en los requerimientos durante la vida de desarrollo del Software.

Clasificación de Requerimientos
La clasificación de requerimientos es importante, de esta manera podemos definir y abstraer con mayor detalle los tipos de requerimientos a los que nos enfrentamos, los requerimientos se pueden clasificar en:

• Requerimientos Funcionales.
• Requerimientos no Funcionales.
• Requerimientos de Implementación.

Requerimientos Funcionales: Describen las interacciones entre el sistema y su entorno, usuarios u otros sistemas

Requerimientos No Funcionales: Describen aspectos visibles del sistema por el usuario, y que no se relacionan directamente con el comportamiento funcional del sistema.

Requerimientos de Implementación: Corresponden a las necesidades del cliente que restringen la implementación, como la plataforma tecnológica, de hardware, redes, etc.

Características en la Toma de Requerimientos
Las características mas importantes y fundamentales para una toma de requerimientos deben contener los siguientes puntos:

• Un requerimientos debe estar especificado siempre por escrito.
• Un requerimiento debe ser posible de probar y verificar.
• Un requerimiento debe ser conciso.
• Un requerimiento debe ser completo.
• Un requerimiento debe ser consistente.
• Un requerimiento no debe ser ambiguo.

Ingeniería de Requerimientos
La Ingeniería de requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajaran, incluye el conjunto de tareas que conducen a comprender cual sera el impacto del software sobre el negocio, que es lo que el cliente quiere y como interactuaran los usuarios finales con el software.

También la ingeniería de requerimientos comprende el proceso de desarrollar una especificación del software, estas pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema

Importancia de la Ingeniería de Requerimientos:

• Permite gestionar las necesidades del proyecto de manera documental y estructurada.
• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados.
• Disminuyen los costos y retrasos del proyecto.
• Mejora la calidad del Software.
• Mejora la comunicación entre equipos.
• Evita rechazos de usuarios finales.

Actividades de la IR

• Estudio de la viabilidad
• Obtención y análisis de requerimientos.
• Validación de requerimientos.
• Administración de requerimientos.

Estudio de la viabilidad
Un estudio de la viabilidad es a corto plazo, y orientado a resolver si el sistema:
Contribuye a los objetivos de la organización?
Se puede implementar con tecnología actual dentro de costo y tiempo?
Puede integrarse a otros existentes en la organización?

Obtención y análisis de requerimientos

• Descubrimiento de requerimientos,
• Puntos de vista: toma en cuenta la existencia de varias perspectivas y provee de una marco de trabajo para descubrir conflictos.
• Entrevistas.
• Escenario: son descripciones de ejemplos de las sesiones de interacción del sistema, se inicio con un bosquejo y durante la obtención se agregan detalles.
• Casos de Uso (UML)
• Clasificación y organización de requerimientos
• Orden por prioridades y negociación
• Documentación

Validación de requerimientos

• Similar al análisis pero comprende un bosquejo completo del documento.
• Importante, ya que los errores en los requerimientos pueden conducir a costos excesivos si se descubren durante el desarrollo o después en la implantación.

Técnicas de validación.

• Revisiones de requerimientos y su documentación.
• Construcción de prototipos.
• Generación de casos de prueba.
• Análisis de consistencia automático con herramientas de software.

Administración de requerimientos.
Los requerimientos de sistemas grandes o complejos son siempre cambiantes.
Los sistemas grandes usualmente se desarrollan para mejorar el status quo.
Surgirán nuevos requerimientos debido a:

• Comunidad diversa de usuarios, los requerimientos finales son comúnmente un termino medio.
• Quien paga es raramente quien usa el sistema.
• Entorno del negocio cambiante.

Se debe generar un proceso formal para que todos los cambios propuestos sean tratados de forma consistente.

Etapas:

• Análisis del problema y especificación del cambio
• Análisis del cambio y costos
• Implementación del cambio

Siempre existe la tentación de hacer un cambio de manera urgente al sistema, y en retrospectiva
modificar el documento de requerimientos. Esto conduce a un desface e inconsistencia

Requerimientos en Normas de calidad
MPS-BR: Norma estándar basada en conceptos similares a los tratados, siguiere la utilización de
UML(casos de uso, secuencia, actividades, estados, etc.) con formato de documentos definidos y
adoptados por la industria como estándar para el modelado y diseño de sistemas con UML.
Propuesta: Utilización de diagramas UML y Procesos, con un modelo de entrega por etapas con
verificación y administración de requerimientos basado en documentación de la norma estándar IEEE-STD-803-1998

Casos de Uso (UML)
UML, de sus siglas en ingles (Unified Modeling Language) se relaciona directamente con el desarrollo de software orientado a objetos y en este nos encontramos con los casos de uso, los cuales nos apoyan al análisis de los requerimientos como una técnica de adquisición de estos, una definición es que los Casos de Uso no son parte del diseño, sino parte del análisis. De forma que al ser parte del análisis nos ayudan a describir qué es lo que el sistema debe hacer. Los Casos de Uso son lo qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario.


Notación de casos de uso:



Lo importante de los casos de uso no es el dibujo que acostumbramos a ver, entonces ¿que es lo importante?, Lo realmente útil de los casos de uso es el documento que describe el caso de uso, en este documento se explica la forma de interactuar entre el sistema y el usuario.
Este podría ser el caso de uso de escribir un mensaje en un foro.



Herramientas de apoyo
Es importante para la buena gestión y administración de tareas, las cuales nacen muchas veces de un requerimiento del cliente, contar con una herramienta tecnológica o aplicación que nos apoye en esta gestión, una aplicación de tipo Workflow que nos permita hacer seguimiento de estas tareas que se pueden asignar a los participantes del proyecto.

Mejores Prácticas
¿Que son las mejores prácticas?
Un conjunto organizado y documentado de principios, métodos y procesos que incrementan la calidad y la productividad en del desarrollo de software.

Mejores practicas orientadas hacia:

El recurso humano.

• Gestión por Roles
• Administración del Tiempo
• Gestión del Conocimiento
• Capacitación basada en competencias

El proceso.

• Desarrollo Iterativo
• Administración de requisitos
• Uso de arquitectura basada en componentes
• Modelado visual
• Aseguramiento continuo de la calidad
• Administración de cambios

El Producto

• La Arquitectura
• El Diseño
• Las Base de datos
• Las Pruebas
• La Operación

Saludos y Suerte !!