Plantilla DRS

Proyecto cine clic
Documento de Requisitos del Sistema

Versin 0.1
Fecha 11-11-2013
Realizado por Esteani !uan Velosa
Realizado para !ine clic
Proyecto Cine clic
!ontrol de !am"ios del Documento
#$mero Fecha %utor !am"io&s' eectuado&s'
0..n (dd-mm-
))))*
(autor* (cam"ios*
+erramienta,Documento Descripcin
<nombre_documento> (descripcin herramienta,documento*
Documentacin de Reerencia
Autorizado por: <nombre_departamento>
Ttulo: Anlisis
Fecha creacin: <fecha_creacin> Responsable: <equipo_responsable>
Fecha revisin: <fecha_revisin> N documento: 2427188!"doc Pginas: 2 / 12 ersin: #"$
Proyecto Cine clic
NDICE
1 -#.R/D0!!-1#............................................................................................................. 2
2 DES!R-3!-1# DE4 S-S.E5% %!.0%4............................................................................. 2
3 /67E.-V/S DE4 S-S.E5%............................................................................................... 2
2 !%.%4/8/S DE RE90-S-./S DE4 S-S.E5%...................................................................:
2.1. Requisitos de -normacin..........................................................................:
2.2. Requisitos Funcionales...............................................................................;
2.1.1 De<nicin de los actores..........................................................................;
2.1.2 Dia=ramas de !asos de 0so.....................................................................;
2.3. Requisitos no uncionales........................................................................... >
: 5atriz de rastrea"ilidad o"?eti@os,requisitos...............................................................10
A !onBictos pendientes de resolucin............................................................................ 10
; %pCndices................................................................................................................... 11
D Resumen..................................................................................................................... 11
> 8losario de .Crminos................................................................................................... 12
10 Endice de .a"las..................................................................................................... 12
11 Endice de Fi=uras.................................................................................................... 12
Ttulo: Anlisis
Proyecto Cine clic
1 INTRD!CCI"N
El cine clic desea un sistema de informacin que le permita a los clientes poder consultar las carteleras
disponibles en diferentes cinemas, idiomas, horario y ubicacin, adicional a esto que le diga el valor
por boleta y el total de su compra o reservacin, tambin que el usuario pueda revisar su historial de
compra y de pelculas vistas.
DES!R-3!-1# DE4 S-S.E5% %!.0%4
<Esta seccin debe contener una descripcin del sistema actual en el caso de que se haya acometido su
estudio. Para describir el sistema actual puede utilizarse cualquier tcnica que se considere oportuno,
por eemplo las descritas en !"aguna et al. #$$$% &Diagrama DocumentosTarea, ''() o en !*rtn et
al. +,,#% &Diagramas de Actividad, tambin descritos en !-ooch et al. #$$$%)..
# $%ETI&S DE' SISTE()
<Esta seccin debe contener una lista con los obetivos que se esperan alcanzar cuando el sistema
soft/are a desarrollar est en e0plotacin, especificados mediante la plantilla para obetivos..
OBJ-<id> <nombre descriptivo >
Versin <n de la versin actual>> &<<fecha de la versin actual>>)
Autores <autor de la versin actual>> &<<organizacin del autor>>)
...
Fuentes <fuente de la versin actual>> &<<organizacin de la fuente>>)
...
Descripcin El sistema deber <<obetivo a cum!lir !or el sistema>
Subobjetivos *-120 <<nombre del subobetivo>
3
Importancia <im!ortancia del obetivo>
Urencia <urgencia del obetivo>
!stado <estado del obetivo>
!stabi"idad <estabilidad del obetivo>
#omentarios <comentarios adicionales sobre el obetivo>
<Identi$icador % nombre descriptivo4 siguiendo la propuesta, entre otros, de !5a/yer et al. #$$6%,
cada obetivo debe identificarse por un cdigo 7nico y un nombre descriptivo. 8on obeto de conseguir
una r9pida identificacin, los identificadores de los obetivos comienzan con "#$.
Versin4 para poder gestionar distintas versiones, este campo contiene el n7mero y la fecha de la
versin actual del obetivo.
Autores& Fuentes4 estos campos contienen el nombre y la organizacin de los autores &normalmente
desarrolladores) y de las fuentes &clientes o usuarios), de la versin actual del obetivo, de forma que
la rastreabilidad pueda llegar hasta las personas que propusieron la necesidad del obetivo.
Descripcin4 este campo contiene un patrn2" que se debe completar con la descripcin del obetivo.
Subobjetivos4 en este campo pueden indicarse los subobetivos que dependen del obetivo que se est9
describiendo. En sistemas compleos puede ser necesario establecer una erarqua de obetivos previa a
la identificacin de los requisitos. En caso de que esto no sea necesario, puede ignorarse este campo.
Ttulo: Anlisis
Proyecto Cine clic
Importancia4 este campo indica la importancia del cumplimiento del obetivo para los clientes y
usuarios. 5e puede asignar un valor numrico o alguna e0presin enumerada como vital, im!ortante o
%uedar&a bien, tal como se propone en !:-; **(8 #$$6%. En el caso de que no se haya establecido
a7n la importancia, se puede indicar que est9 !or determinar &'D), equivalente al (-' &To #e
Determined) empleado en las especificaciones escritas en ingls.
Urencia4 este campo indica la urgencia del cumplimiento del obetivo para los clientes y usuarios en
el supuesto caso de un desarrollo incremental. 8omo en el caso anterior, se puede asignar un valor
numrico o una e0presin enumerada como inmediatamente, ha( !resin o !uede es!erar !:-;
**(8 #$$6%, o 'D en el caso de que a7n no se haya determinado.
!stado4 este campo indica el estado del obetivo desde el punto de vista de su desarrollo. El obetivo
puede estar en construccin si se est9 elaborando, !endiente de negociacin si tiene alg7n conflicto
asociado pendiente de solucin, !endiente de verificacin si no tiene ning7n conflicto pendiente y est9
a la espera de verificacin o, !endiente de validacin si ya ha sido verificado y est9 a la espera de
validacin o por 7ltimo, puede estar validado si ya ha sido validado por clientes y usuarios.
!stabi"idad4 este campo indica la estabilidad del obetivo, es decir una estimacin de la probabilidad
de que pueda sufrir cambios en el futuro. Esta estabilidad puede indicarse mediante un valor numrico
o mediante una e0presin enumerada como alta, media o baa o 'D en el caso de que a7n no se haya
determinado.
"a informacin sobre la estabilidad, bien a nivel de obetivos como en este caso, bien a nivel de
requisitos, ayuda a los dise<adores a dise<ar soft/are que prevea de antemano la necesidad de posibles
cambios futuros en aquellos aspectos relacionados con los elementos identificados como inestables
durante la fase de ingeniera de requisitos, favoreciendo as el mantenimiento y la evolucin del
soft/are !-rac=ett #$$,%.
#omentarios4 cualquier otra informacin sobre el obetivo que no encae en los campos anteriores
puede recogerse en este apartado..
* C)T)'+S DE RE,!ISITS DE' SISTE()
<Esta seccin se divide en las siguientes subsecciones en las que se describen los requisitos del
sistema. 8ada uno de los grandes grupos de requisitos, de informacin, funcionales y no funcionales,
podr9 dividirse para ayudar a la legibilidad del documento, por eemplo dividiendo cada subseccin en
requisitos asociados a un determinado obetivo, requisitos con caractersticas comunes, etc..
2.1. Requisitos de -normacin
<Esta subseccin debe contener la lista de requisitos de almacenamiento y de restricciones de
informacin que se hayan identificado, utilizando para especificarlos las plantillas para requisitos de
informacin descritas.
I'(-<id> <nombre descriptivo>
Versin <n de la versin actual> &<<fecha de la versin actual>>)
Autores <autor de la versin actual>> &<organizacin del autor>>)
...
...
Ttulo: Anlisis
Proyecto Cine clic
Objetivos asociados *-12) <nombre del obetivo>
'e)uisitos asociados >02y <nombre del re%uisito>
Descripcin El sistema deber9 almacenar la informacin correspondiente a <concepto relevante.>.
En concreto4
Datos espec*$icos _ <datos es!ec&ficos sobre el conce!to relevante>
...
+iempo de vida ,edio ,-.imo
<tiem!o medio de vida> <tiem!o m)imo de vida**+E))
Ocurrencias simu"t/ ,edio ,-.imo
<n medio de ocurr. simul> <n m)imo de ocurr. simult>
Importancia <im!ortancia del re%uisito>
Urencia <urgencia del re%uisito>
!stado <estado del re%uisito>
!stabi"idad <estabilidad del re%uisito>
#omentarios <comentarios adicionales sobre el re%uisito>
<Identi$icador % nombre descriptivo4 siguiendo las recomendaciones, entre otros, de !:EEE #$$?% y
!5a/yer et al. #$$6%, cada requisito se debe identificar por un cdigo 7nico y un nombre descriptivo.
8on obeto de conseguir una r9pida identificacin, los identificadores de los requisitos de
almacenamiento de informacin comienzan con ,-. y los de requisitos de restricciones de
informacin con /-..
Versin& Autores& Fuentes4 estos campos tienen el mismo significado que en la plantilla para
obetivos aunque referidos al requisito.
Objetivos asociados4 este campo debe contener una lista con los obetivos a los que est9 asociado el
requisito, es decir de los obetivos de los que depende. Esto permite conocer qu requisitos har9n que
el sistema a desarrollar alcance los obetivos propuestos y ustifican de esta forma la e0istencia o
propsito del requisito.
'e)uisitos asociados4 en este campo se indican otros requisitos que estn asociados por alg7n motivo
con el requisito que se est9 describiendo, es decir de los requisitos de los que depende. 'e esta forma
se posibilita tener una rastreabilidad horizontal, similar a las relaciones entre assets del mismo nivel
descritas en !@arca +,,,%.
Descripcin4 para los requisitos de almacenamiento de informacin este campo usa un patrn2" que
se debe completar con el concepto relevante sobre el que se debe almacenar informacin. En el caso
de los requisitos de restricciones de informacin, este campo usa un patrn2" que se debe completar
con la restriccin o regla de negocio que debe cumplir la informacin almacenada por el sistema.
Datos espec*$icos4 este campo contiene una lista de los datos especficos asociados al concepto
relevante, de los que pueden indicarse todos aquellos aspectos que se considere oportunos
&descripcin, restricciones, eemplos, etc.).
+iempo de vida4 este campo indica el tiempo de vida medio y m90imo que se espera para cada
ocurrencia del concepto relevante.
Ocurrencias simu"t-neas4 este campo indica el n7mero medio y m90imo de ocurrencias simult9neas
del concepto relevante. (anto este campo como el anterior permiten a los dise<adores prever
determinadas necesidades del sistema a desarrollar en lo relativo a las necesidades de almacenamiento
de informacin.
Importancia& Urencia& !stado& !stabi"idad& #omentarios4 estos campos tienen el mismo
significado que en la plantilla para obetivos aunque referidos al requisito..
Ttulo: Anlisis
Proyecto Cine clic
2.2. Requisitos Funcionales
< Esta seccin debe contener la lista de requisitos funcionales, e0presados de la forma tradicional o
mediante casos de uso, que se hayan identificado, dividindose en los siguientes apartados que se
describen a continuacin..
*-1-1 De.nici/n de los actores
<Este apartado debe contener una lista con los actores que se hayan identificado, especificados
mediante la plantilla para actores de casos de uso.
A#+0<id <nombre descriptivo>
Autores <autor de la versin actual> &<<organizacin del autor>0
...
Fuentes <fuente de la versin actual> &<<organizacin de la fuente>>)
...
Descripcin Este actor representa a <<rol %ue re!resenta el actor>
#omentarios <comentarios adicionales sobre el actor>
*-1-# Dia0ramas de Casos de !so
<Este apartado debe contener los diagramas de casos de uso del sistema que se hayan realizado..
U#-<id> <nombre descriptivo>
Versin <n de la versin actual> &<<fecha de la versin actual>)
...
...
Objetivos asociados *-12) <nombre del obetivo>
...>
'e)uisitos asociados >02y <nombre del re%uisito>
...
Descripcin El sistema deber9 comportarse tal como se describe en el siguiente caso de uso A
abstracto durante la realizacin de los siguientes casos de uso4 <lista de casos
de uso>>, cuando <<evento de activacin>> !o durante la realizacin de los
siguientes casos de uso4 <<lista de casos de uso>>%B
1recondicin <!recondicin del caso de uso>
Secuencia norma" 1aso Accin
!1 AEl actor <actor>>, El sistemaB <accin2es realizada2s !or
actor2sistema>>
!3 5e realiza el caso de uso <caso de uso 4-5)0>
!+ 5i <condicin>>, Ael actor <<actor>>, el sistemaB <accin2es
realizada2s !or actor2sistema>>
!6 5i <<condicin>>, se realiza el caso de uso <<caso de uso 4-5)0>>
... ...
1ostcondicin <!ostcondicin del caso de uso>
!.cepciones 1aso Accin
!1 5i <<condicin de e)ce!cin>>, Ael actor <<actor>>, el sistemaB
<accin2es realizada2s !or actor2sistema>>, a continuacin este
caso de uso Acontin7a, queda sin efectoB
Ttulo: Anlisis
Proyecto Cine clic
!3 5i <condicin de e)ce!cin>>, se realiza el caso de uso <caso de
uso 4-5)0>>, a continuacin este caso de uso Acontin7a, queda
sin efectoB
... ...
'endimiento 1aso #ota de tiempo
% > m <unidad de tiem!o>
... ...
Frecuencia <n de veces>. C <<unidad de tiem!o>
<Identi$icador % nombre descriptivo4 igual que en las plantillas anteriores, e0cepto que los
identificadores de los requisitos funcionales empiezan con 7/ para los casos de uso y con 5-. para
los requisitos funcionales e0presados de la forma tradicional, y que para los casos de uso, el nombre
descriptivo suele coincidir con el obetivo que los actores esperan alcanzar al realizarlo. Do se debe
confundir este obetivo con los obetivos del sistema. El obetivo que los actores esperan alcanzar al
realizar un caso de uso es de m9s bao nivel, por eemplo registrar un nuevo socio o consultar los
!edidos !endientes.
Descripcin4 para los requisitos funcionales e0presados de la forma tradicional, este campo contiene
un patrn2" que debe completarse con la capacidad o funcionalidad que debe presentar el sistema a
desarrollar. Para los requisitos funcionales e0presados como casos de uso, este campo contiene un
patrn2" que debe completarse de forma distinta en funcin de que el caso de uso sea abstracto o
concreto &ver seccin E.E.+, p9g. +F).
5i el caso de uso es abstracto, deben indicarse los casos de uso en los que se debe realizar, es decir,
aquellos desde los que es incluido o a los que e)tiende. 5i, por el contrario, se trata de un caso de uso
concreto, se debe indicar el evento de activacin que provoca su realizacin, y en el caso de que sea
incluido desde, o e)tienda a, otros casos de uso, se deber9n indicar dichos casos de uso.
1recondicin4 en este campo se e0presan en lenguae natural las condiciones necesarias para que se
pueda realizar el caso de uso. Estas condiciones se establecen bien sobre el entorno en el que opera el
sistema, y que por lo tanto quedar9n fuera de su control, bien sobre el estado del propio sistema.
Secuencia norma"4 este campo contiene la secuencia normal de interacciones del caso de uso. En cada
paso, un actor o el sistema realiza una o m9s acciones, o se realiza &se inclu(e) otro caso de uso. Gn
paso puede tener una condicin de realizacin, en cuyo caso si se realizara otro caso de uso se tendra
una relacin de e)tensin. 5e asume que, despus de realizar el 7ltimo paso, el caso de uso termina.
*tras propuestas similares, por eemplo !8oleman #$$F%, proponen utilizar estructuras similares al
pseudocdigo para e0presar las interacciones de los casos de uso. En nuestra opinin, esto puede llevar
a que dichas descripciones sean e0cesivamente compleas de entender para los participantes sin
conocimientos de programacin y se corre el peligro de especificar los casos de uso con un estilo
cercano a la programacin.
Para representar estructuras condicionales compleas se puede recurrir a a<adir informacin aparte, por
eemplo una tabla de decisin, y referenciarla desde el paso o los pasos oportunos.
En el caso de estructuras iterativas, su uso puede evitarse con un uso cuidadoso del lenguae natural.
Por eemplo, para indicar que se procesan todos los artculos de un pedido se puede optar por frases
como 8el sistema !rocesa todos los art&culos del !edido introducidos !or el usuario8, en lugar de
estructuras como4
Ttulo: Anlisis
Proyecto Cine clic
REPETIR
procesar artculo del pedido introducido por el usuario
HASTA que no haya ms artculos
*tro eemplo puede ser especificar que el usuario puede intentar conectarse al sistema un m90imo de
tres veces. Gna posible especificacin sera la que puede verse en la figura #H, bastante m9s natural y
f9cil de entender que la que puede verse en la figura #6 utilizando la propuesta descrita en !8oleman
#$$F%.
1ostcondicin4 en este campo se e0presan en lenguae natural las condiciones que se deben cumplir
despus de la terminacin normal del caso de uso. Il igual que en el caso de las precondiciones, las
postcondiciones se pueden establecer tanto sobre el entorno del sistema como sobre el estado del
propio sistema.
!.cepciones4 este campo especifica el comportamiento del sistema en el caso de que se produzca
alguna situacin e0cepcional durante la realizacin de un paso determinado.
'espus de realizar las acciones o el caso de uso asociados a la e0cepcin &una e)tensin), el caso de
uso puede continuar la secuencia normal o quedar sin efecto, en cuyo caso se cancelan todas las
acciones realizadas en el caso de uso deando al sistema en el mismo estado que antes de comenzar el
caso de uso, asumiendo una sem9ntica transaccional del mismo, tal como se describe en !1acobson et
al. #$$6%.
:nicialmente, la e0presin utilizada para indicar una terminacin anormal del caso de uso como
resultado de una e0cepcin era 8este caso de uso aborta8. "a e0periencia durante su aplicacin nos
llev a la conclusin de que el termino abortar resultaba emocionalmente molesto para algunos
participantes !@oleman #$$H%, por lo que se cambi por 8este caso de uso %ueda sin efecto8 con el
significado comentado anteriormente.
'endimiento4 en este campo puede especificarse el tiempo m90imo para cada paso en el que el
sistema realice un accin.
Frecuencia esperada4 en este campo se indica la frecuencia esperada de realizacin del caso de uso,
que aunque no es realmente un requisito, es una informacin interesante para los desarrolladores..
2.3. Requisitos no uncionales
<Esta subseccin debe contener la lista los requisitos no funcionales del sistema que se hayan
identificado, especificados mediante la plantilla para requisitos no funcionales .
2F'0<id <nombre descriptivo>
Autores <autor de la versin actual> &<<organizacin del autor>>)
...
...
Objetivos asociados *-12) <<nombre del obetivo>
...
'e)uisitos asociados _ >02y <nombre del re%uisito>
...
Descripcin El sistema deber9 <ca!acidad del sistema>
Ttulo: Anlisis
Proyecto Cine clic
1 (atri2 de rastreabilidad ob3eti4os5requisitos
<Esta seccin debe contener una matriz obetivore%uisito, de forma que para cada obetivo se pueda
conocer con qu requisitos est9 asociado. El formato de la matriz de rastreabilidad es el siguiente4 .
OBJ034 OBJ035 . . . OBJ-n
I'(034_
J J
I'(035
J
///
U#034
J
U#035
J J
///
2F'034
J
2F'035
J
6
6 Con7ictos 8endientes de resoluci/n
<Esta seccin, que se incluir9 en el caso de que no se opte por registrar los conflictos en un documento
aparte, deber9 contener los conflictos identificados durante el proceso y que a7n est9n pendientes de
resolucin, descritos mediante la plantilla para conflictos..
#F70<id> < <nombre descriptivo>
Versin <n9 de la versin actual>> &<<fecha de la versin actual>>)
...
Fuentes <fuente de la versin actual> &<organizacin de la fuente>>)
...
Objs/8'e)s/ en con$"icto *-1C>yyK) <nombre del obetivo o re%uisito en conflicto>
...
Descripcin <descri!cin del conflicto>
A"ternativas <descri!cin alternativa de solucin>> &<<autores alternativa>>)
...
So"ucin <descri!cin de la solucin ado!tada 4si se ha acordado0>
Importancia <im!ortancia de la resolucin del conflicto>
Urencia <urgencia de la resolucin del conflicto>
!stado <estado del resolucin del conflicto>
#omentarios <comentarios adicionales sobre el conflicto>
Ttulo: Anlisis
Proyecto Cine clic
<Identi$icador % nombre descriptivo4 al igual que el resto de la informacin correspondiente a los
requisitos28, cada conflicto debe poderse identificar de forma 7nica y tener un nombre descriptivo. El
prefio propuesto para lograr una r9pida identificacin es /5:.
Versin& Autores& Fuentes4 estos campos tienen el mismo significado que en las plantillas para
obetivos y requisitos, aunque referidos al conflicto. En este caso especial, las fuentes son los
participantes que deben participar en las posibles negociaciones necesarias para su resolucin.
Objetivos % re)uisitos en con$"icto4 este campo debe contener una lista con los obetivos yCo
requisitos afectados por el conflicto.
Descripcin4 este campo debe contener la descripcin del conflicto.
A"ternativas4 este campo debe contener una lista con las posibles alternativas de solucin que se
hayan identificado para solucionar el conflicto as como los autores de dichas alternativas.
So"ucin4 este campo debe contener la descripcin de la solucin negociada del conflicto, una vez que
se haya acordado.
Importancia& Urencia4 estos campos indican respectivamente la importancia y la urgencia de la
resolucin del conflicto.
!stado4 este campo indica el estado de resolucin del conflicto, que podr9 estar no resuelto, en
negociacin o bien resuelto.
#omentarios4 este campo tiene el mismo significado que en las plantillas descritas previamente..
9 )8:ndices
<"os apndices se usar9n para proporcionar informacin adicional a la documentacin obligatoria del
documento. 5lo deben aparecer si se consideran oportunos y se identificar9n con letras ordenadas
alfabticamente4 I, -, 8, etc..
; Resumen
<En este apartado se rellena una tabla con los identificadores y nombres descriptivos de cada uno de
los elementos principales del documento4 *betivos, >equisitos de :nformacin, >equisitos
funcionales, >equisitos no funcionales y 8onflictos pendientes. Este apartado permite disponer de una
visin global de los requisitos del sistema .
+I1O ID 'escripcion
OBJ!+IVOS *-1 2 # <nombre descri!tivo del obetivo 1>
*-1 2 + <nombre descri!tivo del obetivo 3>
3. <nombre descri!tivo del obetivo ; >
'!(UISI+OS
I2FO',A#IO2
:>L 2 # <nombre descri!tivo del re%uisito de informacin 1>
:>L 2 + <nombre descri!tivo del re%uisito de informacin 3>
3. <nombre descri!tivo del re%uisito de informacin ; >
'!(UISI+OS
FU2#IO2A7!S
G8 2 # <nombre descri!tivo del re%uisito funciona1 1>
G8 2 + <nombre descri!tivo del re%uisito funciona1 3>
3. <nombre descri!tivo del re%uisito funciona1; >
'!(UISI+OS 2O
FU2#IO2A7!S
DM> 2 # <nombre descri!tivo del re%uisito no funciona1 1>
DM> 2 + <nombre descri!tivo del re%uisito no funciona1 3>
3. <nombre descri!tivo del re%uisito no funciona1; >
#O2F7I#+OS 8M" 2 # <nombre descri!tivo del conflicto 1>
3. <nombre descri!tivo del conflicto ; >
Ttulo: Anlisis
Proyecto Cine clic
< +losario de T:rminos
<Esta seccin, deber9 contener una lista ordenada alfabticamente de los trminos especficos del
dominio del problema, acrnimos y abreviaturas que aparezcan en el documento y que se considere
que su significado deba ser aclarado. 8ada trmino deber9 acompa<arse de su significado. 5e deber9
hacer especial hincapi en la especificacin de todos los trminos deducidos del vocabulario del
dominio del problema &para su comprensin por los futuros analistas, dise<adores y programadores),
asi como de los trminos del dominio de la solucin &para su comprensin por el cliente).
= ndice de Tablas
<Esta seccin, deber9 contener una lista ordenada de todas las tablas presentes en el documento.
1>ndice de ?i0uras
<Esta seccin, deber9 contener una lista ordenada de todas las figuras presentes en el documento.
Ttulo: Anlisis

Plantilla DRS

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

Plantilla DRS

Transféré par

Droits d'auteur :

Formats disponibles

Proyecto cine clic

Documento de Requisitos del Sistema

Vous aimerez peut-être aussi