cmoscoso:
Marcio Duran:
:idea: O Analista de negócio tem que se situar sobre os requisitos de sistema b[/b], quem figura tal possibilidade ao plano de modelo de processo é quem interpreta diretamente os requisitos sistemicos com o stakeholders, é o Analista de requisitos(Use Case), (…)
:shock: Voce acha benefico dividir o projeto em fase de requisitos e outra de implementacao :shock:
:?: Analista de Requisitos non ecziste. Mais alguem sabe o que é isso alem do Marcos?
:arrow: Lamento Marcos por saber que vc se denomina analista de requisitos, mas nao vejo necessidade de intermediarios entre o analista de negocio e os programadores para criacao dos casos de uso. :thumbup:
:idea: Penso sim que algumas vezes a figura de um lider tecnico PODE ser importante. Pra concentrar a comunicacao com o analista de negocio, definir a arquitetura geral, inspecionar codigo e programar claro.
Tá dificil de acertar com o nome do cara … :lol: :lol: :lol: :lol: :lol:
Veja bem, os requisitos são para o software o que as leis da física são para a física e os axiomas para a matemática. São as “verdades absolutas” que o software tem que cumprir. Através dos requisitos vc pode prever o funcionamento do software. (o inverso não é verdade)
Sim, alguns são opcionais e alguns são mais importantes que outros, mas os requisitos - que não são software - são a alma do software quando ele estiver pronto.
Bom, então, o levantamento de requisitos é tão importante quanto o software em si. Um sem o outro não faz sentido. As ferramentas, talentos, condicionamentos, treino, etc… que são necessários para construir software não se assemelham aos de levantamento de requisitos. Tal como os de um matemático não se assemelham ao de um lingüista.
Repare que a competência do programador não é levantar requisitos é implementar um modelo que os cumpre. Um bom programador não necessariamente é um bom “levantador de requisitos” e vice-versa.
É como um cara que é bom de matemática ser bom de linguas. São dois mundos diferentes. Não é impossivel, mas em uma sociedade especializada como a nossa, é muiiito raro.
Sim, pode existir um cara que não sendo especializado em nenhum das duas, entenda as duas e ajude a catalizar o dialogo entre ambos ( quem seria esse ? o coordenador? o lider? o gerente? tanto faz… não ha cursos para : cara-que-sabe-um-pouco-de-tudo-para-entender-todos)
Então existe o cara que é melhor a programar e o cara que é melhor a conversar. Levantar requisitos é isso: conversar. É entender, ouvir, perguntar, esclarecer, é ser os olhos e ouvidos da equipa. Repare que ele não lida com problemas como custo, tempo e esforço. Isso é papel do gerente. O gerente por sua vez não interfere nem com o levantamento de requisitos nem com a programação. Ele só deve estar preocupados que as coisas aconteçam nos prazos e custos certos. Mas todos têm que conversas entre si. Isso é o significado de equipa.
Casos de uso não são ferramentas para capturar requisitos. São ferramentas para explorar os requisitos. Exercitá-los e testá-los de forma abstrata. Deixá-los mais simples para o humano comum entender. São muletas para levantar mais requisitos ou esclarecer outros.
Os casos de uso formam a interação com o sistema, mas nem de perto compõem todos os requisitos. Por exemplo, requisitos não-funcionais não cabem em um caso de uso. Requisitos de tipos de dados, interfaces técnicas de, e com, outros sistemas. Requisitos de conformidade com normas ( ISO por exemplo) ou com documentação de terceiros, etc… Casos de Uso são uma ferramente util, mas limitada, que nunca serão capazes de capturar todos os requisitos.
Os requisitos de um sistema são uma simples lista (aka texto). Toda a UML é utilizada para modelar (Unified Modeling Language). Modelar não é levantar requisitos, é arranjar formas de os cumprir. É o rio entre o levantamento e a programação. Esse trafego entre as margens é feito pelo designer e pelo arquiteto juntos( cada um na sua visão) e em ultima grau pela equipe como um todo.
Construir software é um trabalho de uma equipe multi-disciplinar. Isso significa diferentes pessoas fazendo diferentes coisas. Se o mesmo cara sempre faz a mesma coisa em todos os projetos isso é um outro assunto.
O ponto é que alguém tem que as fazer.
Não sei como chamar ao cara cuja responsabilidade é levantar os requisitos. Analista de sistemas ? com certeza não. Analista de Negócios ? pode ser. Analista de Requisitos ? Ok, porque não ?
O cara que levanta os requisitos quase nunca tem o poder de interferir com eles. Ou seja, ele ,quase nunca, tem o poder de convencer o cliente que o requisito que ele está pedindo não faz sentido para o negocio( aka para o cliente ter lucro). “Poder” significa aqui “não lhe pagam para isso” e/ou “ninguém está interessado nisso”. Ele filtra, mas passivamente.
Quando o cara é contratado para levantar os problemas do negocio e/ou como um software o poderia ajudar, esse cara ,tem o poder de convencer o cliente. Esse é o real Analista de Negócios. Ele é pago, para analisar o negocio.
O papel do analista de negócios pode, muitas vezes, confundir-se com o de analisa de requisitos. Tudo depende de quanto poder o cara tem para alterar e/o sugerir requisitos com base no que ele observa do cliente. É uma questão de nivel e de maturidade da pessoa e não do seu “cargo”. Depende também do contrato, se o cliente quer que se faça esse trabalho extra, ou não. Contudo, para que o levantador de requisitos faça o seu trabalho corretamente ele tem que ter a capacidade de entender o negocio do cliente.
Resumindo, não ha porque criar nomes novos para a mesma coisa. Analista de Negócios serve bem para todas as ocasiões que sejam diferentes de gerencia e sejam diferentes de implementação. Mas tal como falamos de arquiteto, desenvolvedor, programador, etc… tb podemos entender categorias dentro do papel do analista: de requisitos, de negocio , de risco, de mercado, etc… Não significa que são pessoas diferentes, mas são papeis diferentes.
É Marcio Duran :lol: :lol: :lol:
