Wa - Ads - Sem 02 - Unidade 02 - Processo de Negócio e Software

Prévia do material em texto

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
WEBAULA 1
Unidade 2 – Engenharia de Requisitos 
 
Na Engenharia de Software, temos uma especialidade que é a Engenharia de Requisitos, sendo um de seus objetivos melhorar a modelagem de sistemas, possibilitando maior entendimento de suas características antes da implementação. Portanto, nesta aula abordaremos conceitos e técnicas aplicados a estes requisitos.
Caro aluno, nesta Web aula abordaremos assuntos relacionados ao tema Engenharia de Software, onde iremos explorar os Processos de Engenharia de Requisitos com suas principais características e funcionalidades. Darei algumas sugestões de leituras e vídeos para que possamos explorar mais a fundo o tema tratado.
 
Conceitos de Requisitos
Antes do assunto direto, vamos assistir algumas curiosidades em relação à Evolução do Computador por meio dos links:
História do computador em minutos
O motivo pelo qual apresentamos as visualizações por meio dos vídeos é para identificar a importância e a agilidade das inovações no meio computacional.
Dessa forma, podemos ter noção de alguns aspectos que destacam a necessidade do entendimento dos princípios de engenharia, para que possamos ter softwares que sejam eficientes e confiáveis.
Agora, voltamos para o assunto em destaque desta web aula, que são os Processos de Engenharia de Requisitos. Esses processos são utilizados para descobrir, analisar e validar os requisitos dos sistemas. Suas principais atividades são:
Estudo de viabilidade;
Elicitação (levantamento) e análise de requisitos;
Especificação e documentação de requisitos;
Validação de requisitos.
Processo de Engenharia de Requisitos
 
Para aprofundar o seu conhecimento:
Assista ao vídeo:
Engenharia de Requisitos
 
Estudo de viabilidade
O estudo de viabilidade consiste num estudo preliminar de requisitos de negócios, no qual é decidido se vale a pena desenvolver o sistema proposto. Um estudo breve verifica se:
sistema contribui para os objetivos da organização;
sistema pode ser implementado com a tecnologia atual e dentro do orçamento;
sistema pode ser integrado com outros sistemas em operação. (SOMMERVILLE, 2007, p. 97).
 
Implementação do estudo de viabilidade
A realização do estudo de viabilidade envolve a avaliação de informações, coleta de dados e a elaboração de um relatório. Para auxiliar na implementação, alguns questionamentos podem ser levantados às pessoas na organização, tais como:
-   O que aconteceria se o sistema não fosse implementado?
-   Quais são os problemas com os processos atuais?
-   Como o sistema proposto irá ajudar?
-   Pode haver troca de informações entre outros sistemas e o sistema proposto?
-   Será necessário nova tecnologia? Quais habilidades?
-   O que precisa e o que não precisa ser compatível com o sistema?
Durante esta fase, podemos consultar os engenheiros de software, especialistas em tecnologia e os usuários finais para coletarmos as informações. Geralmente, leva-se de 02 (duas) a 03 (três) semanas para concluir as atividades.
 
Elicitação e análise de requisitos
Nesta atividade, os engenheiros trabalham em conjunto com os usuários finais do sistema com o intuito de entender o domínio da aplicação. Para tal, envolvem-se várias pessoas da organização, que são denominadas stakeholders.
Os membros da equipe técnica trabalham com o cliente e os usuários para descobrir mais informações sobre o domínio da aplicação, serviços do novo sistema, desempenho e as restrições operacionais.
O termo Stakeholder é aplicado a qualquer pessoa que terá influência direta ou indireta sobre os requisitos do sistema, podendo ser usuários finais, pessoal de uma organização que venha a ser afetado pelo sistema, engenheiros envolvidos no desenvolvimento ou manutenção do sistema (e/ou outros sistemas relacionados), gerentes de negócios, especialistas no domínio da aplicação e até representantes de sindicatos.
Problemas com a análise de requisitos
Durante o processo de elicitação e análise dos requisitos, encontramos alguns problemas para realizar a atividade, pois:
-  Pessoas diferentes podem ter requisitos conflitantes;
-  Pessoas expressam os requisitos usando termos próprios;
-  Fatores políticos podem influenciar os requisitos do sistema;
-  Os requisitos se alteram durante o processo de análise, pois o ambiente econômico e de negócios é dinâmico.
 
