Contenido

Ingeniera de requerimientos. ............................................................................................................. 3

Introduccin .................................................................................................................................... 3
1. Anlisis de requerimientos. ......................................................................................................... 3
1.1 Qu es un requerimiento? ..................................................................................................... 3
1.2 Qu es un anlisis de requerimiento? .................................................................................... 4
1.3 Tipos de Requerimientos .......................................................................................................... 5
1.4 Caractersticas de un Requerimiento ........................................................................................ 6
1.5 Requerimientos C y requerimientos D ...................................................................................... 6
1.6 Por qu deben escribirse los requerimientos ........................................................................... 7
1.7 Dificultades para definir los requerimientos ............................................................................ 8
2. Interaccin con el cliente ............................................................................................................ 8
2.1 Identificacin de interesados .................................................................................................... 8
2.2 Proceso de entrevista y documentacin. .................................................................................. 9
3. Descripcin de los requerimientos C (o del cliente) ................................................................ 10
3.1 Conceptos de operacin.................................................................................................... 10
3.2 Casos de uso ............................................................................................................................ 11
3.3 Diagramas de flujo de datos para la comunicacin con el cliente .......................................... 12
3.4 Diagrama de transiciones de estado para la comunicacin con el cliente ............................. 12
3.5 Diseo preliminar de interfaces de usuarios y otras ............................................................... 13
3.5.1 Pasos para desarrollar interfaces de usuario ................................................................... 14
4. Requerimientos D. ......................................................................................................................... 16
4.1 Tipos de Requerimientos D ..................................................................................................... 16
5. Propiedades Deseadas de los Requerimientos D .......................................................................... 17
5.1 Rastreabilidad ......................................................................................................................... 17
5.2 Comprobacin y no ambigedad ............................................................................................ 18
5.3 Prioridad .................................................................................................................................. 18
5.4 Completos ............................................................................................................................... 18
5.5 Condiciones de error ............................................................................................................... 19
5.6 Consistencia ............................................................................................................................ 19
5.7 Resumen del proceso de escribir un requerimiento detallado ............................................... 19
6. Organizacin de los Requerimientos D ......................................................................................... 20
6.1 Organizacin de requerimientos por clase ............................................................................. 20
6.2 Identificacin de clases ........................................................................................................... 20
6.3 Mtodos para organizar los requerimientos especficos ........................................................ 21
6.4 Clasificacin de Entidades ....................................................................................................... 21
7. Calidad los requerimientos especficos ......................................................................................... 22
7.1 Intervencin del aseguramiento de la calidad (QA) en el anlisis de los requerimientos D... 22
7.2 Mtricas para el anlisis de requerimientos D ........................................................................ 22
7.3 Inspeccin del anlisis de requerimientos D ........................................................................... 24
8. Uso de herramientas e internet para el anlisis de requerimientos. ........................................... 24
9. Mtodos formales para especificaciones de requerimientos ....................................................... 25
9.1 Introduccin a las especificaciones formales .......................................................................... 25
9.2 Cundo debe usarse especificacin formal? ........................................................................ 25
9.3 Precondiciones y pos condiciones ........................................................................................... 25
Bibliografa ........................................................................................................................................ 26




Ingeniera de requerimientos.
Introduccin

A travs de los aos se ha podido constatar que los requerimientos o requisitos son la
pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de
partida para actividades como la planeacin, bsicamente en lo que se refiere a las
estimaciones de tiempos y costos, as como la definicin de recursos necesarios y la
elaboracin de cronogramas que ser uno de los principales mecanismos de control con
los que se contar durante la etapa de desarrollo.
Adems la especificacin de requerimientos es la base que permite verificar si se
alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo
detallado de las necesidades de los clientes o usuarios del sistema y es contra lo que se va
a estar verificando si se estn cumpliendo las metas trazadas.

1. Anlisis de requerimientos.
El anlisis de requerimientos es una de las tareas ms importantes en el ciclo de vida del
desarrollo de software, puesto que en ella se determinan los planos de la nueva
aplicacin.

En cualquier proyecto software los requisitos son las necesidades del producto que se debe
desarrollar. Por ello, en la fase de anlisis de requisitos se deben identificar claramente
estas necesidades y documentarlas.
1.1 Qu es un requerimiento?

Se presenta a continuacin la definicin existente en el glosario de la IEEE de lo que es un
Requerimiento:
Una condicin o necesidad de un usuario para resolver un problema o alcanzar un
objetivo. (Std 610.12-1900, IEEE: 62).
Una condicin o capacidad que debe estar presente en un sistema o componentes de
sistema para satisfacer un contrato, estndar, especificacin u otro documento formal.
(Std 610.12-1900, IEEE: 62)
Tambin, Ian Sommerville presenta una definicin acerca de lo que es un
Requerimiento:
Un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restriccin de ste. (Sommerville, 2005: 108)
Analizando las definiciones anteriores, un requerimiento es una descripcin de una
condicin o capacidad que debe cumplir un sistema, ya sea derivada de una necesidad de
usuario identificada, o bien, estipulada en un contrato, estndar, especificacin u otro
documento formalmente impuesto al inicio del proceso.


1.2 Qu es un anlisis de requerimiento?

Para Construir algo primero debe entenderse lo que debe ser ese algo. El proceso de
entender y documentar este algo se llama anlisis de requerimientos. En general, los
requerimientos expresan qu se supone debe hacer una aplicacin: por lo comn, no
intentan expresar cmo lograr estas funciones. Por ejemplo, la siguiente afirmacin es un
requerimiento para una aplicacin de contabilidad.
El sistema debe permitir a los usuarios, acceso a su saldos.
En trminos generales, la siguiente afirmacin no es un requerimiento para una
aplicacin.
Los estados de cuenta del cliente se almacenaran en una tabla llamada saldos en una base de datos
Access.
Esta ltima afirmacin de refiere a cmo debe construirse la aplicacin y no a que debe
hacer la aplicacin.
Un requerimiento en un nivel con frecuencia se traduce en ms de un requerimiento
especfico en el siguiente nivel ms detallado. Para entender esto imagine que su
requerimiento para una casa es que tenga una vista de 180 a la montaa. Esto podra
traducirse como la afirmacin de que tenga una terraza en el lado derecho con
dimensiones de 20 por 50 pies. Este es un requerimiento ms especfico a un nivel ms
detallado. De manera similar, la segunda afirmacin puede en realidad ser un
requerimiento en un nivel subsecuente dentro del proceso de desarrollo.
Adems, existen excepciones a la regla de que en los requerimientos se evite especificar
como debe hacerse algo. Por ejemplo, el cliente del ejemplo anterior podra, por alguna
razn, querer que los estados de cuenta se almacenen en una base de datos de Access con
el nombre indicado. En ese caso la segunda afirmacin sera un requerimiento.
1.3 Tipos de Requerimientos

