Requisitos

[Rodrigo Soares]

Pessoal, boa noite.

Vocês poderiam contribuir um pouco com a forma com que vocês escrevem requisitos?

Gostaria de melhorar o processo onde trabalho, sugerindo alguma forma de deixar os requisitos mais claros e diretos, sem gerar documentação desnecessária e que o cliente, em muitos casos, nem olha.

Por exemplo, em requisitos de interfaces, vocês indicam o tipo do campo, posição, legenda, tamanho, campos de pesquisa em um combo, etc? 

Nos requisitos de negócios, vocês detalham o máximo possível ou algumas coisas nem são tão detalhadas? Se não são tão detalhadas, como fazem com relação ao cliente que entende que deveria ter feito e como não tem documentado, não foi?

Grato,

Rodrigo Soares

11-98347-1700

[Gerson Dias]

Rodrigo,

Muitas vezes o cliente não olhará a documentação porque ela é não é "usável" e o cliente sabe que aquela documentação não gerará um software que é exatamente o que ele está imaginando. Uma documentação do tipo:

Interface: Cadastro de Cliente

Campo | Tamanho | Tipo

Nome         50        Texto

Idade            2        Número

Além de muito chata não mostra ao cliente o que ele vai receber, tão pouco o faz ter uma noção do que será usar esse software ou mesmo se é aquilo mesmo que ele quer. Enfim, seja o teu processo mais ágil ou mais tradicional, acredito que documentações devem ser mais visuais do que prescritivas. Um desenho da tela por exemplo, com diversos comentários em cada campo pode ser uma boa ideia, pois é bem visual tanto para o cliente quanto para o desenvolvedor por exemplo.

Sei que tua pergunta não foi somente voltada para este tipo de documento, mas, se posso lhe dar uma dica, tente ver como times que seguem métodos ágeis se comportam quanto às documentações do requisito, tente ver sobre o ferramentas como Selenium e sobre Especificação Executável (há pouco tempo houve uma discussão sobre isso no grupo). Pode ser que teu processo e equipe não suportem este tipo de coisa, mas você pode dar novas ideias para todos os envolvidos se der uma boa olhada como outras pessoas estão lidando com requisitos x documentação. 

Se quiser, de mais detalhes sobre o processo em que você está para que outras pessoas possam relatar suas experiências em cenários parecidos!

[]'s

Gerson Afonso Dias

2013/5/14 Rodrigo Soares <rodrigos...@gmail.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 pelo Capítulo SP do IIBA - http://www.theiiba.org.br/
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "Análise de Negócios . br" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para an-br+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Camilo Almendra]

Olá Rodrigo,

Em 14 de maio de 2013 19:29, Rodrigo Soares <rodrigos...@gmail.com> escreveu:

Vocês poderiam contribuir um pouco com a forma com que vocês escrevem requisitos?

Não ficou claro exatamente em qual ponto do processo de requisitos você está buscando melhoria, então vou assumir que há problema tanto no canal Cliente -> Equipe, como internamente na equipe.

 

Gostaria de melhorar o processo onde trabalho, sugerindo alguma forma de deixar os requisitos mais claros e diretos, sem gerar documentação desnecessária e que o cliente, em muitos casos, nem olha.

Cenários de uso é sempre uma boa forma de organizar e registrar requisitos. Claro, estou considerando que o tipo de sistema é o clássico "sistema de informação", com bem mais requisitos referentes a interação do usuário do que a computação e processamentos internos.

Cenários de uso são a base para as abordagens de casos de uso e de estória de usuários. Eu recomendo buscar os clássicos da área: para Casos, o livro do Cockburn, e para Estórias o livro de XP do Kent Beck ou o de User Stories do Mike Cohn.

 

Por exemplo, em requisitos de interfaces, vocês indicam o tipo do campo, posição, legenda, tamanho, campos de pesquisa em um combo, etc? 

Requisitos de interface pedem prototipação. Você pode começar com prototipação de baixa fidelidade, e incluir notas e comentários que detalham 'posição', 'tamanho', etc. 

 

Nos requisitos de negócios, vocês detalham o máximo possível ou algumas coisas nem são tão detalhadas? Se não são tão detalhadas, como fazem com relação ao cliente que entende que deveria ter feito e como não tem documentado, não foi?

Não é uma questão apenas de detalhar. Requisitos de negócios (RN) devem ser necessidades escritas/representadas de tal forma que se alinhem com objetivas e metas da organização. O detalhamento na verdade é derivação desses RN em requisitos de stakeholder (RSt) e depois derivação para requisitos de solução (RSo).

