Requisitos e Regras de Negócio
Paulo Vasconcellos
Shigueru
Paulo,
Vejo que no caso apresentado, há um requisito de usuário que pode ser
traduzido no caso de uso "Liberar crédito". Para tal tarefa, é
necessário "avaliar o cliente" (requisito funcional) e cumprir uma
regra (composta de 4 condições).
Agora sobre concordar ou não...
@Yoshima
"Regras de Negócio ficam fora de casos de uso pois são de observância
geral no sistema. Ficam na sua camada de negócios, pensando na
implementação. Não vale a pena colocar em casos de uso, pois vários
casos de uso podem ter a mesma regra, e repetir não é uma boa idéia e
includes nesse caso ficam bem ruins."
Concordo com a parte da implementação. Já sobre colocar as RNs no caso
de uso, a limitação está na ferramenta (documento). No EA é possível
fazer os links, daí teríamos essa restrição eliminada.
@Elvio
"Em linhas gerais, regras de negócio definem ou restrigem termos do
negócio. No seu caso o termo parece ser "liberação de crédito" e o
mesmo é restrito por uma única regra de negócio, sendo ela: cliente
não possua ficha suja no SPC SERASA, assim como 20% do seu salário
seja 2/3 maior q a prestação solicitada, deve estar empregado a mais
de 1 ano e ser maior de 18 anos."
Concordo integralmente.
[]s
Shigueru.
On Dec 14, 10:26 am, Paulo Vasconcellos <pfvasconcel...@gmail.com>
wrote:
Jean Streleski
Apenas faço a ressalva que talvez as condições possam ser quebradas em quatro regras para fins de uma possível e comum exceção à regra. (Amanhã um gerente aprova o crédito para alguém que não tenha 18 anos, por exemplo).
Embora esta devesse ser uma preocupação da implementação, eu imagino que depois uma máquina de regras pudesse trabalhar compondo regras de negócio de N maneiras diferentes, conforme novas situações surjam.
Mas, como dizia o Kerber aqui na lista, neste caso o AN é apenas consultivo e não deliberativo.
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado e patrocinado pelo finito: pfvasconcellos.com
--
Jean Rozan Streleski
jean.r.s...@gmail.com
msn: jea...@hotmail.com
Jean Streleski
E entendi muito menos a definição dele entre o que é requisito e o que é regra de negócio.
Paulo Vasconcellos
- A distinção entre requisitos e regras de negócio é fundamental. As segundas são bem mais voláteis que os primeiros. Lá na implementação elas deveriam merecer um tratamente diferente (visando a melhoria da manutenabilidade da solução).
- No exemplo colocado, muito bom por sinal, temos uma regra composta por 4 parâmetros distintos. Ou seja, não é equivocada, em meu ponto de vista, a interpretação de que seriam 4 regras. Como cada parâmetro é autônomo (pode ser alterado sem que isso signifique alteração nos demais), deveria ser implementado com a mesma independência.
- O pior cenário seria a "solidificação" daquela(s) regra(s) em código.
- Um analista deve registrar a informação na ferramenta que ele tem em mãos. Se a regra apareceu no momento em que ele *descobria e descrevia os requisitos* (utlizando, por exemplo, uma especificação de casos de uso), não vejo nenhum problema no registro dela naquele documento. Pelo contrário, recomendo que assim seja feito. Da mesma forma que seria se a ferramenta utilizada fosse uma User Story.
Abraços,
Shigueru
Paulo,
Você falou das regras, mas sobre requisito do usuário ou requisito
funcional não. Concorda que é um requisito do usuário? Ou dentre as
opções você escolheria a d) (um requisito funcional e 4 regras de
negócio)?
Agora sobre quebrar em 4 regras, assim como também o Jean sugeriu,
talvez seja forçar um pouco a barra. Vejam, duas claramente seriam:
- Suficiência salarial: 20% do seu salário seja 2/3 maior que a
prestação solicitada
- Estabilidade no emprego: deve estar empregado a mais de 1 ano
Já que aqui caberia uma preocupação em parametrizar. As outras duas
não. Seria preciosismo.
[]s
Shigueru.
On Dec 14, 2:43 pm, Paulo Vasconcellos <pfvasconcel...@gmail.com>
wrote:
> Olá,
>
> Seguem minhas considerações:
>
> 1. A distinção entre requisitos e regras de negócio é fundamental. As
> deveriam merecer um tratamente diferente (visando a melhoria da
> manutenabilidade da solução).
> interpretação de que seriam 4 regras. Como cada parâmetro é autônomo (pode
> ser alterado sem que isso signifique alteração nos demais), deveria ser
> implementado com a mesma independência.
> 4. Um analista deve registrar a informação na ferramenta que ele tem em
> requisitos* (utlizando, por exemplo, uma especificação de casos de uso), não
> vejo nenhum problema no registro dela naquele documento. Pelo contrário,
> recomendo que assim seja feito. Da mesma forma que seria se a ferramenta
>
> Abraços,
> Paulo
>
> 2009/12/14 Jean Streleski <jrs....@gmail.com>
> > Esqueci de ressaltar que não vi como a distinção de requisitos possa trazer
> > tantos prejuízos como o @Francis apontou.
>
> > E entendi muito menos a definição dele entre o que é requisito e o que é
> > regra de negócio.
>
> > Também vejo como o Shigueru e concordo integralmente com a opinião dele em
> >> relação às opiniões.
>
> >> Apenas faço a ressalva que talvez as condições possam ser quebradas em
> >> quatro regras para fins de uma possível e comum exceção à regra. (Amanhã um
> >> gerente aprova o crédito para alguém que não tenha 18 anos, por exemplo).
>
> >> Embora esta devesse ser uma preocupação da implementação, eu imagino que
> >> depois uma máquina de regras pudesse trabalhar compondo regras de negócio de
> >> N maneiras diferentes, conforme novas situações surjam.
>
> >> Mas, como dizia o Kerber aqui na lista, neste caso o AN é apenas
> >> consultivo e não deliberativo.
>
> >> msn: jean...@hotmail.com
>
> > --
> > Jean Rozan Streleski
> > jean.r.strele...@gmail.com
> > msn: jean...@hotmail.com
Paulo Vasconcellos
Shigueru
Entendido.
On Dec 15, 1:51 pm, Paulo Vasconcellos <pfvasconcel...@gmail.com>
wrote:
>
> A nomenclatura de tipos (ou níveis) de requisitos não é uma coisa amplamente
> aceita. Particularmente o termo (que uso), "Requisitos do Usuário", gera
> dúvidas. Afinal, ele pode ser interpretado (corretamente) como um requisito
> funcional. A classificação aqui é bastante arbitrária: é de alto nível,
> então é de usuário. Tá bem detalhado, então é funcional (segundo aquele meu
> diagrama). Mas, ok, concordo contigo: ele é um Requisito do Usuário.
>
> Quanto as regras: pode parecer preciosismo, mas ainda assim eu trataria as 4
> variáveis como tal, variáveis. Tem negócio por aí que anda vendendo a prazo
> mesmo para quem tem restrições de crédito (alguém se lembrou daquela câmera
> que aparece diariamente no programa da Renata Fan? Então..). A idade também
> pode ser revista. Afinal, com 16 anos já se pode votar e trabalhar por aqui.
> Por que não pode comprar a prazo?
>
> Regrinha que aplico: há uma mínima chance de mudança? Então evite colocar em
> código.
>
> Ok?
>
> Abraços,
>
> Paulo
>
Francis Pontes de Albuquerque
desculpe o atraso, mas somente agora estou podendo acompanhar a lista.
Bom... continuo defendendo que a classifica��o mais complica que ajuda.
A aplica��o da regra de "m�nima chance" me d� uma id�ia de "Regra de
neg�cio = parametriza��o".
O problema � que algumas solu��es podem precisar de ser "no c�digo".
Um contra-exemplo t�pico � um sistema que o neg�cio exige um tempo
curto para entrar no mercado. N�o haver� tempo para "parametrizar" a
"regra de neg�cio". E n�o h� nada de errado nisto.
Minha sugest�o �:
- se vc se sente confortavel; n�o perde tempo na classifica��o; n�o tem
problema de comunica��o com todos envolvidos; ent�o classifique os
requisitos da forma que for mais conveniente a todos.
- se vc est� gastando mais tempo que deveria; h� conflitos relacionados
a classifica��o; as pessoas envolvidas est�o ficando confusas; ent�o n�o
classifique.
[]�s
Francis Pontes de Albuquerque
E-mail: fra...@eteg.com.br
Telefone: (31) 3889-0990
ETEG - Tecnologia Adaptada a sua Empresa
Shigueru escreveu:
> Entendido.
>
>
> On Dec 15, 1:51 pm, Paulo Vasconcellos <pfvasconcel...@gmail.com>
> wrote:
>> Oi Shigueru,
>>
>> A nomenclatura de tipos (ou n�veis) de requisitos n�o � uma coisa amplamente
>> aceita. Particularmente o termo (que uso), "Requisitos do Usu�rio", gera
>> d�vidas. Afinal, ele pode ser interpretado (corretamente) como um requisito
>> funcional. A classifica��o aqui � bastante arbitr�ria: � de alto n�vel,
>> ent�o � de usu�rio. T� bem detalhado, ent�o � funcional (segundo aquele meu
>> diagrama). Mas, ok, concordo contigo: ele � um Requisito do Usu�rio.
>>
>> Quanto as regras: pode parecer preciosismo, mas ainda assim eu trataria as 4
>> vari�veis como tal, vari�veis. Tem neg�cio por a� que anda vendendo a prazo
>> mesmo para quem tem restri��es de cr�dito (algu�m se lembrou daquela c�mera
>> que aparece diariamente no programa da Renata Fan? Ent�o..). A idade tamb�m
>> pode ser revista. Afinal, com 16 anos j� se pode votar e trabalhar por aqui.
>> Por que n�o pode comprar a prazo?
>>
>> Regrinha que aplico: h� uma m�nima chance de mudan�a? Ent�o evite colocar em
>> c�digo.
>>
>> Ok?
>>
>> Abra�os,
>>
>> Paulo
>>
>> 2009/12/15 Shigueru <msyamak...@gmail.com>
>>
>>
>>
>>> Paulo,
>>> Voc� falou das regras, mas sobre requisito do usu�rio ou requisito
>>> funcional n�o. Concorda que � um requisito do usu�rio? Ou dentre as
>>> op��es voc� escolheria a d) (um requisito funcional e 4 regras de
>>> neg�cio)?
>>> Agora sobre quebrar em 4 regras, assim como tamb�m o Jean sugeriu,
>>> talvez seja for�ar um pouco a barra. Vejam, duas claramente seriam:
>>> - Sufici�ncia salarial: 20% do seu sal�rio seja 2/3 maior que a
>>> presta��o solicitada
>>> - Estabilidade no emprego: deve estar empregado a mais de 1 ano
>>> J� que aqui caberia uma preocupa��o em parametrizar. As outras duas
>>> n�o. Seria preciosismo.
>>> []s
>>> Shigueru.
>>> On Dec 14, 2:43 pm, Paulo Vasconcellos <pfvasconcel...@gmail.com>
>>> wrote:
>>>> Ol�,
>>>> Seguem minhas considera��es:
>>>> 1. A distin��o entre requisitos e regras de neg�cio � fundamental. As
>>>> segundas s�o bem mais vol�teis que os primeiros. L� na implementa��o
>>> elas
>>>> deveriam merecer um tratamente diferente (visando a melhoria da
>>>> manutenabilidade da solu��o).
>>>> 2. No exemplo colocado, muito bom por sinal, temos uma regra composta
>>> por
>>>> 4 par�metros distintos. Ou seja, n�o � equivocada, em meu ponto de
>>> vista, a
>>>> interpreta��o de que seriam 4 regras. Como cada par�metro � aut�nomo
>>> (pode
>>>> ser alterado sem que isso signifique altera��o nos demais), deveria
>>> ser
>>>> implementado com a mesma independ�ncia.
>>>> 3. O pior cen�rio seria a "solidifica��o" daquela(s) regra(s) em
>>> c�digo.
>>>> 4. Um analista deve registrar a informa��o na ferramenta que ele tem
>>> em
>>>> m�os. Se a regra apareceu no momento em que ele *descobria e descrevia
>>> os
>>>> requisitos* (utlizando, por exemplo, uma especifica��o de casos de
>>> uso), n�o
>>>> vejo nenhum problema no registro dela naquele documento. Pelo
>>> contr�rio,
>>>> recomendo que assim seja feito. Da mesma forma que seria se a
>>> ferramenta
>>>> utilizada fosse uma *User Story*.
>>>> Abra�os,
>>>> Paulo
>>>> 2009/12/14 Jean Streleski <jrs....@gmail.com>
>>>>> Esqueci de ressaltar que n�o vi como a distin��o de requisitos possa
>>> trazer
>>>>> tantos preju�zos como o @Francis apontou.
>>>>> E entendi muito menos a defini��o dele entre o que � requisito e o que
>>> �
>>>>> regra de neg�cio.
>>>>> 2009/12/14 Jean Streleski <jrs....@gmail.com>
>>>>> Tamb�m vejo como o Shigueru e concordo integralmente com a opini�o dele
>>> em
>>>>>> rela��o �s opini�es.
>>>>>> Apenas fa�o a ressalva que talvez as condi��es possam ser quebradas em
>>>>>> quatro regras para fins de uma poss�vel e comum exce��o � regra.
>>> (Amanh� um
>>>>>> gerente aprova o cr�dito para algu�m que n�o tenha 18 anos, por
>>> exemplo).
>>>>>> Embora esta devesse ser uma preocupa��o da implementa��o, eu imagino
>>> que
>>>>>> depois uma m�quina de regras pudesse trabalhar compondo regras de
>>> neg�cio de
>>>>>> N maneiras diferentes, conforme novas situa��es surjam.
>>>>>> Mas, como dizia o Kerber aqui na lista, neste caso o AN � apenas
>>>>>> consultivo e n�o deliberativo.
>>>>>> 2009/12/14 Shigueru <msyamak...@gmail.com>
>>>>>>> Paulo,
>>>>>>> Vejo que no caso apresentado, h� um requisito de usu�rio que pode ser
>>>>>>> traduzido no caso de uso "Liberar cr�dito". Para tal tarefa, �
>>>>>>> necess�rio "avaliar o cliente" (requisito funcional) e cumprir uma
>>>>>>> regra (composta de 4 condi��es).
>>>>>>> Agora sobre concordar ou n�o...
>>>>>>> @Yoshima
>>>>>>> "Regras de Neg�cio ficam fora de casos de uso pois s�o de observ�ncia
>>>>>>> geral no sistema. Ficam na sua camada de neg�cios, pensando na
>>>>>>> implementa��o. N�o vale a pena colocar em casos de uso, pois v�rios
>>>>>>> casos de uso podem ter a mesma regra, e repetir n�o � uma boa id�ia e
>>>>>>> includes nesse caso ficam bem ruins."
>>>>>>> Concordo com a parte da implementa��o. J� sobre colocar as RNs no
>>> caso
>>>>>>> de uso, a limita��o est� na ferramenta (documento). No EA � poss�vel
>>>>>>> fazer os links, da� ter�amos essa restri��o eliminada.
>>>>>>> @Elvio
>>>>>>> "Em linhas gerais, regras de neg�cio definem ou restrigem termos do
>>>>>>> neg�cio. No seu caso o termo parece ser "libera��o de cr�dito" e o
>>>>>>> mesmo � restrito por uma �nica regra de neg�cio, sendo ela: cliente
>>>>>>> n�o possua ficha suja no SPC SERASA, assim como 20% do seu sal�rio
>>>>>>> seja 2/3 maior q a presta��o solicitada, deve estar empregado a mais
>>>>>>> de 1 ano e ser maior de 18 anos."
>>>>>>> Concordo integralmente.
>>>>>>> []s
>>>>>>> Shigueru.
>>>>>>> On Dec 14, 10:26 am, Paulo Vasconcellos <pfvasconcel...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Oi turma,
>>>>>>>> Por acaso voc�s viram uma thread que rolou na �ltima semana l� no
>>>>>>> UML-BR?
>>>>>>>> N�o gosto de fazer isso (importar debates), mas como n�o vi nenhum
>>> de
>>>>>>> voc�s
>>>>>>>> naquele papo, resolvi traz�-lo:
>>>>>>>> http://br.groups.yahoo.com/group/UML-BR/message/11658
>>>>>>>> A abertura da thread foi com a mensagem acima. Rolando a tela,
>>> voc�s
>>>>>>> ver�o
>>>>>>>> as mensagens que foram trocadas sobre o assunto. Quem ler me diga:
>>> o
>>>>>>> que
>>>>>>>> acharam? Concordam com aquelas sugest�es?
>>>>>>>> Abra�os e boa semana para todos.
>>>>>>>> Paulo
>>>>>>> --
>>>>>>> Mensagem do grupo AN-BR {An�lise de Neg�cios}.
>>>>>>> Para publicar mensagens, mande um email para: an...@googlegroups.com
>>>>>>> Para cancelar sua participa��o, mande um email para:
>>>>>>> an-br-un...@googlegroups.com
>>>>>>> Para mais op��es, visite a p�gina do grupo:
>>>>>>> http://groups.google.com/group/an-br?hl=pt-BR
>>>>>>> Este grupo � administrado e patrocinado pelo finito:
>>> pfvasconcellos.com
>>>>>> --
>>>>>> Jean Rozan Streleski
>>>>>> jean.r.strele...@gmail.com
>>>>>> msn: jean...@hotmail.com
>>>>> --
>>>>> Jean Rozan Streleski
>>>>> jean.r.strele...@gmail.com
>>>>> msn: jean...@hotmail.com
>>>>> --
>>>>> Mensagem do grupo AN-BR {An�lise de Neg�cios}.
>>>>> Para publicar mensagens, mande um email para: an...@googlegroups.com
>>>>> Para cancelar sua participa��o, mande um email para:
>>>>> an-br-un...@googlegroups.com
>>>>> Para mais op��es, visite a p�gina do grupo:
>>>>> http://groups.google.com/group/an-br?hl=pt-BR
>>>>> Este grupo � administrado e patrocinado pelo finito:
>>> pfvasconcellos.com
>>> --
>>> Mensagem do grupo AN-BR {An�lise de Neg�cios}.
>>> Para publicar mensagens, mande um email para: an...@googlegroups.com
>>> Para cancelar sua participa��o, mande um email para:
>>> an-br-un...@googlegroups.com
>>> Para mais op��es, visite a p�gina do grupo:
>>> http://groups.google.com/group/an-br?hl=pt-BR
>>> Este grupo � administrado e patrocinado pelo finito: pfvasconcellos.com
>>
>
Paulo Vasconcellos
Caros,
desculpe o atraso, mas somente agora estou podendo acompanhar a lista.
Bom... continuo defendendo que a classificação mais complica que ajuda.
A aplicação da regra de "mínima chance" me dá uma idéia de "Regra de
negócio = parametrização".
O problema é que algumas soluções podem precisar de ser "no código".
Um contra-exemplo típico é um sistema que o negócio exige um tempo
curto para entrar no mercado. Não haverá tempo para "parametrizar" a
"regra de negócio". E não há nada de errado nisto.
Minha sugestão é:
- se vc se sente confortavel; não perde tempo na classificação; não tem
problema de comunicação com todos envolvidos; então classifique os
requisitos da forma que for mais conveniente a todos.
- se vc está gastando mais tempo que deveria; há conflitos relacionados
a classificação; as pessoas envolvidas estão ficando confusas; então não
classifique.
[]´s
Francis Pontes de Albuquerque
E-mail: fra...@eteg.com.br
Telefone: (31) 3889-0990
ETEG - Tecnologia Adaptada a sua Empresa
Shigueru escreveu:
> Entendido.
>
>
> On Dec 15, 1:51 pm, Paulo Vasconcellos <pfvasconcel...@gmail.com>
> wrote:
>> Oi Shigueru,
>>
>> A nomenclatura de tipos (ou níveis) de requisitos não é uma coisa amplamente
>> aceita. Particularmente o termo (que uso), "Requisitos do Usuário", gera
>> dúvidas. Afinal, ele pode ser interpretado (corretamente) como um requisito
>> funcional. A classificação aqui é bastante arbitrária: é de alto nível,
>> então é de usuário. Tá bem detalhado, então é funcional (segundo aquele meu
>> diagrama). Mas, ok, concordo contigo: ele é um Requisito do Usuário.
>>
>> Quanto as regras: pode parecer preciosismo, mas ainda assim eu trataria as 4
>> variáveis como tal, variáveis. Tem negócio por aí que anda vendendo a prazo
>> mesmo para quem tem restrições de crédito (alguém se lembrou daquela câmera
>> que aparece diariamente no programa da Renata Fan? Então..). A idade também
>> pode ser revista. Afinal, com 16 anos já se pode votar e trabalhar por aqui.
>> Por que não pode comprar a prazo?
>>
>> Regrinha que aplico: há uma mínima chance de mudança? Então evite colocar em
>> código.
>>
>> Ok?
>>
>> Abraços,
>>
>>> Você falou das regras, mas sobre requisito do usuário ou requisito
>>> funcional não. Concorda que é um requisito do usuário? Ou dentre as
>>> opções você escolheria a d) (um requisito funcional e 4 regras de
>>> negócio)?
>>> Agora sobre quebrar em 4 regras, assim como também o Jean sugeriu,
>>> talvez seja forçar um pouco a barra. Vejam, duas claramente seriam:
>>> - Suficiência salarial: 20% do seu salário seja 2/3 maior que a
>>> prestação solicitada
>>> - Estabilidade no emprego: deve estar empregado a mais de 1 ano
>>> Já que aqui caberia uma preocupação em parametrizar. As outras duas
>>> não. Seria preciosismo.
>>> []s
>>> Shigueru.
>>> On Dec 14, 2:43 pm, Paulo Vasconcellos <pfvasconcel...@gmail.com>
>>> wrote:
>>>> Olá,
>>>> Seguem minhas considerações:
>>>> 1. A distinção entre requisitos e regras de negócio é fundamental. As
>>>> segundas são bem mais voláteis que os primeiros. Lá na implementação
>>> elas
>>>> deveriam merecer um tratamente diferente (visando a melhoria da
>>>> manutenabilidade da solução).
>>>> 2. No exemplo colocado, muito bom por sinal, temos uma regra composta
>>> por
>>>> 4 parâmetros distintos. Ou seja, não é equivocada, em meu ponto de
>>> vista, a
>>>> interpretação de que seriam 4 regras. Como cada parâmetro é autônomo
>>> (pode
>>>> ser alterado sem que isso signifique alteração nos demais), deveria
>>> ser
>>>> implementado com a mesma independência.
>>>> 3. O pior cenário seria a "solidificação" daquela(s) regra(s) em
>>> código.
>>>> 4. Um analista deve registrar a informação na ferramenta que ele tem
>>> em
>>>> mãos. Se a regra apareceu no momento em que ele *descobria e descrevia
>>> os
>>>> requisitos* (utlizando, por exemplo, uma especificação de casos de
>>> uso), não
>>>> vejo nenhum problema no registro dela naquele documento. Pelo
>>> contrário,
>>>> recomendo que assim seja feito. Da mesma forma que seria se a
>>> ferramenta
>>>> utilizada fosse uma *User Story*.
>>>> Abraços,
>>>>> Esqueci de ressaltar que não vi como a distinção de requisitos possa
>>> trazer
>>>>> tantos prejuízos como o @Francis apontou.
>>>>> E entendi muito menos a definição dele entre o que é requisito e o que
>>> é
>>>>> regra de negócio.
>>>>> 2009/12/14 Jean Streleski <jrs....@gmail.com>
>>>>> Também vejo como o Shigueru e concordo integralmente com a opinião dele
>>> em
>>>>>> relação às opiniões.
>>>>>> Apenas faço a ressalva que talvez as condições possam ser quebradas em
>>>>>> quatro regras para fins de uma possível e comum exceção à regra.
>>> (Amanhã um
>>>>>> gerente aprova o crédito para alguém que não tenha 18 anos, por
>>> exemplo).
>>>>>> Embora esta devesse ser uma preocupação da implementação, eu imagino
>>> que
>>>>>> depois uma máquina de regras pudesse trabalhar compondo regras de
>>> negócio de
>>>>>> N maneiras diferentes, conforme novas situações surjam.
>>>>>> Mas, como dizia o Kerber aqui na lista, neste caso o AN é apenas
>>>>>> consultivo e não deliberativo.
>>>>>> 2009/12/14 Shigueru <msyamak...@gmail.com>
>>>>>>> Paulo,
>>>>>>> Vejo que no caso apresentado, há um requisito de usuário que pode ser
>>>>>>> traduzido no caso de uso "Liberar crédito". Para tal tarefa, é
>>>>>>> necessário "avaliar o cliente" (requisito funcional) e cumprir uma
>>>>>>> regra (composta de 4 condições).
>>>>>>> Agora sobre concordar ou não...
>>>>>>> @Yoshima
>>>>>>> "Regras de Negócio ficam fora de casos de uso pois são de observância
>>>>>>> geral no sistema. Ficam na sua camada de negócios, pensando na
>>>>>>> implementação. Não vale a pena colocar em casos de uso, pois vários
>>>>>>> casos de uso podem ter a mesma regra, e repetir não é uma boa idéia e
>>>>>>> includes nesse caso ficam bem ruins."
>>>>>>> Concordo com a parte da implementação. Já sobre colocar as RNs no
>>> caso
>>>>>>> de uso, a limitação está na ferramenta (documento). No EA é possível
>>>>>>> fazer os links, daí teríamos essa restrição eliminada.
>>>>>>> @Elvio
>>>>>>> "Em linhas gerais, regras de negócio definem ou restrigem termos do
>>>>>>> negócio. No seu caso o termo parece ser "liberação de crédito" e o
>>>>>>> mesmo é restrito por uma única regra de negócio, sendo ela: cliente
>>>>>>> não possua ficha suja no SPC SERASA, assim como 20% do seu salário
>>>>>>> seja 2/3 maior q a prestação solicitada, deve estar empregado a mais
>>>>>>> de 1 ano e ser maior de 18 anos."
>>>>>>> Concordo integralmente.
>>>>>>> []s
>>>>>>> Shigueru.
>>>>>>> On Dec 14, 10:26 am, Paulo Vasconcellos <pfvasconcel...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Oi turma,
>>>>>>>> Por acaso vocês viram uma thread que rolou na última semana lá no
>>>>>>> UML-BR?
>>>>>>>> Não gosto de fazer isso (importar debates), mas como não vi nenhum
>>> de
>>>>>>> vocês
>>>>>>>> naquele papo, resolvi trazê-lo:
>>>>>>>> http://br.groups.yahoo.com/group/UML-BR/message/11658
>>>>>>>> A abertura da thread foi com a mensagem acima. Rolando a tela,
>>> vocês
>>>>>>> verão
>>>>>>>> as mensagens que foram trocadas sobre o assunto. Quem ler me diga:
>>> o
>>>>>>> que
>>>>>>>> acharam? Concordam com aquelas sugestões?
>>>>>>>> Abraços e boa semana para todos.
>>>>>>>> Paulo
>>>>>>> --
>>>>>>> Mensagem do grupo AN-BR {Análise de Negócios}.
>>>>>>> Para cancelar sua participação, mande um email para:
>>>>>>> an-br-un...@googlegroups.com
>>>>>>> Para mais opções, visite a página do grupo:
>>>>>>> http://groups.google.com/group/an-br?hl=pt-BR
>>>>>>> Este grupo é administrado e patrocinado pelo finito:
>>> pfvasconcellos.com
>>>>>> --
>>>>>> Jean Rozan Streleski
>>>>>> jean.r.strele...@gmail.com
>>>>>> msn: jean...@hotmail.com
>>>>> --
>>>>> Jean Rozan Streleski
>>>>> jean.r.strele...@gmail.com
>>>>> msn: jean...@hotmail.com
>>>>> --
>>>>> Mensagem do grupo AN-BR {Análise de Negócios}.
>>>>> Para cancelar sua participação, mande um email para:
>>>>> an-br-un...@googlegroups.com
>>>>> Para mais opções, visite a página do grupo:
>>>>> http://groups.google.com/group/an-br?hl=pt-BR
>>>>> Este grupo é administrado e patrocinado pelo finito:
>>> pfvasconcellos.com
>>> --
>>> Mensagem do grupo AN-BR {Análise de Negócios}.
>>> Para cancelar sua participação, mande um email para:
>>> an-br-un...@googlegroups.com
>>> Para mais opções, visite a página do grupo:
>>> http://groups.google.com/group/an-br?hl=pt-BR
>>> Este grupo é administrado e patrocinado pelo finito: pfvasconcellos.com
>>
>
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado e patrocinado pelo finito: pfvasconcellos.com
Ronan Lucio
Olá Francis,Minha sugestão tem muito a ver com o papo que rola em outra thread, sobre qualidade. Neste caso, qualidade interna.Dos últimos 10 anos, só consigo me lembrar de um caso em que optamos por colocar as regras em código. Era uma complexa solução de seguros (cálculo), e sei lá pq fez mais sentido não optar pela parametrização. Provavelmente falta de confiança (por parte do cliente) nos gerentes de produtos que deveriam atualizar seus produtos (em ciclos mensais). De qq maneira, me lembro de ter "engolido" a estratégia sem concordar muito com ela. :)
[]s
Ronan
Paulo Vasconcellos
A área de TI da empresa em questão não tinha muita 'moral' com as áreas de negócios (pra variar). Ao não optar por uma "senha master" eles criavam uma amarração - ficavam importantes. Sacou? hehe..
Abraços,
Paulo
Ronan Lucio
Fala sumido Ronan! Tudo bem? Espero que sim.
Opa! Sumido sim. Pero no mucho.
A área de TI da empresa em questão não tinha muita 'moral' com as áreas de negócios (pra variar). Ao não optar por uma "senha master" eles criavam uma amarração - ficavam importantes. Sacou? hehe..
[]s
Ronan