Modelos de Maturidade exigem implantação de processos e boas práticas da Engenharia de Software.
Engenharia de Requisitos é uma das principais atividades na construção de Software com qualidade e que agregue valor ao cliente.
Segundo Pressman "
Enteder os requisitos de um problema está entre as tarefas mais dificies enfrentadas por um engenheiro de Software".
Segundo Brooks "
A parte mais difícil ao construir um sistema de software é decidir o que construir. Nenhuma parte do trabalho afeta tanto o sistema resultante se for feita a coisa errada. Nenhuma outra parte é mais dificil de consertar depois".
Abaixo segue o fluxo de requisitos conforme a metodologia de desenvolvimento RUP.
Observando essas duas considerações podemos ver o quanto é importante a engenharia de requisitos no desenvolvimento de software.
Na engenharia de requisitos podemos obter o mecanismo apropriado para enteder a real necessidade do cliente, analisando o que deseja, avaliando a viabilidade, negociando a especificação e negociando uma solução viavel para o problema.
Na engenharia de requisitos temos 7 tarefas: (Concepção, Levantamento, elaboração, negociação, especificação, validação e gestão).
Concepção: Como podemos iniciar o desenvolvimento de um software, procurado evento catalizados onde pode gerar a necessidade de construção.
Levantamento: Validar quais são os objetivos do sistema e ao demais usuários
Problemas que vocês podem se deparar nessa etapa:
Problemas de Escopo, Problema de entendimento, Problemas de Volatilidade.
Elaboração: As informações obtidas nas etapas de Concepção e Levantamento nessa etapa são melhores elaboradas e trabalhadas. Elaboração é o refinamento de cenários onde os usuários terão que interagir.
Negociação: Não é icomum usuários solicitarem mais do que podemos construir ou que realmente se adeque a sua real necessidade, quando ocorrer esse situação será necessario negociar a melhor solução e assim gerenciar o conflito, para encontrar um denominador comum entre as partes.
Especificação: Pode ser um documento escrito, um conjunto de modelos de gráficos, um modelo matematico, um cenário contendo diversos casos de usos (nesse caso aqui é melhor ter apenas um artigo para tratar sua importância) ou até mesmo um protótipo. Alguns autores da area solicita um modelo-padrão para ser utilizado, para apresentar uma especificação de forma consistente.
Validação: Os artefatos produzidos nos itens anteriores são validados quanto a qualidade e garantir que todos os requisitos foram descritos conforme o solicitado, assim garantindo a qualidade do software.
Gestão: Os requisitos são passiveis de mudanças, nesse caso gestão de requisitos é um conjunto de atividades que ajuda a identificar, controlar e acompanhar as necessidades e suas mudanças, isso em qualquer etapa do ciclo de vida do software.
Agora você que não conhece nenhum template segu um link onde podemos obter um modelo padrão.
http://www.wthreex.com/rup/portugues/webtmpl/templates/req/rup_srs.htm
Dentro desse cenário apresentado vamos agora fazer uma explanação sobre os tipos de requisitos, já que agora conhecemos as suas etapas.
Requisitos Funcionais: São requisitos diretamentes ligados a funcionalidade de software, descrevem as funções que o software deve executar.
Requisitos Não Funcionais: São requisitos que expressam condiçoes que o software deve atender ou qualidades especificas que o mesmo deve contemplar.
Para obter um controle de requisitos com qualidade vamos seguir a lista de controle descrita no livro do Pressman Engenharia de Software. Alias muito bom recomendo.
- Os requisitos estão declarados de forma clara?
- A fonte do requisito foi identificada?
- O requisito está limitado em termos quantitativos?
- Que outros requisitos se relacionam a este requisito?
- O requisito viola quaisquer restrições de dominio de sistema?
- O requisito pode ser testado?
Bom acredito que de posse da lista de controle de requisitos, fluxo global para engenharia de requisitos, as fases dessa disciplina de engenharia de software e um template podemos construir ou iniciar o desenvolvimento do software, já adotando uma metodologia, coisa que convenhamos que não é muito utilizada podemos chegar a um resultado que apenas 16% dos projetos alcaçam, o término do projeto.
Abraços acredito que ja ajude essa breve explanação sobre Engenharia de Requisitos.
Até a proxima.