Anda di halaman 1dari 12

Requisitos

• Objetivos ou restrições estabelecidas por


clientes e usuários do sistema que definem
as diversas propriedades do sistema
• Condição ou capacidade necessária que o
software deve possuir
– para que o usuário possa resolver um problema
ou atingir um objetivo
– para atender as necessidades ou restrições da
organização ou de outros componentes do
sistema.

Engenharia de Software, Jair C Leite

Requisitos do usuário, do sistema e


do software [Sommerville, 2004]
• Requisitos do usuário
– Declarações, em linguagem natural e diagramas, sobre os
serviços que o sistema oferece e as restrições para a sua
operação. Escrito para os clientes.
• Requisitos do sistema
– Estabelecem detalhadamente as funções e restrições do
sistema. O documento de requisitos, chamado de
especificação funcional, pode servir como um contrato entre
cliente e desenvolvedor.
• Especificação de software
– Especificação abstrata e precisa do software, indicando o
que ele deve fazer (sem dizer como) que serve de base
para o design e implementação. Acrescenta mais detalhes à
especificação funcional e é escrito para a equipe de
desenvolvimento.

Engenharia de Software, Jair C Leite


Definição e especificação
• Definição dos requisitos do usuário
– O software deve fornecer um meio de representar e acessar
arquivos externos criados por outras ferramentas.
• Especificação dos requisitos do sistema
– O usuário deve dispor de recursos para definir o tipo dos arquivos
externos.
– Cada tipo de arquivo externo pode ter uma ferramenta associada
que pode ser aplicada a ele.
– Cada tipo de arquivo externo pode ser representado por um ícone.
– Quando um usuário seleciona um ícone, o efeito desta seleção é
aplicar a ferramenta associada com o tipo de arquivo.

Engenharia de Software, Jair C Leite

Quem são os interessados nos


requisitos?
• Requisitos do usuário
– Gerentes e contratantes da organização cliente
– Usuários finais
– Engenheiros da organização cliente
– Arquitetos de sistema
• Requisitos do sistema
– Usuários finais
– Engenheiros da organização cliente
– Arquitetos de sistema
– Engenheiros de software
• Especificação de software
– Engenheiros da organização cliente (possivelmente)
– Arquitetos de sistema
– Engenheiros de software
Engenharia de Software, Jair C Leite
Problemas comuns
• Os envolvidos* não sabem o que eles realmente
querem.
• Se expressam num vocabulário diferente dos
desenvolvedores.
• Os envolvidos podem ter requisitos conflitantes.
• Fatores organizacionais e políticos podem influenciar
os requisitos.
• Novos requisitos podem surgir durante o processo de
levantamento/análise/especificação.
• Novos envolvidos podem vir a participar do process.
• Podem haver mudanças externas – ambiente ou
regras de negócios.
*Stakeholders: Envolvidos ou partes interessadas
Engenharia de Software, Jair C Leite

Como descrever os requisitos?


• A especificação dos requisitos deve ser:
– Completa – deve descrever tudo o que é necessário
– Consistente – não deve haver conflitos e contradições
– Não-ambígua – não deve levar a interpretações diferentes
por desenvolvedores e usuários.
• Difícil de atingir considerando que existem diferentes
tipos de envolvidos.
• Depende da precisão da linguagem utilizada
– Linguagem natural, informal – apropriada para os requisitos
do usuário e do sistema.
– Linguagens gráficas, semi-formais – apropriada para os
requisitos do sistema e do software.
– Linguagens formais – apropriada para uma especificação
formal de software em métodos formais.

Engenharia de Software, Jair C Leite


Requisitos funcionais
• Descrição das diversas funções que clientes e
usuários querem ou precisam que o software ofereça
• Casos de Uso
• Exemplos:
– "o software deve possibilitar o cálculo dos gastos diários,
semanais, mensais e anuais com pessoal".
– "o software deve emitir relatórios de compras a cada quinze
dias"
– "os usuários devem poder obter o número de aprovações,
reprovações e trancamentos em todas as disciplinas por um
determinado período de tempo.

Engenharia de Software, Jair C Leite

Requisitos não-funcionais
• Propriedades de um software, como
manutenibilidade, usabilidade, desempenho,
custos e várias outras
• São exemplos de requisitos não-funcionais:
– "a base de dados deve ser protegida para acesso
apenas de usuários autorizados".
– "o tempo de resposta do sistema não deve
ultrapassar 30 segundo".
– "o software deve ser operacionalizado no sistema
Linux"
– "o tempo de desenvolvimento não deve
ultrapassar seis meses".

Engenharia de Software, Jair C Leite


Tipos de requisitos não-funcionais
No n-fu nctional
requ ir ements

Pro du ct Or gan izational Ex tern al


requ ir ements requ ir ements requ irements

Ef ficiency Reliab ility Po rtability Intero perab ility Ethical


requ ir ements requ ir ements requ irements requ irements requ irements

Usab ility Delivery Implementatio n Stand ard s Leg islative


requ irements requirements requ ir ements requ irements requ irements

Perfo rmance Sp ace Privacy Safety


requ irements requ ir ements requ irements requ irements

Engenharia de Software, Jair C Leite

Requisitos não-funcionais e métricas


• Velocidade • Confiabilidade
– Transações – Tempo médio para falhar
processadas/segundo – Taxa de ocorrência de
– Tempo de resposta ao falhas.
usuário – Probabilidade de
• Tamanho indisponibilidade.
– Tamanho em bytes do • Robustez
software final – Tempo de reinício após
– Memória falha
– Porcentual de eventos que
• Facilidade de uso causam falhas
– Tempo de treinamento
• Portabilidade
necessário
– Número de ambientes
– Número de telas de
operacionais nos quais o
ajuda
sistema pode rodar.