Los requerimientos de software pueden dividirse en 2 categoras: requerimientos
funcionales y requerimientos no funcionales.
Los requerimientos funcionales son los que definen las funciones que el sistema ser
capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas
para producir salidas. Es importante que se describa el Qu? y no el Cmo? se deben
hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de
software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema.
A continuacin se presenta un ejemplo de requerimientos funcionales para un mdulo de
matrcula.
Matriculacin
La matrcula ser realizada de forma interactiva. Se le preguntar al alumno cules
el plan de estudios en que desea matricularse (pueden ser varios).
Se podr generar una copia impresa de la matrcula (sin valor oficial) en el
ordenador desde donde se realice el proceso de matriculacin.
Se podr generar el impreso de pago debidamente cumplimentado.
Para la matriculacin se consultarn los datos del expediente y se realizarn las
validaciones necesarias, descritas a continuacin
Pago de matrcula:
La aplicacin generar un impreso para que el alumno realice el pago
correspondiente a la matrcula en 1 2 plazos (segn las fechas establecidas).
Si el alumno tiene matrculas de honor de cursos anteriores o disfruta de algn tipo
de beca, la aplicacin deber calcular automticamente los descuentos
correspondientes

Por otra parte los requerimientos no funcionales tienen que ver con caractersticas que de
una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo
y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de
equipo), mantenimiento, seguridad, portabilidad, estndares, etc.
A continuacin un ejemplo de los requerimientos NO funcionales del ejemplo anterior
sobre el mdulo de matrcula.


Interfaces
Hardware:
El sistema se debe implementar sobre la infraestructura existente en las aulas de
prcticas de la E.T.S. Ingeniera Informtica.
Software:
No existe posibilidad de adquirir licencias de software.
La aplicacin deber funcionar sobre Oracle.
1.4 Caractersticas de un Requerimiento

Es importante no perder de vista que un requerimiento debe ser:
Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
Posible de probar o verificar. Si un requerimiento no se puede comprobar,
entonces cmo se sabe si se cumpli con l o no?
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin
debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su
redaccin, es decir, si se proporciona la informacin suficiente para su
comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al
lector.

1.5 Requerimientos C y requerimientos D

Durante algn tiempo se ha discutido quien es el dueo de los requerimientos: el cliente
o el desarrollador. Para manejar este aspecto, el anlisis de requerimientos se divide en
dos niveles. El primer nivel documenta los deseos y necesidades del cliente y se expresa
en lenguaje claro para l. Los resultados suelen llamarse requerimiento del cliente o
requerimiento C. La audiencia primaria para los requerimientos C es la comunidad del
cliente y la secundaria es la comunidad del desarrollador. El segundo nivel documenta los
requerimientos de manera especfica y estructurada. Estos se llaman requerimientos del
desarrollador o requerimientos D. La audiencia primordial de estos es la comunidad del
desarrollo y la secundaria la del cliente.

1.6 Por qu deben escribirse los requerimientos

Aun para las personas sin experiencia puede ser evidente la necesidad de escribir lo que
se supone debe hacer un programa cuando est terminado. De cualquier forma, este
proceso de escribir suele ignorarse o se deja morir. En estas situaciones, se cree que el
cdigo fuente expresa todos los requerimientos: como el cdigo fuente es imprescindible,
Por qu no reducir el proceso completo a este documento esencial? La respuesta es que
no funciona.
Sin ellos el equipo no sabe en realidad cuales son las metas que intenta lograr, no puede
inspeccionar y probar su trabajo de manera adecuada, no puede controlar su
productividad, no tiene datos adecuados de sus prcticas, no puede predecir el tamao y
esfuerzo de su siguiente trabajo y no puede satisfacer a sus clientes.
Cada requerimiento debe
Expresarse de modo adecuado
Ser de acceso sencillo
Numerarse
Acompaarse con pruebas que lo verifiquen
Tomarse en cuenta en el diseo
Tomarse en cuenta en el cdigo
Probarse aislado
Probarse junto con los otros requerimientos
Validarse con las pruebas despus de construir la aplicacin
Un ejemplo de un requerimiento documentado es el siguiente:
La aplicacin debe desplegar la longitud del gene X12345 en la ventana del sistema
(requerimiento 7824)
Considere el caso que resultara si el requerimiento 7824 no estuviera escrito, muy pocos
de los pasos dados anteriormente se podran llevar acabo de modo apropiado. No sera de
sorprender que la aplicacin en cuestin no fuera apropiable. Cuando se completan todos
los pasos anteriormente mencionados para todos y cada uno de los requerimientos se
obtiene una idea del porque los ingenieros de software manejan de forma extensa los
requerimientos individuales: son el acervo bsico ms importante de la profesin.
1.7 Dificultades para definir los requerimientos

Durante la etapa de especificacin de requerimientos se pueden presentar muchos
inconvenientes los cuales son importantes de identificar y prevenir, a continuacin se
presenta un listado con los problemas ms comunes en este proceso:
Los requerimientos no son obvios y vienen de muchas fuentes.
Son difciles de expresar en palabras (el lenguaje es ambiguo).
La cantidad de requerimientos en un proyecto puede ser difcil de manejar.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
El usuario no puede explicar lo que hace
Tiende a recordar lo excepcional y olvidar lo rutinario
Hablan de lo que no funciona
Los usuarios tienen distinto vocabulario que los desarrolladores.
Usan el mismo trmino con distinto significado


