Técnicas de validación de requerimientos

Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones

Escrito el en español con un tamaño de 6,51 KB

Requerimiento:

1-Según La Real Academia Española, un requerimiento se define como la acción y efecto De requerir. 2- Condición o capacidad que necesita el usuario para lograr un Objetivo o solucionar un problema. 3-Una condición o capacidad que debe tener El sistema para satisfacer un contrato, estándar,  especificación de Software u otro documento Formal.

Requerimientos De Negocio:

Estos Requerimientos “describen como sería mejorar el mundo para ciertas comunidades Si el producto estuviera disponible”.2- Son aquellos requerimientos que Representan los objetivos establecidos por la organización.3-Reflejan las Prácticas de negocio actual de la organización.

Herramientas Para el desarrollo de requerimientos de negocio:

Descomposición funcional o mapeo de procesos . 1 Este tipo de vista es la representación desglosada de los procesos macro de La organización (mientras estos se puedan descomponer). 2 La ventaja de este Tipo de descomposición es que permite un mejor entendimiento de la empresa.

Cadena de responsabilidades 1 Es un patrón de diseño que establece una relación directa Entre los responsables de los requerimientos del negocio y los actores externos Que interactúan con los mismos

Requerimientos De usuario

Los usuarios son los Individuos o grupos de ellos a quien va dirigido el sistema

Son aquellas funcionales Específicas que los usuarios esperan ver en la solución

Declaraciones en lenguaje natural en diagramas, de los servicios que se Espera que el sistema proporcione y de las restricciones bajo las cuales debe De funcionar

Definición de Requerimientos: Gerencia de Cliente,Usuarios Finales del Sistema,

Ingenieros de Clientes, Arquitectos Del Sistema.

Requerimientos de especificación : Usuarios Finales Del Sistema,Ingenieros de Cliente,Arquitectos del Sistema,Desarrolladores de Software.

Especificación de Software: Quizá)  Ingenieros de Clientes,Arquitectos del Sistema,Desarrolladores De Software.

Requerimientos funcionales

Describen lo que el sistema O software debe hacer,Siempre se refieren a funciones específicas que debe Hacer la solución,Dependen del tipo de software y del sistema que se desarrolle y de los Posibles usuarios del software,Los requerimientos funcionales para el usuario son Declaraciones de alto nivel, los describen en forma general. Sin embargo, los Requerimientos funcionales del sistema describen los servicios del sistema en Detalle.

Requerimientos NO funcionales

Definen propiedades y Restricciones del sistema

Expresa Una acción que debe ser capaz de realizar el sistema

También Restricciones físicas sobre los funcionales

Ejemplo :

uUsabilidad: factores humanos, ayuda, documentación.

uConfiabilidad: frecuencia de fallas, tiempo de Recuperación

uPerformance: tiempo de respuesta, tasa de procesamiento, Precisión, capacidad de carga

uSoportabilidad: adaptabilidad, mantenibilidad, Configurabilidad, internacionalización

Clasificación de requerimientos NO funcionales

uRequerimientos del Producto

uÉstos especifican el Comportamiento del producto, por ejemplo, rapidez de ejecución, fiabilidad, etc.

uRequerimientos Organizacionales

uEstos requerimientos Son una consecuencia de las políticas y procedimientos de la organización, por Ejemplo, estándares usados en los procesos, los requerimientos de Implementación, etc.

uRequerimientos Externos

uSon requerimientos Que se originan por factores externos al sistema y de su proceso de desarrollo, Por ejemplo, requerimientos legales, éticos, etc.

Para Qué sirve un SRS

Comunicar De manera precisa los requerimientos, objetivos y presunciones del dominio

Contrato: legal, Documento interno o a modo de memorando

Base Para estimación (tamaño, costo, tiempo) y planificación del proyecto

Base Para evaluación de producto final :Verificación y validación

Debería Tener suficiente información para decidir si el producto final es aceptable (satisface los requerimientos)

Base Para el control de cambios

Requerimientos Cambian, software evoluciona, el entorno evoluciona

Orientación Técnica de un SRS

uClientes y Usuarios

uInteresados en validar objetivos del sistema y Descripción de alto nivel de la funcionalidad

uGeneralmente no interesados en los requerimientos Detallados del sistema.

uAnalistas (de sistemas, de requerimientos),

uEscribirán especificaciones de otros sistemas que Interactúan con este.

uEl SRS sirve mas allá de la puesta en producción

uDesarrolladores (ej. Arquitectos, diseñadores, Programadores, ...)

uDeben implementar los requerimientos

Cualidades De un SRS

uCompletitud,Pertinencia,Consistencia,Medibilidad,Precisión (No ambiguo),Factibilidad,Entendibilidad,Trazabilidad,Buena Estructura,Modificabilidad

Contenido General de un SRS

uFuncionalidad. ¿Que es lo que el software hace?

uInterfaces externas. Como debe interactuar con gente, con El hardware del sistema, con demás hardware y con demás software?

uAtributos de Calidad.

uDisponibilidad, tiempo de respuesta, tiempo de Recuperación después de fallas, etc..

uConsideraciones de portabilidad, correctitud, precisión, Mantenibilidad, seguridad y mas...

uRestricciones de diseño. Existen estándares a cumplir, Lenguaje de programación, recursos, sistemas operativos, etc…

Entradas relacionadas: