Engenharia de requisitos

Engenharia de requisitos
A engenharia de requisitos (no contexto da engenharia de software) é um processo que engloba
todas as atividades que contribuem para a produção de um documento de requisitos e sua
manutenção ao longo do tempo.
Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projeto,
determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos.
O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares,
2005):
1. Identificação.
2. Análise e negociação.
3. Especificação e documentação.
4. Validação.
Uma outra atividade que se pode considerar que faz também parte deste processo, se incluirmos a
fase posterior à produção do documento (isto é, a sua "manutenção"), é a gestão dos requisitos
(change management, sendo que as alterações podem ser causadas pelos mais diversos fatores
desde inovações tecnológicas a mudanças na natureza do negócio (e consequentemente nos
requisitos), entre outras).
1. Estudos de viabilidade
Algumas das questões que podem ser postas nesta coleta de informações são, por exemplo:
* Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização?
* Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá
resolver estas falhas?
* De que forma é que o sistema irá contribuir diretamente para os objetivos da organização?
* É possível a integração com os outros sistemas da organização (de um ponto de vista
tecnológico)? Com que facilidade é que se consegue partilhar informação entre estes sistemas?
2. Identificação
Atividades envolvidas
* Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a
organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais
eficaz será a comunicação entre o analista e as partes interessadas.
* Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de
Engenharia de requisitos file:///Users/rogerio/Desktop/Eng/Engenharia de requisitos.html
1 de 9 10/09/10 11:57

viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos
utilizadores do sistema.
* Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais)
pretendidos para o sistema.
* Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição
deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.
Dificuldades
* O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir
articulá-lo ( o que é bastante comum ).
* Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico,
por exemplo).
* Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo
necessário - através de um bom conhecimento do domínio - identificar estas situações.
See Also: Gestão de requisitos
2.1 Entrevistas e Questionários
Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastante
eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas),
está condicionada a alguns fatores:
* Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê margem ao
entrevistado para expor as suas ideias sem as enviesar logo à partida.
* Relação pessoal entre os intervenientes na entrevista.
* Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afetado
pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à
informação.
* Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja
tendência para que os intervenientes se dispersem um pouco, levando a que a entrevista demore
mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem
cair na tentação de "querer despachar" sendo os últimos pontos da entrevista abordados de forma
superficial (ou podem nem chegar a ser abordados).
Um dos aspectos fundamentais deste tipo de entrevistas é garantir que as ideias e predisposições
naturais do entrevistador não interfiram com uma livre troca de informação. Isto pode ser algo
difícil de conseguir uma vez que cada pessoa é influenciada por um conjunto de vivências
pessoais, que podem dificultar a compreensão de ideias vinda de outras pessoas.
2.1.1 Elaboração das perguntas
2.1.1.1 Perguntas de contexto livre
2 de 9 10/09/10 11:57

As perguntas de contexto livre ajudam o analista a obter informação acerca do problema,
minimizando ao máximo as suas influências pessoais na resposta do cliente.
Como exemplo de perguntas deste género, podemos ter:
* Quem são os utilizadores?
* Quem é o cliente?
* Têm necessidades diferentes?
* Onde podem ser encontradas outras soluções para este problema?
Estas perguntas obrigam o analista a ouvir primeiro antes de tentar encontrar uma potencial
solução, e começar a descrevê-la quase instintivamente influenciando desta forma o entrevistado.
O ouvir cuidadosamente permite uma melhor compreensão do problema principal e quaisquer
outros problemas relacionados, que muitas vezes passam despercebidos, mas que afetam a
motivação e comportamento do entrevistado.
2.1.1.2 Perguntas centradas na solução
Durante a fase de pesquisa e identificação de requisitos, pode também ser apropriado começar a
dirigir o tipo de perguntas mais para o contexto de uma solução, após terem sido obtidas as
respostas às perguntas de contexto livre. No fundo, o papel do analista é o de fornecer soluções
específicas aos problemas em causa, e não apenas compreender o problema no geral.
Após terem sido feitas as perguntas de contexto livre, pode começar-se a explorar as soluções
propostas com estas perguntas mais direccionadas:
* (Apresentar as capacidade gerais de uma solução) E se pudesse fazer … e …?
* Como classificaria a importância de cada uma das funcionalidades apresentadas?
2.2 Workshops de requisitos
O Workshop de Requisitos consiste numa técnica usada através de uma reunião estruturada, da
qual devem fazer parte um grupo de analistas e um grupo representando o cliente, para então
obter um conjunto de requisitos bem definidos. Ao contrário das reuniões, promove-se a
interação entre todos os elementos presentes no workshop fomentando momentos de
descontração como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro
cujo papel é conduzir a workshop e promover a discussão entre os vários intervenientes (ainda
que não tenha realmente poder de decisão). As tomadas de decisão devem seguir processos bem
definidos e devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica
que é também útil em workshops é o uso de brainstorming (tempestade de idéias) como forma
de gerar um elevado número de ideias numa pequena quantidade de tempo. Como resultado dos
workshops deve ser produzida documentação que reflita os requisitos e decisões tomadas sobre o
sistema a implementar.
2.3 Cenários
3 de 9 10/09/10 11:57

* Uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de
cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus
utilizadores podem comentar acerca do seu comportamento e da interação que esperam ter com
ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um
modo geral, os cenários devem incluir os seguintes elementos:
* Estado do sistema no início do cenário.
* Sequência de eventos esperada (na ausência de erros) no cenário.
* Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes
erros serão tratados.
* Outras atividades que podem ser executadas ao mesmo tempo que as deste cenário.
* Estado do sistema depois de o cenário terminar.
2.4 Prototipagem
O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (por
exemplo na identificação, análise e validação). Trata-se de uma versão inicial do sistema,
baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo
falhas que através da comunicação verbal não são tão facilmente identificáveis. Neste tipo de
abordagem apenas são desenvolvidas algumas funcionalidades sendo normalmente desenvolvidas
primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe podem
trazer maior valor acrescentado (principalmente na prototipificação evolutiva, isto é, aquela que
mais tarde é evoluída para a fase de desenvolvimento). O uso de protótipos deve ser considerado
apenas mediante uma análise custo-benefício, já que os custos de desenvolvimento de um
protótipo podem facilmente crescer, sendo particularmente úteis em situações em que a interface
com os utilizadores é, para eles, um aspecto crítico.
2.5 Estudo etnográfico
Os Estudos Etnográficos são uma análise da componente social das tarefas desempenhadas
numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma
pessoa, é de esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as
pessoas com as quais interage para as levar a cabo. Através de uma observação directa das
atividades realizadas durante um período de trabalho de um funcionário é possível
encontrar requisitos que não seriam observáveis usando técnicas convencionais. Esta observação
pode ser acompanhada de registos áudio/vídeo, porém não convém usá-los em demasia visto que o
tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o
representante do cliente observado desempenha as suas funções "correctamente", pelo que convém
ter algum cuidado na escolha do mesmo.
3. Análise e negociação dos requisitos
3.1 Classificação
4 de 9 10/09/10 11:57

Agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento
pretendido para o sistema.
3.2 Resolução de conflitos
Dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e
análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é
importante resolver estes conflitos o mais breve possível.
3.3 Prioritização
Consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa);
obviamente, este pode ser um fator gerador de conflitos.
3.4 Confirmação
É confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade
(de acordo com o que se pretende do sistema).
4. Especificação e documentação
Em todos os tipos de especificação há 2 tipos de requisitos a considerar:
* Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize,
de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça,
atendendo aos propósitos para qual o sistema será desenvolvido.
* Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas
quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em
Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.
4.1 Especificação de requisitos do utilizador
Os requisitos do utilizador destinam-se portanto aos vários níveis hierárquicos da organização na
qual o sistema será implementado (desde gestores a utilizadores), pelo que são descritos usando
apenas (conforme já foi referido) linguagem natural, formulários e diagramas muito simples.
Algumas considerações úteis a ter em conta ao escrever uma especificação de requisitos do
utilizador:
* Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a verificação dos
requisitos).
* Distinguir claramente entre comportamentos esperados e desejáveis do sistema através do uso de
expressões como "O sistema permitirá criar (...)" ou "Deverá ser possível criar (...)"
respectivamente. É importante deixar claro o que o sistema tem de fazer e sugestões de como o
deve fazer e, acima de tudo, usar este tipo de expressões de forma consistente ao longo de todo o
documento.
5 de 9 10/09/10 11:57

