Especificacion Del Sistema PDF

Universidad Nacional de Jujuy-Facultad de Ingeniera
Sistemas de Informacin- Sistemas de Informacin I

UNIDAD 4
ESPECIFICACION DEL SISTEMA
Introduccin
Lo ms difcil en la construccin de un sistema software es decidir precisamente qu construir, no
existe tarea con mayor capacidad de lesionar al sistema cuando se hace mal. Ninguna otra tarea es tan
difcil de rectificar a posteriori (F.P. Brooks, 1987)
Continuamente se publican nuevos datos acerca de la importancia de los requisitos en Ingeniera
1
del Software, por ejemplo segn el Chaos Report del Standish Group , resulta que:
El gasto anual en proyectos software en EEUU es de unos 250 billones de dlares,
invertidos en aproximadamente unos 175000 proyectos
31.1% sern cancelados
52.7% costar un 190% ms de lo estimado
Un 16.2% ser finalizado a tiempo y dentro del presupuesto pero el producto final poseer
(aprox.) la mitad de los requisitos iniciales
Estudios anteriores a ste reflejan:
El 45% de los errores tienen su origen en los requisitos y en el diseo preliminar
El 56% de los errores que tienen lugar en un proyecto software se deben a una maa
especificacin de requisitos
Segn el Chaos Report los factores principales que conducen al fracaso en los proyectos
software son:
Falta de comunicacin con los usuarios
Requisitos incompletos
Cambios a los requisitos
Por otra parte la evidencia demuestra que:
Los requisitos contienen demasiados errores
Muchos de estos errores no se detectan al principio
Muchos de estos errores podran ser detectados al principio
No detectar errores incrementa los costos (tiempo y dinero) de forma exponencial
Y esto trae como consecuencia que:
El sistema resultante no satisface a los usuarios
Se producirn desacuerdos entre usuarios y desarrolladores
Puede ser imposible demostrar si el software cumple o no los requisitos
Se gastar tiempo y dinero en construir el sistema equivocado
Ante esta situacin qu se puede hacer? En primer lugar, se debe tomar conciencia del problema,
quiz no se conozcan todas las soluciones, pero al menos se conocen los problemas. Quiz no sea posible
elaborar los requisitos con absoluta perfeccin, pero se debiera intentar minimizar el impacto de los errores
en los requisitos y se podra tratar de organizar mejor las tareas relacionadas con los requisitos. Los
requisitos se sitan en la frontera socio-tcnica de los sistemas, y esa frontera es borrosa, e inconsistente.
Segn M. Jackson los requisitos son: donde lo formal se encuentra con lo informal. Los requisitos estn
vivos, emergen, interactan, cambian, desaparecen
www.standishgroup.com/chaos.html
Prof. Lic. Anala N. Herrera Cognetta-JTP Ing. Laura R.Villarrubia-JTP Ing. La Rico
Ingeniera de Requisitos
Para remediar en lo posible esta situacin, surge la Ingeniera de Requisitos (IR).
La IR trata de los principios, mtodos, tcnicas y herramientas que permiten descubrir, documentar
y mantener los requisitos para sistemas basados en computadora, de forma sistemtica y repetible.
La ingeniera de requisitos del software es un proceso de descubrimiento, refinamiento, modelado
y especificacin. Se refinan en detalle los requisitos del sistema y el papel asignado al software. Se crean
modelos de los requisitos de datos, flujo de informacin y control, y del comportamiento operativo. Se
analizan soluciones alternativas y el modelo completo del anlisis es creado. Donald Reifer describe el
proceso de ingeniera de requisitos del software en el siguiente prrafo:
La ingeniera de requisitos es el uso sistemtico de procedimientos, tcnicas, lenguajes y
herramientas para obtener con un coste reducido el anlisis, documentacin, evolucin continua de las
necesidades del usuario y la especificacin del comportamiento externo de un sistema que satisfaga las
necesidades del usuario. Todas las disciplinas de la ingeniera son semejantes, la ingeniera de requisitos no
se gua por conductas espordicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso
sistemtico de aproximaciones contrastadas.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniera de requisitos del
software. El cliente intenta replantear un sistema confuso, a nivel de descripcin de datos, funciones y
comportamiento, en detalles concretos. El desarrollador acta como un interrogador, como consultor, como
persona que resuelve problemas y como negociador.
Qu es?
El papel global del software en un gran sistema es identificado durante la ingeniera del sistema.
De cualquier manera, es necesario considerar una visin lo ms profunda posible del papel del software,
para comprender los requisitos especficos que deben ser considerados en la construccin de un software
de alta calidad. Este es el trabajo del anlisis de requisitos del software. Para realizar el trabajo
adecuadamente, se deben seguir un conjunto de conceptos y principios fundamentales.
Quin lo hace?
Generalmente, el ingeniero del software es quin realiza el anlisis de requisitos. En cualquier
caso, para aplicaciones de negocio complejas, un analista de sistemas formado en los aspectos del
negocio del dominio de la aplicacin puede realizar esta tarea.
Por qu es importante?
Si no se analiza, es muy probable que se construya una solucin software muy elegante que
resuelva incorrectamente el problema. El resultado es tiempo y dinero perdido, frustracin personal y clientes
descontentos.
Cules son los pasos?
Los requisitos de datos, funciones y comportamiento son identificados por la obtencin de
informacin facilitada por el cliente. Los requisitos son refinados y analizados para verificar su claridad,
completitud y consistencia. La especificacin se incorpora al modelo del software y es validada tanto por el
ingeniero del software como por los clientes/usuarios.
Cul es el producto obtenido?
Una representacin efectiva del software debe ser producida como una consecuencia del anlisis
de requisitos. Tanto los requisitos del sistema como los requisitos del software pueden ser representados
utilizando un prototipo, una especificacin o un modelo simblico.
Cmo puedo estar seguro de que lo he hecho correctamente?
El resultado obtenido del anlisis de requisitos del software debe ser revisado para conseguir:
claridad, completitud y consistencia.
Requisitos
Se considerar que un problema sw consiste en configurar una mquina M para que ejerza unos efectos R
en un dominio D
La mquina M es la que realizar los requisitos R gracias a su conexin con D. En la fase de requisitos solo
necesitamos describir las conexiones de M con D, es decir el comportamiento externo de M (M-ex), sin
detalles internos (M-int).
En IR se denominan requisitos a los tres conjuntos M-ex, R y D, la razn es que los requisitos estn
constituidos por toda aquella informacin que sirva para construir un sistema que satisfaga las metas
perseguidas.
Ejemplo
Este ejemplo est basado en un caso real, y demuestra que los Requisitos (metas, deseos), no son
suficientes si no se encuentran basados en un contexto:
Se trata de especificar un software para un sistema de avin. En estos sistemas hay un requisito que
establece, que la marcha atrs slo puede ser habilitada s y solo s el avin se encuentra en la pista. Es
decir:
R: marcha_atras-habilitada
avin_en_pista
Para detectar si el avin se encuentra o no en pista, existen unos sensores conectados a las ruedas, que
generan pulsos elctricos, cuando las ruedas estn girando. Para que este mecanismo funcione, se supone
que en el dominio que rodea al software (o sea, en el mundo real) se cumple que las ruedas rotan cuando
se encuentran en pista y que se envan los pulsos cuando las ruedas rotan
D1: pulsos_sensor
ruedas_rotando
D2: ruedas_rotando
avin_en_pista
Las dos afirmaciones no son requisitos, sino descripciones.
Finalmente, la descripcin del comportamiento externo de la mquina M (en realidad el comportamiento
externo del software, M-ex), establecera que
M-ex: marcha_atras_habilitada
pulsos_sensor
Puede comprobarse que dado el comportamiento externo de la Mquina M-ex y dadas las descripciones D,
se cumple R.
La importancia del conocimiento del dominio D, es crucial en la IR. Si se diera el caso (como sucedi en la
realidad) que la pista estuviese mojada (aquaplaning) y por lo tanto las ruedas dejaran de rotar, deja de
cumplirse D2, las ruedas no rotan a pesar de que el avin est en la pista. Por lo tanto, un pequeo cambio
en el Dominio, pese a no hallarse aparentemente conectado con el software, puede conducir a una situacin
en la que R no se cumple.
En IR se denominan requisitos a los tres conjuntos R, M-ex y D. La razn es que los requisitos estn
constituidos por toda la informacin necesaria para construir un sistema que satisfaga las metas
perseguidas.
Los requisitos no son anlisis top-down, ni son la arquitectura del sistema, ni son el qu frente al cmo.
Determinacin e Identificacin de requisitos

El anlisis y la especificacin de los requisitos puede parecer una tarea relativamente sencilla, pero
las apariencias engaan. Abundan las ocasiones para las malas interpretaciones o falta de informacin. Es
muy probable que haya ambigedad. El dilema al que se enfrenta el ingeniero del software puede
entenderse muy bien repitiendo la famosa frase de un cliente annimo: S que cree que entendi lo que
piensa que dije, pero no estoy seguro de que se d cuenta de que lo que escuch no es lo que yo quise
decir.
El anlisis de los requisitos es una tarea de ingeniera del software que cubre el hueco entre la
definicin del software a nivel sistema y el diseo del software
El anlisis de requisitos permite al ingeniero de sistemas especificar las caractersticas
operacionales del software (funcin, datos y rendimientos), indica la interfaz del software con otros
elementos del sistema y establece las restricciones que debe cumplir el software.
El anlisis de requisitos del software puede dividirse en cinco reas de esfuerzo:
(1) reconocimiento del problema
(2) evaluacin y sntesis
(3) modelado
(4) especificacin
(5) revisin.
Inicialmente, el analista estudia la Especificacin del Sistema (si existe alguna) y el Plan del
Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el mbito
del software que se emple para generar las estimaciones de la planificacin. A continuacin, se debe
establecer la comunicacin para el anlisis de manera que nos garantice un correcto reconocimiento del
problema. El objetivo del analista es el reconocimiento de los elementos bsicos del problema tal y como los
percibe el cliente/usuario.
La evaluacin del problema y la sntesis de la solucin es la siguiente rea principal de esfuerzo en
el anlisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y
contenido de la informacin, definir y elaborar todas las funciones del software, entender el comportamiento
del software en el contexto de acontecimientos que afectan al sistema, establecer las caractersticas de la
interfaz del sistema y descubrir restricciones adicionales del diseo. Cada una de estas tareas sirve para
describir el problema de manera que se pueda sintetizar un enfoque o solucin global.
Por ejemplo, un mayorista de repuestos de automviles necesita un sistema de control de
inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son:
(1) incapacidad de obtener rpidamente el estado de un componente
(2) dos o tres das de media para actualizar un archivo a base de tarjetas;
(3) mltiples rdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a
los vendedores con los componentes.
Una vez que se han identificado los problemas, el analista determina qu informacin va a producir
el nuevo sistema y qu informacin se le proporcionar al sistema. Por ejemplo, el cliente desea un informe
diario que indique qu piezas se han tomado del inventario y cuntas piezas similares quedan. El cliente
indica que los encargados del inventario registrarn el nmero de identificacin de cada pieza cuando salga
del inventario.
Universidad Nacional de Jujuy-Facultad

