ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

Transcrição

1 ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Requisitos

2 REQUISITOS Descrições do que o sistema deve fazer, os serviços oferecidos pelo mesmo e as restrições ao seu funcionamento. Reflete as necessidades do cliente. Processo de analisar, documentar e verificar esses serviços é chamada de Engenharia de Requisitos (Requirements Engineering).

3 REQUISITOS Requisito não é um termo utilizado conscientemente pela industria de software. Pode representar: Uma declaração abstrata de alto nível. Uma definição detalhada e formal de uma função do sistema de software.

4 NÍVEIS DE (ABSTRAÇÃO DE) REQUISITOS Falha nos níveis de descrição = falha no Sistema de Software. Níveis de requisitos: Requisitos de Usuário: declarações, em linguagem, natural com diagramas, de quais serviços o sistema deve oferecer e as restrições com as quais deve operar. Requisitos de Sistema: descrições detalhadas das funções, serviços e restrições operacionais do sistema. Essa documentação deve definir exatamente o que deve ser implementado.

5 NÍVEIS DE (ABSTRAÇÃO DE) REQUISITOS Úteis para comunicar informações do sistema sobre o sistema para diferentes tipos de leitores. Os leitores dos requisitos de usuário não costumam se preocupar com a forma como o sistema será implementado. Os leitores dos requisitos de sistema precisam saber mais detalhadamente o que sistema fará, uma vez estão interessados em por que estão envolvidos no sistema, ou como apoiarão os processos operacionais.

6 NÍVEIS DE (ABSTRAÇÃO DE) REQUISITOS Leitores dos requisitos de usuário: Gerentes clientes; Usuários finais do sistema; Engenheiros clientes; Gerentes contratantes; Arquitetos do sistema. Leitores dos requisitos de sistema: Usuários finais do sistema; Engenheiros clientes; Arquitetos de sistema; Desenvolvedores do software.

7 CLASSIFICAÇÃO DE REQUISITOS Requisitos Funcionais: declarações de serviços que o sistema deve fornecer (e, em alguns casos, o que não deve), de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações. Requisitos Não Funcionais: restrições aos serviços que o sistema deve fornecer, mas imposta ao sistema como um todo, e não a características (componentes) individuais.

8 REQUISITOS FUNCIONAIS Especificação completa e consistente. Completude: todos os serviços requeridos pelo usuário devem ser definidos. Consistência: requisitos não podem apresentar definições contraditórias. Na prática, em sistemas de grande escala, é difícil alcançar a completude e manter a consistência. Complexidade falicita erros e omissões. Stakeholders.

9 REQUISITOS NÃO FUNCIONAIS Afetam a arquitetura do sistema como um todo (Ex.: Desempenho). Um único requisito não funcional (Ex.: Proteção) pode gerar uma série de requisitos não funcionais. Surgem: Necessidades do cliente; Restrições orçamentais, organizações ou políticas; Necessidade de interoperabilidade (software e hardware); Regulamentos externos (legislações de segurança ou privacidade).

10 REQUISITOS NÃO FUNCIONAIS Requisitos de Produto: provenientes das características do software requeridas para o software, especificando ou restringindo seu comportamento. Ex.: Memória, confiabilidade, falhas, usabilidade, etc. Requisitos de Organizacionais: provenientes da Organização que desenvolve o software (e/ou da contratante), derivados de suas políticas e procedimentos. Como usar, linguagem, ambiente, etc. Requisitos Externos: provenientes de fatores externos ao sistema e seu processo. Inclui requisitos reguladores, requisitos legais e requisitos éticos.

11 REQUISITOS NÃO FUNCIONAIS

12 REQUISITOS NÃO FUNCIONAIS (MÉTRICAS) Propriedade Velocidade Tamanho Facilidade de Uso Confiabilidade Robustez Portabilidade Medida Transações processadas/segundo Tempo de resposta Tempo de atualização de tela Megabytes Número de chips de Memória ROM Tempo de treinamento Número de frames de ajuda Tempo médio para falha Probabilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade Tempo de reinício após falha Percentual de eventos que causam falhas Corrupção de dados em caso de falha Percentual de declarações do sistema alvo Número de sistemas-alvo

13 DOCUMENTO DE ENGENHARIA DE REQUISITOS Usuário Clientes do sistema Gerentes Engenheiros de sistema Engenheiros de teste de sistema Engenheiros de manutenção de sistema Finalidade Especificar e ler os requisitos para verificar se estes satisfazem suas necessidades, assim como especificar alterações. Planejar uma proposta para o sistema assim como para o processo de desenvolvimento do mesmo. Entender o sistema que será desenvolvido. Desenvolver testes de validação. Entender o sistema e o relacionamento entre suas partes.

14 PROCESSO DE ENGENHARIA DE REQUISITOS

15 PROCESSO DE ENGENHARIA DE REQUISITOS Interativo, com atividades intercaladas. Tempo/Esforço em cada atividade depende do estádio corrente do processo como um todo e do tipo do sistema de software em desenvolvimento. Início: compreensão dos requisitos de negócio e não funcionais, bem como requisitos de usuário para o sistema. Meio: Elicitar e compreender os requisitos de sistema em detalhes. Saída: Documento de Requisitos.