INGENIERIA DE SOFTWARE. Dr. Pedro Mejia Alvarez Obtención de Requerimientos

Transcripción

1 INGENIERIA DE SOFTWARE. Dr. Pedro Mejia Alvarez Obtención de Requerimientos En esta actividad se determina el dominio de la aplicación, se especifican los servicios que debe proveer el sistema, la funcionalidad requerida del sistema, y las restricciones de hardware y software. Es indispensable la participación de los usuarios y clientes para la identificación de los requerimientos del sistema. Como resultado de esta actividad se debe obtener un documento inicial de definición de los requerimientos (DDR), en donde se definen las necesidades iniciales del sistema, o lo que se conoce como requerimientos iniciales. Estos requerimientos pudieran no ser los definitivos, ni tampoco todos los requerimientos. Nuevos requerimientos pueden ser agregados al documento conforme se vayan descubriendo o incluso los requerimientos ya definidos pueden modificarse o eliminarse. En la obtención de los requerimientos existen las siguientes tareas a seguir (referencia): 1. Comprender el problema que se va a resolver, para lo cual es necesario estudiar el dominio o entorno en el que el sistema va a operar. 2. Buscar y recolectar información acerca del sistema a desarrollar, de manuales de operación y mantenimiento, de manuales organizacionales y políticas de operación. 3. Definir los límites y restricciones del sistema para determinar con precisión que es lo que el sistema va a hacer y también especificar lo que no va a hacer.

2 4. Identificar a las personas o usuarios interesados en el sistema, ya que ellos conocen el medio ambiente en que operará el sistema y pueden ayudar describiendo sus necesidades. 5. Recolectar y clasificar requerimientos, los desarrolladores pueden iniciar definiendo un bosquejo general del sistema, su funcionamiento básico y estableciendo su alcance. El desarrollo de las tareas de obtención de requerimientos es realizado de manera secuencial, sin embargo cualquier tarea pudiera regresarnos a la anterior, sobre todo si no se descubre la información necesaria en el primer recorrido del diagrama. La Figura 3.1 muestra esta relación. La salida de esta actividad nos conduce hacia el análisis de requerimientos. Figura 3.1 El proceso de obtención de requerimientos Comprensión del Problema En todo proyecto de desarrollo de software, la primera actividad consiste en comprender el problema que se desea resolver. El problema será resuelto mediante la construcción de un producto o sistema de software. Para poder comprender el problema hay que establecer cuales son los objetivos que persigue el cliente y su organización, cual es su visión del producto a desarrollar y cuales son sus necesidades. Además, para comprender el problema es necesario tener amplios conocimientos sobre el dominio de la aplicación y sobre el ambiente de operación. Un proyecto que no tiene una dirección bien definida claramente llevara al desastre. Los participantes del proyecto pueden tener objetivos y prioridades distintas a los definidos por el 70

3 cliente y con ello llevar al proyecto a no cumplir con la funcionalidad deseada. Todos los involucrados en el proyecto, deben estar de acuerdo con los objetivos de proyecto así como en sus alcances. Una consecuencia de que algunos de los involucrados no están de acuerdo con los objetivos, es que los requerimientos se vuelven inestables. Esto causa frecuentes cambios en los requerimientos. Los detalles específicos del problema del cliente deben ser bien comprendidos. La descripción del problema proviene de cliente, sin embargo, en ocasiones el problema es difícil de documentar. Este problema ocurre por las siguientes razones: El cliente no siempre define claramente el problema. El analista de requerimientos y los desarrolladores no comprenden la naturaleza del problema. El analista y los desarrolladores entienden el problema pero no saben como llevarlo a cabo. El problema es muy amplio, vago, poco factible, o muy volátil. Aunque el problema se comprenda, no será posible llevarlo a cabo si este no es factible. Por lo tanto, después de comprender el problema y antes de comenzar el desarrollo, tanto el cliente como los desarrolladores deben estar de acuerdo en su factibilidad. El problema de la factibilidad se trata en el capítulo anterior. Comúnmente, el problema no siempre es comprendido de forma inmediata, sino que requiere de varias iteraciones. En cada iteración el cliente y los analistas de requerimientos llevan a cabo entrevistas para aclarar el problema y sus implicaciones de desarrollo. En ocasiones el problema es factible de desarrollar pero sus implicaciones en tiempo de desarrollo o costo pueden ser muy altas. El tiempo y el costo son factores que siempre hay que tomar en cuenta cuando se describe el problema. Lo que se desea finalmente en ésta fase, es que el problema esté bien descrito por parte del cliente y bien comprendido por parte de los desarrolladores. En esta actividad se describe el problema a solucionar. La organización que contrata un proyecto de software, persigue unos objetivos con el desarrollo. Por ejemplo, el software pudiera permitirle al cliente optimizar, automatizar o permitir documentar sus procedimientos organizacionales. En una tienda departamental, por ejemplo, se podría requerir de la automatización del proceso de venta, que antes se venia haciendo de forma manual. Este proyecto podría consistir en la instalación de terminales de cómputo en cada punto de venta, y su conexión con los departamentos de contabilidad y almacenes. El sistema de cómputo permitiría a un 71