2. Interaccin con el cliente
Una de las actividades ms importantes que se realiza a la hora de hacer un anlisis de
requerimientos es la interaccin con el cliente, en este captulo tocaremos puntos importantes
que son necesarios para lograr tener xito en este punto.

2.1 Identificacin de interesados

Las personas que tienen intereses en los resultados del producto se llaman Interesados.
Como grupo constituyen el Cliente de la aplicacin. Para ilustrar considere la creacin de
un sitio de comercio electrnico en internet. Un conjunto de interesados consiste en los
visitantes as sitio: su requerimiento principal es la facilidad para encontrar y comprar los
artculos que necesitan. Los dueos de la compaa tambin son interesados, su
requerimiento ms importante puede ser la puede ser la ganancia a corto o largo plazo.
Por esta razn pueden querer que el sitio resalte los artculos con altos mrgenes. Los
administradores, otro grupo de interesados, tal vez requieran que la aplicacin de
seguimiento a los visitantes. Los desarrolladores de la aplicacin tambin son parte de los
interesados, quiz deseen usar la nueva tecnologa de desarrollo para seguir actualizados.
Por lo general los diseadores ponen mayor atencin en la aceptacin de la aplicacin por
el mayor nmero de usuarios posibles. Aunque este puede ser un problema de
mercadotecnia difcil, es claro que los usuarios son los interesados ms significativos. Sin
embargo en el desarrollo de proyectos grandes la identificacin de los interesados ms
significativos es compleja.
Es fcil que los interesados en conflicto den como resultado requerimientos
inconsistentes. Un ejemplo es el de dos grupos diferentes con motivaciones distintas
dentro de una compaa, que en apariencia quieren la misma aplicacin. La
consecuencia es que los requerimientos no son consistentes.
Los desarrolladores estn sujetos a las responsabilidades profesionales que pueden
afectar de manera profunda los requerimientos. Suponga, por ejemplo, que se pide a los
desarrolladores que construyan un software para un dispositivo medico con un
presupuesto fijo, pero ellos determinan que las caractersticas requeridas no pueden
aprobarse de manera adecuada dentro del presupuesto. A menos que este cambie,
tendran que eliminar requerimientos. Incluso cuando las vidas no estn en peligro, los
ingenieros de software tienen la responsabilidad social de crear productos que satisfagan
ampliamente sus requerimientos.
Un buen lder de proyecto supera estas dificultades, proceso que necesita aptitudes
gerenciales, personales, de negocio y polticas (Braunde, 2003).

2.2 Proceso de entrevista y documentacin.

Gran parte del anlisis de requerimientos es una actividad de persona a persona,
organizada con cuidado para producir la mejor aplicacin.
Lo primero es decidir a quin entrevistar. En lugar de intentar que se dedique el mismo
tiempo a todos, lo cual poder resultar en requerimientos contradictorios y esfuerzo
desperdiciado se recomienda seleccionar uno o quiz dos individuos principales,
entrevistarlos y despus solicitar comentarios de otros interesados clave.
Es preferible que haya dos entrevistadores en cada sesin, pues un entrevistador tpico
tiende a perder puntos. Traer una cinta de grabacin suele ayudar, pero debe pedirse
permiso de antemano. Aunque es importante escuchar con cuidado al cliente en las
entrevistas no se pueden obtener requerimientos con solo escuchar. En general el cliente
formula requerimientos conforme avanza y necesita ayuda.
Se hace hincapi en los casos de uso como manera efectiva de obtener requerimientos
para una amplia variedad de aplicaciones. Algunos requerimientos necesitan un diagrama,
para validar los requerimientos escritos el entrevistador les da seguimiento va correo
electrnico y convoca a una reunin si es necesario. Despus de la junta, se escribe un
borrador de los requerimientos C y en un formato como el estndar del IEEE, el borrador
se enva por correo electrnico a la comunidad de clientes para obtener sus comentarios,
y se realizan entrevistas sucesivas hasta que se logra la satisfaccin con los requerimientos
C.
Una manera de manejar las entrevistas
Antes de la entrevista:
1. Enumere y de prioridades a los clientes que se va a entrevistar
Para determinar el xito del proyecto
2. Programe una entrevista con tiempos de inicio y terminacin fijos
Deben ir al menos dos miembros del equipo de desarrollo
Preprese para grabar (si los entrevistados lo autorizan)
En la Entrevista:
3. Concntrese en escuchar
No sea pasivo: investigue y anime
Persista en entender deseos y explorar necesidades
Examines casos de uso; flujo de datos y/o diagramas de estado
Tome notas exhaustivas
4. Programe una reunin de seguimiento
Despus de la entrevista:
5. Bosqueje los requerimientos C del ERS usando un estndar
6. Envi correos electrnicos a los clientes para obtener sus comentarios


3. Descripcin de los requerimientos C
(o del cliente)
Uno de los grandes retos al que uno se enfrenta, es expresar con claridad lo que los
clientes desean y necesitan. Las palabras solas pueden ser apropiadas, pero para muchas
aplicaciones, el texto redactado necesita completarse con figuras de varios tipos.

3.1 Conceptos de operacin

Los clientes desarrollan una visin -con frecuencia inconsistente e incompleta- de cmo
debe operar su aplicacin. Esta visin en ocasiones se conoce como el modelo o concepto
de operacin de la aplicacin. Por ejemplo el modelo de operacin para un sistema puede
ser uno de los siguientes
Un sistema para convertir la informacin cruda del clima en forma grfica.
Un sistema de tiempo real para pronosticar el clima.
Una aplicacin para advertir a los usuarios acerca de las anomalas del clima.
Estos conceptos de operacin llevan a aplicaciones muy distintas. El administrador de
proyectos o ingeniero de requerimientos ayuda al cliente a aclarar su concepto de
operaciones.

3.2 Casos de uso