Processo de elicitação e análise de requisitos
Podemos verificar que cada organização terá a sua própria versão de um modelo para a obtenção e análise de requisitos, dependendo de fatores locais, nível de conhecimento da equipe, tipos do sistema a ser desenvolvido e os padrões dos usuários.
As atividades do processo são:
-  Obtenção de requisitos – um processo que visa coletar requisitos, em que os requisitos de domínio também são descobertos durante esta atividade.
-  Classificação e organização de requisitos – envolve a coleta de requisitos não estruturados, agrupando-os e organizando-os em conjuntos coerentes.
-  Priorização e negociação de requisitos – atividade relacionada à priorização de requisitos, devido a requisitos conflitantes (quando há vários stakeholders atuando), à procura e à resolução de conflitos por meio de negociações.
-  Documentação de requisitos – são documentados e colocados na próxima volta da espiral, podendo ser produzidos documentos de requisitos formais ou informais.
 
Especificação e documentação de requisitos
A especificação de requisitos é uma etapa essencial do processo de desenvolvimento de software, que compreende uma definição completa do comportamento externo de software do sistema ou parte do sistema.
 
Requisitos do usuário
São declarações, em linguagem natural e diagramas, sobre os serviços que o sistema oferece e as restrições para a sua operação. São escritos para os clientes.
 
Requisitos do sistema
Estabelecem detalhadamente as funções e restrições do sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor.
 
Especificação de software
Trata-se de uma especificação abstrata e precisa do software, indicando o que ele deve fazer (sem dizer como), que serve de base para o design e implementação. Ela acrescenta mais detalhes à especificação funcional e é escrita para a equipe de desenvolvimento.
       Ao descrever os requisitos, necessitamos nos atentar às seguintes situações, pois:
A especificação dos requisitos deve ser completa (deve descrever tudo o que é necessário), consistente (não deve haver conflitos e contradições) e não ambígua (não deve levar a interpretações diferentes por desenvolvedores e usuários).
É difícil de ser atingida, considerando que existem diferentes tipos de requisitos envolvidos.
Depende da precisão da linguagem utilizada, visto que a linguagem natural, informal, é mais apropriada para os requisitos do usuário e do sistema, já as linguagens gráficas, semiformais, são apropriadas para os requisitos do sistema e do software, e as linguagens formais são mais apropriadas para uma especificação formal de software em métodos formais.
Os requisitos de software são frequentemente classificados como requisitos funcionais e não-funcionais:
 
Requisitos funcionais
São declarações de serviços que o sistema deve fornecer, como ele deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações, sendo que, em muitas vezes, também podem explicar como o sistema deve ou não fazer.
Exemplo:
"o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal".
"o software deve emitir relatórios de compras a cada quinze dias".
"os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo".
 
Requisitos não-funcionais
São restrições aos serviços ou funções oferecidas pelosistema, que incluem restrições de tempo, no processo de desenvolvimento e também restrições impostas por normas/leis. Os requisitos não-funcionais, muitas vezes, aplicam-se ao sistema como um todo.
São exemplos de requisitos não-funcionais:
"a base de dados deve ser protegida para acesso apenas de usuários autorizados".
"o tempo de resposta do sistema não deve ultrapassar 30 segundos".
"o software deve ser operacionalizado no sistema Linux"
"o tempo de desenvolvimento não deve ultrapassar seis meses".
Validação de requisitos
É o processo pelo qual se verifica se os requisitos elicitados definem o sistema que o cliente realmente quer. A validação também é importante, uma vez que o custo para remover erros de requisitos é grande, quando descobertos tardiamente.
Durante o processo de validação de requisitos, diferentes tipos de verificação devem ser efetuados no documento de requisitos. Essas verificações incluem:
Validade - O sistema fornece as funções que melhor atendem as necessidades de todos os usuários?
Consistência - Existem conflitos de requisitos?
Completeza - Todas as funções necessárias foram incluídas?
Realismo - Os requisitos podem ser implementados com a tecnologia e orçamento disponíveis?
Verificabilidade - Os requisitos podem ser checados?
 
