Requisitos

Introduccion
"Lo mas complicado de construir un sistema software es decidir
exactamente que construir….. Y ninguna otra parte afecta tan
negativamente al resultado si se hace mal. Ninguna otra es tan
dificil de rectificar." F.P.Brooks
Dentro de las actividades de la Ingenieria de Software, las
relaciones con la obención y gestión de los requisitos resultan
especialmente críticas. Este conjunto de actividades consiste en
obtener y documentar los requisitos para desarrollar el sistema y
posteriormente analizarlos con el objetivo de responder a la
pregunta ¿Que debe hacerse?
Un proyecto software, simplificado al máximo, es básicamente la
transformación de un conjunto de requisitos en un sistema
informático. En consecuencia, si se parte de diferentes requisitos
se obtendran diferentes sistemas como resultado. He aqui uno de
los componentes mas importantes de la gestión de requisitos,
puesto que si la descripcion de los mismos no es adecuada, o se
desvía de lo que el cliente o los usuarios finales desean, entonces
tal vez obtendremos un sistema perfecto ( o tal vez no) pero es
evidente que dicho sistema no satisfará las expectativas
generadas.
Establecer con exactitud los requisitos de un sistema es, por tanto,
un principio esencial para llevar a cabo con exito un desarrollo de
software. Es una de las tareas mas complicadas a las que se
enfrentan los desarrolladores.
La obtención de los requisitos es, en definitiva, un proceso muy
complejo en el que intervienen diferentes personas, las cuales
tienen distinta formación y conocimiento del sistema
(desarrolladores, clientes, usuarios, etc.).
En este proceso, es necesario tener en cuenta la influencia de
diversos factores que impactan en el desarrollo del proceso, como
son:
 La complejidad del problema a resolver.
 El cliente no siempre sabe en terminos concretos lo que
quiere.
 Dificultades de comunicacion entre los desarrolladores y el
cliente, incluyo entre los mismo miembros del equipo de
desarrollo.
  Un buen numero de requisitos son ocultos, pues no pueden
obtenerse directamente de los usuarios y cliente, sino que
dependen del proceso de construccion del software.
 Aspectos relacionados con la naturaleza cambiente de los
requisitos y la inclusion de nuevos durante el proceso.
Definiciones preliminares y características

Segun el glorasio de terminos de IEEE:

Un requisito de software es la capacidad que debe alcanzar o

poseer un sistema o componente de un sistema para satisfacer un
contrato, estandar, especificación u otro documento formal.

La guia SWEBOK por su parte lo define como:

Un requisito de software es la propiedad que un software

desarrollado o adaptado debe tener para resolver un problema
concreto.

De acuerdo con la ultima definicion, un requisito software puede

consistir en dar soporte a procesos de negocio de la organizacion
que ha solicitado el software (como calcular e imprimir las nominas
de los empleados a fin de mes), automatizar ciertas tareas de las
que lleva a cabo alguna persona que utilizará el software (por
ejemplo la introducción de datos de un pedido a un proveedor
mediante una terminal con lector optico), realizar funciones que no
realiza el software actual de una organización (cuando se
implemento la moneda única en la Union Europea, hubo que
modificar los sistemas que manejaban unidades monetarias para
que soportaran precios en euros), etc.
Cuando se especifican los requisitos, se almacena información
sobre los mismos que permite gestionarlos e interpretarlos,
información que se conoce como atributos.

Se denomina atributo de un requisito a cualquier información

complementaria que se utiliza para su gestión y que se incluye en
su especificación.

Esta información a menudo consiste en una descripción general del

requisito: su tipo (funcional o no funcional, del sistema, del usuario,
etc.), la fuente del requisito, la historia de cambios sufrida, entre
otros.

El proceso de requisitos se desarrolla en buena medida en un

escenario pluridisciplinar, donde participan especialistas diversos
(actores), tanto en el dominio del problema como en ingenieria de
software.

Un actor es un rol perfectamente definido que una persona puede

desempeñar en el proceso de requisitos. Se pueden identificar los
siguientes actores, en la mayoria de los proyectos de desarrollo de
software: Usuarios, Clientes, Expertos o especialistas,
Reguladores, Ingenieros de software, entre otros.