Con frecuencia los requerimientos se expresan de manera natural como una interaccin
entre la aplicacin y una agencia externa a ella, como el usuario. El caso de uso, es una
forma muy til de esas interacciones. Un caso de uso se identifica primero por su nombre
y por el tipo de usuario de la aplicacin, llamado actor. Consiste en una interaccin tpica
entre un actor y una aplicacin. Por ejemplo abrir un archivo sera un caso de uso tipo
para un procesador de palabras, con el usuario como actor y podra consistir en la
siguiente secuencia de pasos.
EL usuario selecciona el meno de Archivo.
El sistema despliega las opciones nuevo y abrir.
El usuario hace clic en abrir.
El sistema despliega la ventana de archivo.
El usuario introduce el directorio y el nombre de archivo.
El usuario oprime el botn abrir.
El sistema trae el archivo nombrado a la ventana del procesador de palabras.
Dado que los casos de usos son como
historias, son efectivos para producir
informacin a partir de los clientes, y
proporcionan un panorama excelente
de las aplicaciones, los casos de uso se
Figura 3.1 Ejemplo de un caso de uso de un cajero Automatico
pueden expresar en diferentes niveles de generalidad.
Es evidente que casos de uso similares no llevan a un gran valor adicional. Relativos entre
s, los casos de uso deben ser secuenciales u ortogonales. Dos casos de uso son
secuenciales si uno sigue directamente al otro. Los casos de uso ortogonales toman
puntos de vista u opciones opuestas.
3.3 Diagramas de flujo de datos para la comunicacin con el cliente

Suponga que el cliente intenta explicar el tipo de
aplicacin bancaria que desea, comenzando con el
depsito a una cuenta. Las funciones de depsito
pueden ser obtener el depsito del usuario y
verificar la transaccin del depsito para asegurar
que sea licita. Despus en la figura se resalta el tipo
de datos que fluye en estas funciones: nmero de
cuenta y cantidad del depsito. El usuario tambin
est involucrado y debe representarse. Una funcin
para crear el sumen de las cuentas, digamos,
requiere la entrada desde un almacn.
En la figura 3.2 se muestra un ejemplo de un
diagrama de flujo, es fcil notar como los usuarios
son representados por un rectngulo, los procesos
son encerrados en un crculo, los almacenes de datos en un rectngulo sin cerrar y el flujo
de la informacin con flechas, cada una de ellas con la direccin que debe de seguir la
informacin en caso de que se ejecute una determinada funcin. Cada flecha lleva escrito
los datos de salida que arroja el mtodo del cual proviene, los cuales servirn como datos
de entrada para el siguiente mtodo o incluso servirn de salida para un almacn de datos
o para el usuario final

3.4 Diagrama de transiciones de estado para la comunicacin con el
cliente

En ocasiones una aplicacin aparte de ellase interpreta mejor si se piensa en uno de
varios estados. EL estado de una aplicacin es su situacin o condiciones. Algunas veces
los estados se llaman etapas o fases. La idea es dividir la aplicacin en estados de
Figura 3.2 ejemplo de un diagrama de flujo
manera que siempre este junto en uno de ellos. Por ejemplo, en la figura 3.3 se muestra
un diagrama de estados para la cancelacin de un prstamo de un cliente a una
determinada compaa. Se puede observar los diferentes estados que este proceso tiene,
como solicitado que
procesa la solicitud, una
vez revisada pasa al
siguiente estado En
revision, donde el
proceso puede dividirse y
pasar a dos distintos
estados dependiendo si la
solicitud es aceptada o
rechazada, en el primer
caso la aplicacin
cambiaria su estado a
Autorizado la cual haria un deposito al cliente y se cambiaria al estado Entregado
donde si el monto es igual al adeudado la aplicacin pasa al ultimo estado de Pagado y
finalizaria, por otro lado su la revision es rechazada, la aplicacin pasaria al estado de
Cancelado y finalizaria seguidamente.
Despues de identificar los estados, se agregan las tarnsiciones de estado. Las transiciones
se denotan por flechas, cada una etiquetada con el nombre del evento que provoca que
las aplicaciones cambien de un estado a otro. Algunas veces cuando un objeto esta en un
estado dado y ocurre un evento, el objeto puede hacer una transicion de uno a varios
estados dependiendo de la condicion. Cabe destacar que en UML, las condiciones se
denotan por parentesis cuadrados.
3.5 Diseo preliminar de interfaces de usuarios y otras

El diseo de la interfaz de usuarios se incluye en la etapa de diseo del desarrollo del
software, pero tambin puede considerarse para la parte de la etapa de requerimientos,
es cuestin de preferencia.
En general los clientes comprenden una aplicacin al visualizar su (GUI, grafic user
interface), por lo que una buena manera de ayudar a describir la aplicacin es desarrollar
el diseo preliminar de la GUI. Al desarrollar las interfaces de usuario para las
aplicaciones, los afortunados tal vez trabajen con un diseador profesional, o al menos
obtengan la ayuda de uno, sin embargo para muchos proyectos, en especial los pequeos,
Figura 3.3 Ejemplo de diagrama de transicin de estados de un prstamo
los ingenieros de software deben disear por si mismos las interfaces de usuarios. As, se
enumeran algunas guas para ese diseo.
3.5.1 Pasos para desarrollar interfaces de usuario

En [Ga2], Galitz proporciona 11 pasos para desarrollar interfaces de usuario. El autor
adapto estos pasos como se muestra ms adelante. Cada uno de ellos se aplica al proceso
de requerimientos de cliente y/o en los procesos de requerimientos detallados.
Paso 1: conocer al usuario (C)
Paso 2: entender la funcin de negocios en cuestin (C)
Paso 3: aplicar los principios del buen diseado de pantallas (C, D)
Paso 4: Seleccionar el tipo adecuado de ventanas (C, D)
Paso 5: Desarrollar los mens del sistema (C, D)
Paso 6: seleccionar los controles adecuados basados en los dispositivos (C)
Paso 7: elegir los controles adecuados basados en las pantallas (C)
Paso 8: organizar y distribuir la pantalla (C, D)
Paso 9: elegir los colores adecuados (D)
Paso 10: crear iconos significativos (C, D)
Paso 11: proporcionar mensajes, retroalimentacin y gua efectivos (D)


