Mapa Mental

1. Levantamento De Requisito Esta atividade relaciona-se à obtenção dos requisitos do software. Para isto, analistas e engenheiros de software trabalham com clientes e usuários finais para descobrir o problema a ser resolvido, os serviços do sistema, o desempenho necessário, restrições de hardware e outras informações. Entrevista: esta técnica resume-se em “conversas” realizadas com o usuário (entrevistado) para levantar os requisitos do sistema a ser desenvolvido. Podemos decompor esta técnica nas seguintes atividades: • Ler material de suporte; • Estabelecer os objetivos da entrevista; • Decidir quem entrevistar; • Preparar o entrevistado; • Decidir os tipos de questões e a sua estrutura. Uma entrevista pode ser estruturada de três diferentes formas: • Estrutura em pirâmide: iniciamos as entrevistas com perguntas mais especificas sobre o sistema e fechamos com perguntas mais genéricas. Geralmente utilizadas com usuários mais relutantes; • Estrutura em funil: iniciamos as entrevistas com perguntas mais genéricas sobre o sistema e fechamos com perguntas mais especificas. Geralmente utilizadas com usuários que tem uma relação mais afetiva com o assunto; • Estrutura em diamante: esta estrutura combina as duas estruturas anteriores e é utilizadas para manter a usuário entrevistado interessado no assunto e para isto se utiliza de perguntas variadas.

2. Registro Uma vez identificados e negociados, os requisitos devem ser documentados para que possam servir de base para o restante do processo de desenvolvimento. Verificação Esta atividade examina a especificação do software, de forma a assegurar que todos os requisitos foram definidos sem ambiguidades, inconsistências ou omissões, detectando e corrigindo possíveis problemas ainda durante a fase de definição dos requisitos.

3. Requisitos não funcionais São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter. Em vez de informar o que o sistema fará, os requisitos não-funcionais colocam restrições no sistema. Alguns exemplos são: • O software deve ser compatível com os browsers IE (versão 5.0 ou superior) e Firefox (1.0 ou superior); • O software deve garantir que o tempo de retorno das consultas não seja maior do que 5 segundos.

4. Requisitos de domínio São requisitos derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio. 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.

5. Engenharia de Requisitos Existem diferentes definições encontradas na literatura técnica para engenharia de requisitos: • Termo usado para descrever as atividades relacionadas à investigação e definição de escopo de um sistema de software; • Processo sistemático de desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma variedade de formatos e a acurácia das observações é constantemente verificada; • Processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema. Embora coerentes, estas definições podem ser melhoradas. Perceba que elas referem-se apenas às atividades relacionadas à produção de requisitos. Entretanto, nada é dito a respeito da gerência destas atividades, também conhecida como gerência de requisitos. Com isto em mente, podemos evoluir a definição de engenharia de requisitos para: termo usado para descrever as atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos.

6. Definição de requisitos:Requisitos são, além de funções, objetivos, propriedades, restrições que o sistema deve possuir para satisfazer contratos, padrões ou especificações de acordo com o(s) usuário(s). De forma mais geral um requisito é uma condição necessária para satisfazer um objetivo. Requisitos são importantes para: • Estabelecer uma base de concordância entre o cliente e o fornecedor sobre o que o software fará; • Fornecer uma referência para a validação do produto final; • Reduzir o custo de desenvolvimento (como vimos anteriormente, requisitos mal definidos causam retrabalho).

7. Tipos de Requisitos:Requisitos funcionais São requisitos diretamente ligados a funcionalidade do software, descrevem as funções que o software deve executar. Alguns exemplos são: • O software deve permitir o cadastro de clientes; • O software deve permitir a geração de relatórios sobre o desempenho de vendas no semestre; • O software deve permitir o pagamento das compras através de cartão de crédito.

8. Alguns dos principais objetivos da engenharia de requisitos: • estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo projeto de software; • registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento; • documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da engenharia de software; • manter planos, artefatos e atividades de software consistentes com os requisitos alocados. Um processo de engenharia de requisitos é um conjunto estruturado de atividades a serem seguidas para criar, validar e manter um documento de requisitos.

9. A atividade de levantamento de requisitos não é trivial. Existe um conjunto grande e variado de fatores que a tornam complexa, por exemplo: • Falta de conhecimento do usuário das suas reais necessidades • Usuário com vaga noção do que precisa e do que um produto de software pode oferecer. • Falta de conhecimento do desenvolvedor do domínio do problema • Desenvolvedor sem conhecimento adequado do domínio, o que leva a decisões erradas. • Domínio do processo de levantamento de requisitos pelos desenvolvedores • Desenvolvedor não ouve o que os usuários têm a dizer e força suas próprias visões e interpretações. • Comunicação inadequada entre os desenvolvedores e usuários • Usuários incapazes de expressar suas necessidades apropriadamente; • Significados diferentes a termos comuns. • Dificuldade do usuário tomar decisões • Falta de entendimento sobre as conseqüências das decisões ou as alternativas possíveis. • Problemas de comportamento • O levantamento de requisitos é um processo social; • Conflitos e ambiguidades nos papéis que os usuários e desenvolvedores desempenham. • Questões técnicas • Complexidade crescente dos sistemas atuais.A atividade de levantamento de requisitos não é trivial. Existe um conjunto grande e variado de fatores que a tornam complexa, por exemplo: • Falta de conhecimento do usuário das suas reais necessidades • Usuário com vaga noção do que precisa e do que um produto de software pode oferecer. • Falta de conhecimento do desenvolvedor do domínio do problema • Desenvolvedor sem conhecimento adequado do domínio, o que leva a decisões erradas. • Domínio do processo de levantamento de requisitos pelos desenvolvedores • Desenvolvedor não ouve o que os usuários têm a dizer e força suas próprias visões e interpretações. • Comunicação inadequada entre os desenvolvedores e usuários • Usuários incapazes de expressar suas necessidades apropriadamente; • Significados diferentes a termos comuns. • Dificuldade do usuário tomar decisões • Falta de entendimento sobre as conseqüências das decisões ou as alternativas possíveis. • Problemas de comportamento • O levantamento de requisitos é um processo social; • Conflitos e ambiguidades nos papéis que os usuários e desenvolvedores desempenham. • Questões técnicas • Complexidade crescente dos sistemas atuais.

10. Alunos:Matheus Lucas Moraes Fonseca é Lucas De Jesus

10.1. Curso:GTI