Caracteristicas de los requisitos:

La caracteristica escencial de todo requisito software es que

sea verificable, propiedad intrinseca que permitirá comprobar mas
adelante que el sistema software en su conjunto o alguno de sus
componentes, da cumplimiento al requisto tal y como fue
especificado.

De acuerdo con esta propiedad, los requisitos deben establecerse,

cuando sea posible, de manera cuantificable. Una definicion
cuantificable seria por ejemplo "el tiempo maximo en que el usuario
obtiene respuesta a una consulta en la base de datos nunca debe
ser superior a 2 segundos". Esta capacidad de cuantificar los
requisitos facilita la medicion de su cumplimiento, otorgando valor
a un sistema software.

Es muy importante evitar especificaciones ambiguas tales

como "la interfaz de usuario será amigable facil de utilizar", de dificil
verificacion. Lo deseable es, por el contrario, que la mayor parte de
los requisitos esten formulados de tal modo que su verificabilidad
sea sencilla, por lo que puede indicarse "la interfaz debe seguir la
normativa de colores e imagen corporativa de la empresa"

Ademas existen otras propiedades no escenciales como son:

Prorización: Al desarrollar el sistema, sera necesario abordar los

requisitos en un orden que en muchos casos dependera del propio
requisito, lo que justifica la necesidad de clasificar los requisitos
segun su prioridad.

Seguimiento: debe ser posible hacer un seguimiento del requisito

que permita conocer su estado en cada momento del desarrollo.

Identificación unica: cada requisito debe tener un identificador

único que lo distinga y que permita a cualquier involucrado en el
desarrollo hacer referencia al mismo en cualquier punto del ciclo
de vida del software sin ambiguedad.

Tipos de requisitos

Tradicionalmente se han identificado dos tipos de requisitos

atendiendo a criterios de funcionalidad: requisitos funcionales y
requisitos no funcionales. El glorario de la IEEE de ingenieria de
software los define asi.
Un requisito funcional, especifica una función que un sistema o
componente de un sistema debe ser capaz de llevar a cabo.

Los requisitos No funcionales, son aquellos que especifican

aspectos tecnicos que debe incluir el sistema y que pueden
clasificarse en restricciones y calidades.

Dentro de las restricciones se encuentra cualquier limitación a que

se enfrenten los desarrolladores del sistema, como por elemplo: el
sistema operativo de entorno del usuario, la plataforma hardware a
utilizar o el perfil de los desarrolladores disponibles dentro de la
organización de desarrollo. Dentro de las calidades se encuentran
todas aquellas caracteristicas de un sistema que importan a los
clientes y usuarios del mismo, y que por lo tanto serán relevantes a
la hora de establecer un grado de satisfacción con el sistema final,
como puede ser de rendimiento, de fiabilidad o de disponiblidad del
sistema.

Una clasificación amplia de los requisitos no funcionales permite

identificar 3 categorias:

 Requisitos del producto: aquellos que detallan limitaciones

o comportamentos exigidos al producto resultante del
desarrollo. Por ejemplo la cantidad de memoria requerida o la
velocidad de respuesta en operaciones interactivas.
 Requisitos de la organización: aqullos relacionados con las
normativas de funcionamiento de la organización que lleva a
cabo el desarrollo, sus procedimientos y politicas. Por
ejemplo los estandares de desarrollo, la documentación a
entregar junto con el producto, los plazos de entrega, etc.
 Requisitos externos: cubren prospectos externos al sistema
y a su proceso de desarrollo. Por ejemplo interoperatividad co
otros sistemas, requisitos legales, etc.
Si tomamos como ejemplo un pequeño negocio de venta y alquiler
de herramientas, algunos requisitos funcionales podrian ser:

1. Imprimir los contratos de alquiler.

2. Almacenar la información relativa a los contratos de alquiler
en vigor.
3. Guardar información de ventas y pagos.
4. Realizar un seguimiento por cliente del estado de los pagos.
5. Gestionar el inventario de productos en venta y en alquiler.

Algunos requisitos no funcionales podrían ser:

1. El sistema podrá ejecutarse en diferente plataforma como