Facultad de Ingeniera
Sistemas de Informacin
Informacin- Sistemas de Informacin I
Una vez evaluados los problemas actuales y la informacin deseada (entrada y salida), el analista
empieza a sintetizar una o ms soluciones. Para empezar, se definen en detalle los datos, las funciones de
tratamiento y el comportamiento del sistema.
Una vez que se ha establecido esta informacin, se consideran las arquitecturas bsicas para la
implementacin. Un enfoque cliente/servidor parecera apropiada, pero est dentro del mbito esbozado en
el Plan del Software'? Parece que sera necesario un sistema
sistema de gestin de bases de datos, pero, est
justificada la necesidad de asociacin del usuario/cliente? El proceso de evaluacin y sntesis contina hasta
que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el
software para posteriores fases de desarrollo.
A lo largo de la evaluacin y sntesis de la solucin, el enfoque primario del analista est en el
qu y no en el cmo. Qu datos produce y consume el sistema, qu funciones debe realizar el
sistema, qu
interfaces se definen y qu restricciones son aplicables?
Durante la actividad de evaluacin y sntesis de la solucin, el analista crea modelos del sistema
en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento
c
operativo y el contenido de la informacin. El modelo sirve como fundamento para el diseo del software y
como base para la creacin de una especificacin del software.
El Proceso de los Requisitos
El proceso de Ingenieria de Requisitos es un conjunto estructurado de actividades que sirven para
derivar, validar y mantener los requisitos de un sistema (hardware, software o hardware + software). Las
tareas que conlleva este proceso, a grandes rasgos, se representan en el sig
siguiente
uiente grfico:
Prof. Lic. Anala N. Herrera Cognetta-JTP

Cognetta
Ing. Laura R.Villarrubia-JTP
JTP Ing. La Rico
Los cuadros redondeados son tareas. Los cuadros son productos (inputs o outputs). La
separacin que se muestra es ms conceptual que real ya que las tareas que se ejecutan durante el proceso
de requisitos suceden en paralelo y se solapan unas con otras. Por ejemplo durante el proceso de Educcin
de Requisitos empleando prototipado, es inevitable realizar una pequea validacin de los requisitos que se
van obteniendo, o incluso una pequea negociacin, si por ejemplo estamos tratando con varios usuarios a
la vez.
IDENTIFICACIN DE REQUISITOS PARA EL SOFTWARE

Antes que los requisitos puedan ser analizados, modelados o especificados, deben ser recogidos a
travs de un proceso de obtencin. La educcin de requisitos se refiere a la captura y descubrimiento de los
requisitos. Es una actividad ms humana que tcnica, en la que se identifica a los interesados y se
establecen las primeras relaciones entre ellos y el equipo de desarrollo: Un cliente tiene un problema que
pretende sea resuelto con una solucin basada en computadora. Un desarrollador responde a la solicitud de
ayuda del cliente. La comunicacin ha empezado. Pero el camino de la comunicacin al entendimiento est
a menudo lleno de baches.
Principales fuentes de requisitos
Los requisitos pueden proceder de:
Metas: factores crticos de xito
Conocimiento del dominio de la aplicacin
Los interesados. Los afectados por el sistema
El entorno fsico que rodea al sistema
El entorno organizacional. Los procesos de negocio.
Inicio del proceso
La tcnica de obtencin de requisitos (educcin) ms usada, es la de llevar a cabo una reunin o
entrevista preliminar. La primera reunin entre el ingeniero del software (el analista) y el cliente puede
compararse con la primera cita entre dos adolescentes. Nadie sabe qu decir o preguntar; los dos estn
preocupados de que lo que digan sea malentendido; ambos piensan qu pasar (los dos pueden tener
expectativas radicalmente diferentes); los dos estn deseando que aquello termine, pero, al mismo tiempo,
ambos desean que la cita sea un xito.
Sin embargo, hay que empezar la comunicacin. Gause y Weinberg [GAU89] sugieren que el
analista empiece preguntando cuestiones de contexto libre. Es decir, un conjunto de preguntas que llevarn
a un entendimiento bsico del problema, qu solucin busca, la naturaleza de la solucin que se desea y la
efectividad del primer encuentro. El primer conjunto de cuestiones de contexto libre se enfoca sobre el
cliente, los objetivos generales y los beneficios esperados.
Por ejemplo, el analista podra preguntar:

Quin est detrs de la solicitud de este trabajo?
Quin utilizar la solucin?
Cul ser el beneficio econmico del xito de una solucin?
Hay alguna otra alternativa para la solucin que necesita?
Estas preguntas ayudan a identificar todos los participantes que tienen un inters en el software a
construir. Adems, las preguntas identifican los beneficios medibles en una implementacin correcta de
posibles alternativas para un desarrollo normal del software.
El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del problema y al
cliente comentar sus opiniones sobre la solucin:
Cmo caracterizara una buena salida (resultado) generada para una buena solucin?
A qu tipo de problema(s) va dirigida esta solucin?
Puede mostrarme (o describirme) el entorno en que se utilizar la solucin?
Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la
solucin?
El ltimo conjunto de preguntas se concentra en la eficacia de la reunin. Gauge y Weinberg las denominan
meta-preguntas y proponen la siguiente lista (abreviada):
Es usted la persona adecuada para responder a estas preguntas?
Sus respuestas son oficiales?
Estoy preguntando demasiado?
Hay alguien ms que pueda proporcionar informacin adicional?
Hay algo ms que debera preguntarle?
Estas preguntas (y otras) ayudarn a romper el hielo e iniciar la comunicacin tan esencial para el xito
del anlisis. Pero el formato de reunin tipo pregunta y respuesta no es un enfoque que haya tenido
mucho xito. De hecho, esta sesin de preguntas y respuestas debera emplearse solamente en el primer
encuentro y sustituirse despus por una modalidad que combine elementos de resolucin del problema,
negociacin y especificacin. En la siguiente seccin se presenta un enfoque a reuniones de este tipo.
Tcnicas para facilitar las especificaciones de una aplicacin
Entre las tcnicas destacadas para la educcin de requisitos, hallamos:
Entrevistas: que es el mtodo tradicional
Escenarios: los requisitos se situan en el contexto de uso del sistema
Prototipado: cuando la incertidumbre es total acerca del futuro del sistema. De los cuales
hay dos tipos principales, Evolutivo y De Desecho (muchas veces desarrollados con
diapositivas)
Tcnica TFEA
Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de
nosotros y ellos. En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno
define por derecho su propio territorio y se comunica a travs de una serie de memorandos, papeles de
posiciones formales, documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este
mtodo no funciona muy bien. Abundan los malentendidos, se omite informacin importante y nunca se
establece una buena relacin de trabajo.
Con estos problemas en mente es por lo que algunos investigadores independientes han
desarrollado un enfoque orientado al equipo para la reunin de requisitos que se aplica durante las primeras
fases del anlisis y especificacin. Denominadas Tcnicas para facilitar las especificaciones de la aplicacin
(TFEA), este enfoque es partidario de la creacin de un equipo conjunto de clientes y desarrolladores que
trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar
un conjunto preliminar de requisitos de la solucin. Hoy en da, las TFEA son empleadas de forma general
por los sistemas de informacin, pero la tcnica ofrece un potencial de mejora en aplicaciones de todo tipo.
Se han propuesto muchos enfoques diferentes de TFEA. Cada uno utiliza un escenario
ligeramente diferente, pero todos aplican alguna variacin en las siguientes directrices bsicas:
La reunin se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores.
se establecen normas de preparacin y de participacin.
se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes,
pero lo suficientemente informal como para animar el libre flujo de ideas.
Un coordinador (que puede ser un cliente, un desarrollador o un tercero) que controle la reunin.
Se usa un mecanismo de definicin (que puede ser hojas de trabajo, grficos, carteles o pizarras).
El objetivo es identificar el problema, proponer elementos de solucin, negociar diferentes enfoques
y especificar un conjunto preliminar de requisitos de la solucin en una atmsfera que permita
alcanzar el objetivo.
Para comprender mejor el flujo de acontecimientos tal y como ocurren en una reunin TFEA,
presentamos un pequeo escenario que esboza la secuencia de acontecimientos que llevan a la reunin, los
que ocurren en la reunin y los que la siguen.
En las reuniones iniciales entre el desarrollador y el cliente, se dan preguntas y respuestas bsicas
que ayudan a establecer el mbito del problema y la percepcin global de una solucin. Fuera de estas
reuniones iniciales, el cliente y el desarrollador escriben una solicitud de producto de una o dos pginas.
Se selecciona lugar, fecha y hora de reunin TFEA2 y se elige un coordinador. Se invita a participar a
representantes de ambas organizaciones; la del cliente y la de desarrollo. Se distribuye la solicitud de
producto a los asistentes antes de la fecha de reunin.
Mientras se revisa la solicitud das antes de la reunin, se pide a todos los asistentes que hagan
una lista de objetos que formen parte del entorno del sistema, otros objetos que debe producir el sistema y
objetos que usa el sistema para desarrollar sus funciones. Adems, se pide a todos los asistentes que hagan
otra lista de servicios (procesos o funciones) que manipulan o interactan con los objetos.
Finalmente, se desarrollan tambin listas de restricciones (por ejemplo, costes, tamao, peso) y criterios de
rendimiento (por ejemplo, velocidad, precisin). Se informa a los asistentes que no se espera que las listas
sean exhaustivas, pero que s que reflejen su punto de vista del sistema.
Por ejemplo, imagnese que a un equipo de trabajo TFEA de una compaa de productos para el
consumidor se le ha dado la siguiente descripcin del producto:
Nuestras investigaciones indican que el mercado de sistemas de seguridad para el hogar est creciendo a
un ritmo del 40 por 100 anual. Nos gustara entrar en este mercado construyendo un sistema de seguridad
para el hogar basado en un microprocesador que proteja y/o reconozca varias situaciones indeseables tales como
irrupciones ilegales, fuego, inundaciones y otras. El producto, provisionalmente llamado Hogar Seguro, utilizar los
sensores adecuados para detectar cada situacin, puede programarse por el propietario del hogar y llamar
automticamente a una agencia de vigilancia cuando se detecte alguna de estas situaciones.
En realidad, se proporcionara considerablemente ms informacin en esta fase.
Pero incluso con informacin adicional, habra ambigedades presentes, existirn omisiones
probablemente y podran ocurrir errores. Por ahora, la descripcin de producto anterior bastar.
El equipo TFEA est compuesto por representantes de marketing, ingeniera del software y del
hardware, y de la fabricacin tambin participar un coordinador externo.
Todos los componentes del equipo TFEA desarrollan las listas descritas anteriormente. Los objetos
descritos para HogarSeguro podran incluir detectores de humo, sensores de ventanas y puertas, detectores
de movimientos, una alarma, un acontecimiento (se ha activado un sensor), un panel de control, una
pantalla, nmeros de telfono, una llamada de telfono, etc. La lista de servicios podra incluir la instalacin
de la alarma, vigilancia de los sensores, marcado de telfono, programacin del panel de control y lectura de
la pantalla (fjese que los servicios actan sobre los objetos). De igual manera, todos los asistentes TFEA
desarrollarn una lista de restricciones (por ejemplo, el sistema debe tener un coste de fabricacin de menos
de $10.000, debe tener una interfaz amigable con el usuario y debe conectar directamente con una lnea
telefnica estndar) y de criterios de rendimiento (por ejemplo, un acontecimiento detectado por un sensor
debe reconocerse en un segundo; se debera implementar un esquema de prioridad de acontecimientos).
Cuando empieza la reunin TFEA, el primer tema de estudio es la necesidad y justificacin del
nuevo producto, pues todo el mundo debera estar de acuerdo en que el desarrollo (o adquisicin) del
producto est justificada. Una vez que se ha conseguido el acuerdo, cada participante presenta sus listas
para su estudio. Las listas pueden exponerse en las paredes de la habitacin usando largas hojas de papel,
pinchadas o pegadas, o escritas en una pizarra. Idealmente debera poderse manejar separadamente cada
entrada de las listas para poder combinarlas, borrarlas o aadir otras. En esta fase, est estrictamente
prohibido, el debate o las crticas.
Una vez que se han presentado las listas individuales sobre un tema, el grupo crea una lista
combinada. La lista combinada elimina las entradas redundantes y aade las ideas nuevas que se les
ocurran durante la presentacin, pero no se elimina nada ms. Cuando se han creado las listas combinadas
de todos los temas, sigue el estudio moderado por el coordinador. La lista combinada es ordenada,
ampliada o redactada de nuevo para reflejar apropiadamente el producto o sistema que se va a desarrollar.
Dos de los enfoques ms populares de TFEA son Desarrollo Conjunto de Aplicaciones/UAD), desarrollado por IBM, y The METHOD,
desarrollado por Performance Resources, Irte, Falls Church, VA.
El objetivo es desarrollar una lista de consenso por cada tema (objetos, servicios, restricciones y
rendimiento). Despus estas listas se ponen aparte para utilizarlas posteriormente.
Una vez que se han completado las listas de consenso, el equipo se divide en subequipos; cada
uno trabaja para desarrollar una mini-especificacin de una o ms entradas de cada lista. La miniespecificacin es una elaboracin de la palabra o frase contenida en una lista. Por ejemplo, la miniespecificacin del objeto panel de control de HogarSeguro podra ser: montado en la pared; tamao
aproximado 23 * 13 centmetros; contiene el teclado estndar de 12 teclas y teclas especiales; contiene una
pantalla LCD de la forma mostrada en el bosquejo (no presentado aqu); toda la interaccin del cliente se
hace a travs de las teclas usadas para activar o desactivar el sistema; software para proporcionar una
directriz de empleo, recordatorios, etc., conectado a todos los sensores.
Cada subequipo presenta entonces sus mini-especificaciones a todos los asistentesTFEA para
estudiarlas. Se realizan nuevos aadidos, eliminaciones y se sigue elaborando. En algunos casos, el
desarrollo de algunas mini-especificaciones descubrir nuevos objetos, servicios, restricciones o requisitos
de rendimiento que se aadirn a las listas originales. Durante todos los estudios, el equipo sacar a relucir
aspectos que no podrn resolverse durante la reunin. Se har una lista de estas ideas para tratarlas ms
adelante.
Una vez que se han completado las mini-especificaciones, cada asistente de la TFEA hace una
lista de criterios de validacin del producto/sistema y presenta su lista al equipo. Se crea as una lista de
consenso de criterios de validacin. Finalmente, uno o ms participantes (o algn tercero) es asignado para
escribir el borrador entero de especificacin con todo lo expuesto en la reunin TFEA.
TFEA no es la panacea para los problemas que se encuentran en las primeras reuniones de
requisitos, pero el enfoque de equipo proporciona las ventajas de muchos puntos de vista, estudio y
refinamiento instantneo y un paso adelante hacia el desarrollo de una especificacin.
Problemas con la educcin
Entre los principales problemas que pueden entorpecer la tarea de la educcin de requisitos se
cuentan los siguientes:
Los usuarios no pueden /saben describir sus tareas
Mucha informacin importante no llega a verbalizarse
La educcin se afronta como un proceso pasivo, cuando debera ser un proceso cooperativo.
Cmo escribir requisitos?
Y se ha mencionado que los requisitos constituyen la base de la comunicacin entre todas las
partes interesadas en el desarrollo del sistema: usuarios, clientes, desarrolladores y el equipo encargado de
realizar las pruebas. Todas estas personas forman un conjunto heterogneo, lo cual provoca que la mejor
forma de escribir requisitos no exista. Lo que para unos puede ser un lenguaje muy preciso, para otros
puede ser un lenguaje incomprensible.
Debido a esto en la prctica, lo ms utilizado es el lenguaje natural a pesar de su inherente
ambigedad. Se acostumbra a especificar cada requisito como una frase corta (el sistema har X, se
facilitar X, etc.). Tambin se utiliza el lenguaje natural complementado con diagramas y/o notaciones
formales. La notacin utilizada depende de quien leer o quien escribir los requisitos.
Ejemplos:
1. El sistema mantendr la temperatura de la caldera entre 70 y 80 grados
2. El sistema mantendr un registro de todos los materiales de la biblioteca, incluyendo libros,
peridicos, revistas, videos y CDRoms.
3. El sistema permitir a los usuarios realizar una bsqueda por ttulo, autor o ISBN.
4. La interface de usuario se implementar sobre un navegador Web.
5. El sistema deber soportar al menos 20 transacciones por segundo

6. El sistema permitir que los nuevos usuarios se familiaricen con su uso en menos de 15
minutos
Aqu puede verse que los requisitos son de muy distintos tipos:
Requisitos que definen efectos sobre el entorno (1)
Requisitos muy generales
Requisitos funcionales (3)
Requisitos de implementacin (4)
Requisitos de rendimiento (5)
Requisitos de usabilidad (6)
Debido a que hay tantos tipos distintos de requisitos, no es posible establecer una forma estndar
de escribirlos. Tampoco es posible decir cul es la mejor forma de especificarlos. Todo depende de quien
los escribe, quin los va a leer, el dominio de la aplicacin, etc.
Requisitos en negativo
Tan importante como decir lo que el sistema debe hacer, es decir lo que el sistema NO debe hacer.
Estos requisitos en negativo limitan el mbito del sistema. Las razones son varias:
En primer lugar, dicen donde NO se deben emplear recursos
Por otro lado, especificar lo que el sistema no har es fundamental para sistemas crticos
(es decir, sistemas en los que un fallo puede provocar un accidente). Se trata de
especificar cmo el sistema evitar la aparicin de situaciones potencialmente peligrosas.
Requisitos Funcionales y No Funcionales
Los requisitos funcionales describen los servicios (funciones) que se esperan del sistema. Por
ejemplo: El sistema aceptar pagos con VISA
Los requisitos funcionales son restricciones sobre los requisitos funcionales. Por ejemplo:El
Sistema aceptar pagos con VISA de forma segura y con tiempo de respuesta menor a 5 segundos.
Pero el siguiente, muchas veces resulta arbitrario: El Sistema aceptar pagos con VISA a travs
del protocolo SET. En este caso, lo que aparentemente es un requisito funcional, est determinado, en el
fondo por una serie de caractersticas no funcionales (caractersticas que hacen que el protocolo SET sea el
ms adecuado para los objetivos perseguidos).
Modelizacin de requisitos
Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados,
de interaccin, de objetos, etc. La meta es entender mejor el problema, ms que iniciar el diseo de la
solucin (idealmente). El tipo de modelo elegido depende de:
La naturaleza del problema
La experiencia del modelizador
La disponibilidad de herramientas
La imposicin del cliente de una notacin determinada.
Negociacin de Requisitos
En todo proceso de IR intervienen distintos individuos con distintos, y a veces enfrentados
intereses. Estos conflictos entre requisitos se descubren durante el anlisis. Todo conflicto descubierto
10
debera disparar un proceso de (re)negociacin, es decir, los conflictos nunca se deben resolver por
decreto.
Desde este punto de vista, los conflictos son positivos, pues son fuente de NUEVOS
REQUISITOS. Los acuerdos alcanzados deben ser convenientemente anotados, favorecindose asi la
trazabilidad de los requisitos a sus orgenes (el requisito 987 surge como resultado de la reunin entre X y Z
el da tal)
Documento de Requisitos
El llamado Documento de Requisitos es el modo habitual de guardar y comunicar los requisitos.
Debe tenerse en cuenta que al decir documento, nos referimos a cualquier medio electrnico de
almacenamiento y distribucin de informacin como por ejemplo:
Procesador de textos
Bases de datos
Herramientas de Gestin de Requisitos
En general, es buena prctica utilizar, al menos dos documentos, a distinto nivel de detalle:
1. DRU: Documento de Requisitos de Usuario
2. ERS: Especificacion de Requisitos de Software
La pregunta que surge es: En que se diferencian los requisitos de usuario de los requisitos de
software? A grandes rasgos se puede afirmar que:
El DRU se escribe desde el punto de vista del usuario/cliente/interesado. Normalmente los
requisitos de usuario, contenidos en el DRU, no poseen demasiado nivel de detalle. Se
incluye la descripcin del problema actual (razones por las que el sistema de trabajo actual
es insatisfactorio) y las metas que se espera lograr con la construccin del nuevo sistema.
La ERS desarrolla mucho ms los contenidos de la DRU. Los requisitos del software
contenidos en la ERS son ms detallados. Contiene la respuesta a la pregunta Qu
caractersticas debe poseer un sistema que nos permita alcanzar los objetivos y evitar los
problemas expuestos en la DRU?
Estndares
Los documentos estndares ms conocidos de especificacin de requisitos son:
IEEE 830
PSS-05 de la Agencia Espacial Europea (ESA). Las herramientas de gestin de requisitos
permiten generar documentacin en los anteriores formatos, a partir de una base de datos
de requisitos
Caractersticas deseables de una ERS
Una ERS de calidad debera presentar, dentro de lo posible, las siguientes caractersticas:
No ambigua: la ERS es no ambigua si todo requisito posee una sola interpretacin.
Completa: Una ERS es completa si todo lo que se supone que el software debe hacer est
incluido en la ERS. Por completitud, deberan describirse todas las posibles respuestas a
todas las posibles entradas y en todas las situaciones posibles. Adems, la ERS no
contendr secciones de tipo por determinar
Correcta: todo requisito de la ERS contribuye a satisfacer una necesidad real
Comprensible: todo tipo de lectores (clientes, usuarios, desarrolladores, equipo de
pruebas, gestores, etc) entienden la ERS
11
Verificable: si para cada requisito expresado en la ERS existe un procedimiento de prueba