Engenharia de Software, Jair C Leite


Engenharia de Requisitos – 1/2
• Requisitos mudam sempre!
• Requisitos precisam ser levantados,
analisados, especificados, rastreados,
verificados e documentados.
• Estas atividades ocorrem ao longo de todo o
ciclo-de-vida do software.
• A Engenharia de Requisitos propõe
modelos, métodos, técnicas e ferramentas
para a realização destas atividades

Engenharia de Software, Jair C Leite

Engenharia de Requisitos – 2/2


• Estudo de viabilidade
• Levantamento
• Análise
• Especificação
• Gerenciamento
• Rastreamento
• Verificação e Validação
• Documentação

Engenharia de Software, Jair C Leite


O processo de engenharia de
requisitos

Fonte: Ian Sommerville

Engenharia de Software, Jair C Leite

Estudo de viabilidade
• Decide se o sistema proposto é vantajoso e lucrativo.
• Deve verificar se:
– O sistema contribui para os objetivos organizacionais.
– O sistema pode ser construído com a tecnologia corrente e
com o orçamento disponível.
– O sistema pode ser integrado com os outros sistemas em
utilização.
• Questões a serem respondidas por clientes e
usuários:
– E se o sistema não for implementado?
– Quais os problemas atuais?
– Como o sistema irá ajudar?
– Quais serão os problemas de integração?
– Novas tecnologias são necessárias? Quais habilidades?
– Quais facilidades deve ser providas pelo sistema proposto?
Engenharia de Software, Jair C Leite
Levantamento de requisitos
• Obter os requisitos dos especialistas no
domínio – clientes e usuários
• Principal problema: comunicação
– Usuários e especialistas não compartilham o
mesmo vocabulário
• Técnicas de Comunicação
– Entrevistas
– Observação direta
– Encontros

Engenharia de Software, Jair C Leite

Análise de requisitos
• A análise possui dois propósitos:
– Permite julgamentos sobre a qualidade dos
requisitos do sistema
– Elaborar um modelo de alto-nível do sistema com
os principais componentes e suas interfaces
• Abordagens para a análise
– Análise Estruturada
– OMT
– UML: Casos de Uso e Diagramas de classes

Engenharia de Software, Jair C Leite


Especificação de requisitos
• Descrição objetiva, precisa e completa dos
requisitos do software
• A especificação de um requisito funcional
deve determinar o que se espera que o
software faça, sem a preocupação de como
ele faz
• Requisitos funcionais podem ser descritos
por Diagramas de Casos de Uso – UML
• Requisitos não-funcionais são descritos
textualmente.

Engenharia de Software, Jair C Leite

Verificação e Validação de Requisitos


• Validação
– “Estamos construindo o sistema certo?”
• Verificação
– “Estamos construindo certo o sistema?”
• Consistência
– Os requisitos não devem ser contraditórios.
• Completeza
– Os requisitos devem considerar todas as necessidades e
restrições do envolvidos.
• Viabilidade
– Existe tecnologia e recursos suficientes?

Engenharia de Software, Jair C Leite


Abordagens para levantamento-
análise-especificação
• Etnografia
– Técnica de observação da antropologia.
– Considera que os requisitos são derivados do contexto
social e organizacional.
– O engenheiro-analista se insere no ambiente de trabalho.
• Cenários
– Descrição de possíveis situações de uso.
– Estimula o questionamento (5W 1H)
• Casos de Uso
– Baseada em cenários mais diagramas.
– Parte da UML e fundamental para o RUP.
• Definição de Requisitos Orientada a Pontos-de-Vista
(VORD)
– Analisa e descreve os requisitos a partir dos pontos-de-
vistas dos envolvidos.
Engenharia de Software, Jair C Leite

Gerenciamento de requisitos
• Requisitos mudam durante e depois do
desenvolvimento (média de 1%/mês)
• Causas:
– Novas necessidades de clientes e usuários
– Mudanças na tecnologia utilizada
– Mudanças em leis, normas ou padrões
• As mudanças nos requisitos podem causar
impacto nos requisitos relacionados
• As técnicas de gerenciamento visam rastrear
e controlar estas mudanças

Engenharia de Software, Jair C Leite


O processo de levantamento-análise-
especificação-validação.

Engenharia de Software, Jair C Leite

Documentação
• Normas e padrões
– ANSI/IEEE STD 830-1993
– MIL-STD-2167A e MIL-STD-498
• Tópicos comuns
– Descrição geral
– Interfaces externas
– Requisitos funcionais
– Requisitos de desempenho
– Restrições de design
– Atributos de qualidade

Engenharia de Software, Jair C Leite


Documento de requisitos do IEEE
• Introdução • Requisitos específicos
– Propósito do documento de – Esta é a parte substancial
requisitos do documento, mas não
– Escopo do produto existe uma estrutura
– Definições, acrônimos e padrão, variando de acordo
abreviações com o método utilizado.
– Referências – Deve conter a arquitetura
– Visão geral do restante do do sistema, interfaces
documento externas e as funções
• Descrição Geral (serviços) que o sistema
– Perspectiva do produto oferece.
– Funções do produto – Os requisitos não funcionais
– Características dos usuários são colocados aqui
– Restrições gerais também.
– Suposições e dependências • Apêndices
• Indices
Engenharia de Software, Jair C Leite

Anda mungkin juga menyukai