windows, linux para ofrecerlo a establecimientos
similares. (producto)
2. El sistema debe estar disponible al menos el 95% de cada
periodo de 24 hrs. (producto)
3. En el desarrollo debe regirse obligatoriamente por los
procesos y actividades definidos por la metodología estandar
de planificación y desarrollo de Sistemas de Información de
la Administración Publica Española Metrica3. (organizacion)
4. El registro de datos personales debe cumplir la Ley Mexicana
de Protección de Datos Personales. (externo)
Proceso de la Ingeniería de requisitos.

Segun la guia SWEBOK, el conjunto de tareas a realizar en el

área de los requisitos de software se engloba bajo denominación
genérica de actividades de requisitos:

La obtención de requisitos consiste en capturar el proposito y

funcionalidad del sistema desde la perspectiva del usuario. Esta
tarea consiste en elaborar un catalogo en "bruto" de necesidades
del cliente y de los usuarios del futuro sistema, lo cual incluye
obtener información sobre las necesidades generales del mismo,
su funcionamiento, su rendimiento, el diseño y restricciones de la
interfaz, entre otros.

El analisis de requisitos es el proceso de estudiar las

necesidades del usuario para obtener una definición detallada de
los requisitos. Consiste en comprender cuáles son los
comportamientos que se desea tenga el software a desarrollar,
delimitando y determinando detallamente todos los requisitos del
producto a partir de lo solicitado por el cliente y los usuarios del
futuro sistema.

Se denomina especificación de requisitos al proceso de

documentar el comportamiento requerido de un sistema software,
a menudo utilizando una notación de modelado u otro lenguaje de
especificación.

La validación de requisitos consiste en examinar los requisitos

para asegurarse de que definen el sistema que el cliente y los
usuarios desean.

Obtencion de requisitos

Es la primera de las actividades a realizar, donde el objetivo

fundamental de los ingenieros de software consiste en determinar
cuales son los requisitos del sistema a desarrollar para llegar a un
conocimiento suficiente del problema a resolver. Se trata en pocas
palabras, de establecer las fronteras del futuro sistema.

Durante esta actividad el equipo de desarrollo trabaja codo a codo

con los clientes, usuarios y otros actores involucrados, por lo que
la fluidez en la comunicacion es importante para que el proyecto
llegue a buen termino. Se puede elaborar un glosario de terminos
que le permita a los involucrados conocer la definición aceptada
para un determinado concepto.

En primer lugar, deben determinarse las fuentes de

información de las que se obtendrán los requisitos. La información
se obtiene de aquellos actores involucrados que tienen un
conocimiento profundo del dominio del problema. Investigando
además, en las siguientes fuentes de información:

 Los objetivos generales o de alto nivel, que constituyen el

motivo fundamental para que el desarrollo se lleve a cabo.
 El dominio del problema, del que el ingeniero de software
tiene un conocimiento limitado, pero otros actores si conocen.
 Los actores involucrados en el proceso.
 El entorno de operación en el que se ejecutará el software,
que permite establecer restricciones y costes del proyecto.
 El entorno de la organización, al que debe adaptarse el
software.

En segundo lugar, deben establecerse las técnicas de obtención

de requisitos a utilizar. Los miembros del equipo de desarrollo
deben obtener la información sobre los requisitos de los otros
actores, pero este proceso no es estático. Lamentablemente las
cosas no son tan sencillas como sentarse a preguntar y anotar lo
que los clientes, usuarios y otros interesados digan. El ingeniero de
software debe saber hacer las preguntas precisas, investigar
puntos oscuros, entre otras cosas, en una labor dinámica de
extracción de información donde la experiencia proporciona una
capacitación difícil de obtener de otro modo. Por ello usará varias
tecnicas, siendo las mas utilizadas las siguientes:

 Entrevistas: conjunto de técnicas, dentro de las se incluyen

visitas al cliente o a los usuarios, cuestionarios, encuestas y
entrevistas mas o menos estructuradas de carácter formal e
informal. Pueden ser cerradas o abiertas.

 Escenarios: constituyen una interesante herramienta para

