Requisitos de Software. Departamento de Lenguajes y Sistemas Informáticos II

Transcripción

1 Requisitos de Software Departamento de Lenguajes y Sistemas Informáticos II

2 Introducción 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.

3 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).

4 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.

5 Requisitos de usuario y de sistema 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.

6 Requisitos de usuario y de sistema Ejemplo: Requisito de usuario 1. El teléfono móvil permitirá al usuario introducir contactos en la agenda del teléfono Requisitos del sistema 1.1. El usuario tendrá que tener encendido el teléfono y haber accedido mediante su pin Accederá al menú principal y seleccionará Contactos 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. 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.

7 Requisitos de usuario y de sistema 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. Requisito de usuario Administradores Clientes Usuarios finales del sistema Ingenieros Clientes Administradores Contratistas Arquitectos del sistema Requisitos del sistema Usuarios finales del sistema Ingenieros Clientes Arquitectos del sistema Desarrolladores del software

8 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.

9 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 MHz.

10 Requisitos no Funcionales Requisitos no Funcionales La 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)

11 Requisitos no Funcionales 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. REQUISITOS NO FUNCIONALES Requisitos de producto Requisitos externos Requisitos de fiabilidad Requisitos organizacionales Requisitos interoperabilidad Requisitos éticos Requisitos legislativos Requisitos de usabilidad Requisitos De entrega Requisitos implementación Requisitos estándares Requisitos De privacidad Requisitos De seguridad Requisitos de portabilidad Requisitos de eficiencia Requisitos de rendimiento Requisitos de espacio

12 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.

13 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.

14 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

15 Requisitos del Dominio 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.

16 Requisitos de Usuario 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.

17 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!

18 Requisitos de Usuario 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.

19 Requisitos de Usuario 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.

20 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.

21 Requisitos de Sistema 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.

22 Requisitos de Sistema Notaciones Notaciones para la especificación de requisitos Lenguaje natural estructurado Definición de formularios y plantillas estándares para expresar la especificación de requisitos (la siguiente trasparencia muestra un ejemplo de plantilla). Notaciones gráficas Uso de lenguaje gráfico complementado con anotaciones de texto. Casos de uso, diagramas de secuencia, diagramas de estados, (UML) Especificaciones matemáticas 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.

23 Agregar contacto en el móvil/srs/ Función Descripción Entradas Salidas Precondición Postcondición Efectos colaterales Requisitos de Sistema Agregar un contacto nuevo. 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 Datos del contacto de forma manual. Numero de teléfono desde llamada o sms. Contacto nuevo almacenado. El móvil debe estar encendido y desbloqueado y se debe haber accedido mediante el menú a dicha opción. Ninguna. Ninguno. Notaciones Ejemplo de Plantillas: Lenguaje Natural Estructurado

24 Requisitos de Sistema Notaciones Ejemplo de Diagrama de Estados en UML: Semáforo 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). R-V Do/ Contar (t1) t1 cumplido R-Vi Do/ Contar (t2) t2 cumplido R-R Do/ Contar (t3) t6 cumplido t3 cumplido A-R Do/ Contar (t6) t5 cumplido A-R Do/ Contar (t5) t4 cumplido V-R Do/ Contar (t4) 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.

25 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.

26 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.

27 El Documento de Requisitos de Software 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).

28 El Documento de Requisitos de Software 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.

29 Ejemplo de ERS: IEEE El Documento de Requisitos de Software Varias organizaciones grandes han definido sus propios estándares para los documentos de requisitos. Entre ellos, el más conocido es el IEEE/ANSI 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.

30 El Documento de Requisitos de Software Introducció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 IEEE/ANSI 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