4 operador de la tienda, cobrar e introducir datos sobre los productos vendidos. El objetivo de este sistema de cómputo sería la automatización del proceso de venta de productos de la tienda departamental Comprensión del dominio de la aplicación. El conocimiento del dominio de la aplicación permite identificar el ambiente sobre el cual el sistema de software estará operando y también el sistema que se encuentra actualmente en operación. No es posible desarrollar ningún sistema si no se conoce el dominio. Los requerimientos pueden ser mejor obtenidos y analizados si éste dominio es bien comprendido. El dominio de la aplicación comprende varios aspectos. Ambiente operacional. Permite definir el ambiente sobre el cual el sistema estará operando y todos sus componentes. Este medio ambiente podría ser, un sistema distribuido, un sistema en red de área local, un sistema robotizado, un sistema de manufactura computarizado o una aplicación de comercio electrónico. Sistemas de hardware. Estos sistemas comprenden, los sistemas de cómputo, las redes utilizadas y sus protocolos, así como cualquier otros sistemas eléctricos y mecánicos. Sistemas de Software. Estos sistemas comprenden los sistemas operativos, bases de datos, lenguajes, sistemas de manejo de archivos, software de aplicación, sistemas de seguridad, entre otros. Interfaces Hombre-Maquina. Estos sistemas son aquellos con los que los usuarios tendrán contacto directo para llevar a cabo sus labores. Conexiones externas. Estos sistemas son aquellos que provienen del exterior del sistema y que reciben datos del sistema o a quienes el sistema envía datos. Procedimientos operacionales. Estos procedimientos definen las funciones que realiza el sistema actual. Capacidad del Sistema Actual. Este aspecto permite identificar cual es la capacidad de procesamiento y de almacenamiento requeridos por el sistema. Un gran número de sistemas no solo están compuestos por una computadora y un software interno. Las industrias, las empresas bancarias, las empresas de telecomunicaciones o las 72

5 empresas de comercio electrónico, por mencionar solo algunas, tienen medios de operación muy complejos que comprenden sistemas de cómputo, sistemas electro-mecánicos, robots, complejos sistemas de tele-comunicaciones y sofisticadas interfaces de usuario. El desarrollo de sistemas de software sobre éste tipo de ambientes, implica que especialistas de distintas disciplinas de la Ingeniería se involucren en su especificación y diseño. Podemos mencionar por ejemplo, el sistema de software que opera sobre los cajeros automáticos de los bancos. Mediante este cajeros, es posible realizar diversas transacciones bancarias como sacar dinero, hacer transferencias bancarias, consultar saldos o cambiar claves. Estos cajeros contienen un sistema de cómputo el cual controla los dispositivos electro-mecánicos que permiten almacenar y dar dinero a las personas con cuenta en el banco. Además, estos cajeros, cuentan con sistema de comunicaciones, que les permiten enlazarse con los sistemas de cómputo del banco. Cuando un cliente del banco introduce su tarjeta de crédito, para obtener dinero del cajero, el sistema se comunica con el sistema de cómputo del banco para validar la tarjeta y para obtener el estado de la cuenta del cliente. Es necesario que los desarrolladores de este sistema cuenten con los conocimientos necesarios sobre el dominio de la aplicación a desarrollar. Sin estos conocimientos el software sería difícil de desarrollar o tendría fuertes implicaciones en el tiempo y costo de desarrollo. Esta parte debe identificarse durante la fase de factibilidad, anteriormente descrita. La información acerca del dominio de la aplicación no se recolecta de un solo lugar. Existe en variedad de fuentes como, libros, manuales organizacionales, especialistas en el tema, o usuarios que dominan una área de la ciencia Comprensión de las necesidades de los clientes y usuarios. Además de la descripción del problema a resolver por parte del cliente, es necesario conocer los problemas que la organización enfrenta cada día en sus procesos de negocio. Esta información permitirá comprender mejor los objetivos planteados por el cliente y sus necesidades. En ocasiones, el cliente no sabe como describir sus necesidades o no sabe como un sistema de software puede ayudar a solucionar sus problemas. Por eso, esta fase de comprensión de necesidades, puede ayudar a describir el tipo de software que mejor resolverá las necesidades de la organización. Las siguientes actividades ayudan a comprender las necesidades del cliente y los usuarios: 73

6 Identificar las tareas o funciones que describen las necesidades del cliente (identificar los casos de uso). Identificar los eventos del sistema y sus respuestas. Observar a los usuarios en sus labores. Observar reportes de problemas de los usuarios del sistema actual Requerimientos del negocio Una vez comprendido el problema a solucionar o el sistema nuevo a desarrollar es necesario entender cuales son los requerimientos del negocio. Los requerimientos del negocio describen los beneficios que el nuevo sistema proveerá a la organización y a sus usuarios. Los proyectos de desarrollo de software por lo general comienzan con la idea de que el nuevo producto de software mejorará la situación del negocio del cliente de alguna forma. Para la definición de los requerimientos del negocio es necesario detallar los siguientes aspectos: 1. Antecedentes. En los antecedentes se resumen las razones y el contexto del nuevo producto. Proveen una descripción general de la historia o la situación que llevó a la decisión de construir el producto o sistema. 2. Oportunidades de negocio. Para un producto comercial, describen la oportunidad de mercado que existe y el mercado en el cual el producto estará compitiendo. Para un sistema a implantar dentro de una organización, describe el problema del negocio que se pretende solucionar o los procesos que se pretenden mejorar. Describe los problemas que existen y que no pueden ser resueltos con la tecnología y los sistemas actualmente en operación. Aquí se muestran también las tendencias del mercado, la evolución de la tecnología y la historia de las decisiones organizacionales relacionadas al sistema por desarrollar. 3. Visión del producto. Es una descripción general de lo que se persigue con la construcción del software y de los beneficios que se esperan. Resume de forma cuantitativa y cualitativa los beneficios que el producto o el sistema aportará a la organización. En este aspecto es importante que los clientes, usuarios y los directores de proyecto definan la forma en como se medirá el éxito o el fracaso del desarrollo y los factores que afectarán o que tendrán mayor impacto en el éxito del proyecto, incluyendo factores dentro o fuera de la organización. 74

