Modelagem de Sistemas de Informação 04

50 %
50 %
Information about Modelagem de Sistemas de Informação 04
Technology

Published on March 11, 2014

Author: daniballester

Source: slideshare.net

Description

Engenharia de Requisitos

Modelagem de Sistema de Informaçã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ção Té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ção Té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ção Té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ção Té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ção Té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ção Apó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ção Na 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ção Exemplo de requisitos funcionais:

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

Engenharia de Requisitos – especificação e documentação Requisitos 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ção 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 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ção Classificaçã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ção Requisitos 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ção Requisitos de Domínio - Exemplos

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

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

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Modelagem de Sistemas de Informação 04 - Technology

1. Modelagem de Sistema de Informação Aula 04 – Levantamento de Requisitos . 2. Cenário atual do desenvolvimento de software . 3. Causas de falhas em ...
Read more

Modelagem de Sistemas de Informação - unip.moraes.org

83 MODELAGEM DE SISTEMAS DE INFORMAÇÃO Revisora: Marina - Diagramação: Léo/Fabio para 1° Revisão - 19/04/07 || Revi sora: Sueli / Syl via ...
Read more

Modelagem de Sistemas da Informação – Aula 03/05/2011 ...

Modelagem de Sistemas da Informação – Aula 03/05/2011. Publicado por neoand on 04/05/2011. Download. Curtir isso: Curtir ...
Read more

Modelagem de Sistemas de Informação - unip.moraes.org

125 MODELAGEM DE SISTEMAS DE INFORMAÇÃO Revisora: MArina - Diagramação: Meire / Márcio - para 1ª revisão: 19/04/07 // Márcio - para 2ª revisão ...
Read more

Modelagem de Sistemas de Informação 05 - Technology

Share Modelagem de Sistemas de Informação 05.
Read more

ATPS MODELAGEM DE SISTEMAS Trabalhos e monografias 1 - 25

Trabalhos gratuitos em ATPS MODELAGEM DE SISTEMAS. ... Guarulhos 22/04 ... Tecnologia da Gestão da Tecnologia da Informação. ATPS de Modelagem de Sistemas.
Read more

PROVA AV1 MODELAGEM DE SISTEMAS - passeidireto.com

Baixe grátis o arquivo PROVA AV1 MODELAGEM DE SISTEMAS enviado para a disciplina de ... 2 Data: 26/04/2013 11:11:21 1a Questão (Cód ...
Read more

FORUM- MODELAGEM DE SISTEMAS A (2) - passeidireto.com

... 04 A aula 1 fala ... essenciais quando usamos a UML para modelagem de sistemas ... provocados por problemas de comunicação e transformação de ...
Read more