Paso 1 (conocer al usuario). Este paso recomienda reconocer la naturaleza de los
usuarios posibles de la aplicacin. En general el usuario con menor nivel educativo,
capacitacin, aptitudes y motivacin requiere mayor sencillez, ms explicaciones y
ms ayuda. Tal vez tenga que hacer un trueque entre esto y la eficiencia y la
velocidad. Con frecuencia es deseable proporcionar varios niveles de interfaz de
usuario, dependiendo del nivel del mismo usuario.
Paso 2 (comprensin de la funcin de negocios). Este paso pide al diseador que
entienda el propsito de la interfaz de usuario y trminos del propsito global de
la aplicacin. Por ejemplo, si el propsito del negocio es el inventario en un
almacn, entonces tal vez se desee una interfaz de usuario para reflejar la
distribucin del rea del almacn. La secuencia de las pantallas que aparecen
pueden reflejar la manera normal en que los usuarios llevan a cabo sus tareas para
el negocio en cuestin.
Paso 3 (entender los principios del buen diseo de pantallas). La figura 3.4
enumera algunos elementos importantes del buen diseo de pantallas, la figura
incluye varios factores que con frecuencia se aplican al proceso de hacer una
interfaz atractiva. Aunque esto solo sirve para introducir el aspecto de efectos
visuales, de cualquier manera son tiles a este nivel.
Paso 4 (seleccionar el tipo adecuado de ventana). El propsito de cada interfaz de
usuario puede cumplirse con ms efectividad con uno o dos tipos especficos de
ventanas, las figuras 3.5 y 3.6 enumeran cinco propsitos de las GUI y un tipo de
ventana que satisface cada uno. Los tipos de ventanas emplean la terminologa de
Windows, pero son tpicos.
Paso 5 (desarrollar mens del sistema). Algunas reglas para la creacin de los
mens principales, proporcionadas por Galitz, se muestran en el cuadro 3.2. Los
usuarios requieren un ancla estable y comprensible para las aplicaciones. Esto
puede proporcionarse con el men principal constante. En general, el nmero de
opciones en este men debe ser entre cinco y nueve, ya que la mayora nos
sentimos a gusto con esta cantidad.
Proporcionar un men
Desplegar todas las alternativas relevantes (y slo stas)
Amoldar la estructura del men con la estructura de la tarea de la aplicacin
Minimizar el nmero de niveles del men

Cuadro 3.2 Algunas reglas para la creacin de los mens principales, proporcionadas
por Galitz

Paso 6 (seleccionar los controles basados en dispositivos adecuados). Los
controles basados en los dispositivos son los medios fsicos por los que el usuario
comunican sus deseos respecto a la aplicacin. Incluyen joystick, trackballs,
tabletas de grfica, pantalla de contacto, ratones, micrfonos, teclados.
Paso 7 (seleccionar los controles en la pantalla adecuados). Los controles
basados en la pantalla son smbolos que aparecen en el monitor, mediante los
cuales el usuario notifica a la aplicacin de su entrada o intencin. Estos incluye
iconos, botones, cajas de texto, botones de seleccin y cuadros de activacin.
Paso 8 (organizar y distribuir ventanas). Las reglas para colocar ventanas multiples
son las mismas que para colocar una ventana individual (que incluyen simetra,
proporcin, etctera)
Paso 9 (elegir los colores adecuados). Cuando se usa con aptitud y buen gusto el
color puede resaltar las pantallas. Sin embargo, los colores no hacen, de manera
automtica que la interfaz de usuario sea ms til o atractiva y es fcil que la
empeoren.


4. Requerimientos D.
Los Requerimientos D son una lista completa de las propiedades especficas y la funcionalidad que
debe tener la aplicacin, expresada con todo detalle. Cada uno de estos requerimientos de
numera, etiqueta y rastrea durante toda la implantacin. Son consistentes con, y son una
refinamientos de los requerimientos C.
En esencia se supone que los desarrolladores leern los requerimientos D. los clientes tambin
interesados en ellos y casi siempre pueden comprender y comentar muchos de ellos. Recuerde
que la audiencia principal de los Requerimientos C son los clientes.
4.1 Tipos de Requerimientos D

Requerimientos Funcionales: especifica los servicios que debe proporcionar la aplicacin,
por ejemplo: la aplicacin debe calcular el valor del portafolio de inversin del usuario.
Por otro lado, un requerimiento como la aplicacin debe terminar el clculo del valor de
cada portafolio en menos de un segundo eso no es un requerimiento funcional
Requerimientos no funcionales: requerimientos de desempeo; Los requerimientos de
desempeo especifican las restricciones de tiempo que debe observar la aplicacin. Los
clientes y desarrolladores negocian las restricciones del tiempo transcurrido para los
clculos, el uso de RAM, el almacenamiento secundario, etc. Ejemplo: para cualquiera
viga el analizador de tensin debe producir un informe del tipo cinco en menos de un
minuto.
Requerimientos no funcionales: Confiabilidad y disponibilidad; Especifican la confiabilidad
en trminos cuantificados, por ejemplo: la aplicacin de radar del aeropuerto (ARA) debe
experimentar no ms de dos fallas de nivel uno por mes. La disponibilidad tiene una
estrecha relacin con la confiabilidad, cuantifica el grado en el que la aplicacin debe estar
disponible para los usuarios, por ejemplo: ARA debe estar disponible a nivel uno o dos en
la computadora primaria o en la de respaldo en todo momento. ARA podr estar no
disponible en una de estas computadoras a nivel uno o dos, no ms de 2% del tiempo en
cualquier periodo de 30 das.
Requerimientos no funcionales: manejo de errores; esta categora explica cmo debe
responder la aplicacin a los errores en su entorno. Por ejemplo, Qu debe hacer la
aplicacin si recibe un mensaje de otra que no est en el formato que se acord? Estos no
son errores generados por la aplicacin.
Requerimientos no funcionales: Requerimientos de interfaz; Describen el formato con el
que la aplicacin se comunica con su entorno. Por ejemplo: el costo de enviar el artculo
de una fuente a un destino debe desplegarse en todo momento en el cuadro de costo.
Requerimiento no funcionales: Restricciones; Las restricciones de diseo o implantacin
describen los limites o condiciones para disear o implementar la aplicacin. Estos
Requerimientos no pretenden sustituir el proceso de diseo, solo especifican las
condiciones que el cliente impone el proyecto, el entorno u otras circunstancias, e
incluyen la exactitud, por ejemplo: los clculos de daos de la Automobile Impact Facility
(AEF) deben tener una exactitud de un centmetro.
Requerimientos Inversos: Los requerimientos inversos establecen que no debe hacer el
software, es lgico que haya un nmero infinito de requerimientos inversos: se
seleccionan los que aclaran los requerimientos verdadero y los que eliminan posibles
malos entendidos, Por ejemplo: no que requiere que AEF analice los datos de choque.