7 4. Riesgos del negocio. En este aspecto, los riesgos definen los problemas que se contemplan dentro del desarrollo del proyecto; una vez que el comienzo de éste ha sido ha sido aprobado. Los tipos de riesgos que se pueden presentar son: la habilidad de poder controlar y administrar efectivamente el desarrollo del proyecto, la competencia del mercado, el nivel de aceptación del usuario, los posibles problemas con la implementación y operación del sistema, y los posibles impactos negativos en la organización. 5. Alcances del proyecto a través de los requerimientos del negocio. Los alcances del proyecto permiten al cliente y a los desarrolladores, identificar las implicaciones del desarrollo como son, el tiempo de construcción, los costos y las personas involucradas en desarrollo (por parte del cliente y por parte de los desarrolladores). En ocasiones, es difícil para los desarrolladores estimar tiempos y costos de desarrollo, sin embargo, en la mayoría de los proyectos, el cliente tiene un tiempo máximo permitido y un costo que no puede exceder su presupuesto. Los conflictos que surjan por los tiempos y costos deben resolverse cuando la etapa de factibilidad y de especificación de requerimientos estén terminadas. Hasta entonces, se tendrá la información suficiente para llevar a cabo decisiones de contratación, o rechazo del proyecto. 6. Comprensión del negocio. No es posible llevar a cabo ningún proyecto si no se conoce el negocio que la organización del cliente lleva a cabo. En la comprensión del negocio es necesario conocer: 1. La estructura organizacional. 2. Los procesos del negocio. 3. Los sistemas existentes, y 4. El personal clave relacionado con el proyecto. 75

8 3.2. Búsqueda y Recolección de Información Para comprender el problema a solucionar, es importante contar con diversa información que permita conocer la organización del cliente, sus necesidades y en general el dominio de la aplicación. Esta información debe recolectarse de distintos manuales de la organización, estándares y políticas, y manuales técnicos que describan las distintas partes del dominio de la aplicación y los procesos y normas de la organización. La información recolectada sobre el problema a resolver, debe organizarse coherentemente a fin de que pueda ser utilizada no solo durante el proceso de Ingeniería de Requerimientos, sino también durante todo el ciclo de desarrollo. Algunos ejemplos de información que debe ser recolectada son los siguientes: 1. Información sobre el sistema actual. Esta información provee detalles sobre el sistema que se quiere remplazar y que actualmente está en funcionamiento. Si se trata de un producto a desarrollar de uso genérico, ésta información deberá ser aquella que describe los productos similares actualmente en el mercado, contra quienes el producto tendrá que competir. Es importante en este caso, recolectar información sobre la funcionalidad y restricciones del producto competidor, su precio, el soporte que se ofrece y sus limites geográficos de distribución. 2. Necesidades de los clientes y usuarios. La información recolectada anteriormente, derivada de las entrevistas con los clientes, usuarios y con los interesados en el sistema, debe documentarse. 3. Estándares organizacionales. Esta información comprende todos aquellos manuales de procedimientos que la organización sigue en sus procesos. 4. Regulaciones Nacionales e Internacionales. Esta información es aquella que provea estándares o normas para reglamentar al sistema o a los productos de software a construir. Usualmente todo país cuenta con un organismo de gobierno que regula las actividades de las organizaciones y que provee reglas de competencia y de calidad. 5. Información sobre el dominio de la aplicación. Esta información comprende toda aquella información que permita descubrir el dominio. 76

9 3.3. Definición de Límites y Restricciones Los limites definen el contexto de operación del sistema y definen su medio de operación. Las restricciones definen las limitantes organizaciones, técnicas, económicas o de tiempos de desarrollo impuestas para el proyecto o producto de software a desarrollar. Dentro de las restricciones deben definirse las condiciones de confiabilidad, disponibilidad, desempeño, seguridad e integridad, y en general los requerimientos no-funcionales que se le exigirán al sistema. Esta información influirá significativamente en la definición de la arquitectura del sistema (por definir en la etapa de diseño). El diagrama de contexto (referencia) se utiliza para definir los límites y las conexiones entre el sistema y el medio ambiente que lo rodea. Además, identifica interfaces que permiten comunicar al sistema con su medio externo. En la información que sale o entra al sistema a través de las interfaces se utilizan flujos de control, de datos y de materiales. El diagrama de contexto puede utilizarse como el diagrama que se encuentra en lo mas alto de la jerarquía arquitectónica del sistema. La Figura 3.2 muestra el diagrama de contexto de un sistema de inscripciones a una Universidad. El sistema permite a alumnos acceder al sistema mediante la Internet para realizar su inscripción a sus cursos. El sistema reside en una computadora servidora de web y la información de los cursos es introducida por los profesores de la universidad. Figura 3.2 Diagrama de Contexto de un Sistema de Inscripciones. 77

10 3.4 Definición de los interesados en el sistema Los interesados en el sistema ( stakeholders ) son personas, grupos de personas o organizaciones que están involucradas activamente en el proyecto, que son afectadas por sus salidas, o que proveen entradas al sistema. El proceso de Ingeniería de requerimientos está dominado por distintos factores personales, sociales y organizacionales, debido a que involucra a distinto tipo de personas, con distintos conocimientos o provenientes de distintas organizaciones. Así mismo, las distintas personas involucradas en el proceso pueden tener o no conocimientos técnicos relevantes al proyecto, y pueden venir de distintas disciplinas técnicas. Este contrasta con otras etapas del desarrollo, como por ejemplo la etapa de pruebas, en donde el personal involucrado por lo general comparte el mismo interés y conocimiento técnico, y comparten el objetivo de demostrar que el sistema cumple con sus especificaciones. Los interesados deben clasificarse de acuerdo a su actividad y a su perfil. Ejemplos de distintos tipos de interesados en el sistema son los siguientes: 1. Clientes: Estos normalmente son quienes contratan, financian o autorizan el desarrollo del proyecto. 2. Usuarios: Estos son aquellos que terminarán operando el software requerido, después de que el sistema esté completamente desarrollado. 3. Ingenieros de Desarrollo de Software: Son todos aquellos involucrados en el desarrollo del software, en cualquiera de sus etapas (diseño, implementación, pruebas o mantenimiento). 4. Ingenieros del cliente. Son todos aquellos especialistas que asesoran o trabajan dentro de la organización del cliente y que ayudan a especificar los detalles técnicos de la aplicación a desarrollar. 5. Administradores o jefes del proyecto de software: Son aquellos que dirigen y/o administran el proyecto de software. 6. Contratistas externos. Son aquellos desarrolladores externos a quienes se les contrata para realizar una parte del sistema. 7. Reguladores externos: es todo aquel personal que indirectamente verifica que todo reglamento o ley que aplique al desarrollo del proyecto se cumpla. 78

