requisitos de software - inicio | kybeleis... · falta de claridad: es difícil utilizar un...
TRANSCRIPT
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
Tema 6: Requisitos de Software www.kybele.urjc.es
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
Tema 6: Requisitos de Software www.kybele.urjc.es
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
Tema 6: Requisitos de Software www.kybele.urjc.es
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
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
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
Requisitos de usuario y de sistema
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
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)
Tema 6: Requisitos de Software www.kybele.urjc.es
Requisitos no Funcionales
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
Requisitos no Funcionales
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
Requisitos del Dominio
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
Tema 6: Requisitos de Software www.kybele.urjc.es
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 del Dominio
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Requisitos de Usuario
Tema 6: Requisitos de Software www.kybele.urjc.es
Requisitos de Usuario
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!
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Requisitos de Usuario
Tema 6: Requisitos de Software www.kybele.urjc.es
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 Usuario
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Requisitos de Sistema
Tema 6: Requisitos de Software www.kybele.urjc.es
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
Requisitos de Sistema
Notaciones
Tema 6: Requisitos de Software www.kybele.urjc.es
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
Requisitos de Sistema
Notaciones
Tema 6: Requisitos de Software www.kybele.urjc.es
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
Requisitos de Sistema
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
Tema 6: Requisitos de Software www.kybele.urjc.es
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).
El Documento de Requisitos de Software
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
El Documento de Requisitos de Software
Tema 6: Requisitos de Software www.kybele.urjc.es
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.
El Documento de Requisitos de Software
Tema 6: Requisitos de Software www.kybele.urjc.es
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
El Documento de Requisitos de Software