Ingeniera de Software II

CARACTERISTICAS DE UN BUEN REQUISITO Un requerimiento necesita cumplir con varios criterios para ser considerado un "buen requisito". Los requerimientos adecuados deben tener las siguientes caractersticas: No ambiguo, comprobable, claro, cierto, comprensible, viable (realista, posible), independiente, atmica, necesario y abstracto. Adems, existen tres criterios que se aplican al conjunto de requerimientos: coherente, no redundante y completa a) No ambiguo Debe haber una sola manera de interpretar el requisito. A veces se introduce ambigedad por siglas sin definir: Ejemplo: REQ: El sistema ser implementado utilizando ASP. El ASP significa Active Server Pages o Application Service Provider? La forma correcta sera: REQ: El sistema ser implementado utilizando Active Server Pages (ASP). He aqu otro ejemplo: REQ: El sistema no aceptar contraseas de ms de 15 caracteres. No est claro lo que el sistema se supone que debe hacer: El sistema no deber permitir al usuario introducir ms de 15 caracteres. El sistema deber truncar la cadena ingresada a 15 caracteres. El sistema deber mostrar un mensaje de error si el usuario introduce ms de 15 caracteres. La forma correcta sera: REQ: El sistema no aceptar contraseas de ms de 15 caracteres. Si el usuario ingresa ms de 15 caracteres, la pantalla mostrar un mensaje de error al usuario.. Cierta ambigedad puede ser introducida a travs de la colocacin de una determinada palabra: REQ: En la pantalla de Vuelos, el usuario slo puede ver un registro. Una forma de solucionar el problema es volver a escribir la exigencia desde el punto de vista del sistema: REQ: En la pantalla de Vuelos, el sistema mostrar un solo vuelo. b) Comprobable (Verificable) Los verificadores o testeadores deben poder verificar si el requerimiento ha sido implementado correctamente. Para que un requerimiento pueda ser probado, debe ser claro, preciso y no ser ambiguo. Algunas palabras utilizadas pueden hacer que un requerimiento no pueda ser probado. Por ejemplo: Algunos adjetivos: robusto, seguro, exacto, efectivo, eficiente, expandible, flexible, conservable, confiable, amigable, adecuado.

Ingeniera de Software II Algunos adverbios y frases adverbiales: rpidamente, seguramente, en una manera oportuna. Palabras no especficas o siglas: etc, y/o. Ejemplo: La facilidad de bsqueda debera permitir al usuario encontrar una reserva basada en el apellido, da, etc. En este ejemplo de requerimiento, todos los criterios de bsqueda deberan ser listados explcitamente. El diseador y desarrollador no pueden adivinar lo que significa etc. Otros problemas pueden surgir por el uso de palabras o frases ambiguas: Modificacin de frases. Palabras vagas. Tiempo gramatical de voz pasiva: El sujeto de la oracin recibe la accin del verbo en lugar de realizar la accin. Ejemplo: REQ: El cdigo del aeropuerto debe ser ingresado. Quin ingresa el cdigo, el sistema o el usuario? Forma correcta: REQ: El cdigo del aeropuerto debe ser ingresado por el usuario. Pronombres indefinidos: pocos, muchos, algunos, varios, alguno, unos, ninguno, cualquiera, alguien, etc. Ejemplo: REQ: El sistema deber resistir el uso concurrente de muchos usuarios. Qu cantidad deberamos considerar en "muchos"?.

REQ: El sistema deber resistir el uso concurrente de a lo ms 500 usuarios.

C) Claro Los requerimientos no deberan contener informacin innecesaria o palabreo. Deben mantenerse claros y simples. Ejemplo: REQ: Algunas veces el usuario ingresar el cdigo de aeropuerto, que el sistema entender, pero otras veces la ciudad ms cercana lo reemplazar; entonces el usuario no necesita saber cul es el cdigo del aeropuerto y ser tambin entendido por el sistema Forma correcta y simple: REQ: El sistema deber identificar el aeropuerto basado ya sea por el cdigo del aeropuerto o el nombre de la ciudad. d) Cierto Si un requerimiento contiene hechos, stos deben de ser verdaderos. REQ: Los precios de alquiler de automviles muestran todos los impuestos aplicables (incluidos el 6% del impuesto estatal). 2

Ingeniera de Software II Este impuesto depende del estado, por lo que la cifra de 6% es incorrecta, ya que la empresa no puede darse el lujo de adicionar ningn porcentaje. e) Comprensible Los requisitos deben ser escritos en un estilo correcto y coherente al mismo tiempo. Hay palabras reservadas que deben utilizarse. La palabra deber" tiene que ser usado en lugar de las palabras "podr ", tiene" o "puede". REQ: Los usuarios registrados debern poseer nombres de usuario no repetidos. f) Viable (Realistas, Posibles) El requisito debera ser posible realizarlo dentro de las limitaciones existentes, tales como: tiempo, dinero, y recursos disponibles. REQ: El sistema deber tener una interfaz de lenguaje natural que comprenda rdenes dadas en el idioma Ingls.

Este requisito puede no ser factible en un corto lapso de tiempo de desarrollo.

