Erstellt von Raphael Luiz Fonseca
vor etwa 10 Jahre
|
||
- 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 sistema
- Engenheiros de Sw
- Usuários Finais
- Especialistas de Domínio
- Fiscais Externos
- Quanto mais tarde problemas com requisitos são detectados, mais será o custo para corrigi-los
- Definem a funcionalidade do sistema
- Ex: "O sistema deve ser capaz de debitar e creditar uma conta corrente"
- 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"
- Vêm do domínio da aplicação do sistema e refletem característica do domínio
- Derivados da atividade principal da organização
Ex: Em um hospital sempre haverá requisitos relativos aos médicos, pacientes
- Requisitos que mudam durante o desenvolvimento ou quando o sistema está em uso
- Se modificam por causa do ambiente do sistema
- Surge à medida que a compreensão do cliente do sistema se desenvolve
- Resultam na introdução do sistema no ambiente do usuário
- Dependem de outro equipamento ou processo. Conforme eles mudam, o requisito também muda.
- Requisitos que especificam deve se comportar de um determinado modo, por ex: confiabilidade, robustez, rapidez
- Requisitos que são consequência da política e procedimentos
- Requisitos que são externos ao sistema e seu desenvolvimento
- Ex: Legislação, interoperabilidade
- Transação por segundo
- Tempo de resposta para eventos
- Megabytes
- Número de chips ROM
- Tempo médio entre falhas
- Taxa de ocorrência de falhas
- Disponibilidade
- Tempo para recomeçar depois de uma falha
- Probabilidade de corrupção de dados após falha.
- Porcentagem de declarações dependentes de plataforma
- Número de plataformas-alvo
- Se o SW roda em qualquer sistema
- Descobrir
- Tornar explícitos
- Envolve vários stakeholdes
- Levantar documentação
- Entrevistas
- Questionários
- Etnografia
- Workshops
- Casos de Uso
- Prototipagem
- Técnica de observação utilizada para compreender os requisitos sociais e organizacionais
- Analisa como a pessoa trabalha em seu ambiente de trabalho
- 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ção
- Descrições textuais das funcionalidades de um sistema a partir da perspectiva do usuário
- Servem para facilitar o entendimento do sistema mostrando sua "visão externa"
- Nome
- Descrição
- Atores
- Pré Condição
- Fluxo Principal
- Fluxo Alternativo
- Pontos de Extensão
- Pontos de Inclusão
- Fluxo Excepcional
- Pós Condição
- São entidades externas do ambiente do sistema
- Pode ser uma pessoa, sistema ou dispositivo
- Podem ser especializados
- Um caso de uso base incorpora o comportamento de outro Caso de Uso
- Modela partes opcionais da execução de um caso de uso
- Dependem da escolha do ator
- O filho herda o comportamento do pai, podendo adicionar ou redefinir passos em pontos arbitrários do comportamento original
- É iniciado por um ator e constitui um fluxo completo de eventos
- Nunca é instanciando diretamente
- Include, Extend e Generalizaçao
- É um modelo completo das funções do sistema em termos de casos de uso
- Visa descobrir alguns problemas e torná-los mais consistentes antes da especificação formal
- Classificação e Organização
- Checagens de ambiguidade, consistência, Omissões e Relacionamentos
- Priorização e Negociação ( negociar com stakeholders)
- É o produto final produzido pelo engenheiro de requisitos
- Descreve todas as funções de um sistema e as restrições impostas a ele.
- Demonstrar que os requisitos definem o sistema que o usuário realmente deseja
- Um grupo de pessoas se reúne, lê e analisa os requisitos, para identificar problemas e possíveis soluções
- Um protótipo executável demonstra os requisitos e ajudam os stakeholders a descobrir problemas.
- Códigos automatizados que ajudam a mostrar se os requisitos estão ambíguos ou incompletos.
É 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 isso
- Relacionam os requisitos e avaliam seus impactos
- Ligação entre o requisito e o stakeholder que o propôs.
- Ligações de requisitos que dependem entre si
- Ligação entre o requisito e o projeto ( Arquitetura, Módulos, Código)