5. Propiedades Deseadas de los
Requerimientos D
5.1 Rastreabilidad

Capacidad de hacer corresponder (mapear) cada requerimiento con sus partes relevantes del
diseo e implementacin.
Rastreo de Requerimientos Funcionales:

Se Desea que cada requerimiento D sea rastreable hacia adelante y hacia atrs. Por rastreabilidad
hacia delante de los requerimientos D se refiere a la implementacin. La rastreabilidad hacia
atrs significa que el requerimiento es una consecuencia clara de uno o ms requerimientos C. Por
ejemplo, el requerimiento D, los personajes extraos deben moverse de una rea a otra en
intervalos de 5 segundos en promedio.
Se puede rastrear el siguiente requerimiento C, el resto (de los personajes), llamados personajes
(extraos) deben estar bajo el control de la aplicacin
La rastreabilidad hacia atrs es una base para la inspeccin de los requerimientos D.

Rastro de Requerimientos No Funcionales:
Una meta de la etapa de diseo es aislar cada requerimiento no funcional en un elemento de
diseo separado. En el caso de los requerimientos de desempeo se intenta aislar las unidades de
procesamiento ms lentas. Cada Funcin que afecta a los requerimientos de desempeo se
acompaa por los comentarios no funcionales que se pueden inspeccionar. De preferencia, estos
requerimientos son cuantitativos, como debe terminar en menos de un milisegundo en el peor
caso. De manera similar, al especificar las restricciones de almacenamiento se identifican las
funciones que generan el mayor almacenamiento.
As que para validar los requerimientos no funcionales cada uno se liga a un plan de pruebas, de
preferencia en el momento de escribir el requerimiento.

5.2 Comprobacin y no ambigedad

Debe ser posible validar un requerimiento cuando se prueba que se ha implementado de manera
apropiada. Los requerimientos que se pueden probar se llaman comprobables. Los
requerimientos no comprobables tienen poco valor practico.
5.3 Prioridad

Este proceso de realiza de manera planeada. Una tcnica es asignar prioridades a los
requerimientos especficos, jerarquizar todos los requerimientos casi siempre es una prdida de
tiempo; en su lugar, muchas organizaciones clasificar los requerimientos en tres categoras. Se
llamaran esenciales, deseables y opcionales. El proyecto deber incluir los requerimientos
esenciales.
Asignar prioridades a los requerimientos tiene impacto en el diseo en el diseo porque con
frecuencia los requerimientos deseables y opcionales indican hacia donde se dirige la aplicacin.

5.4 Completos

Se hace un esfuerzo para que cada requerimiento detallado sea auto contenido pero pocas veces
es posible en la prctica, donde los requerimientos con frecuencia se refieren a otros
requerimientos. Que un conjunto de requerimientos est completo asegura que no hay omisiones
que comprometan los requerimientos establecidos.
Con respecto al ejemplo anterior del juego, una buena manera de revisar e inventario actual de los
requerimientos es revisarlo mediante los casos de uso.
Se establecen las cualidades del personaje del jugador en el rea de vestidores. Se
puede confirmar que toda la funcionalidad requerida este presente para
especificarlas y que todos los datos e imgenes requeridos tambin estn
presentes
Se mueve el personaje a un area adyacente. Se verifica que toda la funcionalidad
requerida para hacerlo este presente.
Se encuentra un personaje extrao. Se asegura que se dan todos los detalles.

5.5 Condiciones de error

Para cada requerimiento se pregunta qu pasara si ocurriera en las circunstancias equivocadas.
Una falta de condiciones de error en las especificaciones de los requerimientos resalta de manera
especial cuando se prueba la funcin, ya que quien realiza la prueba fuerza las condiciones de
error y debe saber que salida del requerimiento se espera.
Se recomienda imponer la captura de datos incorrectos en muchos puntos posibles, si no en
todos, esta es una prctica equivalente a una muy antigua en ingeniera, donde se acostumbra la
redundancia con el fin de promover la seguridad.

5.6 Consistencia

Un conjunto de requerimientos D es consistente si no hay contradicciones entre ellos, cuando el
nmero de requerimientos D crece, la consistencia se puede volver algo difcil de lograr.
La organizacin orientada a objetos de los requerimientos ayuda a evitar inconsistencias mediante
la agrupacin de los requerimientos D de clases, como el caso de estudio, y con su descomposicin
en formas muy sencillas. Sin embargo, esto no es una garanta de consistencia y por ello las
inspecciones de los requerimientos la verifican junto con las otras cualidades mencionadas.

5.7 Resumen del proceso de escribir un requerimiento detallado

Evaluar si un requerimiento es rastreable o no significa imaginar un diseo para la
aplicacin e imaginar cmo tendra el diseo que satisfacer los requerimientos, esta es la
forma ms sencilla si el requerimiento corresponde directamente a un mtodo.
Ayuda a delinear una prueba para un requerimiento al mismo tiempo que se escribe. Esto
no solo aclara los requerimientos, tambin establece si se puede probar.
Muchos requerimientos depende de datos especficos y es necesario indicar como debe
operar el requerimiento en caso de que el dato est equivocado o sea inconsistente. Para
requerimientos crticos, esto debe incluir errores debidos a un diseo malo o a la
programacin (los requerimientos de rutina pueden no ser responsables de un diseo o
una programacin defectuosos de la aplicacin.) Por ejemplo, un requerimiento
aceptable: cuando se presiona el botn de inicio, el rayo X de alta densidad debe
encenderse si los parmetros satisfacen las siguientes condiciones. Por otra lado, un
requerimiento no aceptable: las posiciones deben desplegarse siempre y cuando ningn
jugador haya movido dos veces ms que algn otro jugador.

