Requisitos de Software - Inicio | KybeleIS... · Falta de claridad: Es difícil utilizar un lenguaje sencillo de forma precisa y no ambigua sin hacer el documento poco conciso y difícil

Requisitos de Software

Departamento de Lenguajes y Sistemas Informáticos II

www.kybele.urjc.es

Tema 6: Requisitos de Software www.kybele.urjc.es

Ingeniería de Requisitos

Definición: La Ingeniería de requisitos comprende todas las tareas

relacionadas con la determinación de las necesidades o de las condiciones a

satisfacer para un software, tomando en cuenta los diversos requisitos de

los clientes (y usuarios), que pueden entrar en conflicto entre ellos.

Básicamente cubre todo el proceso de descubrir, analizar, documentar los

servicios que debe suministrar un software y las restricciones operativas a

las que se deberá enfrentar.

Introducción


Requisitos

Definición: Descripción de los servicios que tendrá que proporcionar el

sistema y de sus restricciones operativas.

Reflejan además las necesidades de los clientes y usuarios de un sistema

para que ayude a resolver algún problema concreto (como el control de un

dispositivo, localizar una determinada información o realizar una

determinada función administrativa como escribir un documento).

Introducción


Se puede observar que la definición citada anteriormente puede llegar a ser muy

ambigua y de hecho en la industria del software encontramos esta ambigüedad en el

uso del término “requisitos”.

El problema radica en que la descripción de lo que un sistema “debe hacer” cambia

radicalmente dependiendo del destinatario de dicha descripción. Obviamente el nivel

de detalle de descripción no puede ser el mismo para un equipo que ha de iniciar el

desarrollo de un sistema que para el equipo directivo que decide contratar el desarrollo

de un sistema. El sistema es el mismo y ambos colectivos saben lo que “el sistema debe

hacer” pero el detalle necesario en la descripción es radicalmente distinto.

Introducción


De este modo, podremos comenzar a diferenciar los requisitos en función del grado de

detalle en la descripción de los mismos:

Requisitos de usuario/cliente: Declaraciones en lenguaje natural y en diagramas de

los servicios que se espera que el sistema proporcione y de las restricciones bajo

las cuales debe operar.

Requisitos de sistema/software: descripción detallada de las funciones, servicios y

restricciones del sistema. El documento de requisitos del sistema/software (a veces

llamado especificación funcional) debe ser preciso. Debe definir exactamente QUÉ

es lo que se va a implementar. A menudo la relación contractual entre el cliente y

los desarrolladores suele estar sujeto a este documento.

Requisitos de usuario y de sistema



Ejemplo:

•1. El teléfono móvil permitirá al usuario introducir contactos en la agenda del teléfono

Requisito de usuario

•1.1. El usuario tendrá que tener encendido el teléfono y haber accedido mediante su pin.

•1.2. Accederá al menú principal y seleccionará Contactos.•1.3. Pulsará Opciones y seleccionará Crear Contacto•1.4. Introducirá todos los datos del contacto a crear y pulsará Aceptar•1.5. El sistema almacenará los datos del nuevo contacto en Contactos.

Requisitos del sistema

Como se puede observar un único requisito de usuario se transforma en 5 requisitos de sistema. El de usuario es más abstracto mientras que los de sistema requieren definir en mayor detalle todas las funciones implicadas.


Como se ha comentado es necesario redactar los requisitos en diferentes niveles de detalle debido a que existen distintos tipos de lectores. A continuación se muestra un clasificación de los “lectores tipo” de cada nivel de detalle.

•Administradores Clientes•Usuarios finales del sistema•Ingenieros Clientes•Administradores Contratistas•Arquitectos del sistema

Requisito de usuario

•Usuarios finales del sistema•Ingenieros Clientes•Arquitectos del sistema•Desarrolladores del software

Requisitos del sistema



Clasificación de Requisitos

Podemos igualmente encajar a los requisitos atendiendo a la siguiente clasificación:

Requisitos funcionales: Definen lo que el sistema “debe hacer”. Declaraciones de los servicios que debe proporcionar el sistema: cómo se debe comportar en situaciones particulares, qué respuestas debe dar a determinadas entradas. En algunos casos, estos requisitos pueden declarar explícitamente lo que el sistema NO debe hacer.