* Usar formatação de texto para salientar determinados aspectos do documento (usando negrito,
por exemplo).
* Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os e
definindo-os de uma forma clara quando for absolutamente necessário usá-los.
4.2 Especificação de requisitos do sistema
Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos
requisitos do utilizador correspondentes recorrendo ao uso, para além da linguagem natural, de
linguagens estruturadas e notações gráficas. Estes requisitos destinam-se ainda aos utilizadores do
sistema (e particularmente aos engenheiros que trabalhem nessa organização) e destinam-se
também às equipes de especificação de arquitetura do sistema e de desenvolvimento.
4.3 Especificação do design da aplicação
A especificação do design da aplicação consiste num documento usado pela equipe de
desenvolvimento do sistema no qual estão definidos pormenores, em um nível mais técnico,
acerca da implementação do sistema e sua arquitetura. A partir deste documento, um elemento
que entre para a equipe de desenvolvimento no meio do projeto deverá ser capaz de "se situar"
quando precisar de começar a codificar, compreendendo a forma como a implementação, em
um nível global, está a ser feita, mas sem conhecer necessariamente os detalhes de
implementação aprofundados. Não convém cair na tentação de deixar toda a implementação
detalhada, uma vez que convém que os desenvolvedores tenham alguma margem de manobra
tanto para inovar como para resolver problemas encontrados em sub-sistemas de formas que uma
especificação inicial da arquitetura não consegue prever.
4.4 Documento de Especificação de Requisitos
Inclui uma combinação dos requisitos do utilizador e do sistema e tem diferentes utilidades para
diferentes pessoas:
* Clientes: confirmar a completude dos requisitos e propor alterações.
* Gestores: orçamentar o sistema e planejar o processo de desenvolvimento.
* Arquitetos/Projetistas: compreender o sistema a desenvolver.
* Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos.
* Arquitetos/Projetistas (manutenção): compreender o sistema e a ligação entre as suas partes.
Existem diversos padrões para este documento, mais a IEEE propõe um modelo IEEE/ANSI
830-1993 (Thayer e Dorfman, 1993).
5. Validação
Pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema
que o cliente pretende.
6 de 9 10/09/10 11:57

Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os
seguintes atributos dos requisitos:
* Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes
interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada
parte interessada) podem diferir da especificação final que se atinge após o cruzamento de
informação e é necessário que cada cliente compreenda e aceite a especificação final obtida.
* Consistência: não devem existir conflitos entre os requisitos identificados.
* Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma
inequívoca pelas partes interessadas.
* Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do
sistema.
* Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema
especificado tem de ser implementável.
* Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos
especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não
concretizados, isto é, se o sistema final corresponde à especificação inicial.
* Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente
identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos.
* Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua
especificação deve obedecer às normas usadas ao longo de todo o documento.
5.1 Revisões dos requisitos
Uma equipe de revisores pode analisar sistematicamente a especificação produzida de forma a
garantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe de revisores
pode simplesmente ter uma conversa, envolvendo o maior número possível de representantes das
partes interessadas, acerca dos requisitos produzidos; em revisões formais, a equipe de revisores
deve confirmar junto do cliente um conjunto de critérios que todos os requisitos devem cumprir:
* verificabilidade;
* compreensibilidade (por parte dos utilizadores finais);
* rastreabilidade (a origem dos requisitos deve ser identificável);
* adaptabilidade (capacidade de sofrer alterações sem produzir efeitos em todos os outros
requisitos);
5.2 Prototipificação
A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para os
7 de 9 10/09/10 11:57

utilizadores finais (e demais interessados), já que se trata do elemento do sistema final com o qual
terão mais contacto quando o sistema estiver operacional;
5.3 Geração de casos de teste
Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os respectivos
testes desde a fase de validação de requisitos; se isto não for possível, é sinónimo de que a
implementação deste requisito será difícil e que este poderá ter de ser reconsiderado.
5.4 Análise de consistência automática
Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramentas
adequadas (como as ferramentas CASE), testar de forma automática a consistência dos modelos
criados (Exemplo: Matriz de reastreabilidade); apenas a consistência é testada nesta técnica, pelo
que tem de ser complementada com uma das outras técnicas referidas.
6. Gestão de requisitos
Responsável por controlar e gerenciar as mudaças de requisitos, que inevitavelmente tendem a
ocorrer durante a especificação do sistema, isto pode suceder por o problema abordado não
conseguir ficar completamente definido antes da produção do documento de requisitos (ou mesmo
antes de o sistema ser implementado) ou, por outro lado, pode também acontecer por os próprios
requisitos se alterarem no decorrer do projeto (reflectindo evoluções tecnológicas ou alterações na
organização na qual é usado).
Na prática, a gestão de requisitos acaba por coincidir com o início de novos processos de
engenharia de requisitos (para os "novos" requisitos, isto é, os "antigos" que sofreram alterações).
Como tal, o planejamento é uma parte importante da gestão de requisitos. Devem estar definidas
desde o início da gestão de requisitos políticas para:
* Identificação de requisitos: identificação unívoca(ser interpretado de uma forma) em especial
para facilitar a rastreabilidade.
* Processo de gestão de mudanças a utilizar: conjunto de atividades que permitem avaliar o custo e
impacto das alterações.
* Rastreabilidade: relações entre os requisitos e relações entre requisitos e design; estas podem
precisar de manter associada a cada requisito informação como a parte interessada que a propôs,
dependências de outros requisitos e associação a módulos específicos do design do sistema.
* Ferramentas a utilizar: para sistemas grandes, a quantidade de informação a processar pode ser
elevada, sendo o uso de ferramentas CASE aconselhado.
Para manter a consistência entre as várias alterações pedidas (e para estas serem feitas de um
modo controlado), é importante que o processo de gestão de mudanças esteja definido de um modo
formal, sendo que deverá incluir as seguintes fases:
* Análise do problema e especificação da alteração a fazer: identificação do problema existente
nos requisitos originais e proposta de alteração a fazer aos requisitos do sistema.
8 de 9 10/09/10 11:57

* Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas
previamente, avaliação do impacto da alteração no sistema.
* Implementação da alteração: alteração no documento de requisitos e, conforme seja necessário,
no design e implementação.
See Also: Identificação, Validação, Especificação e documentação, Análise e negociação dos
requisitos
9 de 9 10/09/10 11:57

Engenharia de requisitos

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Engenharia de requisitos

Ähnlich wie Engenharia de requisitos (20)

Engenharia de requisitos