contextualizar los requisitos que permiten responder a
preguntas del estilo “que pasaría si” o “como hacer esto”.
  Prototipos: Una buena forma de probar cualquier producto y
realizar cambios cuando aun se esta a tiempo.

 Reuniones de grupo: se programan con el propósito de unir

esfuerzos y conseguir entre varios lo que resulta difícil de
alcanzar individualmente. Clarificar requisitos en conflicto.
Puede concebirse como “tormenta de ideas”.

 Observación: se trata de un conjunto de técnicas que

permiten a los ingenieros de software introducirse en el
ambiente en que trabajan los usuarios, observar como
trabajan e interactúan entre ellos y documentar dichos
comportamientos.

 Otros: estudio de documentos y formularios actuales, visitar

instalaciones similares, presentaciones comerciales, estudio
de producto, asistencia a jornadas profesionales, etc.

Análisis de requisitos

El análisis de requisitos describe las tareas que deben llevarse a

cabo para examinar los requisitos con el objeto de delimitarlos y
definir exactamente cada uno de ellos. Según la guía SWEBOK, se
trata fundamentalmente de:

 Deterctar y resolver conflictos entre requisitos.

 Determinar el software y establecer con que elementos
externos interactua.
 Elaborar los requisitos del sistema para obtener, a partir de
ellos, los requisitos del software a desarrollar.

La clasificación de los requisitos consiste en establecer un

conjunto de categorias y situar cada requisito en ellas. La forma de
clasificar los requisitos no es siempre la misma, existen diferentes
critérios. Pueden clasificarse, en funcionales o no funcionales,
del proceso o del producto, por prioridad, derivados por ejemplo de
otro requisito o impuestos por sistemas existentes, por su ámbito,
por su volatilidad, etc.

En cuanto a la priorización, debe determinarse la importancia

relativa de cada requisito de acuerdo con los demás, para esto,
habitualmente se pude preguntar a clientes y usuarios, acerca del
grado de satisfacción o insatisfacción que les proporciona la
implementación de las funcionalidades, restricciones o cualidades
del requisito.

El modelo conceptual tiene como objetivo fundamental facilitar la

comprensión de los requisitos mediante su representación en un
lenguaje o notación que comprendan quienes van a tratar con los
requisitos.

Especificación de requisitos
La especificación de los requisitos consiste en la completa
descripción de los requisitos del sistema a desarrollar. En dicha
especificación se incluye, para cada requisito, información
complementaria que permite gestionarlos e implementarlos,
información que a menudo es "atributo de los requisitos".

La especificación de requisitos implica con frecuencia la

construcción de un modelo (o varios) del sistema a desarrollar,
desde el punto de vista de los usuarios del sistema, que incluya
todos y cada uno de los requisitos obtenidos. Esto facilita la
estimación de costes y tiempos.

Segun el Estándar 830-1998 de IEEE para la especificación de

requisitos del software, una especificación debe ser:

 Completa
 Verificable
  Consistente
 Modificable
 Susceptible de permitir seguimientos
 Utilizable durante las fases de operación y mantenimiento.
 Y además, no debe contener ambiguedades.

De manera generalizada, los requisitos se plasman en un

documento denominado Especificación de Requisitos de
Software (SRS-ERS). Para sistemas sencillos la elaboración de
este documento puede ser suficiente, pero en sistemas complejos
es habitual la elaboración de tres documentos distintos como parte
de esta actividad:

 El documento de definición del sistema: tambien llamado

documento de requisitos del usuario, establece los requisitos
de alto nivle del sistema desde el punto de vista del dominio
del problema, dirigido a los usuarios y clientes del sistema.
 El documento de requisitos del sistema: constituye una
especificación formal de los requisitos del sistema de los que
se derivarán los requisitos del software a desarrollar. Su
principal objetivo es proporcionar una aproximación al
contexto, alcance y capacidades del sistema.
 El documento de especificación de requisitos del
software (ERS): Define explicitamente todo aquello que el
software debe realizar, asi como las restricciónes que debe
contemplar el futuro sistema. Sirve como acuerdo formal o
contrato entre los clientes y los proveedores del software. Los
requisitos a menudo se redactan en lenguaje natural, son
descritos de manera mas pendiente en el ERS utilizando
alguna notacion de modelado u otro lenguaje de
especificación.

