Los requerimientos son los puntos clave que un desarrollador de software debe conocer antes de comenzar a construir un producto

de software.
Sin una clara especificacin de un conjunto de requisitos del usuario, un producto de software no puede ser desarrollado y el esfuerzo invertido en el desarrollo seria una prdida.

Las funciones de un producto de software debe coincidir con los requerimientos del usuario.
Muchos sistemas de informacin basados en computadoras han fracasado debido a su incapacidad para capturar correctamente los requerimientos de los usuarios.

Cuando un producto de software terminado es modificado para incorporar nuevos requerimientos entendidos tardamente por el usuario del usuario, hace que el esfuerzo empleado y el costo se eleven de forma considerable.

Costo de reparar un error de los requerimientos

100

70

10 0.1 Anlisis Diseo Codificacin Pruebas Implementacin

Los requerimientos de software reflejan caractersticas especificas de las necesidades de los usuarios.
El usuario solicita estas caractersticas cuando enfrenta problemas tcnicos o de negocio. Estos requerimientos son expresados en lenguaje de usuario

Requerimiento de software: Es una capacidad del software que necesita el usuario para resolver un problema y lograr un objetivo.

Es una capacidad del software que debe cumplir o poseer un componente del sistema o el sistema para satisfacer un contrato, norma, especificacin u otra documentacin formalmente impuesta.

Una caracterstica es un servicio que proporciona el sistema para cumplir con una o ms necesidades de los interesados (stakeholders). As, mientras que las necesidades del usuario se encuentran en el dominio del problema, las caractersticas y requerimientos de software se encuentran en el dominio de solucin.

Necesidades

Problema de dominio

Caractersticas
Problema de solucin

Requerimientos de software

Los requerimientos de usuario se pueden clasificar en:

Requerimientos duraderos Requerimientos voltiles

Son los requerimientos bsicos y estables de los usuarios. Son aquellos que se mantiene constantes durante el ciclo de desarrollo del software

Son aquellos que cambian durante el desarrollo o la operacin del producto de software. Estos requerimientos voltiles pueden tomar diferentes formas

Requerimientos mutables: son aquellos que pueden cambiar debido a cambios en el ambiente. Requerimientos emergentes: son aquellos que aparecen cuando los usuarios empiezan a comprender las funcionalidades del software que se desarrolla.

Requerimientos consecuentes: son aquellos que aparecen cuando un sistema informtico reemplaza a un sistema manual. Requerimientos compatibles: se dan cuando los procesos de negocio sufren algn cambio.

Conscientes: los usuarios son conscientes de ellos. Inconscientes: los usuarios no los mencionan porque piensan que es natural, por lo que asumir todos los conocen. Impensables: los usuarios piden implementarlo cuando se dan cuenta que son posibles.

El anlisis de requerimientos del ciclo de vida del desarrollo de software, el cual es comnmente tambin llamado fase de anlisis, consta de dos sub fases:
Recopilacin de requerimientos Anlisis de sistemas

Recopilacin de requerimientos: este proceso estudia el trabajo de la organizacin con fin de elaborar el mejor producto de software para ayudar con las tareas cotidianas de la organizacin. Descubre los objetivos de negocio, las partes interesadas, la definicin del producto, las restricciones, las interfaces, lo que el producto tiene que hacer, y las cualidades que debe tener.

Anlisis de sistemas: desarrolla modelos de trabajo de las funciones y datos necesarios para el producto como a sido especificado. Estos modelos ayudan a demostrar que la funcionalidad y los datos trabajaran juntos correctamente para proporcionar los resultados que el cliente espera.

Lo que comenz como el anlisis de requerimientos se ha convertido en el campo de la ingeniera de requerimientos que exige un uso sistemtico de:
Principios verificables Mtodos, lenguajes y herramientas para el anlisis

Descripcin de las necesidades del usuario y la

descripcin de las caractersticas del comportamiento desea y no deseado del sistema de software

La ingeniera de requerimientos es descrita desde el punto de vista de todo el sistema a travs de:
Ingeniera de requerimientos del sistema
Ingeniera de requerimientos del software

Mientras que un sistema es un conglomerado de hardware, software, datos, instalaciones y procedimientos para lograr un objetivo comn, un sistema de software es un conglomerado de programas de software para la prestacin de algunas funcionalidades deseadas.

Un SRS establece la base para un acuerdo entre el cliente y el proveedor en lo que el producto de software lo har. Un SRS proporciona una referencia para la validacin del producto final

Un SRS de alta calidad es un requisito previo para el software de alta calidad. Un SRS de alta calidad reduce el costo de desarrollo.

Para satisfacer adecuadamente los objetivos bsicos, una especificacin de requerimientos de software (SRS) debe tener ciertas propiedades y debe contener distintos tipos de requerimientos.

Algunas caractersticas deseables son: Correcto Completo Sin ambigedades Verificable Consistente

Un SRS es correcta si todos los requerimientos incluidos en el SRS representan algo necesario en el sistema final