11 En general, en la Ingeniería de Requerimientos es importante identificar a todos los involucrados en el proceso a fin de obtener y validar el proceso. El no llevar a cabo esta identificación, puede llevar a diseñar el sistema sin contar con toda la información o sin contar con la valiosa opinión de alguno de los actores que participan en el proceso. El perfil de los interesados en el sistema debe incluir la siguiente información: 1. El valor o beneficio que recibirá el interesado del producto o del sistema y la forma en que el producto satisfacerá al interesado. Los beneficios que podría obtener el interesado podrían ser: b. Mejoras en su productividad. c. Reducción de trabajo redundante. d. Ahorro de costos. e. Mejoras en el proceso del negocio. f. Automatización de tareas que previamente se realizaban de forma manual. g. Aprendizaje de nuevas tareas. h. Cumplimiento de estándares o normas. i. Mejoras en la calidad con respecto a otros productos o sistemas. 2. Su disposición o actitud hacia el sistema. 3. La forma en como el sistema afectará a su trabajo en la organización. 4. Su rol o función en la organización. Además de clasificar a los interesados en el sistema, es necesario proveer detalles acerca de los tipos de usuarios que utilizaran directamente el sistema. A los usuarios de sistema de software se les puede clasificar de acuerdo a los siguientes aspectos: La frecuencia con la que usan el sistema. Las funciones que usan del sistema y su frecuencia. La experiencia en el dominio de la aplicación y su experiencia con otros sistemas similares. El tipo de uso que le dan al sistema (operación, administración, mantenimiento, supervisión). 79

12 Las tareas que desempeñan en soporte de los procesos de la organización. Sus privilegios de acceso o niveles de seguridad (tales como usuario invitado, administrador o usuario de nivel interno). Tipo de usuarios necesario para operar el sistema (persona, grupo de personas, robot, o otra computadora). La clasificación de usuarios del sistema ayuda a la obtención de requerimientos ya que define a detalle las características de los usuarios y sus actividades. Es importante distinguir a los usuarios que utilizan el sistema con frecuencia para sus labores en la organización de aquellos que lo utilizan esporádicamente. Esto no solo permitirá definir su rol en la organización sino también su nivel de experiencia. Algunos usuarios por su inexperiencia, solo utilizan cierta funcionalidad del sistema que les es de mayor utilizad ó la cual conocen mejor. Otra parte de la funcionalidad del sistema no la utilizan, por que la desconocen ó por que no la encuentran útil. Obtener esta información permite definir con mayor precisión los requerimientos y diseñar interfaces de usuario mas útiles y fáciles de usar. Algunos usuarios del sistema no llegan a utilizar el sistema, sin embargo se ven indirectamente influenciados por su operación. Este personal pueden ser los encargados de su mantenimiento, los administradores del sistema o el personal de supervisión. Este personal es importante por que permite verificar que las labores de los usuarios se lleven a cabo de forma eficiente y sin errores. Algunos otros usuarios solo reciben los beneficios o los productos que entrega el sistema y forman parte de la organización. Este tipo de personas pueden ser los integradores ó los ingenieros de producto, los cuales se encargan de usar los productos que produce el sistema de software. Algunos usuarios pueden tener mayor nivel de autorización para el acceso a ciertas funciones o niveles de operación del sistema de software. Por otro lado, los usuarios no necesariamente tienen que ser personas. Algunos sistemas se operan de forma automática, mediante otros sistemas de cómputo, mediante robots o de forma híbrida computadora-humano. Muchos sistemas de software industriales operan en ambiente con un alto nivel de ruido, contaminación o de calor, por lo cual se requiere de un sistema automatizado para operar el sistema. 80

13 3.4.1 Roles y Actividades En general, los interesados involucrados en el proceso de Ingeniería de requerimientos son personas afectadas por este proceso a quienes se les puede identificar por sus roles en la organización. Usualmente es útil cuando se modela un proceso, asociar las actividades del proceso con los roles del personal que está involucrado en el proceso. Los roles del personal y sus correspondientes actividades dentro del proceso de Ingeniería de Requerimientos se describen en la Figura 3.3. Rol Analista de Requerimientos, Experto del dominio, usuario Analista de requerimientos, usuario Ingeniero de desarrollo de software, administrador del proyecto Ingeniero de requerimientos, Ingeniero de desarrollo de software Usuario, experto del dominio, analista de requerimiento e Ingeniero de Desarrollo Actividades Este personal estará a cargo de entender el problema y su definición. Están a cargo de especificar a detalle los requerimientos. Están a cargo de seleccionar posibles prototipos del sistema. Estarán a cargo de desarrollar el sistema o prototipo. Estarán a cargo de evaluar el sistema final o prototipo. Figura 3.3. Roles en el proceso de Ingeniería de Requerimientos 81

