Requerimientos de sistema

UNIDAD 4

Problemas
L os usuarios no saben lo que quieren
Un sistema tiene muchos usuarios y ninguno
tiene una visin de conjunto
No saben cmo hacer ms eficiente la
operacin en su conjunto
No saben qu partes de su trabajo pueden
transformarse en software
No saben detallar lo que saben de forma
precisa

Labores de un analista
Obtener una lista de requisitos de cada usuario
Adquirir una visin de conjunto
Componer una especificacin completa, correcta
y consistente
Desventajas
Listas de requisitos son difciles de comprender y
de hacer bien
Difciles de transformar en especificaciones de
diseo e implemetacin.

Objetivos
Requisitos
Los detalles sobre lo que tendremos que hacer

Viabilidad
Saber si se va a poder hacer o no

Alcance
Cunto de lo que se podra hacer nos va a dar
tiempo a hacer con el tiempo y la gente que
tenemos

Ingeniera de software
La Is 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

Concepto

Todo problema sw. consiste en configurar una

mquina M para que ejerza unos efectos R en un
dominio D
Los efectos R son los requisitos: Necesidades, metas,
objetivos
El dominio D es el contexto: Los requisitos R, sin
contexto, no tienen sentido. Cambiando el contexto D,
un requisito de R pierde su se sentido.
La mquina M es la que realizar los requisitos R,
gracias a su conexin con D. En la fase de requisitos
tan slo necesitamos describir las conexiones de M
con D (comportamiento externo de M, sin detalles
internos).

Ejemplo
Supngase que hay que desarrollar el software
para un sistema de control de una caldera de
vapor
Posibles requisitos:
El agua entra en ebullicin a 100 Grados Centgrados
y a 1 atm de presin
El sistema evitar que el agua entre en ebullicin
El sistema leer la temperatura del agua por medio
del sensor
El sistema podr subir la temperatura del agua por
medio del regulador

 El agua entra en ebullicin a 100 grados

Centgrados y a 1 atm de presin
no es un requisito, ya que no es una meta ni un
objetivo
es parte de la descripcin del dominio (D), y es
verdadera independientemente de la existencia o
no del sistema

El sistema evitar que el agua entre en

ebullicin
Es un requisito (R). Expresa un deseo u objetivo.
Algo que el sistema deber realizar

 El sistema leer la temperatura del agua por

medio del sensor
El sistema podr subir la temperatura del agua
por medio del regulador
Describen la conexin del software (mquina M)
con el entorno, es decir, describen el
comportamiento externo del software.
No son metas ni objetivos, pero son necesarios
para conseguir las metas y los objetivos

Conclusin
A
unque propiamente hablando tan slo el
segundo es un requisito, a la Ingeniera de
Requisitos le interesan todas las afirmaciones
anteriores, ya que todas aportan informacin
relevante para construir el sistema y para que
el sistema funcione de la manera deseada

Tipos de requisitos
Funcionales:
describen
los
servicios
(funciones) que se esperan del sistema
El sistema aceptar pagos con VISA

Los requisitos no funcionales son restricciones

sobre los requisitos funcionales
El sistema aceptar pagos con VISA de forma
segura y con un tiempo de respuesta menor de 5
segundos

Requisitos funcionales
Definen el comportamiento del sistema que se
va a desarrollar, incluyendo los procesos
fundamentales que el software llevar acabo.
La mayora de los requisitos provienen del
usuario.
Ejemplo un pequeo negocio de venta y
alquiler de herramientas:
Imprimir contratos de alquiler
Guardar informacin de ventas y pagos

Requisitos no funcionales
Estos tiene que ver con las restricciones y
exigencias de calidad del sistema, entre los
que se encuentran los requisitos de
rendimientos, caractersticas de interfaces,
requisitos a la facilidad de mantenimiento

Ejemplo de requisitos no funcionales

La capacidad de que el software pueda
ejecutarse en diversas plataformas ( R.
producto).
La obligacin de ajustarse a una metodologa
de desarrollo ( R. organizacin).
La necesidad de cumplir con la Ley de
Proteccin de Datos ( R. externo)

Actividad 4.2
Leer con atencin el siguiente caso de estudio:
El sistema simula el comportamiento de una central de mensajera de
telefona mvil. Este sistema permite a sus afiliados el intercambio de
mensajes a travs de telfonos mviles, adems de otras funciones como
las de consultar el saldo, recargar su saldo, etc. La funcionalidad de este
sistema bsicamente es la siguiente: un usuario debe darse de alta en el
sistema mediante cualquier mtodo tradicional o electrnico. Una vez el
sistema tiene constancia del usuario, ste puede enviar mensajes a otros
usuarios existentes en el sistema, puede consultar su saldo, solicitar una
recarga de su saldo disponible, y activar o desactivar el desvo del
telfono. El sistema en cada momento tendr constancia de los usuarios
conectados al sistema (aquellos usuarios dados de alta que tengan su
terminal mvil encendido) y aquellos usuarios desconectados.
Los administradores del sistema en cualquier momento podrn solicitar a
ste informacin de cualquier usuario y estadsticas del uso del sistema
por parte de los usuarios del mismo.

Actividad 4.2
Analiza detenidamente y menciona cuales son
los requisitos, que debes tomar en cuenta
para el diseo de un sistema computarizado.
(clasificacin y detecta M y D)
Personas
Telfonos
Sistema
Procesos

Actividad 4.2

Personas funcional

Identificador de afiliado al sistema

Recargas, enviar mensajes, formas de pago
Consultar saldo
Contar con tel

Telfonos funcional
Identificador del telfono
saldo asociado al telfono
Estado (conectado y desconectado)
Contactos y permita intercambiar mensajes
Desvo de msn, error y xito

Actividad 4.2
Sobre el sistema (costos)
Costo del mensaje nfe
Formas de pagos NFO
Saldo por telfono F
Estado del telfono (activado y desactivado) F
Historial de uso del telfono NFO
Estadsticas NFP
Permitir intercambio de mensajes F

Actividad 4.2
Procesos
Que el sistema permita a los administradores
consultar toda la informacin de sus clientes
(estadsticas de saldos y usos). F
Uso de recargas , activo e inactivo, saldos,
consultas. F
Recibir y enviar mensajes.NFP
Mensajes de error o xito NFP

4.3 Requisitos a clasificar

1. La interfaz debe seguir la normativa de colores e
imagen corporativa de la empresa
2. La Web debe seguir la normativa internacional
en las reas de protocolos, contenido,
herramientas, formatos y lenguajes relacionado
con la accesibilidad a internet
3. El rea de trabajo debe poder ampliarse o
reducirse mediante los correspondientes
botones de acceso directo en la barra de
herramientas

Requisitos a clasificar
4. La aplicacin permitir consultar las facturas por
diversos criterios, tales como facturas de pronto
vencimiento por cliente por importe, etc.
5. El acceso a la informacin personal sobre
clientes no podr ser consultada por los
usuarios, excepto aquellos a los que les hayan
sido concedidos privilegios especiales para ello.

Requisitos a clasificar
6. El programa cliente que realiza las bsquedas en
las bases de datos debe poder estar seguro de
que la respuesta del sistema no ha sido
falsificado o alterada.
7. El
lenguaje
de
programacin
ser
obligatoriamente Java
8. La aplicacin en desarrollo sigue la filosofa del
software libre y debe por tanto ponerse a
disposicin de la comunidad su cdigo fuente.

Requisitos a clasificar
9. La informacin de enrutamiento
debe
protegerse
contra
modificaciones
no
autorizadas.
10.Deben almacenarse todas las facturas emitidas
por el sistema para su posterior consulta.
11.El sistema incluir algn tipo de comprobacin
de la identidad para las operaciones sensibles
12.El sistema debe permitir la realizacin peridica
de copias de seguridad para todo la informacin
de clientes y ventas.

4.4 Evaluacin de requisitos

Fuentes para obtener requerimientos

Metas: Factores crticos de xito
Conocimiento del dominio de la aplicacin
Por ejemplo, un usuario quiere consultar por
pantalla todas las plizas que venzan durante
el mes. Para que ello sea posible, el software
deber obligar, cada vez que se crea una
pliza, a que se introduzca su fecha de
vencimiento. Esto puede resultar obvio para
un informtico, pero no lo es tanto para un
usuario inexperto

Fuentes para obtener requerimientos

Los interesados. Los afectados por el sistema.
El entorno fsico que rodea al sistema
El entorno organizacional. Los procesos de
negocio

Problemas de la educcin
Los usuarios no pueden/saben describir
muchas de sus tareas
Mucha informacin importante no llega a
verbalizarse
A veces hay que inventar los requisitos
(sistemas orientados a miles de usuarios)

Tcnicas
Preliminares:
Utilizar preguntas libres de contexto.

Lluvia de ideas:
Seleccionar un grupo variado de participantes.
Eliminar crticas, juicios y evaluaciones mientras los
participantes sugieren ideas.
Producir muchas ideas.
Recogerlas todas por escrito.
Otro da, en otra sesin, se evalan las ideas.

Tcnicas
Prototipo:
til cuando la incertidumbre es grande acerca del
futuro sistema

Entrevistas:
Es el mtodo tradicional, pero debe usarse en
complemento con otras tcnicas, y no debe ser el primer
paso de la educcin. Es fundamental:
Entrevistar a la(s) persona(s) adecuadas.
Preparar las preguntas con antelacin.
Utilizar diagramas, modelos, etc.

Tcnicas
Observacin y anlisis de tareas:
Un observador estudia a los futuros usuarios en
su entorno de trabajo. A veces se utiliza el video.
Anota todo aquello que es susceptible de mejora.
Posteriormente, genera una serie de requisitos
tentativo mejora.

Casos de uso / Escenarios:

Requisitos en contexto de uso.

Actividad 4.5
Investiga como poner en practica las tcnicas
obtencin de requerimientos.

Anlisis de los requisitos

Consiste en detectar y resolver conflictos
entre requisitos
Se precisan los lmites del sistema y la
interaccin con su entorno
Se trasladan los requisitos de usuario a
requisitos del software (implementables)
Se realizan tres tareas fundamentales:
Clasificacin
Modelizacin
Negociacin

Clasificacin de los requisitos

En
funcionales
vs.
No
funcionales
(Capacidades vs. Restricciones)
Por prioridades
Por costo de implementacin
Por niveles (alto nivel, bajo nivel)
Segn su volatilidad/estabilidad
Si son requisitos sobre el proceso o sobre el
producto

Modelo conceptual
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)

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 debera disparar un
proceso de (re)negociacin.
Los conflictos NUNCA se deben resolver por
decreto

Documentos de requisitos
Es el modo habitual de guardar y comunicar
requisitos.
Es buena prctica utilizar, al menos, dos
documentos, a distinto nivel de detalle
DRU = Documento de Requisitos de Usuario (URD)
ERS = Especificacin de Requisitos Software (SRS)

Validacin de requisitos: revisiones

Tres fases: Bsqueda de problemas, reunin y
acuerdos.
Como gua para identificar problemas
habituales, se pueden utilizar listas de
comprobacin (checklists).

Validacin de requisitos: revisiones

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, DFDs, etc.)
Validacin de su testeabilidad. El equipo de
pruebas debe revisar los requisitos.

Gestin de requisitos
Consiste, bsicamente, en gestionar los
cambios a los requisitos.
Asegura la consistencia ente los requisitos y el
sistema construido (o en construccin)
Consume grandes cantidades de tiempo y
esfuerzo
Abarca todo el ciclo de vida del producto

4.6 caso de estudio

Ejercicios de copias de libro

4.8 Evaluacin sumativa

Contesta las siguientes preguntas

Unidad 5 caso de estudio fin de

cuatrimestre
Por equipos deben presentar el
requerimientos solicitado por el
donde deben cumplir con las
caractersticas.
Mtodos de obtencin de
(documentacin)
Clasificacin y validacin.

anlisis de
facilitador,
siguientes
requisitos