Es completo si todo el software que se realiza el procesamiento y respectivas respuestas de todas las clases de datos de entrada que se especifican en el SRS.

Es sin ambigedades si y slo si todos los requisitos indican una y slo una interpretacin. Los requerimientos son a menudo escritos en lenguaje natural, que es intrnsecamente ambiguo. Si los requerimientos se especifican en un entorno de natural lenguaje, el escritor de SRS tiene que tener especial cuidado para garantizar que no haya ambigedades.

Un SRS es verificable si y solo si cada requisito declarado es comprobable Un requerimiento es verificable si existe algn proceso econmico que puede comprobar si el software final cumple con ese requerimiento.

Una SRS es consistente si no hay ningn requerimiento que entre en conflictos con otro.

Despus de la fase de anlisis, la fase de diseo comienza. Mientras que los requerimientos especifican lo que el software se supone que debe dar, el diseo especifica la forma de desarrollar el sistema para que sea capaz de dar lo que se supone que debe dar.

El diseo, por lo tanto, es un proceso creativo de transformar el problema en una solucin.

El diseo es tanto un verbo y un sustantivo. Como verbo, que significa "elaborar, para llevar a cabo un plan, para inventar, ...". Significa "los procesos y tcnicas para llevar a cabo el diseo".

Como sustantivo, significa "una relacin de plan o programa formado en la mente, el patrn, de las partes con el todo; ...". Significa "notaciones para expresar o representar el diseo".

Proceso: Es un intelectual (creatividad) la actividad. Proceso y producto: Se refiere a los sistemas romper en partes e identificar las relaciones entre estas partes.

Producto: Es un plan, la estructura del sistema, su funcionalidad, etc, en el sentido del dibujo de un arquitecto respecto al cual el sistema se construir, y tambin forma la base para organizar y planificar el resto del proceso de desarrollo.

Calidad del diseo: Esto constituye las directrices y procedimientos para llevar a cabo la verificacin de diseo y validacin.

El diseo proporciona el marco bsico que gua a cmo los cdigos del programa deben ser escritos y cmo al personal se asigna a las tareas. Los errores de diseo son mayores que los errores de codificacin. Se toma ms tiempo para detectar y corregir, y por lo tanto son ms costoso, que los de la codificacin.

El diseo proporciona una base para monitorear el progreso y seguir a los desarrolladores. Un producto de software mal diseado es a menudo poco fiable, inflexible, ineficiente y no mantenible, ya que est formado por un conglomerado de falta de coordinacin, pobremente probado, y a veces piezas de cdigo no documentadas.

Cuanto mayor sea el sistema y mayor sea el nmero de desarrolladores que participan, el diseo se convierte en una de las fases mas importante del proyecto

El Principio de Totalidad: Los requisitos de diseo estn siempre relacionados entre s y siempre debe ser tratados como tal en toda la tarea de diseo. Un conflicto en los requerimientos del usuario para un producto de software debe ser reconocido debidamente y resolverse.

El Principio del Tiempo: Las funciones y caractersticas de los productos cambia conforme el tiempo pasa. De la entrada simples de lnea de comandos, la produccin ha dado paso a las interfaces grficas de usuario para interaccin humanocomputador.

El principio de valor: Las caractersticas de los productos tienen diferentes valores relativos, dependiendo de las circunstancias concretas y tiempos en los que se pueden utilizar. Un buen programa de antao podra no ser til a los usuarios de hoy.

El principio de Recursos: El diseo, la fabricacin, y la vida de todos los productos y sistemas dependen de los materiales, herramientas y habilidades sobre las que se construyen. Las herramientas de desarrollo, las capacidades humanas, y los sistemas de influyen en la calidad del diseo de software.

El Principio de la Sntesis: las caractersticas combinadamente de un producto deben satisfacer a sus caractersticas deseadas de calidad del diseo con una importancia relativa aceptable por el tiempo que deseamos, teniendo en cuenta los recursos disponibles para realizar y utilizar el mismo. La calidad del diseo de software est fuertemente influenciado por el tiempo y el esfuerzo realizado.

El principio de la iteracin: La evaluacin es esencial para el diseo y es de naturaleza iterativa. Se inicia con la exploracin de la necesidad de que el producto, contina a travs de las etapas de diseo y desarrollo, y se extiende hasta el usuario, cuyas reacciones a menudo hacen que el proceso iterativo para desarrollar un nuevo producto.

El principio del cambio: El diseo es un proceso de cambio, una actividad llevada a cabo no slo a las nuevas circunstancias, sino tambin para lograr cambios en estas circunstancias por la naturaleza del producto que crea. La reingeniera de procesos de negocio se ha convertido en esencial en los nuevos productos de software que se adoptan.

El principio de las relaciones: El trabajo de diseo no puede llevarse a cabo eficazmente sin establecido relaciones de trabajo con todas las actividades relacionadas con la concepcin, fabricacin y comercializacin de los productos y, sobre todo, con el posible usuario.

El Principio de Competencia: El equipo de diseo debe tener la capacidad de sintetizar las caractersticas del producto deseado con las caractersticas de calidad aceptable.