Requisitos

La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software. El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.

El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software

Tipos de requisitos

Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema.

Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)

Características de los requerimientos

Necesario: Lo que pida un requisito debe ser necesario para el producto.

Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno

de tipo técnico y especializado, aunque aun así debe referenciar los aspectos importantesCompleta: Una SRS es completa, sí y solo sí, incluye los siguientes elementos:a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificación del sistema debe ser reconocido y tratado.

 

b) Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada válidos como inválidos.

c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS así como la definición de todos los términos y unidades de medida.

Consistente: Una SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningún subconjunto de requisitos ahí descritos se contradicen o entran en conflicto.

No ambigua: Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.

Verificable: Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable.

Dificultades para definir los requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes.

• Son difíciles de expresar en palabras (el lenguaje es ambiguo).

• Existen muchos tipos de requerimientos y diferentes niveles de detalle.

• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.

• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.

• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.

• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Importancia de la Ingeniería de Requerimiento

Según la autora Lizka Johany Herrera en su documento de la ingeniería de requerimientos, los Principales beneficios que se obtienen de la Ingeniería de Requerimientos son (2003: 3):

• Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.

• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

• Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo.

• Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, y otros)

• Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

• Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto

Ingenieria de requerimentos

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos1 comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de las partes interesadas, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

Identificación de las personas involucradas

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más de un tipo de usuario, los analistas de requisitos han de tomar en consideración a todos los implicados para que se obtengan y depuren sus requisitos de la forma más fidedigna posible. Entre las personas implicadas hay que considerar:

Organizaciones que integran la organización del analista que está diseñando el sistema

Organizaciones o sistemas de respaldo

Dirección

Usuarios.

Relacionados con las personas involucradas

Las vías que pueden dificultar la determinación de los requisitos son:

Los usuarios no tienen claro lo que desean

Los usuarios no se involucran en la elaboración de requisitos escritos

Los usuarios insisten en nuevos requisitos después de que el coste y la programación se hayan fijado.

La comunicación con los usuarios es lenta

Los usuarios no participan en revisiones o son incapaces de hacerlo.

Los usuarios no comprenden los problemas técnicos

Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situación donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya está en marcha.

Requerimientos desde el punto de vista del cliente y del desarrollador

.Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería  de requisitos, un conjunto de actividades que son denominadas análisis. El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador.

Desde el punto de vista de los ingenieros de Software

Ayudar a comprender el problema

Permitir la reutilización

Facilitar el mantenimiento del producto final

Optimizar el conjunto y cada una de las fases del proceso de desarrollo

§Desde el punto de vista de cliente o usuario final

Garantizar el nivel de calidad del producto final

Obtener el ciclo de vida adecuado para el proyecto

Confianza en los plazos del tiempo mostrados en la definición del proyecto

IEEE

Existe un estándar llamado IEEE 830 SRS para una adecuada especificación de requerimientos para el desarrollo de Software

3. Las consideraciones para producir un buen SRS(especificación de requisitos del software).

Los siguientes puntos muestran información que debe ser consideradas al momento de producir un SRS.

El SRS son especificaciones para un producto del software en particular, programa, o juego de programas que realizan ciertas funciones en un ambiente específico. El SRS puede escribirse por uno o más representantes del proveedor, uno o más representantes del cliente, o por ambos.

El software puede contener toda la funcionalidad del proyecto o puede ser parte de un sistema más grande.

Si es una parte del sistema habrá un SRS que declarará las interfaces entre el sistema y su software completo y pondrá que función externa y requisitos de funcionalidad tiene con el software modular.

El proceso de desarrollo de software debe empezar con el proveedor y con el acuerdo del cliente en lo que el software completado debe hacer. Este acuerdo, en la forma de un SRS, debe prepararse juntamente. Esto es importante porque ni el cliente ni el proveedor son calificables para escribir exclusivamente un buen SRS.

Los requisitos del proyecto representan una comprensión entre el cliente y el proveedor sobre materias contractuales que pertenecen a la producción de software y así no deben ser incluidos en el SRS. Éstos normalmente incluyen los puntos como:

a) el Costo;

b) Los tiempos de la entrega;

c) Informando los procedimientos;

d) Los métodos de desarrollo de Software;

e) La convicción de Calidad;

f) La Aprobación y criterio de la comprobación