6. Organizacin de los Requerimientos D
Dentro de las los imprevistos que se pueden presentar sino se maneja una adecuada organizacin
de los requerimientos D, se vuelve inmanejable cuando crece:
1. Su propio tamao hace difcil de entenderla como un evento unitario antes de que crezca
a cientos, si no a miles
2. Los requerimientos son de tipo mixtos: por ejemplo, los requerimientos de desempeo
deben de tratarse de manera diferente de los requerimientos de comportamiento.
3. Algunos requerimientos van junto a otras relaciones de manera natural.
4. Es difcil localizar un requerimiento especfico.
6.1 Organizacin de requerimientos por clase

La atencin se centra en un estilo orientado a objetos para organizar los requerimientos, donde
primero se identifica una clasificacin --- el equivalente a seleccionar las clases--- y despus se
colocan los requerimientos individuales en las categoras o clases obtenidas.
Existen dos enfoques para hacerlo. Uno ve las clases como una herramienta para organizar los
requerimientos, pero no necesariamente considera que se pueden usar para el diseo real. Otro
enfoque, que sigue el caso de estudio, usa las clases desarrolladas para los requerimientos en el
diseo (y la implementacin orientada a objetos reales). Este ltimo enfoque fomenta una
rastreabilidad uno a uno de los requerimientos D a los mtodos donde cada requerimiento D
funcional debe corresponder a una funcin en el lenguaje que se usa.
Una desventaja de este mtodo es el riesgo de cambiar ms adelante las clases usadas, con lo que
se destruye la correspondencia entre los requerimientos y la seleccin de clases.

6.2 Identificacin de clases

Las clases que se usaran como principio de organizacin se identifican con cuidado y de forma
conservadora. Para esto se identifica las clases de dominio de la aplicacin, es decir, las que
pertenecen a la aplicacin. Por ejemplo, el dominio de una aplicacin que simula un banco puede
contener las clases cliente Banco y Cajero pero no Archivo o Base Datos tampoco Cliente o
Transaccin. Los ltimos no son especiales para la aplicacin en cuestin. El uso de clases de
dominio es una manera de organizar, reflexionar y rastrear los requerimientos.

6.3 Mtodos para organizar los requerimientos especficos
Los requerimientos D se pueden organizar de acuerdo con varios esquemas, entre ellos:
1. Por Caracterstica (servicio deseado percibido en el exterior, casi siempre se definen por
los pares estimulo-respuesta).
Esta organizacin que se conoce como requerimientos; a saber, los requerimientos se
agrupan segn las caractersticas observables de la aplicacin.
2. Por Modo (por ejemplo, los sistemas de radar tienen modos de capacitacin, normal y
emergencia.)
3. Por caso de uso (en ocasiones llamada por escenario). Esta organizacin, preferida por el
USDP, se explica despus con ms detalle, la idea es que la mayora de los requerimientos
detallados son parte de un caso de uso.
4. Por clase. Este es un estilo orientado a objetos que se explica ampliamente ms adelante.
En esta organizacin los requerimientos se agrupan en clases. Esta manera de organizar
los requerimientos se usa en el caso de estudio.
5. Por jerarqua de funcin(es decir, descomponiendo la aplicacin en un conjunto de
funciones de alto nivel y, despus, estas en sub-funciones etc.) por ejemplo, los
requerimientos para un programa de presupuestos domestico se pueden descomponer en
chequeras, conciliacin e informes, etc. Esta es una manera tradicional de poner en orden
los requerimientos detallados.
6. Por estado (indicando los requerimientos especficos aplicados a cada estado). Por
ejemplo, la mejor forma de clasificar los requerimientos para una aplicacin que controla
un proceso qumico puede ser por los estados en los que el proceso se puede encontrar
(inicio, reaccin, enfriamiento, entre otros).

6.4 Clasificacin de Entidades

Corresponde a las aplicaciones que requieren la existencia de entidades (instancias u objetos, al
contrario de clases) especificas. Una desventaja de este enfoque es que quiz cambie la decisin
acerca de que objeto crea el objeto requerido y por ello los requerimientos tendran que moverse.
Tambin debe observarse que otros objetos, aunque no crean el objeto requerido, pueden hacer
referencia al ms a menudo que el objeto creador.

7. Calidad los requerimientos especficos
Hoy en da entre ms claros, precisos y concisos sean los requerimientos puede marcar la
diferencia entre el xito del desarrollo de los software, bebido a que la realidad nos sigue
diciendo que uno de los principales motivos del fracaso de los proyectos est en los
requisitos (inadecuados, incompletos, etc.).
Hay que tener muy claro que no especificar los requerimientos detalladamente puede
traer consecuencias muy desastrosas, por lo que se debe intentar clasificar la calidad de
los requerimientos de la manera ms cuantitativa posible.
7.1 Intervencin del aseguramiento de la calidad (QA) en el anlisis de los
requerimientos D

La organizacin de aseguramiento de calidad revisa los requerimientos, por lo tanto creo
un estndar el (730-1995) que establece:
Que se debe identificar o hacer referencia a las prcticas estndares, convenciones y
mtricas que se usarn durante la etapa de requerimientos. Menciona los estndares con
los pasos a seguir y rastreabilidad de los requerimientos deben cumplir. Se utilizan
lenguajes formales para establecer requerimientos, en la medida de lo posible. Debe
preverse un esquema que identifique de manera nica cada requerimiento.
En las organizaciones grandes suele seguirse guas como estas, el problema est en las
pequeas o de mediano tamao donde muchas introducen el aseguramiento de calidad,
solo despus determinado los requerimientos. Algunas veces se pide QA despus de todos
los hechos para verificar que esto se haya construido conformes a las especificaciones.
Las quejas tpicas de QA son que no existen requerimientos adecuados en contra los
cuales verificar la aplicacin.

7.2 Mtricas para el anlisis de requerimientos D