Uma série de técnicas de validação podem ser utilizadas individualmente ou em conjunto, tais como:
Revisões de requisitos - é feita uma análise manual sistemática dos requisitos;
Prototipação - um modelo executável do sistema é demonstrado para os usuários finais para checar os requisitos;
Geração de casos de teste - os requisitos devem ser testáveis, para tal, devem-se desenvolver testes para os requisitos a fim de verificar a testabilidade.
WEBAULA 2
Unidade 2 – Gerenciamento de Requisitos 
 
O gerenciamento de requisitos é o processo de controlar as mudanças nos requisitos durante o processo de engenharia de requisitos e desenvolvimento. Torna-se necessário manter o acompanhamento dos requisitos individuais e manter as ligações entre os requisitos dependentes, de modo que seja possível avaliar os impactos das mudanças de requisitos.
Considerando que os requisitos são inevitavelmente incompletos e inconsistentes, novos requisitos surgem durante o processo de desenvolvimento e os diferentes pontos de vista que esses requisitos possuem frequentemente são contraditórios.
Existem várias razões pelas quais as mudanças são inevitáveis, dentre elas destacam-se:
A prioridade dos requisitos de diferentes pontos de vista se modificam;
As pessoas que pagam pelo sistema podem especificar os requisitos de maneira conflitante com os requisitos das pessoas que irão utilizar o sistema;
A empresa e o ambiente técnico do sistema se modificam durante o seu desenvolvimento.
 
Evolução dos requisitos
       Do ponto de vista da evolução, os requisitos dividem-se em duas classes:
 
Requisitos permanentes
São requisitos estáveis, derivados da atividade principal da organização. Ex. Em um hospital, sempre haverá requisitos relativos aos pacientes, aos médicos, às enfermeiras a aos tratamentos.
Requisitos voláteis
São requisitos que se modificam durante o desenvolvimento ou quando o sistema está em uso. Requisitos resultantes de políticas governamentais. Ex.: planos de assistência médica.
Os requisitos voláteis podem ser classificados em:
Requisitos mutáveis - Requisitos que se modificam por causa do ambiente do sistema que está operando.
Requisitos emergentes - Requisitos que surgem à medida que a compreensão do sistema pelo cliente progride durante o desenvolvimento do sistema.
Requisitos consequentes - Requisitos que resultam da introdução do sistema de computador, onde podem ser criadas novas formas de trabalho, que geram novos requisitos de sistema.
Requisitos de compatibilidade - Requisitos que dependem de outros sistemas ou processos de negócio específicos dentro da organização.
 
Gerenciamento de mudanças de requisitos
A figura abaixo mostra o processo de gerenciamento de requisitos, o qual deve ser aplicado a todas as mudanças propostas aos requisitos. A vantagem de se usar um método formal para gerenciar as mudanças está no fato de que as propostas são tratadas consistentemente e a documentação dos requisitos é feita de maneira controlada.
 
       Existem três estágios no processo de gerenciamento de mudanças, que são:
Análise do problema e especificação da mudança.
         Discutem-se os problemas com os requisitos e propõem-se mudanças.
Análise e custo da mudança.
         Avaliam-se os efeitos da mudança em outros requisitos do sistema.
Implementação das mudanças.
       O documento de requisitos e outros documentos são alterados de forma a refletir as mudanças.
 
Técnicas de Requisitos
A seguir apresentaremos algumas técnicas para o levantamento e análise de requisitos:
Levantamento baseado em pontos de vista;
Entrevistas;
Cenários de utilização do sistema;
Etnografia (análise do ambiente de trabalho dos usuários).
 
Levantamento baseado em pontos de vista
As abordagens baseadas em pontos de vista têm como ponto forte o reconhecimento de várias perspectivas, fornecendo um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders.
Sistemas médios e grandes possuem diferentes tipos de usuários finais:
Pessoas envolvidas com o sistema possuem diferentes interesses e pontos de vista a respeito do sistema;
A análise desta multiperspectiva é importante para se descobrir e esclarecer os requisitos conflitantes propostos por diferentes usuários.
 
Entrevistas
Fazem parte da maioria dos processos de engenharia de requisitos. Nestas entrevistas, a equipe de engenheiros formula questões para os stakeholders sobre o sistema a ser desenvolvido.
As entrevistas podem ser abertas, em que o stakeholder responde um conjunto de perguntas predefinidas, ou fechadas, nas quais não há um roteiro definido, onde o engenheiro explora vários assuntos com os stakeholders no sistema, desenvolvendo assim uma maior compreensão das suas necessidades.
As entrevistas são úteis para se obter um entendimento geral sobre o que os stakeholders fazem, como eles podem interagir com o sistema e as dificuldades que enfrentam com o sistema atual, porém não são eficientes para elicitação de conhecimento sobre os requisitos e suas restrições.
Cenários de utilização do sistema
Geralmente, as pessoas consideram mais simples relatar exemplos da vida real a que abstrair descrições, desta forma, os cenários podem ser descritos e criticados por eles como uma forma de interação com o sistema de software.
Os cenários são úteis para adicionar detalhes a um esboço da descrição de requisitos, onde cada cenário abrange uma ou mais interações possíveis. Assim sendo, diversos cenários foram desenvolvidos, cada um dos quais fornecendo diferentes tipos de informações sobre o sistema em diversos níveis de detalhamento.
Descrições de cenários incluem:
Estado do sistema no início do cenário;
Fluxo normal de eventos no cenário;
O que pode sair errado e como lidar com isso;
Outras atividades concorrentes;
Estado do sistema no final do cenário.
 
Etnografia (análise do ambiente de trabalho dos usuários)
É uma técnica de observação que pode ser usada na compreensão dos requisitos sociais e organizacionais, na qual um analista se insere no ambiente de trabalho onde o sistema será usado, observa o trabalho do dia a dia e anota as tarefas reais nas quais os participantes estão envolvidos.
Denota-se o valor desta técnica na ajuda prestada aos analistas para se descobrir os requisitos implícitos de sistemas que refletem os processos reais, e não os formais no qual as pessoas estão envolvidas.
A etnografia é particularmente eficaz para descobrir:
Requisitos derivados da maneira como as pessoas realmente trabalham, ao invés da maneira pela qual as definições de processodizem o que deveria fazer.
Requisitos derivados da cooperação e do conhecimento das atividades de outras pessoas.
A etnografia pode e deve ser combinada com a prototipação, pois informa o desenvolvimento do protótipo de tal forma que poucos ciclos de refinamento sejam necessários.
Uma vantagem da etnografia é que ela pode revelar detalhes importantes do processo, que frequentemente são ignorados por outras técnicas, porém, não é apropriada para obter os requisitos organizacionais e de domínio. Assim sendo, a etnografia não é uma abordagem completa para a elicitação de requisitos, então devendo ser usada como complemento de outras abordagens como, por exemplo, a de cenários.
 
	
 
BOAVENTURA, Inês A. G. O processo de engenharia de requisitos. São Paulo: UNESP, 2006. Disponível em:. Acesso em: ago. 2013.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson, 2007. 552p.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson, 2011. 529p.