14 3.5 Recolección de Requerimientos Después de la descripción del problema por el cliente, el analista de requerimientos debe escribir en un documento inicial (DDR), una lista de requerimientos específicos, que describen a detalle el problema planteado por el cliente. Este documento debe ser analizado para darle consistencia durante la fase de análisis de requerimientos. De forma general los requerimientos provienen de las siguientes fuentes: 1. Los interesados en el sistema. Todos los interesados en el sistema, principalmente el cliente y los usuario son quienes mas información deben proporcionar sobre los requerimientos. 2. El dominio de la aplicación. El dominio de la aplicación es una fuente de información que permite ubicar el contexto del desarrollo. Permite obtener información acerca de las características de funcionamiento del sistema de forma general, y permite establecer sus restricciones. 3. La organización. No puede validarse la información de los requerimientos a no ser que esta esté de acuerdo a los estándares utilizados en la organización. De hecho la organización también provee algunos de los requerimientos funcionales y principalmente los nofuncionales, por ejemplo, los requerimientos de calidad, confiabilidad y seguridad del sistema. Los requerimientos obtenidos deben de estar de acuerdo con los objetivos y planes de la organización y aquellos requerimientos que no ayuden a lograr estos objetivos no deben ser incluidos. Las fuentes de donde se obtienen los requerimientos dependen de la naturaleza del producto a desarrollar y del ambiente de desarrollo. La necesidad de obtener los requerimientos de múltiples fuentes implica que siempre debe existir una comunicación fluida e intensa entre cliente/usuarios y desarrolladores. A continuación se describen algunas de las fuentes potenciales y las formas de obtención de requerimientos. Entrevistas y discusiones con clientes y usuarios. La forma mas obvia de obtener información acerca del sistema de software a desarrollar es directamente con el cliente. El cliente describe una necesidad y el desarrollador debe saber interpretar éstos requerimientos y analizar su factibilidad. El cliente por lo general define los requerimientos de forma general, pero no siempre define la funcionalidad. Todo software tiene una cierta funcionalidad que lo 82

15 define. El desarrollador debe ser capaz de traducir los requerimientos del cliente en funciones y restricciones que debe incluir el sistema por construir. Documentos que describen sistemas actuales o productos de la competencia. La mayoría de las organizaciones cuentan con documentos que describen los objetivos que persigue la organización, los procedimientos y procesos que llevan a cabo para cumplir con estos objetivos, así como los roles que desempeñan cada persona que labora en la organización. Así mismo, la organización puede contar con documentos que describen los productos o sistemas de otras organizaciones que producen productos similares. Reportes de problemas técnicos del sistema actual. En muchas organizaciones, se almacenan documentos que reportan problemas técnicos o errores de operación del sistema actual. Estos documentos, pueden ser una fuente mediante la cual el cliente justifica la necesidad de un nuevo sistema. Así mismo, estos documentos permiten a los desarrolladores, conceptualizar el sistema requerido, su entorno de operación, y las habilidades del personal que opera estos sistemas. Estudio de la organización ó cuestionarios de usuarios. Para poder construir cualquier sistema de software, es necesario estudiar el medio ambiente sobre el cual estará en operación. Este estudio permitirá comprender mejor los requerimientos planteados por el cliente y ayudará a diseñar un sistema que cumpla mejor con los objetivos de la organización, y que se adapte mejor a las habilidades de los usuarios. Observación de los usuarios futuros y de su medio ambiente. Una fuente importante de datos proviene de los usuarios futuros del sistema. Los usuarios son quienes tienen la experiencia en la operación de los procesos de la organización. Esta experiencia puede ayudar a los desarrolladores a construir un sistema más fácil de usar y que les permita incrementar su productividad. La información obtenida de los procesos de trabajo de los usuarios, permitirá validar la información recolectada de los clientes, e identificar potenciales conflictos y nuevos requerimientos. El no observar a los usuarios en la operación de los sistemas actuales, llevará muy probablemente a construir un sistema con funcionalidad incompleta o difícil de usar. También es necesario estudiar las habilidades individuales de cada usuario, a fin de diseñar un sistema que mejor se adapte a sus capacidades. Análisis de los escenarios de las tareas del usuario. La identificación de las tareas que el usuario necesita llevar a cabo con el sistema, permitirá al analista de requerimientos obtener 83

16 algunos de los requerimientos funcionales. De esta identificación debe también obtenerse toda la información consumida y generada por la tarea y sobre las fuentes de la información. Análisis de Eventos y Respuestas. Este análisis permitirá identificar los eventos externos a los cuales el sistema debe reaccionar y sus respuestas correspondientes. Este análisis es especialmente útil en sistemas que deben responder a eventos externos y que requieren de respuestas en plazos de tiempo cortos o en tiempos bien definidos. 3.6 Clasificación de Requerimientos Es un hecho que cuando se recolectan los requerimientos de los clientes o los usuarios, estos no los entregan de forma organizada o clasificada. El analista de requerimientos debe obtener los requermientos y clasificarlos en varias categorías de acuerdo a la información que recibe de las distintas fuentes, de forma que estos posteriormente puedan ser analizados eficientemente. Ideas y soluciones Requerimientos del negocio Casos de y escenarios Definiciones de datos Reglas del negocio Restricciones Requerimientos de interfaces externas Atributos de Calidad Requerimientos funcionales y no-funcionales Figura 3.4 Clasificación de los requerimientos. 84

