E
E
N
N
G
G
E
E
N
N
H
H
A
A
R
R
I
I
A
A
D
D
E
E
S
S
O
O
F
F
T
T
W
W
A
A
R
R
E
E
2 26 3 PROCESSOS DE ENGENHARIA DE REQUISITOS - ESTUDOS DE VIABILIDADE
T
TÓÓPPIICCOO 2266 –– PPRROOCCEESSSSOOSS DDEE EENNGGEENNHHAARRIIAA DDEE RREEQQUUIISSIITTOOSS -- EESSTTUUDDOOSS DDEE V
VIIAABBIILLIIDDAADDEE
Fonte: Gerência de Requisitos - Miriam Sayão e Karin Koogan Breitman
2.1 PROCESSO DE ENGENHARIA DE REQUISITO
O processo de engenharia de requisitos, segundo Sommerville (1997), é um conjunto estruturado de atividades para extrair, validar e manter um documento de requisitos. Uma completa descrição do processo poderá incluir quais atividades são realizadas, a estruturação ou particionamento destas atividades, quem é responsável pela atividade, as entradas e saídas de/para atividade e as ferramentas usadas para suportar a engenharia de requisitos.
Dessa forma processo pode ser conceituado como o conjunto de atividades para extrair informação, validar e manter um documento de requisitos. E os tipos de processo são:
• Extração de Requisitos = descobrimento (Elicitar, em inglês);
• Análise e Negociação de Requisitos = requisitos acordados;
• Validação de Requisitos = consistentes, completos, precisos;
• Gerenciamento de Mudança de Requisitos;
O processo de engenharia de requisitos pode ser entendido como uma série de atividades consistindo de: articulação do conceito inicial, análise de problema, viabilidade e escolha de opções, análise e modelagem e documentação de requisitos [MACAULAY, 1996]. Cada atividade requererá o uso de técnicas potencialmente diferentes.
• Conceito – o conceito de produto provê um gatilho para o processo de requisitos para começar. Este gatilho pode ser um aperfeiçoamento em serviço do cliente, uma necessidade futura, um pequeno aperfeiçoamento incremental no sistema existente ou a necessidade de uso de alguma tecnologia que está disponível;
• Análise de Problema – preocupação em desenvolver um entendimento da
natureza do problema associado ao conceito de produto;
• Estudo de viabilidade e escolha de opções – preocupação com avaliação de
custos e de benefícios das soluções alternativas;
• Análise e Modelagem – preocupação com a modelagem do domínio da
aplicação e do espaço de solução, onde cada atividade pode ser seguida de validação, a fim de checar a precisão da informação reunida e do entendimento obtido;
• Documentação de Requisitos – complementação do documento de
requisitos.
Poucas organizações têm um processo de engenharia de requisitos padronizado e definido explicitamente. A aplicação varia de uma organização para outra, mas muitos processos envolvem as atividades de: extração, análise e negociação, documentação e validação de requisitos. O funcionamento ocorre de modo espiral, é iterativo e envolve repetições das atividades na geração de versões do documento de requisitos.
2.2 ELICITAÇÃO E ANÁLISE DE REQUISITOS
A palavra “elicitação” não existe na língua portuguesa, mas foi criada e tem sido utilizada por vários autores englobando o significado dos verbos eliciar (fazer sair, extrair, trazer à tona a verdade), clarear, extrair e descobrir. Assim, uma definição sucinta de elicitação é obter e tornar explícito o máximo de informações possíveis para o conhecimento de um objeto em questão.
Elicitação de requisitos é o nome usual dado para as atividades que envolvem o descobrimento em sistema de requisitos [KOTONYA, 1998].
A análise de requisitos e negociação são processos que são fechados provavelmente com elicitações de requisitos.
O objetivo da análise de requisitos e negociação está para a estabilidade e sem dúvida do requisito que são completos e consistentes. Estes requisitos são ambíguos podendo ser usados como uma base para o desenvolvimento de sistemas.
Existem quatro dimensões para tipos de solução de sistema: • Entendimento domínio da aplicação;
• Entendimento do problema; • Entendimento do negócio;
• Entendimento das necessidades e limitações dos Stakeholders do sistema. Cabe à elicitação a tarefa de identificar os fatos que compõem os requisitos do sistema, de forma a prover o mais correto e mais complexo entendimento do que é demandado daquele software.
Todos estes fatores de métodos estruturados não são muito úteis para a elicitação de requisitos. Em geral estes métodos podem ser usados para suporte de análise depois de algumas elicitações iniciais carregadas na saída.
A elicitação de requisitos é a primeira atividade a ser desenvolvida na engenharia de requisitos. Na elicitação busca-se descobrir os requisitos do sistema, normalmente obscuros, vagos e confusos no início do desenvolvimento de um sistema de software [JOHNSON, 1996].
Nessa etapa, usuários e desenvolvedores trabalham em conjunto para definir o problema a ser solucionado, enfocando principalmente os serviços que o sistema deve oferecer. No entanto, é comum os usuários não saberem exatamente o que eles desejam que seja implementado no sistema de software, o que pode fazer com que os requisitos definidos inicialmente não reflitam as reais necessidades dos usuários [CASTRO, 2000].
Assim, esta atividade não envolve apenas perguntar ao usuário o que ele deseja. Ela requer uma análise cuidadosa da organização onde o software será implantado, uma análise do domínio da aplicação e uma análise dos processos de negócios onde o software será utilizado [KOTONYA, 1998].
Segundo Kotonya (1998) a elicitação de requisitos, realizada de forma efetiva, deve abordar quatro dimensões:
• Entendimento do domínio da aplicação: significa conhecer a área onde o sistema é aplicado de uma forma geral. Este entendimento exige conhecimentos gerais sobre a aplicação em questão. Por exemplo, se o sistema será aplicado numa área de seguros de automóveis, então devemos obter conhecimentos gerais sobre sinistro, apólices de seguro, mercado de automóveis etc.
• Entendimento do problema: significa conhecer os detalhes específicos do problema de um cliente em particular. Por exemplo, para um sistema de seguros de automóveis que será desenvolvido especificamente para um cliente, o entendimento do problema envolve conhecer como é o processo de atendimento ao cliente quando ocorre um sinistro, como ocorrerá o pagamento do conserto do automóvel do cliente, com quais oficinas a seguradora trabalha etc.
• Entendimento do negócio: normalmente sistemas contribuem de alguma forma com os objetivos e missão da organização onde eles estão inseridos. O entendimento do negócio significa conhecer como o sistema de software a ser desenvolvido interage e afeta os negócios da organização, e que tipo de contribuição ele irá proporcionar.
• Entendimento das necessidades e restrições das pessoas envolvidas no sistema: para obtermos este tipo de entendimento, é necessário conhecermos os processos que o sistema deverá suportar, pois boa parte destes processos são realizados pelas pessoas envolvidas no sistema.
A atividade de análise de requisitos está muito vinculada à elicitação, uma vez que na medida em que os requisitos vão se desvendando algum grau de análise sobre os mesmos é realizada. O objetivo da análise de requisitos é encontrar possíveis problemas na declaração informal dos requisitos obtida pela elicitação de requisitos [KOTONYA, 1998].
Enquanto os requisitos vão sendo descobertos, alguma análise acaba ocorrendo. Durante a análise é comum encontrarmos problemas nos requisitos descobertos, tipicamente conflitos e ambigüidades, que devem ser negociados entre desenvolvedores e usuários, de forma a se obter um "acordo" sobre os requisitos obtidos.
Existem três elementos fundamentais sobre os requisitos, que devem ser verificados na análise, que auxiliam na identificação de problemas:
• Verificação de necessidade: a necessidade de um requisito obtido deve ser analisada. Alguns requisitos podem ser propostos, mas não contribuem com as metas de negócio da organização ou para o problema específico a ser endereçado pelo sistema.
• Verificação de consistência e completitude: consistência significa que nenhum requisito deve ser contraditório, e completitude significa que nenhum serviço ou restrição que sejam necessários ao sistema tenha sido omitido.
• Verificação de possibilidade: os requisitos devem ser verificados no sentido de assegurar que eles são factíveis de serem implementados no sistema a ser desenvolvido, tanto em termos de orçamento como de tempo.
A análise de requisitos envolve a quebra de requisitos de alto nível em requisitos funcionais detalhados. Durante esta atividade, ocorre uma negociação entre todas as pessoas envolvidas para obter um conjunto de requisitos comumente acordados e aceitos. A Figura 1, adaptada de Kotonya (1998), mostra esta operação.
Figura 1: Interação entre a elicitação e a analise de requisitos. Fonte: [KOTONYA, 1998].
A análise de requisitos é a atividade que deve ser desempenhada simultaneamente com a elicitação, conforme a Figura1. Como os requisitos são descobertos durante a elicitação, a análise deve ocorrer, inevitavelmente, nesta fase, para discutir e resolver os problemas dos requisitos que eventualmente aparecem [KOTONYA, 1998]. Deste modo, melhores resultados podem ser obtidos.
Os requisitos mudam durante o processo de análise. Novos usuários podem surgir, o ambiente de negócio pode mudar e novas necessidades podem aparecer. A análise de requisitos também pode sofrer a influência de fatores políticos e organizacionais.
2.3 VALIDAÇÃO DE REQUISITOS
A validação dos requisitos na definição de Pfleeger (2004), “é o processo que determina que a especificação seja consistente com a definição dos requisitos”. Deve verificar se o conjunto total de requisitos é exatamente aquilo que foi solicitado pelo cliente.
Sendo o processo de confirmação com o usuário do software se os requisitos especificados e documentos são validados, corretos e estão completos [RAGHAVAN, 1994]. É a ultima etapa da engenharia de requisitos e tem como objetivo certificar se os requisitos especificados representam uma descrição aceitável do sistema a ser implementado [KOTONYA, 1998].
Na operação de validação devem-se fazer constantes revisões dos requisitos com a participação dos usuários e da equipe de desenvolvimento. Nesta etapa é fundamental a boa
comunicação entre usuários e desenvolvedores. Todas as alterações devem ser documentadas, em caráter formal. Devem-se realizar revisões informais e um método padronizado deve ser seguido.
Segundo Kotonya (1998), a validação de requisitos tem como objetivo certificar que o documento de requisitos é uma descrição aceitável do sistema a ser implementado. Verificando os seguintes problemas durante a validação do documento:
• Falta de conformidade com padrões de qualidade;
• Pobre formulação (descrição) de requisitos, que acaba gerando ambigüidade; • Erros nos modelos do sistema ou do problema a ser resolvido;
• Requisitos com conflitos que não são detectados na fase de análise.
Para Kotonya (1998), o principal problema de validação de requisitos é que não existe um documento para ser tomado como base na validação, pois não existe maneira de comparar uma SRS (Software Requirements Specifications) com outra. Entretanto uma SRS tem que assegurar que os requisitos representam uma clara descrição do sistema a ser implementado e é uma verificação final para garantir que os requisitos vão ao encontro das necessidades do usuário. As entradas e saídas são mostradas na Figura 2.
Figura 2: Entradas e saídas de validação de requisitos. Fonte: [KOTONYA, 1998]. A importância da validação de requisitos para Sommerville (2003), é que o custo de fazer uma modificação no sistema, resultante de um problema de requisito, é muito maior do que reparar erros de projeto ou codificação. Diferentes tipos de verificação devem ser realizados durante o processo de validação de requisitos. As verificações são aplicadas sobre os requisitos no documento de requisitos. Segundo Sommerville (2003), destacam-se os tipos de verificações:
• Verificações de validade; • Verificações de consistência; • Verificações de completeza; • Verificações de realismo; • Facilidade de verificação.
Para a validação dos requisitos existe uma série de técnicas que podem ser utilizadas, desde técnicas manuais como técnicas automatizadas. Pfleeger (2004) apresenta algumas dessas técnicas:
1. Técnicas manuais a. Leitura;
b. Referência cruzada normal; c. Entrevistas;
d. Revisões;
e. Lista de verificação;
f. Modelos manuais para verificar funções e relações; g. Cenários;
h. Provas matemáticas. 2. Técnicas automatizadas
a. Referência cruzada automatizada;
b. Modelos automatizados para ativar as funções; c. Protótipos.
Uma maneira simples de validar requisitos é revisá-los, segundo Pfleeger (2004), um processo manual que envolve muitos leitores, tanto do pessoal do cliente como do fornecedor. Os conflitos, contradições, erros e omissões nos requisitos devem ser destacados durante a revisão e formalmente registrados.
Créditos:
CÉSAR, ANACRISTINA FREITAS - QUALIDADE DE DOCUMENTO DE REQUISITOS, VISANDO ALGUNS PADRÕES, NORMAS E MODELO - Universidade Federal de Pernambuco - RECIFE, 26 DE FEVEREIRO DE 2008
