Unidade 4: Processo de Desenvolvimento de Software: Levantamento de Requisitos

Visão geral das atividades que compõem a Engenharia de requisitos

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.
Processo de engenharia de requisitos é composto por 4 atividades de alto nível:
--Identificação; --Análise e negociação; --Especificação e documentação; --Validação.
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. 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: Antes de avançar em uma análise mais detalhada dos requisitos de um projeto, deve ser feito
um estudo de viabilidade. Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista
tecnológico e organizacional, o projeto é viável. Uma forma de avaliar a viabilidade de um projeto é obter, através da
interação com "as partes interessadas" (stakeholder) do projeto (em reuniões ou entrevistas, por exemplo), a resposta
às seguintes questões:
-O sistema contribui para os objetivos da organização?
-Existindo restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais
associadas ao projeto, será que o sistema pode ser implementado?
-É possível a integração entre diferentes sistemas?
Deve portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta
informação, procedendo-se de seguida à recolha de todos os dados disponíveis para clarificar ao máximo o âmbito do
projeto e avaliar a sua viabilidade.
Tipicamente, quem poderá fornecer esta informação serão os usuários dos sistemas atuais e do sistema a implementar,
os responsáveis pelos departamentos nos quais o sistema será usado, técnicos que estejam familiarizados com as
tecnologias envolvidas (do novo sistema e dos sistemas existentes) e, de um modo geral, todos aqueles que terão
qualquer tipo de interação com o novo sistema (ou que sejam por ele afetados). 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?
Estudo de viabilidade deverá culminar com a produção de um relatório e determinar a continuação do desenvolvimento
do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e definindo mesmo
alguns requisitos de alto nível.
2.Identificação: Caso determine que o projeto é viável, o passo seguinte é a identificação dos requisitos.
2.1.Atividades envolvidas: Algumas das atividades envolvidas nesta fase incluem:
-Captura: obtenção com o cliente dos requisitos (funcionais e não-funcionais) pretendidos para o sistema.
-Compreensão do domínio: importante para o analista compreender o domínio no qual a organização e o projeto se
inserem;.
-Identificação e análise de problemas: problemas devem ser identificados (e a sua definição deve ser consensual) e
devem ser propostas soluções em conjunto com as partes interessadas.
-Identificação das partes interessadas.
2.2.Dificuldades: Esta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estão associadas:
-Cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo (o que é
comum).
-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.
2.3.Técnicas para levantamento de requisitos: Existem diversas técnicas de identificação de requisitos, e que são
adequadas a diferentes situações, entre as quais podem ser citar:
2.3.1.Entrevistas e questionários: Técnica mais simples de utilizar. Bastante eficaz numa fase inicial de obtenção de
dados e mesmo no esclarecimento de algumas dúvidas.
2.3.2.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 o 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 (ou 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.3.Cenários (Série de Eventos Hipotéticos): 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
usuários 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.3.4.Prototipagem: Usado 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 utilizador e que podem trazer maior valor
acrescentado (principalmente na prototipagem evolutiva, isto é, aquela que mais tarde é evoluída para fase de
desenvolvimento). Uso 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 usuários é, para eles, um aspecto crítico.
2.3.5.Estudos Etnográficos: Análise de componente social das tarefas desempenhadas numa dada organização. Quando
um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de se 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 direta 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
registros á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.
3.Análise e negociação dos requisitos: (Após a identificação dos requisitos do sistema, segue-se esta etapa)
3.1.Atividades envolvidas: Algumas das atividades envolvidas na análise de requisitos incluem:
-Classificação: agrupamento de requisitos em "módulos" para facilitar visão global do funcionamento pretendido para o
sistema;
-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;
-Priorização: consiste na atribuição de uma "prioridade" a cada requisito (por Ex elevada/média/baixa); obviamente,
este pode ser um fator gerador de conflitos;
-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).
Estas fases não são independentes entre si, pois uma informação obtida numa delas pode servir para as demais fases.
Identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro
sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de
trabalho.
3.2.Dificuldades: dificuldades encontradas na análise são de diversas naturezas:
-ambiente (econômico e/ou organizacional) em que a análise é feita possui fatores dinâmicos, e como tal, os requisitos
estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto,
ou alterações em prazos e orçamentos disponíveis).
-fatores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão, pode
exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em
detrimento dos demais interessados que irão operar o sistema);
3.3.Negociações: Na fase de negociação, tornam-se necessários alguns cuidados para que esta decorra sem problemas,
chegando-se logo a consensos. Sugestões :
-Saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde, fora
de reunião), de preferência nunca tomando partidos;
-Fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação;
-Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos;
-Relaxar restrições, quando se torna óbvio que as atuais não levarão a um consenso.
4.Especificação e documentação: Nesta fase ocorre produção propriamente dita do documento de especificação de
requisitos. Uma especificação de programa é a definição do que se espera que um software faça. Ela pode ser
informal, neste caso ela pode ser considerada como um blueprint ou manual de usuário do ponto de vista do
desenvolvedor, ou formal, no caso de ela ser definida principalmente em termos matemáticos ou programáticos. Na
prática, as especificações mais bem sucedidas são escritas para a compreensão e ajustes em uma aplicação que já se
encontra bem desenvolvida, embora sistemas de segurança críticos sejam cuidadosamente especificados antes do
desenvolvimento da aplicação. Especificações são mais importantes para interfaces externas que devem permanecer
estáveis.
Em todos os tipos de especificação há 2 tipos de requisitos a considerar:
---Requisitos funcionais: São as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e
consistente. Aquilo que utilizador espera que sistema ofereça, atendendo aos propósitos para qual o sistema será
desenvolvido. Em Engenharia de software, um requisito funcional define uma função de um sistema de software ou seu
componente. Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas. Requisitos
funcionais podem ser cálculos, detalhes técnicos, manipulação de dados e de processamento e outras funcionalidades
específicas que definem o que um sistema, idealmente, será capaz de realizar.
–--Requisitos não-funcionais: São os requisitos relacionados ao uso da aplicação em termos de desempenho,
usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral,
requisitos não-funcionais podem constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre
eles, pois eles são características mínimas de um software de qualidade, ficando a cargo do desenvolvedor optar por
atender esses requisitos ou não. Situações:
- Demonstram qualidade e ou restrições acerca dos serviços ou funções disponibilizadas pelo sistema. Ex.: restrições de
tempo, restrições sobre o processo de desenvolvimento, padrões, etc.
- Surgem conforme a necessidade dos usuários, em razão de restrições de orçamento e outros fatores.
- Podem estar relacionados à confiabilidade, tempo de resposta e espaço nas mídias de armazenamento disponíveis.
- Caso ocorra falha do não atendimento a um requisito não funcional, poderá tornar todo o sistema ineficaz. Ex.:
requisito confiabilidade em um sistema de controle de voos.
Classificação dos Requisitos não Funcionais
- Requisitos de produtos: Requisitos que especificam o comportamento do produto. Ex. portabilidade; tempo na
execução; confiabilidade, mobilidade, etc.
- Requisitos da organização: Requisitos decorrentes políticas e procedimentos corporativos. Ex. padrões, infra-
estrutura,etc.
- Requisitos externos: Requisitos decorrentes de fatores externos ao sistema e ao processo de desenvolvimento. Ex.
requisitos de interoperabilidade, legislação, localização geográfica etc.
- Requisitos de eficiência. Ex.: sistema deverá processar N requisições por um determinado tempo.
- Requisitos de confiabilidade. Ex.: sistema deverá ter alta disponibilidade.
- Requisitos de portabilidade. Ex.: sistema deverá rodar em qualquer plataforma.
- Requisitos de entrega. Ex.: relatório de acompanhamento deverá ser fornecido toda segunda-feira.
- Requisitos de implementação.: Ex.: sistema deverá ser desenvolvido na linguagem Java.
- Requisitos de padrões.: Ex. uso de programação OO sob a plataforma A.
- Requisitos de interoperabilidade.: Ex. sistema deverá se comunicar com o Sql Server.
- Requisitos éticos. Ex.: sistema não apresentará aos usuários quaisquer dados de cunho privativo.
- Requisitos legais. Ex.: sistema deverá atender às normas legais, tais como padrões, leis, etc.

