Modelagem deSistema deInformação

Aula 04 – Levantamento de Requisitos

Cenário atual do desenvolvimento de software

Causas de falhas em projetos de software

Requisitos e análise de sistemas

Requisitos - Definição

Segundo o Rational Unified Process (RUP):

É uma condição ou uma capacidade que deve ser atendida pelo sistema.

Definição do IEEE (Institute of Electrical and Electronics Engineers):

É uma condição ou capacidade que deve ser atendida pelo software, necessária a um usuário para solucionar um problema ou atender a um objetivo.

O conjunto de todos os requisitos formam a base para posterior desenvolvimento do sistema ou componente do sistema.

SWEBOK (Software Engineer Body Of Knowledge)

Expressa necessidades e restrições ao produto de software que contribui para a solução de problemas no domínio do negócio.

Engenharia de Requisitos

É 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.

O processo de engenharia de requisitos é composto por quatro atividades de alto nível :

• identificação;

• análise e negociação;

• especificação e documentação;

• validação.

Engenharia de Requisitos

Engenharia de Requisitos

Engenharia de Requisitos

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.

Engenharia de Requisitos

• Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com "as partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões:

• Será que o sistema contribui para os objetivos da organização?

• Dadas as restrições tecnológicas, organizacionais e temporais associadas ao projeto, será que o sistema pode ser implementado?

• Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?

Engenharia de Requisitos - identificação

• Algumas das atividades envolvidas nesta fase incluem:

• 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 viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos usuários 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.

Engenharia de Requisitos - identificação

Algumas dificuldades típicas estão associadas:

• 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.

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Entrevistas e Questionários

• É a técnica mais simples de utilizar. 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).

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Workshops 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.

• 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 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.

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Cenários

• Uma forma de levar as pessoas a imaginarem o comportamento de um sistema. 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.

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Prototipagem

• 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.

• São desenvolvidas apenas 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.

• 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 usuários é, para eles, um aspecto crítico.

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Estudo etnográfico

• 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. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções "corretamente", pelo que convém ter algum cuidado na escolha do mesmo.

Engenharia de Requisitos – análise e negociaçãoApós a identificação dos requisitos do sistema, segue-se à etapa de análise dos requisitos e negociação.

Algumas das atividades envolvidas na análise de requisitos incluem:

• classificação: agrupamento de requisitos em "módulos" para facilitar a 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 exemplo elevada/média/baixa); este pode ser um fator gerador de conflitos;

• confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade.

A 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.

Engenharia de Requisitos – análise e negociaçãoNa fase de negociação, tornam-se necessários alguns cuidados para que esta decorra sem problemas, chegando-se logo a consensos. Algumas sugestões são:

• 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.

Engenharia de Requisitos – especificação e documentaçãoÉ nesta fase que se dá a produção propriamente dita do Documento de Especificação de Requisitos.

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 usuário espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.

• Requisitos não-funcionais (de qualidade): referem-se a aspectos não-funcionais do sistema, como restrições e propriedades nas quais o sistema deve operar ou propriedades emergentes do sistema. São a forma como os requisitos funcionais devem ser alcançados.

Engenharia de Requisitos – especificação e documentaçãoExemplo de requisitos funcionais:

Engenharia de Requisitos – especificação e documentaçãoEXERCÍCIO:

Engenharia de Requisitos – especificação e documentaçãoRequisitos Não funcionais

• Demonstram qualidade acerca dos serviços ou funções disponibilizadas pelo sistema. Ex.: tempo, o processo de desenvolvimento, padrões, etc.

• Surgem conforme a necessidade dos usuários, em razão 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.

Engenharia de Requisitos – especificação e documentaçãoClassificaçã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 de 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 facilidade de uso. Ex.: usuários deverão operar o sistema após um determinado tempo de treinamento.

• Requisitos de eficiência. Ex.: o sistema deverá processar n requisições por um determinado tempo.

• Requisitos de confiabilidade. Ex.: o sistema deverá ter alta disponibilidade, p.exemplo, 99% do tempo.

Engenharia de Requisitos – especificação e documentaçãoClassificação dos Requisitos Não Funcionais

• Requisitos de portabilidade. Ex.: o sistema deverá rodar em qualquer plataforma.

• Requisitos de entrega.Ex.: um relatório de acompanhamento deverá ser fornecido toda segunda-feira.

• Requisitos de implementação.: Ex.: o sistema deverá ser desenvolvido na linguagem Java.

• Requisitos de padrões.: Ex. uso de programação orientada a objeto sob a plataforma A.

• Requisitos de interoperabilidade.:Ex. o sistema deverá se comunicar com o SQL Server.

• Requisitos éticos. Ex.: o sistema não apresentará aos usuários quaisquer dados de cunho privativo.

• Requisitos legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, etc.

• Requisitos de Integração. Ex.: o sistema integra com outra aplicação.

Engenharia de Requisitos – especificação e documentaçãoRequisitos de Domínio

Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e não de necessidades específicas dos usuários, podendo depois ser classificados como funcionais ou não-funcionais.

Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas. Dois exemplos de requisitos do domínio são:

• O calculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3)/5;

• Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pré-requisitos.

Engenharia de Requisitos – especificação e documentaçãoRequisitos de Domínio - Exemplos

Engenharia de Requisitos – especificação e documentaçãoRequisitos de Domínio - Exercício

Engenharia de Requisitos – especificação e documentaçãoRequisitos de Domínio – Respostas