Eric Lemes de Godoy Cintra is a software developer. I’m always trying to share a bit of the stuff I end up using on a daily basis and I found relevant for enthusiasts and professional developers.
I’m interested in software design, C#, C#, C++, Python, agile methodologies (Scrum, Lean, Kanban), code metrics, build and deploy automation.
If you want to contact me directly, I can be found:
- E-mail: ericlemes at gmail.com
- Twitter: @eric_lemes
- Linked in: http://br.linkedin.com/in/ericlemes
I kindly ask who adds me on social network that sends a message telling that you found me through this blog. Since there are a lot of fake profiles, sometimes I don’t accept real profiles by mistake.
Eric Lemes' Blog 
Eric, li teu artigo sobre levantamento de requisitos e gostei bastante. Você deve saber que na maioria das vezes, no esquema de trabalho em fábrica, não temos muito contato com os desenvolvedores. Queria saber se existe (na disciplina de requisitos) algum documento formal que contenha apenas as informações (campos, filtros e regras) que devem ser buscadas/fornecidas, e que oriente a equipe de desenvolvimento, na construção de um webservice.
Aguardo um breve retorno.
Muito obrigada.
Helena.
Helena,
Esse comentário está aqui a um tempão e eu não respondi. Desculpe.
Confesso que eu busquei esse documento perfeito de requisitos um tempão da minha vida. Nunca achei literatura ou técnicas de descrição deles mais práticas do que as que eu descrevi no post sobre requisitos. A questão é que cada documento é um modelo. Um modelo sempre vai ser uma abstração, uma simplificação do que é a realidade, senão deixaria de ser o modelo e sim o próprio artefato final. Por exemplo, se uma maquete fosse tão perfeita como o prédio, não haveria razão para se fazer o prédio.
Esse é o problema com software. Chegar numa boa definição de requisito pode ser as vezes mais que a metade do caminho de se fazer o software. É por isso que mais e mais, eu venho exercitando o caminho de requisitos num ambiente ágil (tem um post sobre isso), porque o importante do requisito ou de qualquer documento é comunicar o que fazer da melhor forma possível. Por melhor forma, entendo custo x benefício. Se fazer e manter os modelos é mais caro que fazer o software, não faz sentido.
E infelizmente tem muitas empresas que ainda trabalham nesse modelo de que as pessoas se conversam através de documentos, e infelizmente é um modelo falido. Se você observar as grandes empresas de tecnologia que atingem resultados fenomenais (Google, Microsoft, Amazon, etc), elas se organizam em pequenos times autônomos, não em estruturas faraônicas que se conversam através de documento e contratam desenvolvimento baseado em hora homem (como se fosse uma commodity).
Espero que ajude.
Abraço,
Eric