Podem-se distinguir três tipos de especificação:

--Especificação de requisitos do usuário ou utilizador;
--Especificação de requisitos do sistema; --Especificação do design da aplicação.
Vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se
comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando "linguagens" que o
utilizador conheça). Por exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de alto
nível das funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas
(esquemas), nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitos
relativos à arquitetura do sistema, fazendo-se uso de linguagens estruturadas.
4.1.Requisitos do utilizador: Destinam-se aos vários níveis hierárquicos da organização na qual o sistema será
implementado (desde gestores a usuários), pelo que são descritos usando apenas linguagem natural, formulários e
diagramas simples.
4.2.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 usuários 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.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.
4.4.Documento de Especificação de Requisitos: Apesar da existência dos 3 tipos de especificação vistos nos itens
anteriores, existe uma especificação que é a usada como declaração oficial dos requisitos do sistema.
Este documento, normalmente chamado de “Documento de Especificação de Requisitos” (Software Requirements
Specification ou SRS) 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.
-Engenheiros: compreender o sistema a desenvolver.
-Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos.
-Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes.
5.Validação de requisitos: Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde,
de fato, ao sistema que o cliente pretende. Semelhança do que sucede análise dos requisitos, pretende-se encontrar
problemas ou conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação
completa de requisitos. Validação é especialmente importante em sistemas de grandes dimensões uma vez que erros
encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento
de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já
consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados
custos e necessidade de refazer muito do trabalho que se julgava já concluído.
5.1.Técnicas de validação: para tornar a validação mais eficaz, existe um conjunto de técnicas que podem ser
empregues:
5.1.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, nomeadamente: verificabilidade, compreensibilidade (por
parte dos usuários finais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capacidade
de sofrer alterações sem produzir efeitos em todos os outros requisitos).
5.1.2.Prototipificação: A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para os
usuários finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão mais contato
quando o sistema estiver operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempo gasto na
sua implementação pode não justificar o seu uso, pode enviesar os usuários (levando a desilusões com a versão final do
sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair na tentação de
usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva ser
implementado noutra linguagem que não aquela usada pelo sistema, eliminando por completo esta tentação).
5.1.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.1.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; apenas a consistência é testada nesta técnica, pelo que tem de ser complementada com uma das
outras técnicas referidas.
5.2.Recomendações: A fase de validação trata-se de uma fase muito importante na engenharia de requisitos e da qual
dependem elevados custos a médio e longo prazo.
Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos em validação de requisitos) é
bastante falível e regra geral há erros que não são encontrados num primeiro momento, o que leva inevitavelmente a
discordâncias numa fase posterior, já com o documento validado e o projeto em desenvolvimento ou concluído.
Quando isto sucede, torna-se necessário negociar e chegar a um acordo quanto à forma de corrigir o erro detectado.

Bibliografia: http://pt.wikipedia.org/wiki/Engenharia_de_requisitos