Cuando se utiliza mtricas de forma selectiva se maximiza la inversin en inspeccin al
enfocarse el proceso de inspeccin en resultados tiles y cuantificados. Hay que tener en
cuenta que cada mtrica proporciona beneficios pero cuesta dinero y tiempo para
recolectar, almacenar, analizar e informar. La razn de aplicar mtricas es por optimizar la
razn costo/beneficio. Esta depende de la cultura de la organizacin, el estado del
proyecto, la naturaleza del mismo, etc. Cuando se recolecta mtricas hay que tener el
cuidado que sea realmente til para la empresa y no solo porque en un futuro se pueden
utilizar siendo una prctica dudosa. Debido a que esto puede generar habitaciones llenas
de mtricas sin ningn uso ya que se almacenaron pensando en que iban a ser tiles pero
no fue as, adems que no se especific cul sera su utilidad.
La siguiente lista de mtricas de aseguramientos de la calidad incluye las mtricas del
anlisis de requerimientos en el estndar IEEE (982.2-1998):
Medidas de qu tambin escrito estn los requerimientos
Porcentaje de requerimientos especficos no ambiguos (IEEE mtrica 6)
Grado en que est completo (IEEE mtrica 23 y 35)
Porcentaje de requerimientos D mal clasificados (en el estilo orientado a
objetos esto mide el porcentaje asignado a la clase equivocada)
Porcentajes de requerimientos especficos que no son
Comprobables
Rastreables (IEEE mtrica 7)
Con prioridades
Atmico (indivisibles en partes pequeas)
Consistente con el resto de requerimientos (IEEE mtrica 12 y 13)
Medidas de efectividad de la inspeccin de requerimientos
Porcentajes de requerimientos faltantes o defectuosos encontrados por hora
de inspeccin
Medidas de efectividad del proceso de anlisis de requerimientos
Costo por requerimientos D
Costos brutos (tiempo total dedicado / nmero de requerimientos D)
Costo marginal (costo de obtener uno ms)
Tasa a la que los requerimientos especficos se
Modifican
Eliminan
Agregan
Medidas del grado en que un requerimientos est completo
Esto se puede estimar, despus del fin oficial de la recoleccin de los
requerimientos D, a partir de la tasa a la que los requerimientos especficos
se
Modifican
Agregan

7.3 Inspeccin del anlisis de requerimientos D

La inspeccin tambin es conocida como revisin tcnica formal, y es el punto de vista
ms efectivo desde el punto de vista de aseguramiento de calidad, y es dirigida por los
ingenieros de software u otras personas. Para los ingenieros la inspeccin es un medio
efectivo para descubrir errores y mejorar la calidad del software
Los requerimiento especficos (o requerimientos D) constituyen los primeros de software
que se puede inspeccionar contra los documentos anteriores (requerimientos C). Los
inspectores se preparan para la inspeccin leyendo de nuevo los requerimientos C y
comparndolos los requerimientos especficos de ellos.

8. Uso de herramientas e internet para el
anlisis de requerimientos.
El uso de herramientas permiten ayudar al proceso de captura y administrar los
requerimientos; por ejemplo, ordenado, asignado prioridades y rastreando. Unos de los
beneficios de esta herramienta es saber quin trabaja en qu requerimiento y cundo,
adems puede permitir el arrastre de las caractersticas, es decir el proceso mediante el
cual las caractersticas que no son necesarias se agregan a la aplicacin. Con las
herramientas adecuadas es ms fcil para un lder de proyectos evaluar el estado del
anlisis de requerimientos. De este modo se puede saber qu porcentaje de los
requerimientos D esenciales se han implementado y que QA ha probado por completo.
Por ejemplo la siguiente tabla:

9. Mtodos formales para especificaciones
de requerimientos
9.1 Introduccin a las especificaciones formales

Las matemticas son buenas para expresa el estado; en otras palabras, lo que es. Esto
difiere de los procedimientos y algoritmos para el cmo. Dado que las especificaciones
de los requerimientos en su mayor parte describen el estado de la aplicacin antes y
despus de la acciones, la notacin matemtica puede ser ms adecuada que el lenguaje
natural para especificar los requerimientos detallados.

9.2 Cundo debe usarse especificacin formal?

La mejor forma de comunicar los requerimientos es la efectividad, siendo la mejor prueba
para cundo usar requerimientos formales e informales, la mayor parte del tiempo es
mejor expresar los requerimientos en un lenguaje natural y algunas veces es preferible
hacerlo mediante una especificacin formal. Las especificaciones formales se requieren
para implementar las especificaciones ejecutables. Estas especificaciones se pueden
traducir de manera automtica en cdigo objeto, por tanto es necesario que sean
precisas.


9.3 Precondiciones y poscondiciones

Estas son descripciones del estado requerido de la aplicacin antes y despus de un
clculo. En general, las precondiciones y pos condiciones usan seudocdigo, al igual que
partes del lenguaje de implementacin (java, c++, etc.), en lugar de solo matemtica.
Precondicin: Relacin lgica que deben de cumplir los valores de entrada para que la
operacin se pueda aplicar con garantas de producir una ejecucin correcta.
Poscondicin: Relacin lgica que se cumple con los valores de salida despus de ejecutar
la operacin, siempre que se cumpliera la precondicin.
Bibliografa
Braunde. (2003). Ingenera de sotfware, una perspectiva orientada a objetos. Mexico D.F:
Alfaomega.
IEEE - 830. (14 de Marzo de 2000). Facultad de Informtica Universidad Complutense de Madrid.
Recuperado el 15 de Abril de 2012, de
http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
J., L. J. (7 de Diciembre de 2011). Monografias. Recuperado el Abril de A de 2012, de 20
Pressman, R. S. (2002). Ingeniera del software, un enfoque practico. Mexico, DF: Mcgraw-Hill
Interamericana editores, S.A de C.V.
Senn, J. A. (1992). Anlisis y diseo de sistemas de informacin. Mexico.
Universidad de Granada, DECSAI. (2008). Especificacion de requerimientos. Granada, Espaa.
Wikipedia. (10 de Marzo de 2012). Wikipedia. Recuperado el 15 de Abril de 2012, de
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos