1. Especificación funcional del sistema. (v1.0)

Ingeniería del software de gestión.
Caso práctico: Ejemplo de especificación funcional con DCUs (extracto).
1. Especificación funcional del sistema. (v1.0)
Nota: Este documento es un extracto de la documentación funcional de un sistema. También se
trata de una primera versión, por lo que incluye notas del equipo de desarrollo.
1.1.
Introducción.
La especificación funcional se dividirá en cuatro subsistemas: “cartera de inquilinos”, “cartera
de propietarios”, “cartera de inmuebles” y “gestión vía web”. Los tres primeros especificarán
los aspectos funcionales de los requisitos RF1, RF2 y RF3, respectivamente, en cuanto a las
operaciones a realizar en los ordenadores de las oficinas de la agencia. En el subsistema
“gestión vía web” se incluyen las operaciones a realizar por el sistema en el sitio web de la
agencia.
En cuanto a los actores, se especificarán los siguientes:
− Agente: Los agentes inmobiliarios. Son los únicos actores que interactuarán
directamente con el sistema con el objetivo de introducir nueva información.
− Director regional: Los directores regionales.
− Gerente: El gerente de la empresa.
− Inquilino: Los inquilinos.
− Propietario: Los propietarios.
− Sistema: Representa al propio sistema. Los casos de uso relacionados con el actor
“sistema” son ejecutados sin requerir interacción con usuario ninguno.
Habitualmente, suelen asociarse a eventos temporales: por ejemplo, diariamente a
las 6:00.
− Usuario web: Será el actor que visita el sitio web de la inmobiliaria. Nota: ¿Habrá
sólo un tipo de usuario en la web?
1.2.
1.2.1.
Subsistema “cartera de inquilinos”.
Diagramas de casos de uso.
Nótese que el caso de uso “gestión de contactos con inquilinos” se explica con un nuevo
diagrama.
José García Fanjul e Isabel Sevilla Rodríguez
Página 1
Ingeniería del software de gestión.
Caso práctico: Ejemplo de especificación funcional con DCUs (extracto).
Consulta de
inmuebles por preferencias
«uses»
Ficha de inquilino
Inactivar inquilino
Agente
Inquilino
Gestión de
contactos con inquilinos
Propietario
Anotar inquilinos
pendientes de contacto
Listado de inquilinos
pendientes de contacto
Sistema
Listado de
inquilinos potenciales
Figura 1. Diagrama de casos de uso de la gestión de inquilinos.
José García Fanjul e Isabel Sevilla Rodríguez
Página 2
Ingeniería del software de gestión.
Caso práctico: Ejemplo de especificación funcional con DCUs (extracto).
Ficha de visita a
inmueble
«extends»
Propietario
Ficha de contacto
Agente
Rellenar informe
de contacto
Inquilino
Listado de
contactos recientes
Figura 2. Diagrama de casos de uso de la gestión de contactos con inquilinos.
Nota: La gestión de contactos para inquilinos y propietarios son muy similares (o exactamente
iguales).
1.2.2.
Descripción de escenarios.
ESCENARIO “Ficha de contacto”
Numeración: 1.1
Descripción:
Nota: Rellenarlo. Pueden ser:
- Telefónicos
- En oficina
Excepciones:
Nota: Describir aquí mismo las fichas de visitas a inmuebles:
Cuando se concierta una cita, debe hacerse en función de la disponibilidad de horario del
propietario.
Opcionalmente, se emitirá un SMS al propietario (o al inquilino, o a los dos).
ESCENARIO “Ficha de inquilino”
Numeración: 1.2
Descripción:
1. El escenario se inicia cuando un posible inquilino se pone en contacto con un agente,
habitualmente en una oficina de la agencia.
2. El agente preguntará si el inquilino fue cliente de la agencia en el pasado: en caso afirmativo se
intentará buscar al cliente entre los inquilinos inactivos y se comprobará si sus datos personales
siguen siendo correctos.
3. El inquilino expresa sus preferencias al agente (ver RF1.11), tras lo que se realiza una “consulta de
inmuebles por preferencias”.
4. El agente describe brevemente las características de los inmuebles que aparecen en la consulta,
anotando aquellos inmuebles que son del agrado del inquilino.
José García Fanjul e Isabel Sevilla Rodríguez
Página 3
Ingeniería del software de gestión.
Caso práctico: Ejemplo de especificación funcional con DCUs (extracto).
ESCENARIO “Ficha de inquilino”
Numeración: 1.2
5. El agente solicita y anota los datos personales del inquilino (ver RF1.10).
6. Se imprime copia de las características de los inmuebles que son del agrado del inquilino. Nota 1:
El inquilino no debe llevarse datos concretos que permitan identificar el inmueble, como la
dirección o el nombre del propietario. Nota 2: Este informe estará entre los de la “cartera de
inmuebles”.
7. Si el inquilino lo desea, se puede gestionar, a continuación, la realización de visitas a los
inmuebles (ver escenarios de gestión de contactos).
Excepciones:
a) Si el inquilino ya es cliente de la agencia, la ficha puede utilizarse para cambiar sus datos
personales ó sus preferencias.
b) La “consulta de inmuebles por preferencias” también estará accesible al agente sin necesidad de
abrir la ficha de un inquilino. En ese caso, obviamente, el agente rellenará las preferencias.
Anotaciones:
− Deben almacenarse y actualizarse los inmuebles que son del agrado del inquilino, de modo que se
faciliten los futuros contactos.
ESCENARIO “Listado de contactos recientes”
Numeración: 1.3
Descripción:
Nota: Listado con los contactos más recientes llevados a cabo por el agente.
Será una de las funcionalidades más utilizadas: base para las operaciones del agente.
Podrían ser los del último mes, ordenados por fecha.
Podrían tener una estructura jerárquica, de forma que se agruparan los del mismo inquilino.
ESCENARIO “Listado de inquilinos potenciales”
Numeración: 1.4
Descripción:
1. Se muestra un listado con los datos de los inquilinos que han rellenado la ficha a través del sitio
web de la inmobiliaria.
2. El agente revisa dichos datos, y procede a marcar aquellos que parecen veraces (por ejemplo, se
eliminaría un cliente cuyo nombre fuera “Mickey Mouse”). En caso de duda, procederá a llamar al
teléfono de contacto del cliente potencial.
3. Los datos de los clientes potenciales marcados como veraces se incorporarán a la cartera de
clientes.
Anotaciones:
− El sistema debería también filtrar (o ayudar a filtrar) aquellos inquilinos potenciales que parezcan
repetidos: por ejemplo porque el cliente haya introducido sus datos varias veces en el formulario
de la web.
− Sólo aparecerán, en los listados, los inquilinos potenciales que busquen un inmueble en la
localidad y zona en que se encuentre la agencia.
1.2.3.
Descripción de otras funciones.
1.2.3.1. Anotar inquilinos pendientes de contacto.
Al iniciar el sistema, se comprobará qué inquilinos están “pendientes de contacto”. Por defecto,
se definen como tales aquellos que no han tenido contactos con la agencia en las últimas 2
semanas (aunque este parámetro debe ser configurable a nivel de agencia).
Nota 1: ¡No tenemos aún requisitos relativos a la parametrización! Revisarlo a nivel de todo el
sistema.
Nota 2: ¿es esto un caso de uso? ¿hace falta? Revisar el modelo de datos.
José García Fanjul e Isabel Sevilla Rodríguez
Página 4
Ingeniería del software de gestión.
Caso práctico: Ejemplo de especificación funcional con DCUs (extracto).
1.2.3.2. Inactivar inquilino.
Nota: Incluir descripción breve de esta funcionalidad. Hay varias formas de inactivar un
inquilino:
- Inactivación a petición del inquilino.
- Borrado de datos a petición del inquilino (revisar entonces que no haya contratos en los cinco
años anteriores).
Cuando un inquilino está inactivo, no saldrá en los listados normales, sólo podrá reactivarse
desde la ficha de inquilinos.
También se producirá inactivación en la cartera de inmuebles, cuando se firme un contrato...
posiblemente puedan compartir código.
1.2.3.3. Listado de inquilinos pendientes de contacto.
Nota: Incluir descripción breve de esta funcionalidad.
1.2.3.4. Rellenar informe de contacto.
Nota: Incluir descripción breve de esta funcionalidad.
Opcionalmente, los agentes pueden rellenar un informe sobre los contactos, típicamente
después de que éste se haya realizado.
1.2.4.
Otros aspectos funcionales.
Este subsistema interactúa con otros subsistemas en cuanto a:
− La gestión de los inquilinos potenciales, cuyos datos se recogen en el subsistema de
“gestión vía web”.
− La gestión de los contactos, que deben hacerse conforme al horario disponible de
los propietarios (subsistema “cartera de propietarios”).
− Los inquilinos inactivos: en la “cartera de inmuebles” se inactivarán los inquilinos
que firmen un contrato de alquiler.
José García Fanjul e Isabel Sevilla Rodríguez
Página 5
Ingeniería del software de gestión.
Caso práctico: Ejemplo de especificación funcional con DCUs (extracto).
ANEXO: Relaciones de dependencia en Visio.
La herramienta “visio” no usa, por defecto, la notación estándar de UML para las relaciones de
dependencia. A continuación se muestran ejemplos de dependencias “include” y “extend”
utilizando “visio”:
Consulta de
inmuebles por preferencias
«uses»
Ficha de inquilino
Inactivar inquilino
Inquilino
Figura 3. Dependencia “include” con “visio”.
Ficha de visita a
inmueble
«extends»
Ficha de contacto
Figura 4. Dependencia “extend” con “visio”.
No obstante, se pueden cambiar las propiedades de las formas para que utilicen la notación
estricta de UML. Por ejemplo:
Consulta de
inmuebles por preferencias
«uses»
Ficha de inquilino
Figura 5. Dependencia “include” con “visio” (forma de la flecha de UML).
José García Fanjul e Isabel Sevilla Rodríguez
Página 6