Karteikarten
Engenharia de Software - Requisitos
Karten in diesem Stapel (47)
- 1- Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer - Delimitar fronteira do sistema - Definir uma interface de usuário para o sistemaEngenharia de Requisitos
- 2—Ciclo de Vida dos Requisitos
- 3- Engenheiros de Sw - Usuários Finais - Especialistas de Domínio - Fiscais ExternosPartes Interessadas ( Stakeholders )
- 4- Quanto mais tarde problemas com requisitos são detectados, mais será o custo para corrigi-losCusto dos Requisitos
- 5- Definem a funcionalidade do sistema - Ex: "O sistema deve ser capaz de debitar e creditar uma conta corrente"Tipos de Requisitos - Funcionais
- 6- Expressam restrições sob as quais o sistema deve operar ou qualidades específicas que o software deve ter - Ex: "O sistema deve suportar pelo menos 20 transações por segundo"Tipos de Requisitos - Não Funcionais
- 7- Vêm do domínio da aplicação do sistema e refletem característica do domínioTipos de Requisitos - De Domínio
- 8- Derivados da atividade principal da organização Ex: Em um hospital sempre haverá requisitos relativos aos médicos, pacientesTipos de Requisitos - Permanentes (Estáveis)
- 9- Requisitos que mudam durante o desenvolvimento ou quando o sistema está em usoTipos de Requisitos - Voláteis
- 10- Se modificam por causa do ambiente do sistemaTipos de Requisitos - Voláteis de Mutação
- 11- Surge à medida que a compreensão do cliente do sistema se desenvolveTipos de Requisitos - Voláteis Emergentes
- 12- Resultam na introdução do sistema no ambiente do usuárioTipos de Requisitos - Voláteis Consequentes
- 13- Dependem de outro equipamento ou processo. Conforme eles mudam, o requisito também muda.Tipos de Requisitos - Voláteis de Compatibilidade
- 14- Requisitos que especificam deve se comportar de um determinado modo, por ex: confiabilidade, robustez, rapidezTipos de RNF's - Produto
- 15- Requisitos que são consequência da política e procedimentosTipos de RNF's - Organizacionais
- 16- Requisitos que são externos ao sistema e seu desenvolvimento - Ex: Legislação, interoperabilidadeTipos de RNF's - Externos
- 17- Transação por segundo - Tempo de resposta para eventosMedição RNF - Desempenho
- 18- Megabytes - Número de chips ROMMedição RNF - Armazenamento
- 19- Tempo médio entre falhas - Taxa de ocorrência de falhas - DisponibilidadeMedição RNF - Usabilidade
- 20- Tempo para recomeçar depois de uma falha - Probabilidade de corrupção de dados após falha.Medição RNF - Robustez
- 21- Porcentagem de declarações dependentes de plataforma - Número de plataformas-alvo - Se o SW roda em qualquer sistemaMedição RNF - Portabilidade
- 22- Descobrir - Tornar explícitos - Envolve vários stakeholdes - Levantar documentaçãoElicitar
- 23- Entrevistas - Questionários - Etnografia - Workshops - Casos de Uso - PrototipagemTécnicas de Elicitação
- 24- Técnica de observação utilizada para compreender os requisitos sociais e organizacionais - Analisa como a pessoa trabalha em seu ambiente de trabalhoTécnica de Elicitação - Etnografia
- 25- Pões todos os stakeholders juntos por um período INTENSIVO(focado) - O facilitador de um workshop é o responsável pelas atividades logísticas e de organizaçãoTécnica de Elicitação - Workshop de Requisitos
- 26- Descrições textuais das funcionalidades de um sistema a partir da perspectiva do usuárioTécnica de Elicitação - Casos de Uso
- 27- Servem para facilitar o entendimento do sistema mostrando sua "visão externa"Técnica de Elicitação - Diagrama de Caso de Uso
- 28- Nome - Descrição - Atores - Pré Condição - Fluxo Principal - Fluxo Alternativo - Pontos de Extensão - Pontos de Inclusão - Fluxo Excepcional - Pós CondiçãoEspecificação de um Caso de Uso
- 29- São entidades externas do ambiente do sistema - Pode ser uma pessoa, sistema ou dispositivo - Podem ser especializadosPapéis Casos de Uso - Atores
- 30- Um caso de uso base incorpora o comportamento de outro Caso de UsoCasos de Uso - Include
- 31- Modela partes opcionais da execução de um caso de uso - Dependem da escolha do atorCasos de Uso - Extend
- 32- O filho herda o comportamento do pai, podendo adicionar ou redefinir passos em pontos arbitrários do comportamento originalCasos de Uso - Generalização
- 33- É iniciado por um ator e constitui um fluxo completo de eventosTipos de Caso de Uso - Concreto
- 34- Nunca é instanciando diretamente - Include, Extend e GeneralizaçaoTipos de Caso de Uso - Abstrato
- 35- É um modelo completo das funções do sistema em termos de casos de usoModelo de Caso de Uso
- 36- Visa descobrir alguns problemas e torná-los mais consistentes antes da especificação formalAnálise de Requisitos
- 37- Classificação e Organização - Checagens de ambiguidade, consistência, Omissões e Relacionamentos - Priorização e Negociação ( negociar com stakeholders)Análise de Requisitos - Atividades
- 38- É o produto final produzido pelo engenheiro de requisitos - Descreve todas as funções de um sistema e as restrições impostas a ele.Especificação de Requisitos
- 39- Demonstrar que os requisitos definem o sistema que o usuário realmente desejaValidação de Requisitos
- 40- Um grupo de pessoas se reúne, lê e analisa os requisitos, para identificar problemas e possíveis soluçõesTécnicas de Validação de Requisitos - Revisões (Inspeções)
- 41- Um protótipo executável demonstra os requisitos e ajudam os stakeholders a descobrir problemas.Técnicas de Validação de Requisitos - Prototipagem
- 42- Códigos automatizados que ajudam a mostrar se os requisitos estão ambíguos ou incompletos.Técnicas de Validação de Requisitos - Casos de Teste
- 43É o processo de gerenciar as mudanças nos requisitos durante o processo de Engenharia de Requisitos - A prioridade de cada requisito muda ao longo do tempo - É necessário gerenciar tudo issoGerenciamento de Requisitos
- 44- Relacionam os requisitos e avaliam seus impactosRastreabilidade
- 45- Ligação entre o requisito e o stakeholder que o propôs.Rastreabilidade de Fonte
- 46- Ligações de requisitos que dependem entre siRastreabilidade de Requisitos
- 47- Ligação entre o requisito e o projeto ( Arquitetura, Módulos, Código)Rastreabilidade de Projeto
Informationen
- Beschreibung
- HARD Específica (Engenharia de Software) Karteikarten am Engenharia de Software - Requisitos, erstellt von Raphael Luiz Fonseca am 18/11/2014.
- Erstellt von
- Raphael Luiz Fonseca · Nov 2014
- Aktualisiert
- 13 Apr 2017
- Aufrufe
- 94
- Tags
- Bewertung