Voce esta dizendo com isso que requisitos consiste tb em especificar uma solucao?
IMO, a diferenca entre especificar a solucao e desenvolver é um sprint.
Se isso nao é BDUF, realmente nao sei o que dizer.
[quote=cmoscoso][quote=sergiotaborda]
Especificar o solução , o software é uma coisa completamente diferente de desenvolve-lo e implementá-lo. Requisitos não são apenas os problemas que tem que ser resolvidos ( isso são requisitos macro)
[/quote]
Voce esta dizendo com isso que requisitos consiste tb em especificar uma solucao?
[/quote]
Quero dizer que apenas com a especificação de requisitos vc pode ter uma solução.
Sim, vc está especificando a solução do problema do cliente. Lembre-se que o problema do cliente é um problema de negocio e a solução é a resolução desse problema. No caso, tem um software envolvido, mas pode ser mais que isso. Pode ter hardware especifico envolvido também. Seguimento de normas. Adoção de padrões de trabalho, etc…
O designer e o arquiteto pegam esses requisitos e produzem uma arquitetura e um design. Ou seja, decidem tecnologias e como elas vão se interligar para implementar a solução proposta. Coisas como a plataforma frameworks, bancos etc… são decididos depois que se tem os requisitos. Caso contrário dá merda e o programador acaba sendo obrigado a fazer gambiarra.
Depois que se têm os requisitos , e o design, ai sim vamos à implementação. Os requisitos são agrupados em unidades de trabalho que os programdores executam. Quer chamar a isso de user stories, features … vc que sabe. O ponto é que existem essas únidades de trabalho. O ponto é não confundir essas unidades com requisitos.
Tlv do ponto de vista do programador seja tudo a mesma coisa, mas não é.
Se vc implementar as unidades com sprint ou sem sprint , se a gerencia é com scrum ou sem, se o trabalho é terceirizado ou outsourced… não importa.
BDUF signfica que o designer e o arquiteto fazem toda a modelagem antes da programação começar e não que os requisitos são levantados antes da programação começar. Como já lhe disse, Design não signficia levantamento de requisitos.
Imagine que vc vai mandar fazer um movel sob medida a um marceneiro. Vc chega-lá e pergunta:
-Amigo, quero que me faça um movel.
-Blz, qual movel ?
-Um movel para a sala.
-Qual tipo de movel ?
-Uma mesa.
-Com gavetas ?
-não.
-De jantar ?
-não.
-Explique-me exactamente como é essa mesa …
(algum tempo depois o mrceneiro faz um esboço da mesa e pergunta)
- É mais ou menos isso ?
- Sim. qual é o preço ?
-Vou fazer o orçamento e lhe digo depois
A conversa continua até que o marceneiro saiba exactamente o que tem que fazer. É isso que ele vai orçar e executar.
Ha um dialogo entre os dois até que seja acordado o que será feito.
Aquele dialogo é o levantamento de requisitos. Não ha madeira nem ferramentas de marceneiro associadas a ela, embora o tema da conversa seja sobre um movel de madeira que será construido usando certas feramentas.
O levantamento de requisitos tem que acontecer antes de começar a construir, porque não ha como saber o que o cara quer sem perguntar primeiro. Claro que ha ajustes conforme a coisa vai, mas ai não é mais levantamento de requisitos, são ajustes. às vezes aparecme requisitos novos. Mas ai ha um aumento do projeto ou o cliente tem que dicidir postergar para outra versão ou abandonar outros requitios para incluir esses. Para os novos requisitos têm que haver um novo levantamento. E assim vai…
é mais claro agora?
Só que desenvolver software não é a mesma coisa que levantar prédio nem fabricar móveis.
Mas levantar requisitos é igual em qualquer ocasião.
Requisitos não são software. Software é uma das muitas formas de satisfazer os requisitos.
Requisitos diferentes têm formas diferentes de serem satisfeitos.
O ponto é exemplificar o que “levantar requisitos” é e como isso nada têm a ver com a fase posterior de construir as coisas.
Estão partindo de uma ideia de algo que poderiamos chamar de requisitos on-the-fly ( eu levanto quando preciso) : isso simplesmente não funciona. O que é on-the-fly são os ajustes.
Vc faz o sistema inteiro e é perfeito. Agora o cliente pergunta : como eu faço para mostrar em espanhol ?
Ups… se isso não era um requisito, não havia como prever que ele queria isso. Então vc não fez.
De quem é o erro ? Não está escrito nos requisitos que precisa, mas tb não está que não precisa. (afinal os requisitos nem estão escritos, são on-the-fly)
Repare que o seus sistema falhou ao olhos do cliente, porque ele preveu que o sistema teria isso.
Estas falhas acontencem quando os requisitos não são levantados com antecedencia.
[quote=sergiotaborda]
…
Vc faz (…)
Repare que o seus sistema falhou ao olhos do cliente, porque ele preveu que o sistema teria isso.
Estas falhas acontencem quando os requisitos não são levantados com antecedencia. [/quote]
:idea: Você tem informação sobre o uso de ficha de Volere, para levamento de requisitos tecnológicos ou esse conceito de template é algo ultrapassado, entranto esse tipo de requisito deva se encaixar como elicitação de requisitos, onde envolve Template de Alta-Pressão:Kree um Ranfath
[quote=Marcio Duran][quote=sergiotaborda]
…
Vc faz (…)
Repare que o seus sistema falhou ao olhos do cliente, porque ele preveu que o sistema teria isso.
Estas falhas acontencem quando os requisitos não são levantados com antecedencia. [/quote]
:idea: Você tem informação sobre o uso de [b]ficha de Volere/b
[/quote]
não, não sei o que é isso. Pelo que puder entender (http://www.systemsguild.com/GuildSite/Robs/Template.html)
é um padrão de escrita de requesitos. Se for isso, é legal, mas não é para ser abusado. É apenas um guia.
Um livro legal de padrões de requisitos que tb aborda documentação e templates é http://www.microsoft.com/MSPress/books/10808.aspx. Este livro eu acho muito bom porque chama a atenção do que precisa ser levantado em um requisito e quais outros requisitos nascem dele. Acho que todo o analista (seja do que for) precisa ler este.
Tá dificil!
[quote=sergiotaborda]
O designer e o arquiteto pegam esses requisitos e produzem uma arquitetura e um design. Ou seja, decidem tecnologias e como elas vão se interligar para implementar a solução proposta. Coisas como a plataforma frameworks, bancos etc… são decididos depois que se tem os requisitos.[/quote]
Se isso é decidido depois o que consiste realmente “decidir tecnologias e sua interligacao para implementar a solucao”.
Nao era vc que estava recomendando leitura de agile ainda pouco?
A que ponto chegamos… :evil:
Me permita o cv…
[quote=cmoscoso]Tá dificil!
O que é que vc não entendeu ?
Requisitos -> decisão de como implementa (aka modelo) -> implementação ( aka codigo)
A decisão vem depois dos requisitos serem sabidos.
Acho que vc está pensando e um ciclo assim:
Requisitos -> decisão de como implementa (aka modelo) -> implementação ( aka codigo) -> adiciona requisitos -> altera modelo -> altera codigo-> adiciona requisitos -> altera modelo -> altera codigo-> … etc…
Eu estou-lhe dizendo que é :
Requisitos -> modelo inicial -> unidades de trabalho -> implementação ( aka codigo) -> altera modelo -> adiciona unidades de trabalho -> altera modelo -> altera codigo -> adiciona unidades de trabalho -> altera modelo -> altera codigo -> …
Um BDUF seria
Requisitos -> modelo inicial -> unidades de trabalho -> implementação ( aka codigo) -> altera codigo -> altera codigo -> altera codigo -> …
consegue ver a diferença ?
Se não consegue desisto. Alguem que explique melhor.
Ficou claro agora. Voce considera o modelo como algo que vive alem do codigo.
Requisitos sao conhecidos.
Torna requisito uma especificacao executavel -> design (aka modelo/codigo) -> Torna outro requisito uma especificacao executavel -> design (aka modelo/codigo) -> adiciona especificacao -> design (aka modelo/codigo) etc…
Nao há certificacao melhor pra agilidade do que essa. Reconhecer que vc sabe praticamente nada do sistema de UP FRONT, antes de implementa-lo.
Sim, e a segunda opcao parece tentadora. Na pratica é o que acaba acontecendo. Ou alguem ja viu por ai transformacao de modelos assim como prega o pessoal do MDA?
Se era isso que vc queria dizer com “UML não é documentação” acho que nao era essa a intencao do autor.
São conhecidos ? Por quem ? Como se tornam conhecidos dessa(s) pessoa(s) ?
[quote=sergiotaborda]
Leia o artigo do Rodrigo Yoshima na Mundo Java para mais detalhes de porque UML não é uma documentação e porque não se deve abusar de Casos de Uso. [/quote]
Está disponível para download este artigo:
Não vejo diferença entre uma Storie e um Caso de Uso. A motivação de ambos é a mesma coisa. Quando falamos “usar caso de uso” é simplesmente especificar um software sob o ponto de vista do usuário. Alguma diferença com relação à User Stories?
Use Case é um conceito que existe mesmo você não se importando que eles existam.
[quote=rodrigoy]Não vejo diferença entre uma Storie e um Caso de Uso. A motivação de ambos é a mesma coisa. Quando falamos “usar caso de uso” é simplesmente especificar um software sob o ponto de vista do usuário. Alguma diferença com relação à User Stories?
Use Case é um conceito que existe mesmo você não se importando que eles existam.
[/quote]
Mesmo sendo essa diferenca irrelevante para a discussao atual eu tentei mas nao consegui entender o seu ponto. Sao conceitos iguais porque suas motivacoes sao iguais? É isso?
Vc colocou que equipes ágeis não usam casos de uso. Se você partir da premissa que a raiz da técnica de User Stories são as práticas do Jacobson (Use Cases), TODAS AS EQUIPES ÁGEIS usam casos de uso. Agora especificação formal de casos de uso algumas equipes ágeis não usam.
Só isso… sei que vc está no calor da discussão… deixa eu ficar quietinho aqui senão vai sobrar porrada pra mim também… pode continuar sua acalorada discussão com o Sergio… 
“É um absurdo total não querer entender a UML e pior ainda querer desmerecer Use Case, ou levantamento de requisitos.”
Vejo em tudo requisitos, aliás não se pode imaginar entender serviços em arquitetura J2EE, JEE, SpringFrameWork, .NET onde tudo passa a ter contexto ou qualquer melhor significado tecnologico por decisões de requisitos ao sistema e por os mesmo serem compativeis ao interesses por sua arquitetura ou não.
Até por analise de ponto de função ter o uso de uma linguagem que seja melhor aderente ao tempo de projeto, e por ai vai., o que me transfere um requisito por optar por um outra solução.
Estão querendo desmerecer uma matéria onde a Analise de Requisitos que permite o melhor estudo possivel de viabilidade para senão a melhor adequação de artefatos de sistemas,e implementa-las posteriormente a uso da OO e Design Patterns desejáveis.
[quote=rodrigoy]
Só isso… sei que vc está no calor da discussão… deixa eu ficar quietinho aqui senão vai sobrar porrada pra mim também… pode continuar sua acalorada discussão com o Sergio… [/quote]
Minha nao, sou da paz! 8)
Além do mais eu ja desisti de tentar convencer o Sergio que UML ´e no maximo documentacao. 
Mas se nao for capaz de ater-se ao tema do topico sua decisão não é de todo ruim. :thumbup:
[quote=cmoscoso][quote=rodrigoy]
Só isso… sei que vc está no calor da discussão… deixa eu ficar quietinho aqui senão vai sobrar porrada pra mim também… pode continuar sua acalorada discussão com o Sergio… [/quote]
Minha nao, sou da paz! 8)
Além do mais eu ja desisti de tentar convencer o Sergio que UML ´e no maximo documentacao.
[/quote]
Ah! era isso que estava tentando ? … quem diria…
Eu achei que vc estava falando de levantamento de requisitos , sua relação com o desenvolvimento e tentando constestar que
Casos de Uso não são formas de capturar requisitos…
… afinal foi tudo perda de tempo.
Acho que vcs todos nao sabem nada, tudo uns ,muleke que no maximo programou uns CRUDzinho. A unica pessoa que falou algo com sentido aki foi o Marcio Duran
:thumbup: [size=24]Thank you !!![/size]