17 En capítulos anteriores hemos dado distintas clasificaciones de los requerimiento, sin embargo aquí daremos una clasificación general que permita distinguir los requerimientos capturados. La Figura 3.4, muestra 9 de éstas posibles categorías. La información que no se encuentre dentro de esta clasificación no debe considerarse, y puede ser lo siguiente: Un requerimiento no relacionado con el desarrollo de software, por ejemplo la necesidad de entrenar a los usuarios en el nuevo sistema. Una restricción del proyecto de desarrollo, por ejemplo el costo o el plan de ejecución (que no se trate de restricciones de diseño e implementación). Una suposición. Un requerimiento de datos, el cual puede ser asociado con la funcionalidad del sistema, por ejemplo que los datos deben ser almacenados en la computadora. Información adicional de contexto histórico o informativo. La siguiente clasificación proporciona algunas frases que permitirán identificar cada requerimiento de acuerdo a la siguiente clasificación (referencia Libro Wiegers: chapter 7): 1. Requerimientos de negocio: Todo lo que describa beneficios de mercado, financieros o del negocio para los clientes o su organización, y que sean obtenidos del producto de software. Las frases que describen algunos de estos requerimientos son los siguientes: Incrementa el porcentaje del mercado en 30 %. Ahorra 20% en costos de producción por la automatización instalada. Ahorra 40% en costos de mantenimiento. 2. Casos de uso y escenarios: Los casos de uso son descripciones generales de metas del cliente o tareas del negocio que los usuarios deben realizar. Un patrón único del caso de uso se conoce como escenario. Es necesario trabajar con los clientes y usuarios para extraer los escenarios, y de aquí conceptualizar los casos de uso. Los casos de uso se pueden obtener mediante la descripción de los flujos de trabajo de los procesos de negocio del cliente. Otra forma de obtener los casos de uso es preguntando a los usuario sobre la descripción de sus tareas o funciones. Un usuario que dice: Tengo que <hacer algo> esta probablemente describiendo un caso de uso. Algunos ejemplos de casos de uso son los siguientes: 85

18 Yo necesito imprimir una etiqueta de correo para el paquete. Yo necesito administrar una cola de reactivos químicos que esperan ser analizados. Yo necesito calibrar las maquinas para control numérico. Mas detalles de los casos de uso y los escenarios se describen mas adelante en la sección de técnicas de obtención de requerimientos. 3. Reglas del negocio: Cuando un cliente dice que solo algunas clases de usuarios realizan alguna actividad bajo condiciones especificas, podría estar describiendo una regla del negocio. Se podrían derivar algunos requerimientos funcionales mediante estas reglas, pero es importante considerar que éstas reglas no definen requerimientos no funcionales. De hecho las reglas de negocio definen hechos, restricciones, acciones que habilitan funciones, formulas de cómputo o inferencias. Las siguientes son algunas de las frases que sugieren reglas del negocio: Debe de seguir el estándar de acuerdo con alguna ley o política de la organización. Si <algunas condiciones ocurren>, entonces <lo siguiente ocurre>. Debe ser calculado de acuerdo a las siguientes formulas. 4. Requerimientos funcionales: Los requerimientos funcionales describen el funcionamiento que el sistema observará bajo ciertas condiciones y las acciones que permitirá el sistema llevar a cabo a los usuarios. Varios ejemplos de clasificación de requerimientos funcionales fueron presentados en el capitulo anterior. A continuación se describen algunos ejemplos de frases de requerimientos funcionales obtenidas de usuarios: Si el voltaje rebasa los 20 v. enciende la alarma amarilla. El sistema envía un de confirmación cuando recibe cualquier . El sistema debe ordenar los productos del inventario en orden alfabético. Algunos de los requerimientos funcionales podrían ser opcionales. Es decir que podrían implementarse solo en el caso de que el tiempo o el presupuesto asignado lo permitiera. Los requerimientos opcionales suelen presentarse con frecuencia, ya que es difícil predecir los tiempos y los costos de desarrollo. Podrían considerarse también, a un precio por separado o ser ignorados. 86

19 5. Atributos de calidad: Los atributos de calidad son requerimientos no-funcionales, los cuales indican la forma en que el sistema debe realizar alguna actividad. Estos atributos se obtienen de escuchar algunas frases o palabras que describen el comportamiento del sistema, tales como: rápido, robusto, seguro, confiable, o eficiente. El analista de requerimiento tendrá que estar de acuerdo con el cliente sobre el significado de estos términos de forma que se eviten ambigüedades o descripciones subjetivas. 6. Requerimientos de interfaces externas: Los requerimientos de esta clase definen conexiones entre el sistema y el mundo externo. Estas interfaces pueden ser interfaces de usuarios, interfaces de hardware o software o redes de conexión. Las frases que indican que se está describiendo una interfase externa podrían ser las siguientes: Las señales de voltaje se leen de los convertidores analógico-digital. Los mensajes se envían a través de la Internet. El software debe controlar el tablero de diagramas eléctricos. Los archivos recibidos electrónicamente deben leerse del disco externo El usuario debe poder ver paginas de web amigables. 7. Restricciones: Las restricciones de diseño e implementación restringen las opciones del desarrollador. Existen áreas y casos particulares en donde las restricciones son bastante obvias. Por ejemplo, en aplicaciones de sistemas basados en web, es importante que el servidor designado reciba peticiones de varios clientes de forma concurrente y las procese en un tiempo limitado. Otro ejemplo son las aplicaciones de sistemas empotrados ( embedded ), en donde es importante tener en cuenta las restricciones de peso, potencia, tamaño, y limitaciones de memoria. Es importante, de acuerdo al dominio de la aplicación, dar significado a cada restricción impuesta, verificando su origen y su valides. Hay algunas restricciones mas severas que otras, por lo que en todo momento debe de verificarse su valides y debe identificarse claramente cuando la restricción es claramente una limitación y no una meta a seguir. Asignar demasiadas restricciones o restricciones innecesarias al sistema, impone un límite a la funcionalidad del sistema y puede bloquear algún requerimiento importante. Por otro lado, asignar pocas restricciones pueden hacer que el sistema se salga de control y que acepte cualquier estado de funcionalidad sin ninguna verificación. Es importante por lo tanto validar toda restricción y verificar que sea realista. 87

20 Las siguientes son ejemplos de algunas restricciones descritas por el cliente o el usuario: Los archivos recibidos no deben exceder los 10 Mbytes. La Base de Datos debe manejar archivos en formato relacional. El envío de paquetes en la red, debe de usar encriptación de 128 Bits. Otras frases que describen restricciones al diseño podrían ser las siguientes: El software debe ser escrito en lenguaje Java. El manejador de bases de datos a utilizar debe ser Oracle. El sistema debe soportar el browser de Explorer. Es importante distinguir entre las restricciones impuestas al sistema y las restricciones impuestas al desarrollo. 8. Definiciones de datos: Las definiciones de datos permiten identificar formato de los datos o archivos, rango de valores permitidos, valores por defecto, o estructura la base de datos. Estas definiciones las puede proveer el cliente o pueden ser abstraídas por el analista (o por cualquier desarrollador). Algunos ejemplos de definiciones de datos pueden ser las siguientes: Los números enteros capturados no deben sobre pasar el valor de 10,000. El numero de asientos inicial a vender por la aerolínea debe ser 400. El valor de temperatura limite es de 40 grados centígrados. 9. Ideas de solución: Mucho de lo que los clientes presentan como requerimientos podría considerarse mas bien como ideas de solución. Algún cliente que describe como debería comportase el sistema ante el operador, tal vez solo está describiendo sus ideas sobre posibles soluciones. Las ideas de solución podrían derivar en requerimientos, si estas son validadas y son factibles de implementar, pero en otras ocasiones estas solo podrían ser alternativas de diseño. Por ejemplo, un cliente podría indicar que para proporcionar seguridad al sistema ante ataques externos, este debe pedir un pasword, o podría construirse un firewall o hacer que los datos usen encriptación. En este caso, el cliente esta dando ideas sobre posibles soluciones al problema de añadir seguridad al sistema. 88

21 3.6.1 Identificación de los Elementos del Sistema Otra clasificación de los requerimientos del sistema puede darse mediante la identificación de los elementos que la componen. Una vez ubicados los limites del sistema mediante su diagrama de contexto, es importante identificar cada elemento que compone al sistema y sus características. Los elementos del sistema son los siguientes: 1. Entradas al sistema: describen no solo el identificador y el contenido de la entrada, sino también todos los detalles de funcionalidad de los dispositivos de entrada. Este elemento puede ser muy complejo e involucrar dispositivos de manipulación, como ratón, joystick, dispositivos para apuntar a la pantalla, teclados o superficies sensibles al tacto. Los dispositivos de entrada como la pantalla o teclados, pueden ser muy complejos, como los que existen en aplicaciones de multimedia, juegos por computadora o aplicaciones robotizadas de la industria. 2. Salidas del sistema: describen los dispositivos de salida, que pueden ser dispositivos de video o audio, así como la funcionalidad de los mismos. 3. Funciones del sistema: describen el mapeo de las entradas a las salidas, y sus distintas combinaciones. Así mismo describen, los comandos que requiere cada función del sistema. 4. Atributos del sistema: describen los requerimientos no-funcionales necesarios para que el sistema opere correctamente, como la confiabilidad, la usabilidad, la disponibilidad, la mantenibilidad o el desempeño. 5. Atributos del ambiente del sistema: describe otros atributos requeridos del sistema, tales como la máxima carga permitida, máxima temperatura permitida, restricciones de operación, o compatibilidad. 89

22 3.7 Características de calidad de los requerimientos Muchas de las características de calidad de los requerimientos han sido conocidas desde hace muchos años, sin embargo aun hoy muchos proyectos carecen de algunas de éstas características por lo cual producen productos de software con poca calidad. Para mejorar las características de calidad de los requerimientos es necesario detallar los conceptos que permiten mejorar la calidad de los requerimientos de software. La calidad de los requerimientos está dada de acuerdo a sus características. Dicha calidad permitirá garantizar a los desarrolladores y clientes su entendimiento y utilización. Estas características son: 1. Entendible. Un requerimiento es entendible si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que lo consulten en un futuro. Con frecuencia los requerimientos son definidos por desarrolladores que utilizan conceptos y terminología técnica difícil de entender por otros interesados. 2. Necesario. Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir y además en su capacidad. Representa características físicas o un factor de calidad que no pueden ser reemplazados por otras capacidades del producto o del proceso. 3. Consistente. Un requerimiento es consistente si no es contradictorio con otro requerimiento. Un requerimiento inconsistente será muy difícil de implementar. Para asegurar la consistencia de un requerimiento es útil verificar si cada requerimiento es consistente con sus fuentes, y si es consistente con otros requerimientos y no los contradice. 4. No ambiguo. Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado para su especificación no debe causar confusión al lector. Para que un requerimiento no sea ambiguo, este debe ser claro y preciso, objetivo y entendible. 5. Completo. Un requerimiento es completo si no necesita ampliar detalles en su redacción, y proporciona toda la información suficiente para su comprensión. Es relativamente fácil omitir información cuando se obtienen requerimientos, y con ello hacer que estos resulten incompletos. Además, es difícil verificar que cada requerimiento es completo ya que 90

