C a p э t u l o V DETERMINACI N DE REQUERIMIENTOS
Contents
1. la gesti n de configuraci n detalla la correspondencia entre los elementos de la definici n de requerimientos y aquellos de la especificaci n de requerimientos de modo que la visi n del cliente est unida a la visi n del desarrollador en una forma organizada y rastreable Si no se definen estas l neas no hay manera de dise ar casos de prueba para determinar si el c digo satisface los requerimientos 5 1 2 Requerimientos funcionales y no funcionales Los requerimientos describen el comportamiento de un sistema A medida que el sistema act a sobre los datos o las instrucciones los objetos y las entidades se mueven desde un estado de ser a otro por ejemplo de lleno a vac o de ocupado a libre o de enviando a recibiendo Esto es en un estado dado el sistema satisface un conjunto de condiciones cuando el sistema act a puede cambiar su estado global cambiando el estado de un objeto Los requerimientos expresan los estados del sistema y de los objetos y las transiciones de un estado a otro En particular los requerimientos describen las actividades del sistema como una reacci n a la entrada y el estado de cada entidad en el sistema antes y despu s de que ocurra dicha actividad Por ejemplo en un sistema de n mina de pago el empleado puede existir en al menos dos estados empleados a n no pagados y empleados pagados Los requerimientos describen c mo al emitir los cheques de pago un empleado pasa del primero al segundo estado Inge2. Cabe se alar que el Sistema ser probado 65 Ingenier a de Software FCC BUAP Oto o 2003 inicialmente en 2 colegios Luego pretende ser implementado a corto plazo en 30 colegios para despu s extender dicha cifra a 100 establecimientos Vale la pena destacar que el n mero de establecimientos ir increment ndose de acuerdo a la necesidad de la comuna Necesidad No negociable Prioridad Alta Estabilidad 10 de 10 Fuente RU 23 5 3 8 Problemas de los requerimientos de software Una vez que se han definido los atributos de estos requerimientos es necesario analizar algunos de los problemas que se deben evitar en los requerimientos Completitud de los requerimientos de software Es necesario considerar dos aspectos importantes Si es que se han considerado todos los requerimientos de usuario dentro de la construcci n de los requerimientos de software y si es que se ha especificado una actividad para cada conjunto posible de entradas En la medida que se pueda responder afirmativamente a estas dudas planteadas se habr hecho todo lo posible porque los requerimientos de software est n completos La completitud quedar demostrada mediante una matriz de trazabilidad entre requerimientos de usuario y requerimientos de software Esta matriz es parte del DRS A continuaci n se muestra un ejemplo de dicha matriz m E Fig 5 4 Matriz de trazabilidad de requerimientos La matriz muestra en las columnas a los RU y en las f
3. de la lectura inicial de los datos De manera similar pueden decirnos que las consultas al sistema deben ser respondidas dentro de los tres segundos posteriores Estas restricciones por lo general estrechan nuestra selecci n de lenguaje plataforma o t cnicas y herramientas de implementaci n sin embargo la selecci n se realiza en la etapa de dise o despu s de haber especificado los requerimientos Tanto los requerimientos funcionales como los no funcionales son obtenidos del cliente de manera formal y cuidadosa Esta extracci n formal de los requerimientos es necesaria porque los clientes no siempre son buenos para describir con exactitud lo que desean o necesitan y los desarrolladores no siempre son buenos para comprender los intereses del negocio de los dem s Los clientes conocen su negocio pero no siempre pueden describir sus problemas de negocios a terceros las descripciones est n llenas de expresiones en jerga y de suposiciones con las cuales los desarrolladores no est n familiarizados Por otra parte los desarrolladores conocen las soluciones de computaci n pero no siempre saben c mo afectar n las soluciones posibles a las actividades de negocios de los clientes Tambi n tienen su propia jerga y suposiciones y a menudo creen estar hablando el mismo lenguaje cuando de hecho dan significados diferentes a la misma cosa As si la comunicaci n entre desarrolladores y clientes no est cuidadosamente 57 Ingenier a de Softw
4. o 2003 Requerimientos operacionales Son los que especifican la forma en que correr el sistema y como se comunicar con los operadores humanos Incluyen todas las interfaces de usuario interacci n humano computador y requerimientos log sticos y organizacionales e Requerimientos de recursos Requerimientos que especifican los l mites superiores de los recursos f sicos tales como capacidad de procesamiento memoria principal espacio en disco etc Requerimientos de verificaci n Estos requerimientos especifican las restricciones de c mo se verificar el software Pueden incluir requerimientos de simulaci n emulaci n tests vivos con entradas simuladas tests vivos con entradas reales e interfaces con ambientes de testeo e Requerimientos de aceptaci n de tests Requerimientos que deben especificar las restricciones de c mo se validar el software e Requerimientos de documentaci n Requerimientos que especifican documentaci n adicional a la requerida en el est ndar e Requerimientos de seguridad de la informaci n Son requerimientos para asegurar el sistema y sus datos contra amenazas a la confidencialidad integridad y disponibilidad e Requerimientos de portabilidad Son aquellos que especifican la facilidad para utilizar el sistema en otros computadores y sistemas operativos e Requerimientos de calidad Requerimientos que especifican atributos del software para asegurar que estar saludable para sus pro
5. por distintos perfiles de usuarios asociados al proyecto o descomposici n en m dulos etc Lo importante es que sea posible hacer una descomposici n de la funci n principal en sub funciones de forma a poder atacar cada una de forma independiente N tese que ya a este nivel se puede notar la importancia de que los requerimientos de usuario conserven su independencia El proceso de modelaci n es un proceso que debe ser iterativo pues requiere mucho desarrollo y cambios El desarrollo de la especificaci n de las funciones se realiza por niveles partiendo por la funci n principal hacia abajo El modelo conceptual debe satisfacer las siguientes reglas 63 Ingenier a de Software FCC BUAP Oto o 2003 Las funciones deben tener un prop sito nico Sus nombres deben tener una estructura declarativa qu hacen en vez de c mo lo hacen lo cual hace que esta estructura se mantenga a nivel de modelo y no corresponda a una implementaci n de la soluci n Esto se hace para mantener un esquema de alto nivel del desarrollo del proyecto e Las funciones deben estar en el nivel apropiado en el que aparecen Esto se refiere a que se debe mantener cierto orden cronol gico en la implementaci n de la soluci n y tambi n un orden de prioridades con respecto al orden topdown definido anteriormente Esto se hace para mantener consistencia en la soluci n del problema e Las interfaces con otros sistemas de software deben minimizarse
6. que un requerimiento ha sido declarado se pueden examinar todas las posibles entidades y las actividades que podr an satisfacer el requerimiento dividi ndolas en dos clases aquellas que satisfacen el requerimiento y las que no Esta partici n debe ser repetible los miembros de la clases no deben variar de acuerdo con quien est haciendo la clasificaci n La capacidad de verificaci n Sacilidad de medici n debe tratarse apenas se extraen los requerimientos ntentaremos cuantificar las maneras en que se puede probar si una soluci n potencial satisface un requerimiento dado Estos criterios de encaje forman una descripci n objetiva del significado del requerimiento cuando tales criterios no pueden ser f cilmente expresados es probable que los requerimientos sean ambiguos incompletos o incorrectos Por ejemplo un cliente puede enunciar un requerimiento de esta manera La informaci n sobre calidad del agua debe estar accesible en forma inmediata El cliente probablemente tenga una clara idea acerca de lo que significa inmediatamente y es ese concepto el que debe ser capturado en el requerimiento Podemos expresarlo con mayor exactitud diciendo Los registros de calidad del agua deben ser recuperados dentro de los cinco segundos de la solicitud Es esta segunda formulaci n del requerimiento la que puede ser probada objetivamente se efect a una serie de solicitudes y los registros deben ser suministrados por el sistema dentro de los ci
7. 3 Requisitos espec ficos 3 1 Requisitos funcionales 3 2 Requisitos de interfaces externos 3 2 1 Interfaces de usuario 3 2 2 Interfaces hardware 3 2 3 Interfaces software 3 2 4 Interfaces de comunicaci n 3 3 Requisitos de rendimiento 3 4 Requisitos de desarrollo 3 5 Requisitos tecnol gicos 3 6 Atributos 3 7 Otros requisitos 4 Ap ndices 69 Ingenier a de Software FCC BUAP Oto o 2003 Por ultimo presentamos otra propuesta de es uema tomada de la p gina eb Plantilla de la specificaci nde e uisitos de oft are cu adirecci nes _ttp polaris lcc uma es Uamg P re uisitos tml ESPECIFICACI N DE REQUISITOS DEL SOFTWARE 1 0 Introducci n n esta secci n se ace un resumen del contenido del documento 1 1 Objetivos Describir los objeti os generales del soft are 1 2 Alcance Describir el soft are ent rminos de entradas salidas principales funcionalidades principales sin entrar en detalles de implementaci n 1 3 Contexto l soft are se encuadra en una l nea de productos se discuten los aspectos estrat gicos deesalnea lobjeti o es situar al lector acerle comprender el sistema como un todo 1 4 Restricciones principales e enumeran las restricciones de negocio ue puedan afectar a la especificaci n dise o implementaci n o prueba del soft are 2 0 Escenarios de uso sta secci n organi a la informaci n de re uisitos ue se recoge del cliente 2 1 Perfiles de usuario Describir los
8. CI N Y AN LISIS ESPECIFICACI N DE REQUERIMIENTOS DE REQUERIMIENTOS Documentaci n An lisis Descripci n Prototipado del problema del problema y prueba validaci n Hemos capturado Estamos usando La funci n Hemos capturado todo lo que el las t cnicas o es factible todo lo que el usuario necesita visiones correctas usuario espera Figura 5 1 El proceso de determinaci n de los requerimientos La falta de cuidado en la comprensi n la documentaci n y la gesti n de los requerimientos puede llevar a una mir ada de problemas construir un sistema que resuelve el problema equivocado que no funciona como se espera o que presenta dificultades para que los usuarios puedan comprenderlo y utilizarlo Es m s un proceso de requerimientos mediocre puede en realidad resultar muy caro As que es rentable tomar el tiempo que sea necesario para comprender el problema y su contexto y obtener los requerimientos correctos desde el primer momento 53 Ingenier a de Software FCC BUAP Oto o 2003 La extracci n de los requerimientos es una parte especialmente cr tica del proceso Podemos utilizar una variedad de t cnicas para determinar qu es lo que los usuarios y los clientes quieren realmente A veces el trabajo consiste en la automatizaci n de un sistema manual de modo que es f cil examinar lo que ya est hecho Pero a menudo debemos trabajar con los usuarios y los clientes para comprender un problema cuando todav a
9. Cada uno de los requerimientos de usuario puede tener asociado uno o m s atributos que complementan su informaci n y que ayudan a entender el requisito y luego a monitorear su adecuado tratamiento durante todo el proceso de desarrollo Algunos de los atributos considerados en el est ndar ESA PSS 05 0 son e entifica or De la forma RU x donde x es un n mero nico asociado a cada requisito de Usuario escripci n el requisito Consiste en una explicaci n en espa ol del requisito explicando en forma no ambigua qu restricciones impone el requisito sobre el sistema ecesi a Qu tan importante es el requisito en el proyecto Si es muy importante entonces se estipula como un requisito esencial de lo contrario es no esencial e riori a Puede ser alta media o baja En cierta medida diferencia entre los requerimientos esenciales prioridad alta los requerimientos normales prioridad media y los requerimientos de menor importancia prioridad baja e stabili a Algunos requerimientos se mantendr n estables a lo largo del proyecto otros estar n sujetos a cambios Estos cambios podr n darse en las fases DA y DD Por esto es necesario hacer una revisi n sobre todos los requerimientos a lo largo del proyecto uente e informaci n Aqu se debe citar de d nde proviene el requisito requisito de usuario persona documento grupo entrevista etc haciendo referencia a dicha fuente Adicionalmente los requerim
10. En esta etapa de desarrollo del proyecto no interesa mayormente desarrollar dichas interfaces sino que tratar la soluci n de fondo del problema concentr ndose en la descomposici n de ste Se recomienda que cada funci n no se descomponga en m s de siete subfunciones Esto para evitar complejidades en el manejo de dichas funciones El modelo debe omitir informaci n de implementaci n porque solamente se est proponiendo una descomposici n del problema y no se est presentando la soluci n final e Debe especificarse los atributos de rendimiento de cada funci n capacidad velocidad de ejecuci n tiempos de respuesta etc con el fin de tener una medida aproximada del costo de la soluci n en t rminos de velocidad de la capacidad de procesamiento del sistema como de los par metros f sicos que el entorno del sistema debe soportar e Se debe identificar las funciones cr ticas Una funci n cr tica es aquella que por su naturaleza requiere un tratamiento especial Algunos aspectos que pueden hacer cr tica a una funci n son su complejidad de dise o o implementaci n rendimiento seguridad o conectividad con otros sistemas e Es conveniente utilizar herramientas CASE para construir el modelo conceptual Esto no s lo ayuda a la especificaci n del modelo conceptual sino que tambi n a su futura manutenci n 5 3 6 Especificaci n de los requerimientos de software El est ndar ESA PSS 05 0 define claramente los dis
11. Ingenier a de Software FCC BUAP Oto o 2003 Cap tulo Y DETERMINACI N DE REQUERIMIENTOS Cuando un cliente solicita que se contruya un nuevo sistema tiene alguna noci n de lo que el sistema debe hacer Cada sistema basado en software tiene un prop sito usualmente expresado como algo que el sistema debe hacer Un requerimiento es una caracter stica del sistema o una descripci n de algo que el sistema es capaz de hacer con el objeto de satisfacer el prop sito del sistema La Figura 5 1 explica el proceso de determinaci n de los requerimientos para un sistema basado en software En primer lugar se trabaja con los clientes para extraer los requerimientos formulando preguntas haciendo demostraciones de sistemas similares y hasta desarrollando prototipos de todo o partes del sistema propuesto Despu s se capturan dichos requerimientos en un documento o en una base de datos En primer t rmino se escriben los requerimientos de modo que clientes y desarrolladores puedan ponerse de acuerdo acerca de lo que el sistema debe hacer Por lo general los requerimientos se escriben nuevamente en una representaci n m s matem tica para que los dise adores puedan transformar los requerimientos en un buen dise o del sistema Un paso de verificaci n asegura que los requerimientos sean completos exactos y consistentes y un paso de validaci n garantiza que lo descrito es lo que el cliente pretende ver en el producto final DEFINICI N Y EXTRAC
12. are FCC BUAP Oto o 2003 organizada y fomentada puede suceder que una especificaci n sea malentendida o quede incompleta 5 2 ASPECTOS A CONSIDERAR EN LA DEFINICI N Y ESPECIFICACI N DE REQUERIMIENTOS Los documentos de definici n y especificaci n de requerimientos describen c mo el sistema interact a con su ambiente incluyendo los siguientes aspectos Ambiente f sico D nde est el equipamiento que necesita el sistema para funcionar e Existe una localizaci n o varias e Existen restricciones ambientales tales como temperatura humedad o interferencia magn tica Interfaces e La entrada proviene de uno o m s sistemas La salida va a uno o m s sistemas e Existe una manera prescrita en que deban formatearse los datos Existe un medio prescrito que los datos deban utilizar Usuarios y factores humanos e Qui n usar el sistema e Habr varios tipos de usuario Cu l es el nivel de habilidad de cada tipo de usuario Qu clase de entrenamiento requerir cada tipo de usuario e Cu n f cil le ser a un usuario comprender y utilizar el sistema e Cu n dif cil le resultar a un usuario hacer un uso indebido del sistema Funcionalidad e Qu har el sistema e Cu ndo lo har e Existen varios modos de operaci n C mo y cu ndo puede cambiarse o mejorarse un sistema e Existen restricciones de la velocidad de ejecuci n tiempo de respuesta o rendimiento Docu
13. bras ning n requisito especificado debe contradecir a ning n otro requisito o conjunto de requerimientos e epen encia e los requerimientos Es deseable que todos los requerimientos sean independientes unos de otros En caso de que esto no se cumpla resulta conveniente marcar las dependencias entre los requerimientos Esto debido a que si se desea modificar uno ser necesario revisar los requerimientos con dependencias para evitar introducir defectos e mbi e a e los requerimientos Es muy importante que los requerimientos est n especificados en forma exacta clara y no ambigua Esto requiere un proceso conciente de revisi n de cada uno de los requerimientos con el prop sito de asegurar una sola interpretaci n e uplici a e los requerimientos Cada requisito debe ser especificado solamente una vez Se debe evitar especificar varias veces un mismo requisito dado que constituir a una p rdida de tiempo y un m ltiple control sobre un mismo requisito que ya fue controlado No obstante en caso de requerirse debido a facilidad de entendimiento de los requerimientos es 62 Ingenier a de Software FCC BUAP Oto o 2003 posible duplicarlo En dicho caso se hace necesario introducir un atributo que permita mantener los identificadores de los requerimientos duplicados En caso de modificar alguno de estos requerimientos se modifican tambi n sus copias 5 3 3 Definici n de Requerimientos de Soft are Esta fase corresponde a la se
14. ealizar lluvias de ideas con los usuarios actuales y potenciales e Observar las estructuras y los patrones Deseos y necesidades Model s de dominio de los interesados Organizaci n y sistemas actuales Extraer requerimientos J Modelo de la situaci n actual Documentos existentes Tipos de NO requerimientos Requerimientos recomendados reutilizables Plantilla de requerimientos a Biblioteca de reutilizaci n Figura 5 3 Fuentes de posibles requerimientos 5 3 EL AN LISIS DE REQUERIMIENTOS Y LOS EST NDARES DE CALIDAD DE SOFTWARE En SW CMM se habla de requerimientos del sistema para referirse a la especificaci n completa del software a desarrollar No obstante es frecuente observar en est ndares internacionales de desarrollo de software que dividen el proceso de an lisis en dos la primera fase corresponde a la fase de requerimientos de usuario y la segunda a requerimientos de software En la fase de requerimientos de usuario se especifican los requerimientos que el sistema de software debe cumplir utilizando el lenguaje del usuario Los analistas deben tener especial preocupaci n por entender el problema en funci n del lenguaje de sus usuarios con el prop sito de apoyarlos El conjunto de requerimientos especificados de esta forma son presentados en un documento llamado Documento de Requerimientos de Usuario o DRU Por otro lado en la fase de requerimientos de software los analistas d
15. eben transformar los requerimientos de usuario en un conjunto de requerimientos que especifiquen las caracter sticas del software utilizando lenguaje t cnico Dicha labor termina con la aprobaci n del Documento de Requerimientos de Software tambi n conocido por su sigla DRS El proceso de captura de los requerimientos se realiza a trav s de entrevistas y cuestionarios al usuario con el prop sito de determinar de forma m s precisa los requerimientos del sistema Esta actividad debe ser iterativa ya que los requerimientos ir n cambiando a medida que los usuarios y analistas van estructurando y entendiendo mejor los conceptos en discusi n Como salidas de este proceso se encuentra todo tipo de informaci n que permita apoyar el proceso de an lisis y especificaci n de los requerimientos de usuario Espec ficamente se tienen documentos cintas de audio o de video con reuniones tablas gr ficos anotaciones etc 60 Ingenier a de Software FCC BUAP Oto o 2003 5 3 1 Esl ecificaci n de requerimientos de usuario Dentro de los requerimientos de usuario es posible distinguir dos tipos diferentes e equerimientos uncionales Son declaraciones de los servicios que proveer el sistema y de c mo se comportar ante determinado est mulo e equerimientos o uncionales Son restricciones de los servicios o funciones ofrecidos por el sistema ncluyen restricciones de tiempo sobre el proceso de desarrollo est ndares etc
16. enderlo sin tener que conocer todos los detalles del sistema m s grande En particular un tipo de usuario puede comprender la funcionalidad propuesta sin que tenga que aprender sobre la funcionalidad de los otros usuarios e Se pueden aplicar los casos de uso como base para estimar cu nto tiempo y esfuerzo se necesitar para dise ar y codificar el sistema e El desarrollo del sistema puede ser rastreado en t rminos de los casos de uso Esto es los gerentes pueden seguir el avance de cada caso de uso a medida que es dise ado codificado y probado Las preguntas destinadas a determinar los requerimientos funcionales tienen respuestas que son independientes de la implementaci n de una soluci n para el problema del cliente Se describe lo que el sistema har sin considerar la computadora particular que se podr a utilizar ni el lenguaje de programaci n empleado ni las estructuras internas de datos involucradas o la clase de papel en que se imprimir n los cheques Es evidente que en lugar de decirnos qu har el sistema este tipo de requerimientos impone restricciones al sistema Esto es un requerimiento no funcional o restricci n describe una restricci n sobre el sistema que limita nuestras elecciones en la construcci n de una soluci n al problema Por ejemplo pueden decirnos que el sistema debe ser desarrollado sobre una computadora Compaq o que los cheques del pago deben entregarse a los empleados no m s de cuatro horas despu s
17. ente sobre la pieza de software entregada La tarea realizada en esta fase es la de tomar cada uno de los requerimientos de usuario traduci ndolos a requerimientos de software Es posible y recomendable usar prototipos para esta fase de desarrollo del proyecto para poder ilustrar el avance que se lleva en el proyecto asociando los requerimientos en cuesti n Por otra parte tambi n es positivo usar prototipos para medir el impacto que tiene cierto requisito sobre el proyecto Al igual que en la fase de definici n de requerimientos de usuario una de las salidas que tiene esta fase es el DRS Este documento define los requerimientos de software descritos anteriormente La fase finaliza al ser aprobado el DRS actividad que se realiza despu s de la actividad de revisi n de requerimientos de software RSM El proceso de aprobaci n del DRU es una actividad formal que se realiza de acuerdo a un procedimiento establecido antes del inicio del proyecto 5 3 5 Construcci n del modelo concel tual El modelo conceptual de un sistema corresponde a una definici n jer rquica de las funciones de dicho sistema Dicha especificaci n funcional debe ser independiente de la implementaci n del sistema Es posible construir el modelo conceptual por descomposici n top down de la funci n principal lo cual debe ser inferido del DRU en una jerarqu a de funciones Para algunos tipos de proyecto estas funcionalidades podr an por ejemplo venir dadas
18. eral C Restricciones del Proyecto de software alcances del sistema II DESCRIPCI N DE LA INFORMACI N A Representaci n del contenido de la informaci n B Representaci n del flujo de la informaci n 1 Flujo de datos 2 Flujo de control II DESCRIPCI N FUNCIONAL A Participaci n funcional divisi n en funciones principales y secundarias B Descripci n funcional 1 Descripci n del procesamiento 2 Restricciones limitaciones 3 Requisitos de rendimiento 4 Restricciones de dise o 5 Diagramas de Soporte C Descripci n del control 6F Ingenier a de Software FCC BUAP Oto o 2003 1 Especificaci n del control 2 Restricciones de dise o DESCRIPCI N DEL COMPORTAMIENTO A Estados del sistema B Eventos y acciones CRITERIOS DE VALIDACI N A L mites del rendimiento B Clases de pruebas C Respuesta esperada del software D Consideraciones especiales BIBLIOGRAF A VIT AP NDICES ESQUEMA PARA LA ESPECIFICACI N DE REQUISITOS IEEE ANSI 830 1998 1 Introducci n 1 1 Prop sito del documento de requerimientos 1 2 mbito o alcance del sistema 1 3 Definiciones acr nimos y abreviaturas 1 4 Referencias 15 Visi n general o resumen del documento 2 Descripci n general 2 1 Perspectiva del producto 2 2 Funciones del sistema 2 3 Caracter sticas de los usuarios 2 4 Restricciones 2 5 Suposiciones y dependencias
19. esenta una bre e descripci n de los interfaces con los usuarios umanos del soft are 5 0 Modelo de comportamiento sta secci n presenta los elementos principales del modelo de comportamiento 5 1 Comportamiento software e describen los e entos estados principales 5 1 1 Eventos ista de e entos principales 5 1 2 Estados ista de estados principales 5 2 Diagramas de transici n de estados lo los del sistema soft are completo 6 0 Limitaciones y restricciones e describen restricciones espec ficas ue puedan afectar a la especificaci n dise o implementaci n o prueba del soft are 7 0 Criterios de validaci n nfo ue general ue se usar para la alidaci n del soft are inclu endo tipos de pruebas respuestas esperadas l mites de rendimiento admisibles Ingenier a de Software FCC BUAP Oto o 2003 8 0 Ap ndices Cualquier informaci n suplementaria que complemente la especificaci n anterior
20. gunda fase del proceso de desarrollo en donde tambi n se realizan tareas de an lisis La fase de requerimientos de usuario corresponde a un proceso que se realiza desde el lado del usuario utilizando su lenguaje y formas de especificar el problema a resolver En dicha etapa no se utiliz lenguaje t cnico para describir el sistema a desarrollar Ello debido a que el usuario generalmente no tiene capacitaci n en el rea inform tica Mto indica que es necesario tomar el documento DRU producido en la fase anterior y traducirlo a especificaciones del sistema de software utilizando lenguaje t cnico Por ello a partir de los requerimientos de usuario se debe construir un conjunto de requerimientos de software lo m s completo consistente y correcto posible Esto es crucial debido a que se est n produciendo requerimientos que afectan directamente al software a construir Esta segunda fase contempla principalmente el desarrollo de los requerimientos del sistema pero no desde el punto de vista del usuario sino que del desarrollador Dichos nuevos requerimientos se denominan requerimientos de software Lo anterior indica que esta fase toma como entrada el DRU y produce un documento donde se expresan los requerimientos de software Dicho documento se denomina Documento de Requerimientos de Software conocido tambi n por su sigla DRS Es necesario tener una buena definici n de requerimientos de software porque stos influir n directam
21. ientos deben tener ciertos atributos impl citos los cuales tambi n deben ser tomados en cuenta y descritos dentro del requisito lari a El requisito debe ser claro y entendible por toda persona que lea la especificaci n Por lo mismo debe existir s lo una interpretaci n v lida para el requisito especificado e erificabili a Debe ser posible de checar que el requisito est presente de asegurarse de que el software tendr implementando el requisito y que se puede probar el requisito dentro del software implementado 5 3 2 Elemllos de requerimientos de usuarios A continuaci n se mostrar n tres ejemplos de requerimientos de usuario el primeros y segundo son funcionales y el tercero es no funcional El Sistema debe ser capaz de generar el n mero de matr cula de manera autom tica o dar la opci n al usuario de hacerla manualmente Durante esta etapa del proyecto el ingreso del n mero de matr cula se har manualmente Necesidad No negociable Prioridad Alta Estabilidad Ode 0 No se esperan cambios a futuro Ingenier a de Software FCC BUAP Oto o 2003 Fuente Entrevista del mar 2003 con el Sr P rez El Sistema debe permitir el c lculo de los promedios tanto trimestral como semestral dependiendo de cada establecimiento Para cada alumno debe existir el c lculo de los promedios semestrales o trimestrales promedio general todas las notas hasta antes del examen y por ltimo el promedio final
22. ilas a los RS El ejercicio requiere realizar para cada RU una cruz en el o los correspondientes RS que lo especifican Del ejemplo se puede observar que el requisito de usuario 7 es especificado por los requerimientos de software 1 2 y 3 Al realizar la matriz es recomendable poner los RU en las columnas y los RS en las filas debido a un problema de tama o el n mero de RS es considerablemente mayor que el de RU e Correctitud de los requerimientos de software El proceso de traducci n desde los requerimientos de usuario a requerimientos de software puede introducir defectos Por ello se hace necesario trabajar sobre dicho proceso con el prop sito de obtener requerimientos de software correctamente traducidos N tese que es de suma importancia que los requerimientos de usuario definan adecuadamente el sistema que desea el usuario Por ello la correcci n radica en que el proceso de traducci n de los RU no haya introducido ning n tipo de error o inconsistencia en su o sus correspondientes RS e Consistencia de los requerimientos de software La consistencia de los requerimientos de software se da si es que ning n requisito entra en conflicto con alg n otro Con el fin de evitar estos conflictos se nombrar n algunas de estas inconsistencias 1 T rminos diferentes para nombrar el mismo objeto 66 Ingenier a de Software FCC BUAP Oto o 2003 2 El mismo t rmino para nombrar diferentes objetos 3 Actividades incompatible
23. inici n de requerimientos y es escrito por analistas de requerimientos A veces un nico documento puede servir para ambos prop sitos lo que lleva a un entendimiento com n entre clientes analistas de requerimientos y dise adores Pero a menudo se necesitan ambos documentos y debemos ser especialmente cuidadosos para que no se produzcan p rdidas de informaci n ni se introduzcan cambios cuando se reinterpreta la definici n como una especificaci n Existe una correspondencia directa entre cada requerimiento del documento de definici n y aquellos documentados en la especificaci n Es aqu donde comienza la aplicaci n de los m todos de gesti n de configuraci n usados a lo largo del ciclo de vida La gesti n de configuraci n es un conjunto de procedimientos que rastrean Los requerimientos que definen lo que el sistema debe hacer Los m dulos de dise o que se generan a partir de los requerimientos El c digo del programa que implementa el dise o Las pruebas que verifican la funcionalidad del sistema Los documentos que describen el sistema En un sentido la gesti n de configuraci n proporciona las cuerdas que ligan las partes del sistema entre s unificando los componentes que se han desarrollado por separado Estas cuerdas son las que permiten coordinar las tareas de desarrollo como muestran las trazas horizontales entre las entidades en la Figura 5 2 En particular durante la extracci n y el an lisis de los requerimientos
24. lar deben eliminarse de cualquier especificaci n de requerimientos aquellas caracter sticas que no tienen nada que hacer con el prop sito del sistema e dice que los requeri mientos identifican el qu del sistema en tanto el dise o establece el c mo del sistema Esta distinci n se vuelve todav a m s clara si tenemos en mente el prop sito de la extracci n y an lisis de los requerimientos La Figura 5 muestra d nde se acomodan estas actividades en el amplio contexto del desarrollo del sistema Los requerimientos se extraen al comienzo del desarrollo siendo nuestra meta la determinaci n de la naturaleza del problema del cliente Discutir sobre cualquier soluci n es prematuro hasta tanto el problema no est definido Ingenier a de Software FCC BUAP Oto o 2003 con claridad Es m s el problema se expresa m s f cilmente en t rminos del negocio del cliente De este modo los requerimientos deben centrarse en el cliente v el problema no sobre la implementaci n o la soluci n Extracci n Definici n Verificaci n y an lisis de reque de reque rimientos rimientos Pr posito y metas Problema nentes de c digo y prueba unitaria Comprensi n del dominio de la aplicaci n y del problema Figura 4 2 Actividades del proceso de desarrollo del software Compren si n del problema Especifi caciones ay que procurar que los requerimientos sean verificables De esta forma una vez
25. mentaci n e Cu nta documentaci n se requiere e Debe estar en l nea en papel o en ambos e A qu audiencia est orientado cada tipo de informaci n Datos e Cu l ser el formato de los datos tanto para la entrada como para la salida e Cu n a menudo ser n recibidos o enviados 58 Ingenier a de Software FCC BUAP Oto o 2003 e Cu n exactos deben ser e Con qu grado de precisi n deben hacerse los c lculos e Cu ntos datos fluyen a trav s del sistema e Debe retenerse alg n dato por alg n per odo de tiempo Recursos e Qu recursos materiales personales o de otro tipo se requieren para construir utilizar y mantener el sistema e Qu habilidades deben tener los desarrolladores e Cu nto espacio f sico ser ocupado por el sistema e Cu les son los requerimientos de energ a calefacci n o acondicionamiento de aire e Existe un cronograma prescrito para el desarrollo Existe un l mite sobre la cantidad de dinero a gastar en el desarrollo o en hardware y software Seguridad e Debe controlarse el acceso al sistema o a la informaci n e C mo se podr n aislar los datos de un usuario de los de otros e C mo podr n aislarse los programas de usuario de los otros programas y del sistema operativo e Con qu frecuencia deben hacerse las copias de respaldo backup Las copias de respaldo deben almacenarse en un lugar diferente e Deben tomarse preca
26. nco segundos de cada solicitud Existen tres maneras que ayudan a hacer requerimientos verificables Especificar una descripci n cuantitativa para cada adverbio o adjetivo de modo que el significado de cada calificador sea claro y no ambiguo l eemplazar los pronombres por los nombres espec ficos de las entidades Asegurar que todo sustantivo est definido exactamente en un lugar en los documentos de los requerimientos 55 Ingenier a de Software FCC BUAP Oto o 2003 es de documentos de requerimientos Debido a que el foco de la atenci n est puesto sobre el problema del cliente la extracci n y el an lisis de requerimientos sirve a dos prop sitos diferentes pero relacionados Por una parte la extracci n nos permite escribir un documento de definici n de requerimientos Documento de Requerimientos de Usuario o DRU escrita en t rminos que el cliente puede entender la definici n de requerimientos es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto Representa una comprensi n entre el cliente y el desarrollador de lo que el cliente necesita o desea y por lo general es escrito en forma conjunta por el cliente y el desarrollador Por la otra parte la especificaci n de requerimientos Documento de Requerimientos de Software o DRS reitera la definici n en los t rminos t cnicos apropiados para el desarrollo del dise o de un sistema es la contrapartida t cnica al documento de def
27. nier a de Software FCC BUAP Oto o 2003 Los requerimientos pueden pensarse de dos maneras funcional y no funcional lo que ayuda a describirlos Un requerimiento funcional describe una interacci n entre el sistema y su ambiente Por ejemplo para determinar los requerimientos funcionales se decide cu les estados son aceptables para el sistema Adem s los requerimientos funcionales describen c mo debe comportarse el sistema ante determinado est mulo Por ejemplo para un sistema que imprime cheques semanales de pago los requerimientos funcionales deben responder a las preguntas acerca de cu ndo se emiten los cheques Qu entrada es necesaria para que un cheque se imprima Bajo qu condiciones puede cambiarse el monto del pago Qu provoca la remoci n de un empleado de la n mina de pagos Se pueden utilizar diversas t cnicas para determinar los requerimientos funcionales incluyendo los casos de uso Una de las maneras m s convenientes para la determinaci n de los requerimientos funcionales de un sistema es la identificaci n de sus casos de uso Los casos de uso particionan al sistema en un conjunto de piezas l gicas m nimamente relacionadas cada una de las cuales describe alguna de las maneras en que funcionar el sistema Hay varias ventajas de la visi n de un sistema en t rminos de sus casos de uso Debido a que existen pocas conexiones entre casos de uso puede examinarse cada caso de uso en forma separada y compr
28. no se ha encontrado una soluci n Debemos analizar el problema antes de considerar cualquier soluci n lo que por lo general se hace desglosando el problema en piezas peque as m s f ciles de comprender Una de las maneras de realizar un an lisis de problema consiste en identificar las personas los procesos y los recursos involucrados y despu s documentar las relaciones que existen entre ellos e les pregunta a los clientes qui n est involucrado y se intenta determinar el l mite del sistema e averigua qu elementos de datos pasan de un rol a otro y cu les procesos transforman los datos de una forma o estado a otro Durante la extracci n de los requerimientos se interroga a usuarios y clientes sobre los mismos aspectos de muchas maneras hasta tener la seguridad de que se comprende lo que quieren y necesitan Por lo general resulta til separar los requerimientos en tres categor as 1 1 equerimientos que deben ser absolutamente satisfechos l equerimientos que son muy deseables pero no indispensables 3 1 equerimientos que son posibles pero que podr an eliminarse El an lisis de requerimientos por categor a es til para que todos los participantes comprendan lo que realmente se necesita 3ambi n es til cuando el proyecto est restringido en tiempo o recursos por lo tanto si el sistema tal como se encuentra definido costar demasiado o tomar demasiado tiempo desarrollarlo los requerimientos de categor a 3 se dejan de lado
29. p sitos Cuando sea posible se debe definir atributos de calidad que sean claramente medibles e Requerimientos de confiabilidad stos especifican los tiempos medios entre fallas o la tasa de ocurrencia de fallas que ser an aceptables e Requerimientos de mantenimiento Son los requerimientos que especifican cuan f cil es reparar fallas y adaptar el software a nuevos requerimientos Debiera especificarse en forma cuantitativa tal como el tiempo medio para reparar una falla e Requerimientos de seguridad de la operaci n Son aquellos que especifican cualquier requisito para reducir la posibilidad de da o que puede producirse de una falla del software Los atributos asociados a los requerimientos de software son los mismos que los de los requerimientos de usuario lo nico que se cambia es la clave del identificador por RS x 5 3 7 Ejemplos de requerimientos de software A continuaci n se muestran dos ejemplos de Requerimientos de Software uno funcional y uno de desempe o RS 04 El Sistema debe permitir que las fechas de inicio y t rmino de cada a o escolar d as de vacaciones feriados puedan ser modificadas por el administrador de cada colegio teniendo en consideraci n que estas fechas pueden diferir para cada curso Necesidad No negociable Prioridad Alta Estabilidad 4 de 10 Fuente RU 15 RS 38 El Sistema debe soportar una cantidad simult nea de usuarios acorde con la demanda estimada por la Corporaci n
30. r por qu se e Especificar las restricciones de la desarrollar el sistema implementaci n e Ser f cil de cambiar ANNAN E Especifican los requerimientos y los lee para verificar que cumplen sus necesidades Especifican los cambios en los requerimientos Utilizan el documento de requerimientos para planear el proceso de desarrollo del sistema de 7 l Ingenieros proba Utiliza los requerimientos a Servir como herramienta de dores del sistema para desarrollar las pruebas referencia para los mantenedores del terme de validaci n para el sistema sistema d Registrar las previsiones del ciclo de ma r aio 1 i Ingenieros ltz s requerimi vida del sistema oro para ayudar a comprender el sistema y las relaciones e Caracterizar las respuestas aceptables ME del sistema B entre las partes para los eventos no deseados Figura 5 5 Usuarios de un documento de requerimientos La ficina Nacional de Est ndares de E E U U ANSI el Departamento de Defensa de E E U U y la IEEE est ndar RF30 1 F4 han propuesto formatos para las especificaciones de requisitos del Software Algunos puntos propuestos son 67 Ingenier a de Software FCC BUAP Oto o 2003 Introducci n Establece metas y objetivos del Software Visi n I isi n del sistema alcance etc Descripci n de la nformaci n Proporciona una detallada descripci n del problema que el software
31. s pasando al mismo tiempo 4 Actividades pasando en orden err neo e Duplicaci n de los requerimientos de software En general este problema debe ser evitado pero a veces es necesario para llevar a un mejor seguimiento del DRS 5 3 E E E E E E E E Este algunas veces denominado especificaci n de requerimientos del software es la declaraci n oficial de qu es lo que requieren los desarrolladores del sistema Incluye tanto los requerimientos del usuario para el sistema como una especificaci n detallada de los requerimientos del sistema En algunos casos los dos tipos de requerimientos se integran en una nica descripci n En otros los del usuario se definen en una introducci n de la especificaci n de los del sistema Si existe un gran n mero de requerimientos los detalles de los requerimientos del sistema se pueden presentar como documentos separados El documento de requerimientos tiene un conjunto diverso de usuarios que PES va desde los administradores principales y Clientes de la organizaci n quienes pagan por el del sistema sistema hasta los ingenieros responsables del software La figura 5 16 tomada de P otonya y Sommerville 1 F muestra los posibles usuarios del documento y c mo lo utilizan El documento de requerimientos de software debe satisfacer seis requisitos Especificar nicamente E pei z Utilizan los re al A a HIZ mI comportamiento externo del sistema Ingenieros E g para comprende
32. tintos tipos de requerimientos de software a considerar dividi ndolos en catorce grupos distintos Todos los requerimientos de software tienen que ver esencialmente con la parte de operaci n funcionamiento seguridad y mantenimiento del software En total dichos requerimientos especifican el software Estos requerimientos son derivados de los requerimientos que fueron estipulados por el usuario en la fase de definici n de requerimientos de usuario A continuaci n se definen cada uno de los catorce grupos que componen los requerimientos de software e Requerimientos funcionales stos especifican qu debe hacer el software los cuales son derivados del modelo conceptual e Requerimientos de rendimiento Son valores num ricos para variables medibles Pueden ser incluidos en la especificaci n cuantitativa de cada funci n o especificados en forma independiente Los atributos de rendimiento deben ser presentados como rangos de valores peor caso aceptable valor nominal a ser usado en la planificaci n mejor caso para indicar potencial de crecimiento e Requerimientos de interfaces Estos requerimientos especifican hardware software o elementos de bases de datos con los que el sistema o sus componentes interact an o se comunican Deben ser clasificados en requerimientos de software hardware y comunicaciones Pueden utilizarse diagramas de bloques para ilustrar parte de este tipo de requerimientos Ingenier a de Software FCC BUAP Oto
33. todas las notas incluyendo el examen Necesidad No negociable Prioridad Alta Estabilidad 5 de 0 El cliente no se encuentra seguro Se espera una especificaci n m s detallada de la especificaci n del n mero de pruebas durante el per odo Fuente Entrevista del 2 mar 2003 con el Sr Lu rez El Sistema debe proveer mensajes de ayuda sobre cada funci n El usuario decidir si ocupa o no esta opci n de modo de no sobrecargarlo con demasiada informaci n Necesidad No negociable Prioridad Media Estabilidad 7 de 0 Se espera el DRS para definir adecuadamente cual funcionalidad deber tener la ayuda Fuente Entrevista del 5 may 2003 con el Sr Ariza 5 3 3 Problemas de los requerimientos de usuarios El proceso de especificaci n de los requerimientos de usuario es iterativo y termina cuando stos se han estabilizado No obstante los requerimientos pueden tener algunos problemas cl sicos Mtos son e orrectitu Es necesario que todos los requerimientos de usuario sean especificado en forma correcta con respecto a lo que el usuario desea para poder cumplir con el objetivo que se pide ompletitu Es necesario asegurarse de que todos los requerimientos que se especificaron permiten definir completamente el sistema a desarrollar y no falta ninguno de ellos Esto es extremadamente complejo de realizar e onsistencia Se debe mantener consistencia entre todos los requerimientos especificados En otras pala
34. uciones contra el fuego el da o provocado por agua o el robo Aseguramiento de la calidad e Cu les son los requerimientos para la confiabilidad disponibilidad facilidad de mante nimiento seguridad y los restantes atributos de calidad e C mo deben demostrarse las caracter sticas del sistema a terceros e Debe el sistema detectar y aislar defectos Cu l es el promedio de tiempo prescrito entre fallas e Existe un tiempo m ximo permitido para la recuperaci n del sistema despu s de una falla e C mo puede el sistema incorporar los cambios al dise o e El mantenimiento corregir meramente los errores o incluir tambi n el mejoramiento del sistema e Qu medidas de eficiencia se aplicar n al uso de recursos y al tiempo de respuesta e Cu n f cil debe ser mover el sistema de una ubicaci n a otra o de un tipo de computa dora a otro La Figura 5 3 muestra como los requerimientos pueden extraerse de muchas maneras Podemos ampliar este concepto siendo creativos en la forma de averiguar qu es lo que quieren los clientes Por ejemplo se puede e revisar la situaci n actual e trabajar en el mbito del usuario para comprender el contexto los problemas y las rela ciones 59 Ingenier a de Software FCC BUAP Oto o 2003 e entrevistar a los usuarios actuales y potenciales e realizar un video para mostrar c mo podr a funcionar el nuevo sistema investigar los documentos existentes e r
35. usuarios en el sentido de 6actores6 del soft are 2 2 Casos de uso e presentan todos los casos de uso del sistema 2 3 Consideraciones especiales e describen silas a las consideraciones re uisitos relacionados con el uso del soft are 3 0 Modelo de datos sta secci n describe el dominio de informaci n del soft are 3 1 Modelo de objetos e describe el modelo de objetos esencial el deri ado directamente del dominio del problema e describen tanto objetos como relaciones 4 0 Modelo Funcional sta secci n describe cada una de las funcionalidades principales del soft are 4 1 Descripci n de funciones Ingenier a de Software FCC BUAP Oto o 2003 e detalla la descripci n de una de las funcionalidades principales sta secci n se repite para cada funci n principal 4 1 1 Especificaci n de proceso e describe la funcionalidad te tualmente mediante diagramas de acti idad colaboraciones etc 4 1 2 Rendimiento e describen los re uisitos de rendimiento de la funcionalidad 4 1 3 Restricciones de dise o e describen las restricciones de dise o ue puedan afectar a la especificaci n dise o implementaci n o prueba del soft are 4 2 Descripci n Interfaces sta secci n detalla los interfaces del soft are con el 6mundo e terior6 4 2 1 Interfaces HW e describen las interfaces con otras m uinas ordenadores o dispositi os 4 2 2 Interfaces SW e describen las interfaces con otros sistemas o productos 4 2 3 Interfaces Humanas e pr
36. va a resolver Se documenta el contenido de la informaci n y sus relaciones flujo y estructura Se describen las interfaces ardware Software Usuarios Interfaz ombre I quina del sistema Descripci n uncional Se describen todas las funciones requeridas para la soluci n del problema Se proporciona una descripci n del proceso de cada funci n se establecen y justifican las restricciones del dise o se establecen las caracter sticas del rendimiento Se especifica el comportamiento del sistema es decir como actuar el sistema ante acontecimientos externos y como son los mecanismos de control internos Se anexar n diagramas de flujo de datos DFDSS de flujo de control DFC y de transici n de estados DET para describir gr ficamente la Estructura Tlobal del Software y las interacciones entre las funciones del software y otros elementos del sistema Criterios de alidaci n El tipo de pruebas que se efectuar n para validar una funci n el rendimiento y las restricciones S ibiograf a Referencias a los documentos de la Empresa o Instituci n que se consultaron para establecer los requisitos a libros y art culos sobre el tema y a est ndares utilizados Ap ndices Tablas de Datos Descripciones detalladas de Algoritmos Gr ficas Dibujos Prototipos de Manual de Usuario etc ESQUEMA PARA LA ESPECIFICACI N DE REQUISITOS IEEE ANSI 830 1984 I INTRODUCCI N A Referencia del Sistema B Descripci n gen
37. y los de categor a pueden analizarse para su eliminaci n o postergaci n Cada uno de los requerimientos de un sistema trata acerca de los o eto oenti e los et o en que estos pueden estar y las un one que se realizan para cambiar los estados o las caracter sticas del objeto 3 odos los requerimientos son descripciones espec ficas de funciones o caracter sticas que conducen al prop sito m s general del sistema Por lo tanto se buscan los requerimientos que definen los objetos del sistema 5 un empleado es una persona que es pagada por la compa a que los limitan 5 un empleado ser pagado por no m s de horas de trabajo por semana o define relaciones entre ellos 5 un empleado est supervisado por el empleado si puede autorizar el cambio del salario de x tese que ninguno de estos requerimientos especifica c mo debe implementarse el siste ma En otras palabras no se hace menci n de qu sistema de gesti n de base de datos utilizar de cu nta memoria debe tener la computadora o qu lenguaje de programaci n se debe aplicar para desarrollar el sistema Estas descripciones espec ficas de la implementaci n no se consideran como requerimientos a menos que as lo establezca el cliente Es decir un requerimiento apunta al prop sito del sistema sin considerar c mo se va a implementar Cuando los requerimientos se contemplan con esta luz es f cil ver que algunas caracter sticas del sistema pueden ser irrele vantes En particu
Download Pdf Manuals
Related Search