Eu resolvi escrever esse artigo devido a uma visita em um suposto novo cliente, depois de ele ter solicitado a criação de um sistema.
Grande parte das vezes que visitamos um cliente que necessita de um software de gestão para a empresa, a primeira coisa que escutamos é: "Eu quero pouca coisa", "É coisa rápida e fácil".
Escutamos isso porquê o cliente tem pouca noção para análisar um problema, então é aí que entra o analista de sistemas para levantar os requisitos de sistema.
INTRODUÇÃO
A análise de requisitos é uma das sub-áreas da engenharia de software, que a função é detectar e documentar problemas do cenário atual para que eles sejam implementados com qualidade e com o mínimo de manutenção possível.
Creio que cerca de 80% dos erros nos projetos são causados por defeitos inseridos durante a análise e requisitos, causando um custo maior de manutencão e de testes do sistema e, o pior são os erros descobertos pelos usuários. Atire a primeira pedra o programador que nunca escutou: "Está dando problema!", "Esta com bug!", "Não funciona!". Além disso, a pior coisa para uma empresa é a perda de oportunidades e de confiança com os clientes.
Para terminar a introdução, segundo a wikipedia, Análise de requisitos é: " O estudo das características que o sistema deverá ter para atender às necessidades e expectativas do cliente.
Cada funcionalidade demandada pelo cliente deve ser analisada para verificar os possíveis impactos no desenvolvimento das demais funcionalidades do sistema, e verificado em conjunto com a equipe de desenvolvimento se as necessidades tecnológicas para a sua implementação estão disponíveis."
ESTUDO DE VIABILIDADE
Você esta prestes a criar a documentação necessária e a implementar o novo sistema. Mas será que é realmente viável a criação do mesmo?
Uma forma de avaliar a viabilidade de um projeto é obter, através de interação com as partes interessadas a resposta às seguintes questões:
- Será que o sistema contribui para os objetivos da organização? (POR PARTE DO CLIENTE)
- Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado? (POR PARTE DOS ANALISTA/DESENVOLVEDOR)
- Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível? (POR PARTE DOS ANALISTA/DESENVOLVEDOR)
PROCESSOS DA ENGENHARIA DE REQUISITOS
Você deve estar se perguntando: "E quais são os passos para o levantamento de requisitos?"
- Identificação do problema (Questionar os problemas e as necessidades que o cliente esta enfrentando).
- Análise e negociação (Saber como funciona cada processo e a regra de negócio é fundamental!).
- Especificação e documentação (Documentar por meios legíveis todos os processos que cada tarefa terá. É nesta fase que se dá a produção do documento de especificação de requisitos).
- Validação (Rever os 3 passos anteriores e demonstrar que o documento de requisitos produzido corresponde ao sistema que o cliente pretende receber).
Esses passos podem ser feitos de vários meios: Entrevistas, Questionários, Workshops ou qualquer outro meio de obter o máximo de informações dos usuários.
Não podemos começar a implementar um sistema pelo que achamos que deve ser feito, por isso o usuário "trabalha", passando todas as informações necessárias.
Como criar a documentação jogando todos os requisitos funcionais e todos os processos que cada requisito terá, explicarei em outro Post...caso eu ainda esteja vivo com esse carnaval.
Abraços e até +.
2 comentários:
Como os requisitos são muito dinâmicos, após o término da fase de Engenharia de requisitos, como você pretende mantê-los atualizados?
Olá broodrigo,
desculpe a demora para responder, pois o blog não esta me avisando por e-mail quando recebo comentários.
A análise de requisitos é uma das partes do ciclo de vida de todo sistema.
Novas atualizações seja por qualquer ator(Cliente, Analista, desenvolvedor, hardware), são atualizadas tendo como base a análise de requisitos já existente.
Claro que em cima disso torna-se necessário a verificação da viabilidade, como se estivesse começando um novo requisito.
Uma das formas de manter a documentação atualizada, é no Caso de Uso. Por isso a importância da data de atualização e por qual analista o caso de uso foi atualizado.
Dai em cima disso é gerada uma nova implementação e testes.
Por isso costumamos chamar de "clico de vida de um sistema".
Tirei sua dúvida?
Postar um comentário