23 requiere dedicar tiempo, presupuesto y esfuerzo adicional, lo cual no siempre está disponible en todo proyecto. Para asegurar que un requerimiento es completo se requiere verificar si este es autocontenido, sin información faltante y si este es realmente un solo requerimiento. En otro caso, un requerimiento podría descomponerse en múltiples requerimientos. Además es útil verificar que cada requerimiento contenga toda la información necesaria relevante, que no requiere mayor clarificación o ampliación, y que provee la suficiente información como para evitar ambigüedad y confusión (referencia: paper specifying good requirements: firesmith). 6. Verificable. Es verificable cuando puede ser cuantificado de manera que nos permita hacer uso de métodos de verificación (tales como inspección, análisis, demostración o pruebas) para garantizar que cumple sus propósitos. Los requerimientos deben cumplir con las necesidades de los interesados. Para asegurar que un requerimiento es verificable es útil asegurar que cada requerimiento es lo que los clientes y usuarios realmente necesitan. 7. Correctos. Los requerimientos son correctos si estos describen lo que el cliente o usuario indican. Estos deben ser revisados por el cliente y el desarrollador, para asegurar que no tienen errores. Los defectos en los requerimientos naturalmente llevarán a producir defectos en el diseño y en la implementación. Para asegurar que algún requerimiento es correcto es necesario verificar que es semánticamente correcto, que cumple con alguna de las necesidades de los interesados, y que está correctamente escrito. 8. Reales. Todos los requerimientos deben ser revisados para asegurar que su implementación es posible en el sistema. Esta característica también define si un requerimiento es factible. Los requerimientos no tienen valor si no pueden ser implementados. Si no existe a tecnología, el personal, la experiencia o el presupuesto para implementarlo no será factible. 9. Rastreables. Los requerimientos pueden ser rastreables hacia atrás y hacia delante. Rastreable hacia atrás significa que para cada requerimiento se conoce su origen. Rastreable hacia delante significa que todo requerimiento está escrito de tal forma que facilita la referencia a los requerimientos con los que se relaciona. 91

24 10. Modificable. Un requerimiento es modificable si permite realizar cambios de manera fácil, completa y consistentemente. 11. No redundantes. No deben existir dos requerimientos que definan funciones iguales o similares, de otra forma estaríamos observando un requerimiento redundante. 3.8 Factores que llevan a realizar cambios en los requerimientos Los cambios en los requerimientos pueden ocurrir en cualquiera fase del ciclo de desarrollo del software. Aun después de que el sistema entra en operación, pueden darse cambios en los requerimientos. Estos cambios pueden ser inevitables y no necesariamente son el resultado de una pobre práctica de la Ingeniería de Requerimientos, sino mas bien podrían ser el resultado de los siguientes factores: 1. Errores en los requerimientos (conflictos e inconsistencias). A medida que los requerimientos son analizados e implementados, los errores e inconsistencias deben ser descubiertos y corregidos. Estos problemas pueden descubrirse durante las etapas de análisis o después en las posteriores etapas del desarrollo. 2. Evolución del conocimiento del sistema del cliente/usuario o del analista. A medida que los requerimientos se desarrollan, los clientes/usuarios o los analistas pueden entender mejor el sistema y por lo tanto solicitar cambios en los requerimientos. 3. Problemas técnicos, de planificación o de costos. Pueden aparecer distintos problemas al implementar algún requerimiento. Este requerimiento puede ser muy costoso de implementar o puede tomar bastante tiempo para su implementación. 4. Cambios en las prioridades. Las prioridades del cliente pueden cambiar durante el desarrollo del proyecto y pedir cambios. Esto puede deberse a cambios en la organización, cambios en el ambiente operacional del producto, o cambios en el personal. 5. Cambios en el ambiente. El ambiente en el que se instalará el sistema puede cambiar su estructura, lo cual demandará cambios en los requerimientos para mantener compatibilidad. 6. Cambios organizacionales. La organización que usará el sistema puede cambiar su estructura y sus procesos lo cual demandará cambios en los requerimientos. 92

25 7. Poco involucramiento del cliente o del usuario. Los clientes con frecuencia no comprenden por que es tan importante trabajar frecuentemente junto con el analista para definir con precisión los requerimientos y asegurar su calidad. En ocasiones los clientes creen que en pocas reuniones han sido ya capaces de transmitir toda la información necesaria acerca del sistema que se desea construir. Sin embargo, los desarrolladores pueden no tener claro muchos aspectos y requerir mas interacción. En ocasiones los clientes no están muy disponibles o se encuentran en otras ciudades y la interacción con ellos se vuelve problemática. Los clientes pueden creer que al escribir un documento en donde describen sus necesidades los libera de perder su tiempo con los desarrolladores en la especificación. Sin embargo, es claro que a pesar de que este documento esté muy completo (de acuerdo a la definición del cliente), se pueden requerir múltiples entrevistas con el cliente a fin de aclarar cualquier duda acerca de la definición de los requerimientos. En proyectos en donde existe poca interacción con el cliente puede llevar a el descubrimiento tardío de requerimientos que necesariamente provocarán retrasos en la entrega del software. Es importante mencionar también que existen otros factores que contribuyen a que los procesos y los requerimientos en si observen cierta variabilidad. 1. Madurez técnica. Las técnicas y métodos usados en el proceso de Ingeniería de Requerimientos pueden cambiar y evolucionar conforme las tecnologías de cómputo y sistemas evolucionen. De esta forma, los cambios tecnológicos podrían causar alteraciones a los requerimientos. 2. Cultura organizacional. La cultura organizacional tiene un efecto importante en todos los procesos de negocio, por lo cual cualquier cambio en la organización podría provocar cambios en los requerimientos. 3. Dominio de la aplicación. Esta influye sustancialmente a la variabilidad de la aplicación, ya que distintas aplicaciones podrían requerir distintos tipos de procesos. 4. Movimientos de personal. Los cambios y salidas del personal de la organización que desarrolla el software pueden causar una fuerte influencia en el desarrollo. Si las personas desarrollaban alguna actividad importante, podría ser que su salida produzca considerables retrasos en la entrega del software. Además, esto podría causar cambios importantes en los requerimientos debido a que las habilidades del personal que dejo la organización podrían no ser fácil de encontrar, y por lo tanto el software podría sufrir limitaciones. 93