Nesse ponto, volto a questão dos cenários: se algo "deveria ter sido feito" e não foi, faltou uma comunicação com o cliente em termos de objetivos de usuários dentro do sistema. Esse é um problema que pode ocorrer (não estou dizendo que isso ocorreu na sua empresa) quando se conversa com o cliente usando como referência Tela X ou Módulo Y. O cliente pode ter no subconsciente uma série de cenários que a Tela X deve suportar, e esses cenários não serem compreendidos pela equipe, que imagina apenas um cenário principal para a tela.

Se os problemas não forem em termos de cenários que foram omitidos ou erroneamente entendidos, e sim relativo a detalhes de interface, layout, validação de campos, então adotar prototipação de alta fidelidade pode resolver.

Espero ter ajudado.

Abraços,

--
Camilo Almendra

[Silva, Ailton]

Olá....

 

Acho que não tem a “melhor forma” porque o mais importante – entendo - é escrever de uma maneira que qualquer pessoa “leiga” ou “fora” do projeto/demanda leia e entenda.

 

Aqui escrevemos (hipoteticamente):

 

1)      Requisito de negócio. Ex.: “O cliente deve poder cadastrar um pedido de campanha”

2)      Regra de negócios. Ex: “O pedido de campanha não deve permitir um ‘código de produto’ inválido.”

3)      Requisito Funcional. Ex.:  “O sistema deve permitir o usuário incluir as seguintes informações para um pedido de campanha: data, hora, número do pedido, cliente, número da campanha, segmento do cliente, telefone do cliente e valor do pedido”.

4)      Requisito Não funcional. Ex.:  “ O tempo de resposta do relatório de clientes não deve exceder 3 segundos.”

 

Outras empresas utilizam “estórias de usuário” para escrever “requisitos funcionais”.

 

Características de um requisito de boa qualidade:

 

- completo

- correto

- não ambíguo

- verificável

- necessário

- viável

- priorizado

 

Espero que ajude...ou...que provoque reflexões...

 

Abs

 

 

Ailton Silva   Análise de Negócios   Tel. 5511 2599-7627   ailton...@br.experian.com   serasaexperian.com.br

--

--
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 pelo Capítulo SP do IIBA - http://www.theiiba.org.br/
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "Análise de Negócios . br" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para an-br+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

---

This email and any attachments are for the exclusive and confidential use of the named intended recipient(s) and may be legally privileged. Any review, re-transmission, dissemination or any other use of its contents, or taking of any action in reliance upon this information by persons and/or entities other than the named intended recipient(s) is strictly prohibited. If you have received this communication in error, please send this communication back to the sender, disregard its contents, and promptly delete the original message and any copy of it from your computer systems. The misuse of this message will be dealt according to company rules and current legislation. This message expresses the sender’s point of view about the topics described and not necessarily expresses Serasa Experian’s opinion about them.

As informações contidas nesta mensagem e no(s) arquivo(s) anexo(s) são endereçadas exclusivamente à(s) pessoa(s) e/ou instituição(ões) acima indicada(s), e podem conter dados confidenciais. É expressamente proibido a pessoas não autorizadas, sob qualquer forma ou pretexto, utilizá-las, divulgá-las, alterá-las, de forma impressa ou copiada, total ou parcialmente. Caso tenha recebido esta mensagem erroneamente, por favor, notifique o remetente e providencie imediata exclusão da original e de qualquer cópia. O uso impróprio será tratado conforme as normas da empresa e da legislação em vigor. Esta mensagem expressa o posicionamento pessoal do subscritor e não reflete necessariamente a opinião da Serasa Experian.

[Claudio Br (Kerber)]

Sugiro perguntar para quem é cliente desses requisitos, principalmente os desenvolvedores. Meus requisitos variam de produto para produto, de time para time porque a forma de descrevê-los vai evoluindo conforme aprendemos mais uns sobre os outros.

A comunicação de um requisito é uma atividade essencialmente humana, portanto a interação, de preferência contínua, é o que deve guiar, não um padrão ou formatação específica.

O nosso foco precisa estar no objetivo que é "todos entenderam isso?", a não ser que para a organização os padrões sejam mais importante do que os produtos produzidos.

Há requisitos para os quais eu desenho a interface, há requisitos que ganham um esboço de diagrama de classes, outros merecem uma simulação em um arquivo Excel quando há matemática envolvida. O que não podemos fazer é nos obrigar a desenhar a interface quando há matemática envolvida e criar uma simulação do Excel quando o que importa é a interface.

Liberte-se das convenções e a coisa vai fluir bem melhor.