Requisitos no funcionales: Requisitos que no se refieren directamente a las funciones específicas del sistema sino a las propiedades emergentes de éste como la fiabilidad, rendimiento, tiempo de respuesta, capacidad de almacenamiento, etc. Además también no tienen por qué referirse, exclusivamente, al sistema a desarrollar, sino a técnicas a seguir como estándares de calidad, uso de una herramienta CASE concreta o la descripción del modelo de proceso de desarrollo a seguir.

Requisitos de dominio: Provienen del dominio de aplicación del sistema y reflejan las características y restricciones de dicho dominio.


Clasificación de Requisitos

Ejemplo:

Requisitos funcionales:

El teléfono móvil permitirá crear nuevos contactos y almacenarlos en la agenda (Contactos).

Requisitos no funcionales:

La pantalla del teléfono móvil será táctil.

Requisitos de dominio

El teléfono móvil deberá operar en un rango de frecuencias comprendidas entra los 800 y 1.800 MHz.


Requisitos no Funcionales

Requisitos no FuncionalesLa siguiente trasparencia muestra una clasificación detallada de los requisitos no funcionales. Estos requisitos pueden venir de las características requeridas por el software (producto), de la organización que desarrolla el software (organizacionales) y de otras fuentes externas:

Requerimientos del producto: especifican el comportamiento del producto. Ejemplos:

Rendimientos de rendimiento en el tiempo de carga de una página Web o el uso máximo de la memoria.

Fiabilidad en los resultados ofrecidos por el sistema.

Portabilidad: por ejemplo multinavegador (Internet Explorer v.X y Firefox v.X)

Requerimientos Organizacionales: provienen de las políticas y procedimientos existentes en las organizaciones (tanto cliente como desarrollador)especifican el comportamiento del producto. Ejemplos:

Lenguajes de programación, procesos a utilizar, documentación exigida basados en determinados estándares, etc.

Requerimientos Externos: todos los requisitos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Ejemplo:

Requisitos de interoperabilidad (definen los protocolos para interactuar con otros sistemas), legislación competente (ej. Ley Orgánica de Protección de Datos de Carácter Personal)



REQUISITOS NO FUNCIONALES

Requisitos organizacionales

Requisitos interoperabilidad

Requisitos externos

Requisitos éticos

Requisitos legislativos

Requisitos De seguridad

Requisitos De privacidadRequisitos

estándaresRequisitos

implementaciónRequisitos De entrega

Requisitos de producto

Requisitos de portabilidad

Requisitos de fiabilidad

Requisitos de eficiencia

Requisitos de rendimiento

Requisitos de espacio

Requisitos de usabilidad

A continuación se muestra una clasificación de los requisitos no funcionales. Estos requisitos pueden venir de las características requeridas por el software (producto), de la organización que desarrolla el software (organizacionales) y de otras fuentes externas.



Ejemplo en el dominio de un sistema de expedición de billetes de tren.

Requisito del producto :

RNF.10. La interfaz de usuario se implementará en HTML.

Requisito organizacional

RNF.20. La documentación a entregar seguirá el estándar IEEE.

Requisito externo

El sistema no deberá revelar al personal de ventas, la información personal de teléfono y dirección postal de los clientes ni viajeros.


Requisitos del Dominio

Requisitos de Dominio. Definición:Requisitos que provienen del dominio de especificación del sistema y que reflejan las características

y restricciones de ese dominio (no tienen por qué derivarse de las especificaciones del usuario).

Pueden ser funcionales o no funcionales: restringir algún requisito existente, o establecer cómo se

deben ejecutar cálculos particulares.

El dominio tiene su propio vocabulario/lenguaje.

Es importante comprenderlo para comprender a los usuarios y clientes.

Antes de entrar de lleno a especificar, con los usuarios y clientes, hay que trabajar para

conocer el dominio del sistema.

Estos requisitos plantean un problema especial a los ingenieros del software porque han de

comprender un dominio que en ocasiones se escapa de nuestro conocimiento habitual. El grado de

dificultad lo marca el dominio, no requiere el mismo esfuerzo adaptarse a un dominio para

desarrollar el sistema de expedición de billetes de tren que un Broker-Online.



Ejemplo (Requisitos de Dominio)

En el desarrollo de un producto software (VERTA) para la gestión de billetes dentro de un

entorno ferroviario, parte del vocabulario que se puede llegar a utilizar es éste:

Tarifa

Descuento de calendario

Descuento general

Origen / Destino

Retraso

Cliente

Viajero


Glosario (Ejemplo de Requisitos de Dominio)

Tarifa: Precio que queda determinado por el origen/destino y la fecha/hora en la que el cliente

va a viajar.

Descuento de calendario: Descuento que se aplica en determinados días sobre el precio de la

tarifa.

Descuento general: Descuento que se aplica al precio de la tarifa en función de determinados

criterios (tercera edad, grupos de clientes que viajan al mismo sitio, familia numerosa, etc.)

Origen / Destino: Origen / Destino del tren en un viaje. No se refiere a las estaciones por las que

pasa sino del punto de partida del tren y del destino final del mismo.

Retraso: Se considera retraso a superar en más de 10 minutos la hora prevista de llegada. Se

desembolsará el importe del billete al viajero, si existe retraso.

Cliente: Persona que compra un billete de tren a su nombre.

Viajero: Persona que compró un billete de tren a su nombre y que viaja en el tren. Algunos

clientes pierden el tren, por lo tanto estos no son viajeros. La importancia de este concepto es

fundamental en términos económicos ya que el desembolso por retraso sólo se aplicará a los

viajeros y no a los clientes.



Requisitos de Usuario

Deben describir los requisitos funcionales y no funcionales de tal forma que sean comprensibles

para los usuarios, sin conocimiento técnico detallado.

Se deben centrar en especificar el comportamiento externo del sistema, alejándose todo lo

posible de las consideraciones de diseño del sistema, aspectos ajenos a la problemática de los

usuarios. Pensemos en la diferencia existente en la especificación de un coche para un ingeniero

mecánico y para un usuario que está decidiendo su compra. Ambos “visualizan” el mismo vehículo

pero desde dos perspectivas diferentes. Obviamente la enorme cantidad de información técnica

asociada al motor -necesaria para el ingeniero- se resume para el usuario en una línea: 175 CV de

potencia.

No se debe utilizar una jerga técnica.

Deben redactarse en un lenguaje sencillo, utilizando tablas y formularios sencillos y diagramas

intuitivos.




Aun teniendo claro lo expuesto en la trasparencia anterior, suelen surgir

problemas cuando se plasman requisitos de usuario en un documento de

texto:

Falta de claridad: Es difícil utilizar un lenguaje sencillo de forma precisa y no

ambigua sin hacer el documento poco conciso y difícil de leer.

Confusión de requisitos: No se distinguen claramente los requisitos funcionales de

los no funcionales, las metas del sistema y la información para el diseño.

Conjunción de requisitos: A veces se expresan diferentes requisitos de forma

conjunta en un único requisito.

¡Veamos un ejemplo!


Problemas que suelen surgir – Ejemplos:

Falta de claridad: VERTA proporcionará un sistema de contabilidad que mantendrá

registro de todos los pagos hechos por los clientes. Los administradores del sistema

pueden configurarlo de forma que los clientes habituales puedan recibir precios

rebajados a través de los descuentos generales.

Conjunción de requisitos: Se están expresando diferentes requisitos juntos. Por un

lado se habla de que el sistema mantendrá un registro de los pagos. Por otro lado se

indica que se aplicarán descuentos a los clientes habituales.



Recomendaciones para minimizar malentendidos:

Formato estándar para todos los requisitos. Esto permite homogeneizar la captura de los

requisitos aunque sea realizada por diferentes personas. También suele ser recomendable indicar

la persona que solicitó el requisito.

Utilizar el lenguaje de forma consistente para distinguir entre los requisitos obligatorios de los

deseables. Los obligatorios se redactan en futuro simple y los deseables en condicional.

Resaltar el texto para distinguir las cuestiones claves del requisito (negrita, cursiva, colores).

Evitar en la medida uso de jerga informática. Es habitual encontrar a personal técnico que abusa de

la terminología técnica como medio para hacer visible la diferencia de conocimientos entre ellos y

los usuarios. Es ridículo, obviamente dicha diferencia es evidente y un buen profesional de ser

capaz de “traducir” simultáneamente de un “idioma” a otro. El hecho de no dejar claramente

especificado un requisito porque el usuario no lo entendió correctamente se debe a que el

ingeniero de requisitos no realizó bien su trabajo.