g) Independiente Para entender un requisito, no debera haber necesidad de conocer cualquier otro requisito. REQ 1: La lista de vuelos disponibles incluye nmeros de vuelo, hora de salida, y hora de llegada para cada tramo de un vuelo. REQ 2: Estos debern ser ordenados por orden de precio. La palabra estos" en la segunda frase se refiere al requisito anterior. Sin embargo, si el orden de los requerimientos cambia, este requisito no ser comprensible.

Lo correcto sera: REQ: La lista de vuelos disponibles deber ser ordenado por precio.
h) Atmico El requerimiento debe contener un elemento de trazabilidad individual: REQ: El sistema deber proporcionar la posibilidad de reservar el vuelo, compra un billete, reservar una habitacin de hotel, reservar un coche, y proporcionar informacin sobre las atracciones. Este requisito se combina con cinco requisitos atmicos, lo que hace muy difcil la trazabilidad. Frases que incluyen las palabras "y" o "pero" deben ser revisados para ver si se puede dividir en los requisitos atmicos. Lo correcto debera ser:

REQ 1: El sistema deber proporcionar la posibilidad de reservar el vuelo. REQ2: El sistema deber permitir comprar un ticket. REQ3: El sistema deber proporcionar la opcin de reservar una habitacin de un hotel. REQ4: El sistema deber permitir reservar un auto. REQ5: El sistema deber proporcionar informacin sobre lugares de inters.
3

Ingeniera de Software II i) Necesario Un requerimiento no es necesario si ninguno de los Stakeholder necesita el requerimiento o si al retirar dicho requerimiento no afectar el sistema. Un ejemplo de un requerimiento que no es necesario para un actor es un requerimiento que se agrega por los desarrolladores y diseadores, ya que asumen que los usuarios o clientes lo quieren. Por ejemplo, el hecho de que un desarrollador piense que los usuarios desean una funcin que muestra un mapa del aeropuerto y sabe cmo poner en prctica no es una razn vlida para aadir este requisito. Un ejemplo de un requerimiento que se puede quitar porque no proporciona ninguna nueva informacin podra tener el siguiente aspecto: REQ: Todos los requisitos especificados en el documento Visin deberan ser implementados y probados. j) Abstracto Los requerimientos no deben contener diseo e informacin innecesaria: REQ: La informacin de contenido se almacena en un archivo de texto. La forma como se almacena la informacin es transparente para el usuario y debe ser decisin del diseador o del arquitecto. k) Coherente Un requisito es consistente si no es contradictorio con otro requisito. Por ejemplo puede darse el caso en que dos requisitos utilicen trminos diferentes para un mismo concepto: REQ1: El sistema deber permitir reservar una habitacin. REQ2: El sistema deber permitir registrar el hospedaje a partir de una separacin de habitacin registrada. Para evitar esta situacin conviene estandarizar trminos. Entonces, los requisitos anteriores se escriben mejor as: REQ1: El sistema deber permitir reservar una habitacin. REQ2: El sistema deber permitir registrar el hospedaje a partir de una reserva de habitacin registrada. Los enunciados siguientes muestran conflictos que pueden resolverse mediante el anlisis de las condiciones en las que el requisito se lleva a cabo: REQ1: Las fechas debern ser mostradas en el formato mm/dd/aaaa. REQ2: Las fechas debern ser mostradas en el formato dd/mm/aaaa. Aqu, si el REQ1 fue presentado por un usuario americano y el REQ2 por un usuario francs, los requisitos anteriores podrn ser escritos as: REQ1: Para los usuarios en los EE.UU., las fechas se muestran en el formato mm/dd/aaaa. REQ2: Para los usuarios en Francia, las fechas se muestran en el formato dd/mm/aaaa. l) No redundante Cada requerimiento debe expresarse una sola vez y no debera solaparse con otro requisito: 4

Ingeniera de Software II REQ1:Un calendario estar disponible para ayudar a la entrada en la fecha del vuelo. REQ2: El sistema mostrar un calendario emergente al entrar en cualquier fecha. El primer requisito (en relacin con slo la fecha del vuelo) es un subconjunto de la segunda (en relacin con cualquier fecha introducida por el usuario). m) Completo Un requisito debe ser especificado para todas las condiciones que pueden ocurrir: REQ1: Un pas de destino no es necesario que se muestren para los vuelos dentro de los EE.UU. REQ2: Para los vuelos fuera del continente, el sistema deber mostrar un pas de destino. Qu pasa con vuelos a Canad y Mxico? No son ni "dentro de los EE.UU." ni fuera del continente". Todos los requerimientos aplicables deberan ser especificados. Esta es la condicin ms difcil de verificar. Realmente no hay manera de estar seguro de que todos los requisitos son capturados y que una semana antes de la fecha de produccin de las partes interesadas no se va a decir, "se me olvid mencionar que tengo una funcin ms en la solicitud. Un bueno requisito debe tener ms criterios. Sin embargo, por lo general pueden ser expresadas como combinacin de los criterios que hemos discutido: Modificables: Si es atmica y no redundante, por lo general es modificable. Trazabilidad: Si es atmica y tiene un identificador nico, por lo general es rastreable.