Atenciosamente,
Claudio Br

........_˜Ô
...._  \ >_
...(_) /  (_)

Em 17 de maio de 2013 09:27, Raphael Silva <raphaellea...@gmail.com> escreveu:

Rodrigo

Aqui na empresa tínhamos problemas de comunicação entre a equipe de Tecnologia e a área de Negócios.

Algumas mudanças ocorreram no decorrer de alguns meses e mudamos a metodologia de trabalho, testamos algumas formas, e isto nos possibilitou concluir que produzir user stories, além de tornar o processo mais ágil, trouxe o envolvimento e comprometimento de todos os participantes do projeto (time técnico, área de negócios, sponsors, ...).

Para escrever e gerenciar estas user stories, utilizamos o artefato product backlog, onde a estória recebe um Identificador, um nome, a descrição e os critérios de aceite.

Seguimos o conceito de que cada estória deve ser testável, pequena, de valor agregado ao negócio, negociável, estimável e independente.

Espero ter contribuido para as reflexões.

Abraços

--

[Ricardo Cristiano Tapia]

Kerber, tudo bem.

 

Você poderia dar alguns exemplos, creio que ajudaria na compreensão.

 

Abs.

 

Ricardo

[Fabrício Laguna]

Está bacana a discussão e os diferentes pontos de vista. Com certeza não há uma abordagem "bala de prata" e a melhor opção "vareia".

Para quem puder comparecer, acredito que a 3a Conferência de Análise de Negócios (24/05, próxima sexta-feira) será uma boa oportunidade de discutir diferentes formas de trabalhar com requisitos. Teremos um case de Gestão de Requisitos em metodologia tradicional e outro em cascata. O primeiro trabalha com modelagem em casos de uso bem formais e voltados para reuso no ciclo de vida do produto. O segundo utiliza user stories.

Maiores informações no endereço: http://iibasp2013.yubi.me/

Grande abraço,

Fabrício Laguna Consultor e Instrutor celular: (11) 99659-8948 skype: flaguna

[Claudio Br (Kerber)]

Concordo, a melhor opção "vareia", mas ela vareia em mais de um sentido, não é somente entre times/produtos, mas dentro do mesmo time/produto ao longo do tempo.

Ricardo Tapia, exemplos em PVT, beleza?

Atenciosamente,
Claudio Br

........_˜Ô
...._  \ >_
...(_) /  (_)

[Eduardo Cristiano Negrão]

Em minha opinião, além de se orientar pelo "cliente" do requisito, é interessante também você analisar os fatores ambientais de sua empresa. Se a documentação se torna um ativo de processo organizacional, documentando as funcionalidades e visando refletir, comunicar e controlar a evolução do que você possui no produto, então você precisará de um modelo de documentação e um gerenciamento de requisitos mais robustos para atualização e rastreamento das mudanças.

Caso contrário, se o objetivo de seu requisito é orientar o desenvolvimento do produto, considerando que ele é o principal entregável na organização, então a sua documentação e processos poderão ser mais "leves".

Att,  

2013/5/17 Claudio Br (Kerber) <clau...@claudiobr.com>

--

Eduardo Cristiano Negrão - eduardo...@gmail.com

Software Engineer

portalengenhariadesoftware.blogspot.com
portalarquiteto.com.br

[Rodrigo Soares]

Bom dia pessoal.. obrigado pelas considerações.. já deu pra refletir sim...

A documentação de fato é um ativo da empresa onde trabalho, sendo que já temos um repositório com uma grande quantidade de requisitos mapeados do software já em uso pelo cliente há alguns anos. A questão é que a forma como fazemos, geramos muita documentação, talvez com informações desnecessárias para o cliente final.. sempre que é alterado o comportamento de um requisito, a documentação com os requisitos alterados é enviada ao cliente, porém, em alguns casos chegam a dezenas de folhas... 

Daí queria entender como fazem isso, se teria alguma forma mais enxuta de elaborar os requisitos e compilar as alterações... 

Um exemplo de requisito de interface levantado aqui:

Disponibilizar formulário da tree-view para cadastro de registros da tabela de condições de atendimento (XPTO_CONDATENDIMENTO) com as seguintes características:

> CAMPOS:

- Código: do tipo inteiro. {Nome físico: CODIGO}

- Descrição: do tipo linha de texto, com no máximo 50 caracteres. {Nome físico: DESCRICAO}

- Urgência: do tipo lógico, devendo assumir 'Desmarcado' como valor inicial. {Nome físico: URGENCIA}