finito y no costoso para demostrar que el futuro sistema lo satisface
Internamente Consistente: no existen subconjuntos de requisitos contradictorios
Externamente Consistente: ninguno de los requisitos est en contradiccin con lo
expresado en documentos de nivel superior. Por ejemplo los requisitos del software no
pueden contradecir los requisitos del sistema.
Realizable: si dados los actuales recursos la ERS es implementable
Concisa: la ERS debe ser lo ms breve posible, sin que esto afecte al resto de atributos de
calidad
Independiente del Diseo: existen ms de un diseo e implementacin que realizan la
ERS. Para ello la ERS debiera limitarse a describir el comportamiento externo del sistema.
Trazable: cada requisito se puede referenciar de forma unvoca. Es fundamental para
precisar qu requisitos son implementados por que componente del diseo, lo cual es
imprescindible a la hora de realizar las pruebas de dicho componente.
Modificable: los cambios son fciles de introducir
Electrnicamente almacenada: se encuentra en un archivo de texto, en una base de datos
o, mejor an, ha sido creada con una herramienta de Gestin de Requisitos (RequisitePro,
Doors, etc)
Ejecutable/Interpretable/Prototipable/Animable: si existe una herramienta software que,
recibiendo como entrada la ERS, realice un modelo ejecutable de la misma. Aplicable tan
solo a ciertas notaciones como las notaciones formales o los diagramas de transicin de
estados.
Anotada por importancia relativa: si los requisitos se clasifican segn su importancia.
Como mnimo un requisito puede ser Obligatorio, Deseable u Opcional. Esto sire para no
asignar demasiados recursos a la implementacin de requisitos no esenciales.
Anotada por estabilidad relativa: los requisitos son, en general, inestables y voltiles. A
cada requisito se le asigna una probabilidad de cambio (Alta, Media o Baja).
Anotada por versin: si un lector de la ERS puede determinar qu requisitos sern
satisfechos por qu versin del producto.
No redundante: cada requisito se expresa en un solo lugar de la ERS. La redundancia de
todas formas, no es del todo mala si aumenta la legibilidad
Nivel de Abstraccin: al nivel adecuado, ni demasiado detallada ni demasiado vaga
Precisa: una ERS es precisa si hace uso de valores numricos para precisar
caractersticas del sistema. La precisin es aplicable, ante todo, a los requisitos no
funcionales. Por ejemplo, no es til decir el tiempo de respuesta ser mas bien rpido!,
sino El tiempo de respuesta ser menor a dos segundos (esto es fuertemente
dependiente de la tecnologa disponible, que no siempre se conoce al principio del
proyecto).
Reutilizable: si ciertas secciones de la ERS se pueden reutilizar
Trazada: sin est claro el origen de cada requisito (quien o que pide)
Con referencias cruzadas: si se utilizan referencias entre requisitos relacionados o entre
otras secciones
Validacin de Requisitos
El objetivo de la validacin de requisitos es descubrir problemas en el Documento de Requisitos
antes de comprometer recursos a su implementacin. El documento debe revisarse para:
Descubrir omisiones o falta de requisitos
Conflictos
Ambiguedades
12
Comprobar la calidad del documento y su grado de adhesin a estndares
Revisiones
Las revisiones del documento de requisitos constituyen la frmula ms empleada en validacin.
En estas revisiones, un grupo de personas (incluyendo usuarios) se ocupan de revisar el documento de
requisitos. Tiene tres fases:
Busqueda de problemas
Reunin
Establecimiento de acuerdos
Como gua para identificar problemas habituales, se pueden utilizar listas de comprobacin,
checklists.
Otros tipos de validacin son:
Prototipado: permite descubrir con rapidez si el usuario se encuentra satisfecho o no con
los requisitos
Validacin de modelos: cuando los requisitos se expresan por medio de modelos (de
objetos, DFD, etc)
Validacion de la testeabilidad. El equipo de pruebas debe revisar los requisitos.
Un ejemplo de cuestiones que debieran figurar en una lista de comprobacin podra ser:
Estn todos los requisitos convenientemente numerados?
El mismo servicio es solicitado en distintos requisitos? Existen contradicciones entre ellos?
Los requisitos relacionados se encuentran agrupados en el documento?
Los requisitos son fcilmente comprensibles? Por todo tipo de lectores?
Gestin de Requisitos (Requirements Management, RM)
Consiste bsicamente, en gestionar los cambios a los requisitos. Asegura la consistencia entre los
requisitos y el sistema construido (o en construccin). Esta tarea consume grandes cantidades de tiempo y
esfuerzo y abarca todo el ciclo de vida del producto.
Es necesario realizar una adecuada gestin de requisitos por una serie de razones, como:
Los requisitos son voltiles
El entorno fsico del sistema cambia
Trasladar un sistema de un entrono a otro requiere modificaciones
El entorno organizacional cambia
Las polticas cambian
Cambios en las reglas y en los procesos del negocio provocan cambios en el sistema
La propia existencia del sistema va a generar nuevos requisitos por parte de los usuarios
La Gestion de Requisitos implica:
Definir procedimientos de cambios: definen los pasos y los anlisis que se realizarn antes de
aceptar los cambios propuestos.
Cambiar los atributos de los requisitos afectados
Mantener la trazabilidad hacia atrs, hacia adelante y entre requisitos
Control de versiones del documento de requisitos
Para realizar adecuadamente estas tareas, se pueden emplear herramientas de Gestion de Requisitos, que
facilitan las tareas relacionadas con la escritura, trazabilidad y gestin de cambios. Estas herramientas
organizan los requisitos en bases de datos y permiten aadir atributos a los requisitos. Conocidas
herramientas comerciales de Gestin de requisitos seran DOORS, REQUISITEPRO, ICCONCEPT.
13

