Engenharia De Requisitos 1

Os Processos Típicos da Engenharia de Requisitos – Parte 1 Fonte: Kotonya e Sommerville – Requirements Engineering – Processes and Techniques ISBN 0-471-97208-8 Traduzido por Eduardo Marquioni Segundo o IEEE1 um requisito é definido como: 1. Uma condição ou capacidade necessitada por um usuário para resolver um problema ou atingir um objetivo. 2. Uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de sistema para satisfazer um contrato, padrão, especificação, ou outro documento de formalidade. 3. Uma representação documentada de uma condição ou capacidade como em (1) ou (2). “O começo é a parte mais importante do trabalho.” – Platão Geralmente os projetos de software são entregues com atraso, custo acima do estimado e não atendem às reais necessidades do usuário final ou da Organização que está pagando por ele. As falhas em sistemas não são devidas ao staff incompetente ou engenharia de software pobre; elas são conseqüência de problemas com os requisitos de sistema. Requisitos de sistema são as especificações dos serviços que o sistema deve prover, as regras e informações de background que são necessárias para desenvolver o produto. O processo de engenharia de requisitos pode ser descrito como um processo sistemático de 5 passos distintos: elicitação de requisitos2, análise e negociação de requisitos, especificação de requisitos, modelagem do sistema, validação de requisitos, gerenciamento de requisitos. O termo “engenharia” é aplicável por se tratar de processo prático e sistemático para identificação da melhor solução. A partir desta edição do InfoChoose, serão apresentados em linhas gerais as características dos 5 processos típicos da Engenharia de Requisitos. Neste artigo, serão tratadas a Elicitação de Requisitos e a Análise e Negociação de Requisitos.

1. Elicitação de Requisitos A elicitação de requisitos corresponde a identificar junto aos clientes, usuários e outros envolvidos quais são os objetivos do sistema ou produto, o que deve ser acompanhado, como o sistema ou produto se encaixa no contexto das necessidades do negócio e, finalmente, como será a utilização do sistema ou produto no dia-a-dia. “A parte mais árdua na construção de um software consiste exatamente em identificar ’o que’ construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correções posteriores.” – Fred Brook Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas das razões desta dificuldade: • Problemas de escopo: os limites do sistema são geralmente definidos de forma incompleta, ou os clientes/usuários especificam detalhes técnicos desnecessários que podem confundir (ao invés de esclarecer) os objetivos gerais do sistema; • Problemas de compreensão: os clientes/usuários: • Não estão completamente certos das necessidades; • Têm uma compreensão pobre das capacidades e limitações de seu ambiente computacional; • Não possuem uma compreensão plena do domínio do problema; • Têm problemas comunicando suas necessidades aos engenheiros de software; • Omitem informações que julgam óbvias; • Especificam requisitos conflitantes com necessidades de outros clientes/usuários; • Especificam requisitos ambíguos ou instáveis; • Problemas de volatilidade: os requisitos mudam o tempo todo. “Fatos não deixam de existir porque são ignorados.” – Aldous Huxley Para auxiliar a superar estes problemas, os engenheiros de sistema devem abordar os requisitos de maneira organizada. Alguns passos são sugeridos para elicitação de requisitos: • Avaliar a viabilidade técnica e de negócio para o sistema proposto;

•

Identificar as pessoas que vão auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais; • Definir o ambiente técnico3 no qual o sistema será instalado; • Identificar “regras de domínio4” que limitam a funcionalidade ou performance do sistema ou produto que será construído; • Definir um ou mais métodos de elicitação de requisitos5; • Solicitar participação de várias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista; • Identificar claramente a justificativa de existência para cada requisito registrado; • Identificar requisitos ambíguos que serão candidatos a prototipação. Os produtos de trabalho a criar como conseqüência das atividades de elicitação de requisitos irão depender do tamanho do sistema ou produto que será construído. Para a maioria dos sistemas, estes produtos de trabalho incluem: • As necessidades e viabilidade estruturadas; • O limite de escopo do sistema ou produtos; • Uma lista de clientes, usuários e outros stakeholders que participaram da atividade de elicitação de requisitos; • Uma descrição do ambiente técnico do sistema; • Uma lista de requisitos e as regras de domínio aplicáveis a cada um; • Um conjunto de cenários de uso capazes de prover uma idéia do uso do sistema ou produto sob diferentes condições de operação; • Qualquer protótipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos. Cada um destes produtos deve ser revisado por todas as pessoas que tenham participado da elicitação de requisitos.

2. Análise e negociação de requisitos Com os requisitos elicitados, os produtos de trabalho citados anteriormente formam a base para a análise de requisitos. Esta análise categoriza e organiza os requisitos em subconjuntos relacionados, explora o relacionamento de cada requisito com todos os demais, examina consistência, omissão e ambigüidade dos requisitos e prioriza requisitos com base nas necessidades dos clientes/usuários. As seguintes questões devem ser respondidas para a análise de requisitos: • Cada requisito é consistente com os objetivos gerais do sistema/produto? • Todos os requisitos foram especificados no nível apropriado de abstração? Em outras palavras, algum requisito está em um nível de detalhe técnico inapropriado para este estágio? • O requisito é realmente necessário, ou ele representa uma característica que pode não ser essencial ao objetivo do sistema? • Não há requisitos ambíguos; • Cada requisito tem atribuição? Em outras palavras, há uma fonte (geralmente um indivíduo específico) apontada para cada requisito? • Nenhum requisito conflita com os outros? • Cada requisito é passível de desenvolvimento no ambiente técnico designado para o sistema/produto? Não é raro os clientes e usuários solicitarem mais do que pode ser realizado. É também relativamente comum que clientes ou usuários distintos solicitem requisitos conflitantes, argumentando que sua respectiva versão do requisito “é essencial para nossas necessidades especiais”. O engenheiro de sistemas deve harmonizar estes conflitos através de um processo de negociação. Clientes, usuários e stakeholders devem ser também questionados quanto à priorização de requisitos e então discutirem eventuais conflitos na priorização. Os riscos associados a cada requisito são identificados e analisados. Estimativas de alto nível do esforço de desenvolvimento devem ser realizadas para avaliar o impacto de cada requisito no custo do projeto e tempo de entrega. Usando uma abordagem interativa, os requisitos são eliminados, combinados e/ou modificados de forma que cada grupo obtenha uma média de satisfação. 1

Instituto de Engenharia Elétrica e Eletrônica Elicitar requisitos = “levantar”, identificar requisitos. 3 P.EX. arquitetura computacional, sistema operacional, necessidades de telecomunicações, etc. 4 Características do ambiente de negócio que são específicas para o domínio da aplicação. 5 Entrevistas, reuniões com grupos envolvidos, etc 2