- Código exportação: opcional, do tipo linha de texto, com no máximo 5 caracteres. {Nome físico: CODIGOEXPORTACAO}

- Sigla: opcional, do tipo linha de texto, com 1 caractere. {Nome físico: SIGLA}

Quando fazemos a manutenção desse requisito, destacamos a alteração e enviamos essa documentação para o cliente (todo o requisito), junto com os demais requisitos alterados:

Disponibilizar formulário da tree-view para cadastro de registros da tabela de condições de atendimento (XPTO_CONDATENDIMENTO) com as seguintes características:

> CAMPOS:

- Código: do tipo inteiro. {Nome físico: CODIGO}

- Descrição: do tipo linha de texto, com no máximo 50 caracteres. {Nome físico: DESCRICAO}

- Urgência: do tipo lógico, devendo assumir 'Desmarcado' como valor inicial. {Nome físico: URGENCIA}

- Código exportação: opcional, do tipo linha de texto, com no máximo 5 caracteres. {Nome físico: CODIGOEXPORTACAO}

- Sigla: opcional, do tipo linha de texto, com 1 caractere. {Nome físico: SIGLA}

- Novo Campo: opcional, do tipo drop-down que deverá realizar pesquisa na tabela de xpto (TABELA_XPTO), realizando a busca pelos campos "Código" (CODIGO) e "Descrição" (DESCRICAO). Dica: "indica novo campo". {Nome físico: CAMPOXPTO}

Vocês atuam de que forma nesse caso?

Abs,

Rodrigo

[Claudio Br (Kerber)]

Sobre o rastreamento de mudanças: automação. Hoje podemos rastrear um requisito até o trecho de código que ele afetou. Isso mesmo: cada mudança no código vinculada ao respectivo requisito. Isso é algo que tentamos resolver com burocracia por anos e que a informática resolveu do seu jeito.

Cada centavo investido nessa automação traz muito mais retorno do que um centavo investido em templates que, por mais que tentemos, sempre acabam desvinculados da realidade, de como o software está em cada momento.

Eu fico muito preocupado quando as discussões aqui envolvem coisas como testes manuais e rastreabilidade de requisitos manual ou quase manual porque parece que estamos em um grupo de discussão de 1998.

O analista de negócios, por melhor intencionado que seja não vai conseguir resolver os problemas sozinho (como você pode ouvir aqui: http://www.slideshare.net/oclaudiobr/palestra-babrazil-20111124semefeitos-10417879). O desenvolvimento de software evoluiu muito nos últimos anos e essa gama de métodos e ferramentas está à nossa disposição, precisamos fazer uso dela como clientes.

A sua organização não sabe fazer isso? Seja analista de negócios! Isso é um GAP, uma lacuna (descrito no BABOK), uma falta de prontidão organizacional. Desenvolver software sem testes automatizados e com rastreabilidade manual é um baita gap e o analista de negócios tem o dever de apontar esse problema e qual seria o retorno disso para o... negócio.

Na empresa onde trabalho quando vendemos consultoria, o fazemos nas duas frentes, técnica e negócios porque não se sai do chão atuando em apenas uma (isso sim parece discurso dos anos 90 hein).

O ALM, Application Lifecycle Management, é o melhor amigo do analista de negócios e você deve virar um vendedor interno disso na sua organização caso ela ainda não leve isso a sério (veja mais aqui: http://www.lambda3.com.br/services/alm).

Bora trabalhar na década de 2010. Bora aprender a trabalhar com o GIT e a escrever requisitos na forma de testes automatizáveis.

Atenciosamente,
Claudio Br

........_˜Ô
...._  \ >_
...(_) /  (_)

[Selma gmail]

Cláudio,

·         Sempre muito firme em suas posições.

o   Concordo com você, mas nem todas as empresas estão MADURAS para tal.

 

·         Só acho que o analista de negócios sozinho não faz verão.

o   A estrutura acima dele, de gestores e executivos, tem que ver isto funcionando nos poucos lugares onde isto esteja mais pé no chão, com evidências de ganho para acreditarem e investirem nisto nas suas organizações.

o   Tem como disponibilizar alguma visita em alguma empresa onde você tenha implementado isto, mesmo que parcialmente, para podermos marcar uma visita?

§  Acho que o caminho é este.

·         Quanto a requisitos, deve ser o template mais simples possível, pois o segredo está em fazer as perguntas certas e garantir o elo e entrosamento bem forte entre os analistas e o pessoal que desenvolve e gerencia projetos.

o   Ainda sou defensora que as habilidades de comunicação e integração tem que melhorar muito nestas áreas técnicas de TI e Engenharia, especialmente.

 

Espero ter contribuído para o grupo com a minha visão.

 

Selma Carvalho, MSc, PMP

Selma...@gmail.com

Fones: (21) 6957-7712 / (21) 2529-2277

Fabrício Laguna

[Rafael Barbosa camargo]

Concordo com quase tudo do Claudio.

Exceto a venda de ALM...nem de longe...

[Claudio Br (Kerber)]

ALM da Lambda3 :)

Atenciosamente,
Claudio Br

........_˜Ô
...._  \ >_
...(_) /  (_)

[Rafael Barbosa camargo]

tool-vendor-guy :P

[Claudio Br (Kerber)]

Hehehe. Que nada, o Giovanni Bassi está agora ajudando um time cliente da Suzandeise a integrar código, fazer testes automatizados e deploy contínuo SEM TFS.

Não vou negar que gosto do TFS, mas pode ser síndrome de Estocolmo né? Será que o mesmo ocorre com o GIT?

Atenciosamente,
Claudio Br

........_˜Ô
...._  \ >_
...(_) /  (_)

[Rafael Barbosa camargo]

Huahua.

Acho que é síndrome de Estocolmo sim, pois também a tenho com o TFS na Resource...mas sempre que posso me questiono quanto a ALM "monobloco" "tool" "for all".

Guardo ótimas experiências com Wiki, JBehave, Concordion, Jenkis, Selenium, Fitinesse e Hudson.



Enviado pelo meu Windows Phone

---

De: Claudio Br (Kerber)
Enviada em: 21/05/2013 17:30
Para: an...@googlegroups.com
Assunto: Re: [an.br :: 9195] Re: Requisitos

[Claudio Br (Kerber)]

Estaria essa discussão ficando muito técnica? Nããããão. É de total interesse do analista de negócios :)