Plantilla para la SRS segun el estandar IEEE 830-1998:

Tabla de contenidos

1. Introducción
 1.1. Propósito
1.2. Ambito del Sistema
1.3. Definiciones, Acrónimos y Abreviaturas
1.4. Referencias
1.5. Visión General del Documento

2. Descripción General

2.1. Perspectiva del Producto

2.2. Funciones del Producto
2.3. Características de los Usuarios
2.4. Restricciones
2.5. Suposiciones y Dependencias
2.6. Requisitos Futuros

3. Requisitos Específicos

3.1. Interfaces Externas

3.2. Funciones
3.3. Requisitos de Rendimiento
3.4. Restricciones de Diseño
3.5. Atributos del Sistema
3.6. Otros Requisitos

4. Apéndices

Formato para especificar los requisitos:

Representación de requisitos

 Casos de uso y escenarios en UML

Proporcionan una descripción de cómo se usará el sistema.

Modelo de contexto y validación de requisitos.

 Modelos entidad-relación
Modelo conceptual de datos

 Diagrama de clases UML

Modelo conceptual estático que representa el conjunto de clases y

sus relaciones.

 Notaciones formales

Métodos matemáticos que aspiran a la obtención de una

documentación donde se especifiquen las funcionales del sistema.

Validación de Requisitos
La validación de los requisitos consiste en examinar si los
documentos de requisitos definen el software que los usuarios
esperan y no otro. Al igual que cualquier producto del proceso de
desarrollo, los documentos de requisitos estan sujetos a procesos
de valicación y verificación para comprobar, entre otras cuestiones
que el ingeniero de software ha comprendido los requisitos, que los
documentos son acordes a los estandares establecidos o que
dichos documentos son consistentes, comprensibles y
completos. Los metodos comunes de validación son:
 Revisión de requisitos, por un grupo de personas
designadas especialmente para tal fin, se revisa en busca de
inconsistencias, malentendidos, puntos poco claros,
conflictos entre requisitos y otros problemas similares.
 Prototipado, que su construcción es una forma de probar
cualquier producto.
 Validación del modelo, se lleva a cabo para verificar si el
modelo es consistente y si refleja adecuadamente los
requisitos reales del sistema.
 Pruebas de aceptación, que permiten comprobar si el
producto terminado satisface o no el requisito.
Modelo de Requisitos
 El modelo de requisitos tiene como objetivo delimitar el
sistema y capturar la funcionalidad que debe ofrecer desde la
perspectiva del usuario. Su propósito es comprender
completamente el problema y sus implicaciones. Este modelo
puede funcionar como un contrato entre el desarrollador y el
cliente o usuario del sistema, y por lo tanto proyecta lo que el
cliente desea según la percepción del desarrollador. Por lo
tanto, es esencial que los clientes puedan comprender este
modelo.
 El modelo de requisitos es el primer modelo a desarrollarse,
sirviendo de base para la formación de todos los demás
modelos en el desarrollo de software. En general, en
cualquier cambio en la funcionalidad del sistema es más fácil
de hacer, y con menores consecuencias, a este nivel que
posteriormente.
 El modelo de requisitos que desarrollaremos se basa en la
metodología Objectory (Jacobson et al. 1992), basada
principalmente en el modelo de casos de uso.
 Actualmente esta metodología es parte del Proceso Unificado
de Rational (RUP). El modelo de casos de uso y el propio
modelo de requisitos son la base para los demás modelos.
 Casos de Uso (Use Case)
 El modelo de casos de uso sirve para expresar el modelo de
requisitos, el cual se desarrolla en cooperación con otros
modelos como se verá más adelante.
 Casos de Uso es una técnica para capturar información
respecto de los servicios que un sistema proporciona a su
entorno.
 Los Casos de Uso particionan el conjunto de necesidades
atendiendo a la categoría de usuarios que participan en el
mismo.
 El usuario debería poder entenderlos para realizar su
validación.
 No pertenece estrictamente al enfoque orientado a objeto, es
una técnica para captura y especificación de requisitos.