84 Capitulo 4 m Ingenieria de requerimientos Requerimientos del usuario y requerimientos del sistema Definicin del requerimiento del usuario 1. EI MHC-PMS elaboraré mensualmente informes administrativos que revelen el costo de los medicamentos presctitos por cada clinica durante ese mes. Especificacién de los requerimientos del sistema 1.1 En el dltimo dia laboral de cada mes se redactaré un resumen de los medicamentos prescitos, su costo y las clinicas que los prescriben. 1.2 El sistema elaborara automaticamente el informe que se imprimiré después de las 17:30 del sltimo dia laboral del mes. 1.3 Se realizaré un reporte para cada clinica junto con los nombres de cada medicamento, el ntimero de prescripciones, las dosis prescritas yel costo total de los medicamentos prescritos. 1.4 Si los medicamentos estén disponibles en diferentes unidades de dosis (por ejemplo, 10 mg, 20 mg) se harén informes por separado para cada tnidad de d 1.5 El acceso a los informes de costos se restringiré a usuarios autorizados en la lista de control de acceso administrativ. Es necesario escribir los requerimientos con diferentes niveles de detalle, ya que varios lectores los usardn de distintas formas. La figura 4.2 muestra los posibles lectores de los requerimientos del usuario y los del sistema. De éstos, los primeros por lo gene~ ral no estén interesados en la manera en que se implementaré el sistema, y quiza sean administradores a quienes no les atraigan las facilidades detalladas del sistema, Mientras que los segundos necesitan conocer con mas precisién qué hard el sistema, ya que estén preocupados sobre cémo apoyari los procesos de negocios o porque estin inmersos en la implementacién del sistema. En este capitulo se presenta un panorama “tradicional” de los requerimientos, mas que de los requerimientos en los procesos dgiles. Para la mayoria de los sistemas gran- des, todavia se presenta una fase de ingenierfa de requerimientos claramente identifi- cable, antes de comenzar la implementacién del sistema. Fl resultado es un documento de requerimientos que puede formar parte del contrato de desarrollo del sistema. Desde luego, por lo comtin hay cambios posteriores a los requerimientos, en tanto que los reque- rimientos del usuario podrian extenderse como requerimientos de sistema més detalla- dos. Sin embargo, el enfoque égil para alcanzar, al mismo tiempo, los requerimientos a medida que el sistema se desarrolla rara vez. se utiliza en el disefio de sistemas grandes. Requerimientos funcionales y no funcionales ‘A menudo, los requerimientos del sistema de software se clasfican como requetimientos funcionales o requerimientos no funcionales: 1. Requerimientos funcionales Son enunciados acerca de servicios que el sistema debe prover, de cémo deberia reaccionar el sistema a entradas particulares y de cémo4.1 m Requerimientos funcionales y no funcionales 85 igura 4.2 Lectores de diferentes tipos de especificacién de requerimientos 4aa Gerentes del cliente Usuarios finales del sistema = _ngenieros det cliente Gerentes de los contratistas Arquitectos del sistema Requerimientos del usuario Usuarios finales del sistema Ingenieros del cliente Arquitectos del sistema Desarrolladores de software Requerimientos del sistema deberia comportarse el sistema en situaciones especificas. En algunos casos, los reque- rimientos funcionales también explican lo que no debe hacer el sistema, 2. Requerimientos no funcionales Son limitaciones sobre servicios © funciones que oftece el sistema, Incluyen restricciones tanto de temporizaciGn y del proceso de desarrollo, como impuestas por los estndares. Los requerimientos no funcionales se suelen aplicar al sistema como un todo, més que a caracteristicas o a servicios individuales del sistema, En realidad, la distincién entre los diferentes tipos de requerimientos no es tan clara como sugieren estas definiciones sencillas. Un requerimiento de un usuario interesado pot la seguridad, como el enunciado que limita el acceso a usuarios autorizados, parece- ria un requerimiento no funcional. Sin embargo, cuando se desarrolla con més detalle, este requerimiento puede generar otros requerimientos que son evidentemente funciona- les, como la necesidad de incluir facilidades de autenticaciGn en el sistema. isto muestra que los requerimientos no son independientes y que un requerimiento genera o restringe normalmente otros requerimientos. Por lo tanto, los requerimicntos del sistema no s6lo detallan los servicios o las caracterfsticas que se requieren del mismo, sino también especifican Ia funcionalidad necesaria para asegurar que estos servicios y caracteristicas se entreguen de manera adecuada. Requerimientos funcionales Los requerimientos funcionales para un sistema refieren Io que el sistema debe hacer. Tales requerimientos dependen del tipo de software que se esté desarrollando, de los usuarios esperados del software y del enfoque general que adopta la organizacién cuando se escriben los requerimientos. Al expresarse como requerimientos del usuario, los requerimientos funcionales se describen por lo general de forma abstracta que entien- dan los usuarios del sistema. Sin embargo, requerimientos funcionales mas especificos del sistema detallan las funciones del sistema, sus entradas y salidas, sus excepciones, etcétera Los requerimientos funcionales del sistema varian desde requerimientos generales que cubren lo que tiene que hacer el sistema, hasta requerimientos muy especificos que refle- jan maneras locales de trabajar o los sistemas existentes de una organizacién. Por ejem- plo, veamos algunos casos de requerimientos funcionales para el sistema MHC-PMS, que86 Capitulo 4 m Ingenieria de requerimientos So Requerimientos de dominio Los requerimientos de dominio se derivan del dominio de aplicacién del sistema, mas que a partir de las necesidades especificas de los usuarios del sistema. Pueden ser requerimientos funcionales nuevos por derecho propio, restrcciones @ los requerimientos funcionales existentes o formas en que deben realizarse éleulos particulares. El problema con los requerimientos de dominio es que los ingenieros de software no pueden entender las caracteristicas del dominio en que opera el sistema, Por lo comin, no pueden indicar si un requerimiento de dominio se perdié o entré en contlicto con otros requerimientos. http://www SoftwareEngineering-9.com/Web/Requirements/Dom: Req.htmnl se usan para mantener informaci6n de pacientes que reciben tratamiento por problemas de salud mental: 1. Un usuario podré buscar en todas las elfnicas las listas de citas. 2. El sistema elaboraré diariamente, para cada clinica, una lista de pacientes que se espera que asistan a cita ese dia 3. Cada miembro del personal que usa el sistema debe identificarse de manera indivi- dual con su niimero de ocho digitos, Estos requerimientos funcionales del usuario definen las actividades especificas que debe proporcionar el sistema. Se tomaron del documento de requerimientos del usuario y rmuestran que los requerimientos funcionales pueden escribirse con diferentes niveles de detalle (contraste los requerimientos 1 y 3) La inexactitud en Ia especificacién de requerimientos causa muchos problemas en la Ingenieria de software. Es natural que un desarrollador de sistemas interprete un reque- rimiento ambiguo de forma que simplifique su implementacidn, Sin embargo, con frecuencia, esto no es lo que desea el cliente, Tienen que establecerse nuevos requerimientos y efectuar cambios al sistema, Desde luego, esto aplaza la entrega del sistema y aumenta los costos, Es el caso del primer ejemplo de requerimiento para el MHC-PMS que establece que un usuario podré buscar las listas de citas en todas las clinicas. E] motivo para este requerimiento es que los pacientes con problemas de salud mental en ocasiones estén confundidos. Quiz tengan una cita en una clinica y en realidad acudan a una diferente. De ahf que si tienen una cita, se registrard que asistieton, sin importar la clinica Los miembros del personal médico que especifican esto quizs esperen que “buscar” significa que, dado ¢l nombre de un paciente, el sistema busca dicho nombre en las citas de todas las clinicas, Sin embargo, esto no es claro en el requerimiento, Los desarrollado- res del sistema pueden interpretar el requerimiento de forma diferente e implementar una bisqueda, de tal modo que el usuario deba elegir una clinica y luego realizar la busqueda. Evidentemente, esto implicaré més entradas del usuatio y tomaré més tiempo. En principio, la especificacién de los requerimientos funcionales de un sistema debe ser completa y consistente. Totalidad significa que deben definirse todos los servicios requeridos por el usuario, Consistencia quiere decir que los requerimientos tienen que evitar definiciones contradictorias. En la practica, para sistemas complejos grandes, es4.1 m Requerimientos funcionales y no funcionales 87. 42 casi imposible lograr la consistencia y la totalidad de los requerimientos. Una causa para ello es la facilidad con que se comeien errores y omisiones al escribir especificaciones para sistemas complejos. Otra es que hay muchos participantes en un sistema grande. Un participante es un individuo o una funcién que se ve afectado de alguna forma pot el sis- tema. Los participantes tienen diferentes necesidades, pero con frecuencia son inconsis- tentes. Tales inconsistencias tal vez no sean evidentes cuando se especifican por primera vez los requetimientos, de modo que en la especificacién se incluyen requerimientos inconsistentes. Los problemas suelen surgir sélo después de un andlisis en profundidad 0 después de que se entregé el sistema al cliente. Requerimientos no funcionales Los requerimientos no funcionales, como indica su nombre, son requerimientos que no se relacionan directamente con los servicios especificos que el sistema entrega a sus usuarios, Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad, tiempo de respuesta y uso de almacenamiento. De forma alternativa, pueden definir res- tricciones sobre la implementacién del sistema, como las capacidades de los dispositivos VO o las tepresentaciones de datos usados en las interfaces con otros sistemas. Los requerimientos no funcionales, como el rendimiento, la seguridad o la disponi- bilidad, especifican o restringen por lo general caracteristicas del sistema como un todo. Los requerimientos no funcionales a menudo son més significativos que los requerimientos funcionales individuales. Es comtin que los usuarios del sistema encuentren formas para trabajar en tomo a una funcién del sistema que realmente no cubre sus necesidades. No obstante, el fracaso para cubrit los requerimientos no funcionales harfa que todo el sis- tema fuera initil, Por ejemplo, si un sistema de aeronave no cubre sus requerimientos de fiabilidad, no seré certificado para su operacién como dispositive seguro; si un sistema de control embebido fracasa para cubrir sus requerimientos de rendimiento, no operarén correctamente las funciones de control Aunque es posible identificar con regularidad cules componentes de sistema imple- ‘mentan requerimientos funcionales especiticos (por ejemplo, hay componentes de forma- {eo que implementan requerimientos de informe), por lo general es més dificil relacionar componentes con requerimientos no funcionales. La implementacién de dichos requeri- mientos puede propagarse a lo largo del sistema, Para esto existen dos razones 1. Los requerimientos no funcionales afectan més la arquitectura global de un sistema que los componentes individuales. Por ejemplo, para garantizar que se cumplan los requerimientos de rendimiento, quiza se deba organizar el sistema para minimizar las comunicaciones entre componentes. 2. Un requerimiento no funcional individual, como un requerimiento de seguridad, podria generar algunos requerimientos funcionales relacionados que definan nuevos servicios del sistema que se requieran. Ademés, también podria generar requeri- mientos que restrinjan los requerimientos ya existentes, Los requerimientos no funcionales surgen a través de necesidades del usuario, debido a restricciones presupuestales, politicas de la organizacién, necesidad de interoperabilidad con otto software o sistemas de hardware, o factores extemos como regulaciones de segu- ridad o legislacidn sobre privacidad. La figura 4.3 es una clasificacién de requerimientos88 Capitulo 4 m Ingenieria de requerimientos Requerimientos no funcionales Requerimientos Requerimientos Requerimientos del producto de la organizacion fextemos Requerimientos | Requerimientos |__| Requerimientos Requerimientos | Requerimientos deeliciencia de confiablidad de seguridad regulatorios| ‘tices Requetimientos Requerimientos | Requerimientos__Requetimientos Requetimientos de usabilidad ambientales —“operacionales de desarrollo legales Requerimientos | Requetimientos Requerimientos __Requerimientos devendimiento de espacio ‘ontables_protecci6n/seguridad de requerimientos no funcionales no funcionales. Observe a partir de este diagrama que los requerimientos no funciona- les provienen de caracterfsticas requeridas del software (requerimientos del producto), la organizaci6n que desarrolla el software (requerimientos de Ia organizacién) o de fuentes externas: 1. Requerimientos del producto Estos requetimientos especifican o restringen el com- portamiento del software, Los ejemplos incluyen requerimientos de rendimiento sobre qué tan répido se debe ejecutar el sistema y cudnta memoria requiere, reque- rimientos de fiabilidad que establecen la tasa aceptable de fallas, requerimientos de seguridad y requerimientos de usabilidad. 2. Requerimientos de la organizacién Son requerimientos de sistemas amplios, deri- vados de politicas y procedimientos en la organizacién del cliente y del desarrollador. Los ejemplos incluyen requerimientos del proceso operacional que definen cémo se usaré el sistema, requerimientos del proceso de desarrollo que especifican el len- guaje de programacisn, esténdares del entomo o el proceso de desarrollo a utilizar, y requerimientos ambientales que definen el entomo de operacién del sistema. 3. Requerimientos externos Este término cubre todos los requerimientos detivados de factores externos al sistema y su proceso de desarrollo. Bn ellos se incluyen requeri- mientos regulatorios que establecen lo que debe hacer el sistema para ser aprobado en su uso por un regulador, como serfa un banco central; requerimientos legislativos que tienen que seguirse para garantizar que el sistema opere conforme a la ley, y requerimientos éticos que garanticen que el sistema serd aceptable para sus usuarios y el ptiblico en general, La figura 4.4 muestra ejemplos de requerimientos del producto, de la organizacién y requerimientos extemos tomados del MHC-PMS, cuyos requerimientos de usuario se4.1 m Requerimientos funcionales y no funcionales 89 REQUERIMIENTO DEL PRODUCTO EI MHC-PMS estaré disponible en todas las clinicas durante las horas de trabajo niormales (lunes @ viernes, de 8:30 a 17:30). En cualquier dia, os tiempos muertos dentro de las horas laborales normales no rebasaran los cinco segundos. REQUERIMIENTOS DE LA ORGANIZACION Los usuarios del sistema MHC-PMS se acreditarén a si mismos con el uso de la tarjeta de identidad de la autoridad sanitaria, REQUERIMIENTOS EXTERNOS, Como establece la HStan-03-2006-priv, el sistema implementaré provisiones para la privacidad del paciente. igura 4.4 Ejemplos de requerimientos no funcionales len el MHC-PMS introdujeron en la seccién 4.1.1. El requerimiento del producto es un requerimiento de disponibilidad que define cuando estard disponible el sistema y el tiempo muerto permi- tido cada dia, No dice algo sobre la funcionalidad del MHC-PMS e identifica con clari- dad una restriccién que deben considerar los disefiadores del sistema. Fl requerimiento de la organizacién especifica cémo se autentican los usuarios en el sistema, La autoridad sanitaria que opera el sistema se mueve hacia un procedimiento de autenticacién estindar para cualquier software donde, en vez de que los usuarios tengan ‘un nombre de conexién (login), pasan su tarjeta de identidad por un lector para identifi- carse a si mismos. El requerimiento externo se deriva de la necesidad de que el sistema esté conforme con Ia legislacisn de privacidad. Evidentement, la privacidad es un asunto ‘muy importante en los sistemas de atencidn a la salud, y el requerimiento especifica que el sistema debe desarrollarse conforme a un estandar de privacidad nacional. ‘Un problema comiin con requerimientos no funcionales es que los usuarios o clientes con frecuencia proponen estos requerimientos como metas generales, como facilidad de uso, capacidad de que el sistema se recupere de fallas, o rapidez. de respuesta al usuario. Las m s establecen buenas intenciones; no obstante, ocasionan problemas a los desa- rolladores del sistema, pues dejan espacio para la interpretacién y la disputa posterior tuna ver.que se entregue el sistema, Por ejemplo, la siguiente meta del sistema es tipica de cémo un administrador expresa los requerimientos de usabilidad: Para el personal médico debe ser facil usar el sistema, y este tiltimo debe organi- zarse de tal forma que minimice los errores del usuario. Lo anterior se eseribi6 para mostrar cémo podria expresarse Ia meta como un reque- timiento no funcional “comprobable”. Aun cuando es imposible comprobar de manera objetiva la meta del sistema, en la siguiente descripcién se puede incluir, al menos, la instrumentacién de software para contar los errores cometides por los usuarios cuando prucban el sistema, Después de cuatro horas de capacitacién, el personal médico usard todas las fun ciones del sistema, Después de esta capacitacién, los usuarios experimentados no deberén superar el promedio de dos errores cometidos por hora de uso del sistema. Siempre que sea posible, se deberdn escribir de manera cuantitativa los requerimientos no funcionales, de manera que puedan ponerse objetivamente a prueba. La figura 4.5 mues- tra las métricas que se utilizan para especificar propiedades no funcionales del sistema.90 Capitulo 4 m Ingenieria de requerimientos Ce Rapidez Tamafo Faclidad de uso Fiabilidad Robustez Portabilidad Transacciones/segundo procesadas Tiempo de respuesta usuario/evento Tiempo de regeneracién de pantalla Mbytes Namero de chips ROM Tiempo de capacitacion Numero de cuadros de ayuda Tiempo medio para fala Probabilidad de indisponibilidad Tasa de ocurrencia de falla Tiempo de reinicio después de fella Porcentaje de eventos que causan falla Probabilidad de corrupcién de datos en falla Porcentaje de enunciados dependientes de objetivo Numero de sistemas objetivo Figura 4.5 Métricas para especificar requerimientos no funcionales Usted puede medir dichas caracterfsticas cuando el sistema se pone a prueba para compro- bar si éste cumple 0 no cumple con sus requerimientos no funcionales. En la practica, los usuarios de un sistema suelen encontrar dificil traducir sus metas en requerimientos mensurables. Para algunas metas, como la mantenibilidad, no hay métricas para usarse, Fn otros casos, incluso cuando sea posible la especificacién cuanti- (aliva, los clientes no logran relacionar sus necesidades con dichas especificaciones. No comprenden qué significa algin nimero que define la fiabilidad requerida (por ast decirlo), en términos de su experiencia cotidiana con los sistemas de cémputo. Mas atin, el costo por verificar objetivamente los requerimientos no funcionales mensurables sucle ser muy elevado, y los clientes que pagan por el sistema quizé piensen que dichos costos no estén justificados. Los requerimientos no funcionales entran a menudo en conflicto ¢ interactiian con otros requerimientos funcionales o no funcionales. Por ejemplo, el requerimiento de autenticacidn en la figura 4.4 requiere, indiscutiblemente, la instalacién de un lector de tarjetas en cada computadora unida al sistema. Sin embargo, podria haber otro requeri- miento que solicite acceso mévil al sistema desde las computadoras portatiles de médicos o enfermeras. Por lo general, las computadoras portatiles no estén equipadas con lectores de tarjeta, de modo que, ante tales circunstancias, probablemente deba permitirse algxin método de autenticacién alternativo. En la préctica, en el documento de requerimientos, resulta dificil separar los requeri- mientos funcionales de los no funcionales. Si los requerimientos no funcionales se expre= san por separado de los requerimientos funcionales, las relaciones entre ambos serfan diffciles de entender. No obstante, se deben destacar de manera explicita los requeri- mientos que estén claramente relacionados con las propiedades emergentes del sistema, como el rendimiento o la fiabilidad. Esto se logra al ponerlos en una seccién separada del documento de requerimientos o al distinguirlos, en alguna forma, de otros requerimien- tos del sistema.4.2 Eldocumento de requerimientos de software 91. So Esténdares del documento de requerimientos ‘Algunas organizaciones grandes, como el Departamento de Defensa estadounidense y el Institute of Electrical and Electronic Engineers (IEEE), definieron estandares para los documentos de requerimientos. Comiinmente son muy geneéricos, pero tiles como base para desarollar esténdares organizativos mas detallados. EI IEEE es uno de los proveedores de estindates mejor conocidos y desarrollé un esténdar para la estructura de documentos de requerimientos. Este esténdar es més adecuado para sistemas como comando nilitary sistemas de control que tienen un largo tiempo de vida y, por lo general, los disefa un grupo de ‘organizaciones. http://www. SoftwareEngineering-9.com/Web/Requirements/IEEE-standard.html Los requerimientos no funcionales, como los requerimientos de fiabilidad, proteccién y confidencialidad, son en particular importantes para los sistemas fundamentales, En cl capitulo 12 se incluyen estos requerimientos, donde se describen técnicas especificas para definir requerimientos de confiabilidad y seguridad, El documento de requerimientos de software El documento de requerimientos de software (llamado algunas veces especificacisn de requerimientos de software o SRS) es un comunicado oficial de lo que deben implementar los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para un sis- tema, como una especificacidn detallada de los requerimientos del sistema. En ocasiones, los requerimientos del usuario y del sistema se integran en una sola descripeién. En otros casos, los requerimientos del usuario se definen en una introduccién a la especificacién de requerimientos del sistema, Si hay un gran ntimero de requetimientos, los requetimientos del sistema detallados podrian presentarse en un documento aparte Son esenciales los documentos de requerimientos cuando un contratista externo disefa el sistema de software. Sin embargo, los métodos de desarrollo égiles argumentan que los requerimientos cambian tan rapidamente que un documento de requerimientos se vuelve obsoleto tan pronto como se escribe, asi que el esfuerzo se desperdicia en gran ‘medida. En lugar de un documento formal, los enfoques como la programacidn extrema (Beck, 1999) recopilan de manera incremental requerimientos del usuario y los eseriben en tarjetas como historias de usuario. De esa manera, el usuario da prioridad a los reque= rimientos para su implementacién en el siguiente incremento del sistema. Este enfoque es adecuado para sistemas empresariales donde los requerimientos son inestables. Sin embargo, atin resulta itil escribir un breve documento de apoyo que defina Jos requerimientos de la empresa y los requerimientos de confiabilidad para el sistema; es ficil olvidar los requerimientos que se aplican al sistema como un todo, cuando uno se enfoca en los requerimientos funcionales para la siguiente liberacién del sistema. EI documento de requerimientos tiene un conjunto variado de usuarios, desde el administrador ejecutivo de la organizacién que paga por el sistema, hasta los ingenie~ ros responsables del desarrollo del software. La figura 4.6, tomada del libro del autor con Gerald Kotonya sobre ingenieria de requerimientos (Kotonya y Sommerville, 1998), muestra alos posibles usuarios del documento y emo ellos lo utilizan.