Atenciosamente,
Claudio Br

........_˜Ô
...._  \ >_
...(_) /  (_)

[Rafael Barbosa camargo]

FTW \o/

Enviado pelo meu Windows Phone

---

De: Claudio Br (Kerber)

Enviada em: 21/05/2013 19:50
Para: Rafael Barbosa camargo
Cc: an...@googlegroups.com
Assunto: Re: [an.br :: 9197] Re: Requisitos

[Anderson Valentim de Bastos]

A forma de escrever os requisitos deve variar levando em consideração, além do "tipo do requisito" como já mencionado pelo Kerber, como também com os stakeholders que irão "receber" o requisito, estou falando de escrever o mesmo de requisito de formas diferentes de acordo com o stakeholder. As técnicas que serão utilizadas devem ser adequadas aos stakeholders envolvidos no ciclo de vida do produto. Por exemplo: para o time de desenvolvimento: um diagrama de classes, domínio, casos de uso, sequência e etc... e para os gestores de negócio: protótipos, descrição em linguagem natural, planilhas e etc....

Anderson Valentim de Bastos
anderso...@yahoo.com.br
anderso...@gmail.com.br

[Jorge Diz]

Claudio:

Tudo é técnico. Há técnicas para gestão, para o projeto da interface entre humanos e dispositivos, para o marketing, para o teste, para as finanças e para a análise de negócios.

Odeio a frase: "isso é técnico" quando se fala de programação e ferramentas de software, como se o resto não fosse. A gente aprende e usa o lado técnico que se torna necessário para desempenhar uma certa função. Isso vale para qualquer profissional, seja qual for sua formação de origem.

Jorge Diz

2013/5/22 Anderson Valentim de Bastos <anderso...@gmail.com>

[Rafael Barbosa camargo]

Acho que o que o Claudio quis dizer é técnico no sentido de Programação, Código.

Não no sentido que não existem coisas técnicas em análise e talz.

[]s. 

[Fabrício Laguna]

Muito bom, isso!

Não tenho certeza se "tudo é técnico". Me parece que existem também outras "coisas" que talvez não sejam . Mas, com certeza há técnicas em praticamente todos os níveis. 

Sobre o tema análise de requisitos, eu gostava da visão síntese proposta na versão anterior do BABOK que classificava as técnicas de Análise em 3 grupos distintos:

• Dados e Comportamento
• Processos e Fluxo
• Uso

Cada grupo deste engloba uma série de técnicas. O interessante é que os 3 grupos propõem pontos de vista complementares.

Inté

Fabrício Laguna Consultor e Instrutor celular: (11) 99659-8948 skype: flaguna

Em 22 de maio de 2013 13:24, Jorge Diz <jorge...@gmail.com> escreveu: