Engenharia de requisitos - Requirements engineering

Engenharia de requisitos ( RE ) é o processo de definição, documentação e manutenção de requisitos no processo de projeto de engenharia . É uma função comum na engenharia de sistemas e engenharia de software .

O primeiro uso do termo engenharia de requisitos foi provavelmente em 1964 no artigo da conferência "Maintenance, Maintainability, and System Requirements Engineering", mas não entrou em uso geral até o final dos anos 1990 com a publicação de um tutorial da IEEE Computer Society em março 1997 e o estabelecimento de uma série de conferências sobre engenharia de requisitos que evoluiu para a Conferência Internacional de Engenharia de Requisitos .

No modelo em cascata , a engenharia de requisitos é apresentada como a primeira fase do processo de desenvolvimento. Métodos de desenvolvimento posteriores, incluindo o Rational Unified Process (RUP) para software, presumem que a engenharia de requisitos continua durante a vida útil de um sistema.

O gerenciamento de requisitos, que é uma subfunção das práticas da Engenharia de Sistemas, também está indexado nos manuais do International Council on Systems Engineering (INCOSE).

Atividades

As atividades envolvidas na engenharia de requisitos variam amplamente, dependendo do tipo de sistema que está sendo desenvolvido e das práticas específicas da organização envolvidas. Isso pode incluir:

  1. Requisitos criação ou elicitação de requisitos - promotores e partes interessadas se encontram; os últimos são indagados sobre suas necessidades e desejos em relação ao produto de software.
  2. Análise e negociação de requisitos - os requisitos são identificados (incluindo novos se o desenvolvimento for iterativo) e os conflitos com as partes interessadas são resolvidos. Tanto as ferramentas escritas quanto as gráficas (as últimas comumente usadas na fase de design, mas algumas as consideram úteis também neste estágio) são usadas com sucesso como auxiliares. Exemplos de ferramentas de análise escritas: casos de uso e histórias de usuários . Exemplos de ferramentas gráficas: UML e LML .
  3. Modelagem de sistema - alguns campos de engenharia (ou situações específicas) exigem que o produto seja completamente projetado e modelado antes do início de sua construção ou fabricação. Portanto, a fase de projeto deve ser realizada com antecedência. Por exemplo, as plantas de um edifício devem ser elaboradas antes que qualquer contrato possa ser aprovado e assinado. Muitos campos podem derivar modelos do sistema com a Linguagem de Modelagem de Ciclo de Vida , enquanto outros podem usar UML . Nota: Em muitos campos, como engenharia de software, a maioria das atividades de modelagem são classificadas como atividades de projeto e não como atividades de engenharia de requisitos.
  4. Especificação de requisitos - os requisitos são documentados em um artefato formal denominado Especificação de Requisitos (RS), que se tornará oficial somente após a validação. Um RS pode conter informações escritas e gráficas (modelos), se necessário. Exemplo: Especificação de requisitos de software (SRS).
  5. Validação de requisitos - Verificar se os requisitos e modelos documentados são consistentes e atendem às necessidades das partes interessadas. Somente se o rascunho final passar no processo de validação, o RS se torna oficial.
  6. Gerenciamento de requisitos - Gerenciar todas as atividades relacionadas aos requisitos desde o início, supervisionando enquanto o sistema é desenvolvido e até mesmo depois de ser colocado em uso (por exemplo, mudanças, extensões, etc.)

Às vezes, eles são apresentados como estágios cronológicos, embora, na prática, haja uma considerável intercalação dessas atividades.

A engenharia de requisitos demonstrou contribuir claramente para o sucesso do projeto de software.

Problemas

Um estudo limitado na Alemanha apresentou possíveis problemas na implementação da engenharia de requisitos e perguntou aos entrevistados se eles concordavam que eram problemas reais. Os resultados não foram apresentados como generalizáveis, mas sugeriram que os principais problemas percebidos eram requisitos incompletos, alvos móveis e time boxing, com problemas menores sendo falhas de comunicação, falta de rastreabilidade, problemas terminológicos e responsabilidades pouco claras.

Crítica

A estruturação do problema, um aspecto-chave da engenharia de requisitos, tem sido especulada para reduzir o desempenho do projeto. Algumas pesquisas sugerem que é possível que, se houver deficiências no processo de engenharia de requisitos, resultando em uma situação onde os requisitos não existam, os requisitos de software podem ser criados independentemente como uma ilusão, deturpando as decisões de design como requisitos

Veja também

Referências

links externos