ANEXO
RequisitePro: Rational RequisitePro ayuda a los equipos de proyectos para gestionar sus necesidades, para escribir
buenos casos de uso, para mejorar la trazabilidad, para fortalecer la colaboracin, para reducir el trabajo redundante
proyecto, y para aumentar la calidad.
Evitar el reproceso y la duplicacin con la ms avanzada en tiempo real, integracin con Microsoft Word
Gestionar la complejidad de trazabilidad con vistas detalladas que muestran relaciones padre / hijo
Mitigar el riesgo del proyecto con indicacin de los requisitos que pueden ser afectados por los cambios
ascendentes o descendentes de los requisitos
Lograr la colaboracin para equipos geogrficamente distribuidos a travs de pleno funcionamiento, la interfaz web
escalable y foros de discusin
Capturar y analizar las necesidades de informacin de atributo, con personalizacin detallada y filtrado
Mejorar la productividad al seguimiento de los cambios con las comparaciones de proyectos de versiones con las
lneas de base del proyecto basados en XML
Alinear las metas y objetivos de negocio con las prestaciones del proyecto, aunque la integracin con mltiples
herramientas en el desarrollo de software de IBM Rational y plataforma de entrega
Sistemas operativos compatibles: la familia de Windows
Doors: IBM Rational DOORS es una aplicacin de gestin de requisitos para optimizar la comunicacin, la
colaboracin y la verificacin de requisitos en su organizacin y en toda la cadena de suministros. Esta
solucin escalable puede ayudarle a gestionar el mbito y los costes del proyecto y a alcanzar los objetivos
empresariales. Rational DOORS le permite capturar, rastrear, analizar y gestionar cambios en la
informacin, as como demostrar la conformidad con las normativas y estndares.
Gestin de requisitos: proporciona un amplio entorno de gestin de requisitos.
Rastreabilidad: vincula los requisitos a los elementos de diseo, los planes de prueba, los casos de
prueba y otros requisitos.
Escalabilidad: es escalable para afrontar las necesidades de gestin de requisitos en constante
cambio.
Test Tracking Toolkit (kit de herramientas para el seguimiento de pruebas): Incluye Test Tracking
Toolkit para entornos de prueba manuales, de manera que los probadores puedan vincular requisitos a
casos de prueba.
Integraciones: gestiona los cambios en los requisitos con un sencillo sistema de propuesta de
cambios predefinidos o bien con un flujo de trabajo de control de cambios personalizado ms completo
mediante la integracin con las soluciones de gestin de cambios de Rational.
14
Bibliografa
ROGER PRESSMAN Ingeniera del software 5 edicin.
ANDRES SILVA, Documentacin Master en Ingenieria del Software. UPM, 2000
KOVITZ B. L., Practical Software Requirements. A Manual 01 Content and Style. Manning 1999
15

Especificacion Del Sistema PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Especificacion Del Sistema PDF

Transféré par

Droits d'auteur :

Formats disponibles

Universidad Nacional de Jujuy-Facultad de Ingeniera

Sistemas de Informacin- Sistemas de Informacin I