Requisitos de Sistema

Requisitos del Sistema. Son versiones extendidas de los requisitos de usuario

para los ingenieros de software.

Agregan detalle y deben especificar cómo el sistema debe proporcionar los requisitos

para satisfacer los requisitos de usuario.

Debe ser una especificación completa y consistente del sistema en su conjunto. Ha de

tenerse en cuenta que este conjunto de requisitos establece la relación contractual

entre cliente y proveedor. Debe definir claramente el sistema a desarrollar de forma

que ambas partes puedan asegurarse los compromisos alcanzados.

Evitar el uso exclusivo del lenguaje natural porque puede ser confuso y dar lugar a

malentendidos que se detectan en las últimas fases del ciclo de desarrollo.


Requisitos del Sistema ¿Cómo expresarlos?

Como se ha comentado, los requisitos de usuarios se redactan en lenguaje natural, lo

que facilita la comprensión de los mismos por parte de todos los potenciales lectores.

Sin embargo, en el caso de los requisitos de sistemas es diferente. Estos requisitos

necesitan de un mayor nivel de detalle y las especificaciones en lenguaje natural puede

ser excesivamente confusas y difíciles de entender propensas a malas

interpretaciones.

Para evitar estos problemas, se pueden utilizar diferentes notaciones que mejoren el

entendimiento de los requisitos de sistemas, permitiendo llegar a un nivel de detalle

mayor y facilitando la comprensión de los mismos por parte de los lectores “no

técnicos”. En la siguiente transparencia se muestra este conjunto de notaciones.



Notaciones para la especificación de requisitos

• Definición de formularios y plantillas estándares para expresar la especificación de requisitos (la siguiente trasparencia muestra un ejemplo de plantilla).

Lenguaje natural estructurado

• Uso de lenguaje gráfico complementado con anotaciones de texto.

• Casos de uso, diagramas de secuencia, diagramas de estados,… (UML)

Notaciones gráficas

• Notaciones que se basan en conceptos matemáticos como el de las máquinas de estados finito o los conjuntos.

• La mayoría de los clientes no comprenden estas especificaciones y son reacios a aceptarlas como un contrato del desarrollo del sistema.

Especificaciones matemáticas


Notaciones


Agregar contacto en el móvil/SRS/3.5.1.

Función Agregar un contacto nuevo.

Descripción Agregará un contacto nuevo a la lista de contactos del móvil. Se deberá verificar que no se duplique ni el nombre ni el número de teléfono……

Entradas Datos del contacto de forma manual. Numero de teléfono desde llamada o sms.

Salidas Contacto nuevo almacenado.

Precondición El móvil debe estar encendido y desbloqueado y se debe haber accedido mediante el menú a dicha opción.

Postcondición Ninguna.

Efectos colaterales

Ninguno.

Ejemplo de Plantillas: Lenguaje Natural Estructurado


Notaciones


R-V

Do/ Contar (t1)

R-Vi

Do/ Contar (t2)

R-R

Do/ Contar (t3)

t1 cumplido

A-R

Do/ Contar (t5)

V-R

Do/ Contar (t4)

t5 cumplido

t2 cumplido

t3 cumplido

t4 cumplidoA-R

Do/ Contar (t6)

t6 cumplido

X-Y en cada estado identifica el color del visor del automóvil y del peatón respectivamente.Visor del automóvil: R (rojo), A (ámbar) , V (verde).Visor del peatón: R (rojo), Vi (verde intermitente), V (verde).

Ejemplo de Diagrama de Estados en UML: Semáforo


Notaciones

Veremos con mayor detalle este tipo de diagramas, pero aun sin conocerlo en profundidad se puede observar que es intuitivo y refleja fácilmente lo que pretendemos capturar: el funcionamiento de un semáforo.


Especificación de la interfaz

Especificación de la Interfaz

Actualmente es muy difícil encontrar sistemas que se desarrollen aislados, sin necesidad de comunicarse con otros sistemas ya existentes o con otros en fase igualmente de desarrollo. De esta forma se hace imprescindible la definición clara de las interfaces de comunicación entre estos sistemas. Estas interfaces se deben definir al inicio del proceso de desarrollo y debería incluirse en el documento de requisitos. Tipos:

Interfaces de procedimiento: los sistemas o subsistemas ya existentes ofrecen una variedad de

servicios a los que se accede invocando a los procedimientos de la interfaz. Estas interfaces a veces

se denominan APIs (Interfaz de Programación de Aplicaciones).

Estructuras de datos: se refiere a las estructuras de datos que pasan de un sistema a otro. Casi

todos los sistemas a desarrollar trabajarán con Bases de Datos, que en algunos casos ya existen y

que trabajan con otros sistemas en explotación. Será necesario definir estas nuevas estructuras

para el sistema nuevo a desarrollar.


El Documento de Requisitos de Software

El Documento de Especificación de Requisitos Software –ERS– es la declaración

oficial de qué deben implementar los desarrolladores del sistema.

Debe incluir los requisitos de usuario y los de sistema.

Los lectores de dicho documento abarca tanto a los altos cargos de la organización cliente (es decir,

la que paga por el nuevo sistema) como a los ingenieros responsables de desarrollar el software.

Debe ser un documento equilibrado para comunicar los requisitos a los clientes, detallar los

requisitos para desarrolladores e ingenieros de pruebas del software, y contener la información

relativa a la evolución del software.

Debe incluir la información sobre cambios previstos. Esto ayudará a los diseñadores a evitar

decisiones de diseño restrictivas y a los ingenieros encargados del mantenimiento del sistema,

quienes tendrán que adaptar el sistema a nuevos requisitos.


Tipología de lectores destinatarios del documento ERS

Clientes

Especifican los requisitos y los leen para verificar que se cumplen sus necesidades. Especificarán

cambios si es necesario.

Administradores

Planifican una oferta por el sistema y el proceso de desarrollo.

Ingenieros de sistemas/software

Utilizan el SRS para saber QUÉ sistema debe desarrollarse

Ingenieros de pruebas

Utilizan el SRS para desarrollar las pruebas de validación para el sistema/software.

Ingenieros de mantenimiento

Utilizan el SRS para comprender el sistema nuevo y las relaciones entre sus partes (subsistemas).



Usuarios del documento ERS

La diversidad de posibles usuarios significa que el documento de requisitos tiene que presentar un

equilibrio entre la comunicación de los requisitos a los clientes y la definición de los requisitos en el

detalle necesario por los desarrolladores.

En cualquier caso, en nivel de detalle del documento ERS dependerá del tipo de sistema que se

desarrolle y del proceso de desarrollo que se esté empleando. Pueden existir varios escenarios (entre

ellos remarcamos dos):

Desarrollo subcontratado a una empresa de desarrollo: las especificaciones de los sistemas han de

ser claras y muy detalladas

Desarrollo dentro de la empresa utilizando un proceso de desarrollo iterativo: el documento puede

ser mucho menos detallado y posponer la resolución de ambigüedades en los sucesivas iteraciones

del proceso de desarrollo.



Ejemplo de ERS: IEEE

Varias organizaciones grandes han definido sus propios estándares para los documentos de requisitos.

Entre ellos, el más conocido es el IEEE/ANSI 830-1998. La siguiente trasparencia muestra la estructura

propuesta por el IEEE para los ERS.

Aunque el estándar no es ideal, contiene un gran número de consejos sobre cómo redactar los

requisitos y cómo evitar los problemas descritos en este tema. Es demasiado general como para poder

convertirse en un estándar de una organización, pero puede servir de marco de trabajo para adaptarlo a

las necesidades particulares de cada organización.

La información a incluir en el documento ERS dependerá del tipo de software a desarrollar y se verá

fuertemente influenciado por el proceso de desarrollo a utilizado.



IEEE/ANSI 830-1998Introducción

Propósito

Alcance del producto

Definición, acrónimos y abreviaturas

Referencias

Descripción del resto del documento.

Descripción general

Perspectiva del producto

Funciones del producto

Características del usuario

Restricciones generales

Suposiciones y dependencias

Requisitos específicos

Es la parte más sustancial del documento. Incluye los requisitos funcionales, no funcionales y de interfaz. Dada la

amplia variabilidad en la práctica organizacional, no es apropiado definir una estructura estándar para esta

sección.

Apéndices

Índice


Documents

Requisitos de Software - Inicio | KybeleIS... · Falta de claridad: Es difícil utilizar un lenguaje sencillo de forma precisa y no ambigua sin hacer el documento poco conciso y difícil