Upload
internet
View
119
Download
1
Embed Size (px)
Citation preview
Requisitos de Software
Engenharia de Requisitos• Estabelece o processo de definição de Requisitos
como um processo no qual o que deve ser feito é elucitado, modelado e analisado.
• Este processo deve lidar com diferentes pontos de vista, e usar uma combinação de métodos, ferramentas e pessoal. O produto desse processo é um modelo, do qual um documento de requisitos é produzido.
3
Engenharia de requisitos
• Um dos principais objetivos da engenharia de requisitos é melhorar a modelagem de sistemas e a capacidade de analisá-los, possibilitando maior entendimento de suas características antes da implementação.– É seu papel realizar a interação entre requisitantes
e desenvolvedores, entre “o que” deve ser feito e “como” deve ser feito.
Tarefas• Elicitar, • Analisar conflitos, • validar, • priorizar, • modificar e reusar requisitos, • rastreá-los considerando sua origem, os componentes
arquiteturais e o código que os implementa, • Dentre outras tarefas.
ELICITAR
ANALISAR
MODELAR
UdeI
Documento de Requisitosdo Software
Decisões daAnálise
Métodos,Técnicas eFerramentas
UdeI
Modelo deAnálise doSistema
Ambiente do negócio
Atividades desenvolvidas
6
Elicitação• Objetivo Obter conhecimento do domínio do problema• ELICITAR Eliciar + Clarear + Extrair + Descobrir , tornar explícito, obter o máximo
de informação para o conhecimento do objeto em questão– Eliciar = Fazer sair, extrair, trazer à tona (a verdade).
• HÁ TRÊS ATIVIDADES PRINCIPAIS:– Identificação de fontes de informação– Coleta de Fatos– Comunicação
• Faz Coleta de Fatos• Faz Identificação de Fontes de Informação• Faz Comunicação• Usa Ferramentas• Usa Pessoal• Usa Métodos• Depende de Pontos de Vista
7
Identificação das fontes de informação
• UdeI Contém toda informação necessária– Agentes (Atores, Usuários)
• Outras fontes de Informação:– Políticas– Manuais– Memos, atas, contratos...– Livros sobre tema relacionado– Outros sistemas da empresa– Outros sistemas externos
• Importante: – Priorizar as Fontes de Informação:
• Atores mais importantes• Documentos mais mencionados• Rede de comunicações entre os componentes do macro-sistema
8
Coleta de fatos
• Leitura de documentos• Observação• Entrevistas• Questionários• Análise de Protocolos• Participação ativa dos agentes do UdeI• Reuniões• Reutilização• Recuperação (eng. reversa) do projeto do software
9
Comunicação
• (...ENTRE CLIENTES/AGENTES E OS ENG. SOFTWARE)• Apresentação: A forma como a informação é apresentada• Entendimento: Estabelecimento de contextos comuns.• Linguagem• Nível de Abstração• Retro-alimentação
Níveis de Descrição
• Usuário – declarações em linguagem natural e também em diagramas sobre as funções que o sistema deve fornecer e suas restrições.
• Sistema – estabelece detalhadamente as funções e restrições do sistema. Tem como saída o documento de requisitos, que deve ser preciso.
• Projeto de software – documento ainda mais detalhado. Descrição abstrata do projeto do software.
1. The software must provide a means of representing and1. accessing external files created by other tools.
1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.
Requirements definition
Requirements specification
Client managersSystem end-usersClient engineersContractor managersSystem architects
System end-usersClient engineersSystem architectsSoftware developers
Client engineers (perhaps)System architectsSoftware developers
User requirements
System requirements
Software designspecification
Tipos de Requisitos
• Funcionais• Não-funcionais• De Domínio
Requisitos Funcionais
• São declarações de funções que o sistema deve fornecer.
• Como o sistema deverá reagir a determinadas entradas.
• Como deve se comportar em determinadas situações.
Requisitos Funcionais
• Descrevem a função de sistema detalhadamente, suas entradas, saídas, exceções, etc.
Requisitos Não-Funcionais
• São restrições sobre os serviços ou as funções oferecidas pelo sistema.
• Podem estar relacionados a propriedades como confiabilidade, tempo de resposta e espaço em disco.
Requisitos Não-Funcionais
• Muitos desses requisitos dizem respeito ao sistema como um todo, e não a características individuais do sistema.– A falha em não cumprir com um requisito
funcional pode degradar o sistema, a falha em não cumprir um requisito não funcional pode tornar todo o sistema inútil.• Ex: confiabilidade sistema de aviação.
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
Métricas para especificar requisitos não-funcionais
Property MeasureSpeed Processed transactions/second
User/Event response timeScreen refresh time
Size K BytesNumber of RAM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
Requisitos do Domínio
• São derivados do domínio da aplicação do sistema, em vez de serem obtidos a partir das necessidades específicas dos usuários do sistema.– Ex: podem especificar como um cálculo é feito.– Pi = 3,14
Requisitos do usuário
• Devem descrever os requisitos funcionais e não funcionais de forma clara e compreensível por usuários do sistema que não têm conhecimento técnico.– Devem especificar somente o comportamento
externo, evitando tanto quanto possível as características do projeto.
Requisitos do usuário
• Devem descrever os requisitos funcionais e não funcionais de forma clara e compreensível por usuários do sistema que não têm conhecimento técnico.– Devem especificar somente o comportamento
externo, evitando tanto quanto possível as características do projeto.
– Devem ser escritos usando linguagem natural, tabelas e diagramas
Problemas com a Linguagem Natural
• Falta de clareza– Utilizar linguagem de maneira precisa sem ambiguidades.
• Confusão de requisitos– Requisitos funcionais, não-funcionais e objetivos do sistema podem
não estar claramente definidos.
• Fusão de requisitos– Vários requisitos diferentes podem ser expressos juntos como um só.
Exemplo 1 – Requisito Funcional – Login
• RF01 – Realizar login/logout; • Para a execução do login no sistema, o usuário deve fornecer
seu login e senha.• O login sendo efetuado com sucesso, o usuário terá mais opções
referentes aos módulos mencionados na descrição do sistema– Sistema possui apenas um tipo de usuário.– Usuário possui a opção de efetuar o logout.
Exemplo 1 – Requisito Não-Funcional
• RNF01 – Portabilidade com os sistemas operacionais Windows e Linux, através de browsers.
Guia a seguir
• Crie um formato padrão e use para todos os requisitos.
• Utilize a linguagem de forma consistente.• Utilize destaques no texto para ressaltar
partes importantes.• Evite o uso de termos técnicos (jargões).
Requisitos do Sistema
• Descrições Mais detalhadas dos requisitos do usuário.
• Servem de base para o projeto do sistema• Podem ser usada como base para o contrato
destinado a implementação do sistema.• A especificação dos requisitos do sistema
pode incluir diferentes modelos do sistema.
Documento de requisitos
• Como resultado do processo de engenharia de requisitos é desenvolvido o documento de requisitos do software. – Este documento contém a especificação de todos
os requisitos funcionais e de qualidade do software, incluindo as capacidades do produto, os recursos disponíveis, os benefícios e os critérios de aceitação
• Cada requisito deve ter um identificador único, por exemplo, um identificador numérico, para posterior referência
• Os requisitos do software devem estar divididos em requisitos funcionais e não funcionais.
Documento de requisitos
Estrutura do documento de Requisitos
• Índice • Introdução• Glossário • Definição dos requisitos do usuário• System architecture• System requirements specification• System models• System evolution• Apêndices
Exemplo
• Definição do contextoEste sistema será utilizado para uma rede de hotéis. Cada hotel terá um ou vários terminais que permitirão as operações básicas de um hotel, podendo o cliente reservar um apartamento através da Web, terá também comunicação com outro hotéis da mesma rede de modo a consultar sobre disponibilidade de vagas.
Exemplo • Escopo
Este sistema será utilizado para uma rede de hotéis. Cada hotel terá um ou vários terminais que permitirão as operações básicas de um hotel, podendo o cliente reservar um apartamento através da Web, terá também comunicação com outro hotéis da mesma rede de modo a consultar sobre disponibilidade de vagas.Este produto é um sistema para gerenciar reservas e ocupações de apartamentos de uma rede de hotéis. Em cada hotel, terá um ou mais terminais para controlar os serviços internos e comucação entre hotéis da mesma rede de forma a consultar sobre disponibilidade de vagas em outrqas unidades da mesma cidade ou região. Além disso, permite o cliente fazer reservas e cancelamento de reservas através da Web. Este sistema também faz interface com outros dois sistemas internos do hotel: controle de restaurante e controle de tarifação de telefone.As funções básicas de controle que devem se ter são: cadastro de cliente, gerenciamento de reservas e ocupações, gerenciamento de pagamento, emissão de nota fiscal, emissão relatórios contábeis e reservas pela Web.
Requisitos Interface• interface gráfica fácil de usar 'tipo Windows' para entrada de dados e operação. Utilização de
mouse para selecionar os itens tais como tela de menus e sub menus. • Deverá mostrar mensagem de erros em casos de inconsistência dos dados de entrada (tal
como digitar alfabetos no campo onde deveria ser número, por exemplo). • Interface com o sistema de tarifa do telefone. • Interface com o sistema de controle de restaurante. • Procedimento de backup do cadastro de clientes e ocupação e dados correntes. • Senha de acesso ao sistema. Deverão ter senhas diferentes para recepcionistas, camareiras,
gerentes e proprietário de modo que cada usuário tenha acesso restrito a certas informações. • Mais de um usuário pode estar operando vários terminais do sistema simultaneamente
espalhados pelo hotel (recepção, sala de controle, restaurante, bar). • Controlar também a reserva de salas e auditório para congressos e reunião de empresários. • Sistema 'no-break' em caso de queda de energia.
Funcionais• Interface gráfica para entrada de dados. • Entrada para cadastro de cliente (nome, endereço, e-mail,
data de chegada, data de saída, classificação do cliente, documento).
• Consultas, reservas e cancelamento de reserva através da Web.
• Cadastro de apartamento: tipo de quarto (suíte, standard, duplo, ar-condicionado), cidade ou local.
• Cadastro de salas e auditório. • Cadastro de despesas.
Funcionais• Serviços adicionais são também incluídos no sistema:
telefone, TV paga, acesso à internet, 'frigobar', lavanderia, serviço de lanche e café da manhã.
• Conexão para consultas e reservas de vagas em outros hotéis do grupo.
• Controle de ocupação de apartamento (reservado ou entrada do hóspede).
• Controle de ocupação de salas e auditório. • Controle de limpeza dos apartamentos.
Funcionais• Preços diferenciados para alta temporada e baixa temporada. • Descontos para clientes VIP e grupos. • Recebimento de pagamento (tipo de pagamento cheque, dinheiro, cartão,
parcelado, moeda estrangeira). • Registrar situações de pagamento (cheque compensado, transferência
realizada, parcelado, em dinheiro, ou moeda estrangeira). • Emissão de nota fiscal (podendo ser separado por itens: hospedagem,
restaurante, lavanderia, etc). • Emissão da fatura parcial (somente para consulta). • Emissão de relatórios contábeis.
Funcionais• Relatórios de ocupação. • Relatórios parciais de consulta. • Os relatórios e consultas deverão também ser visualizados pelo terminal. • Consulta o nome do cliente (se já existente). • Pesquisa dos clientes no banco de dados segundo alguns tipos de critérios
(frequência que o cliente se hospeda, preferência de apartamentos, preferência de local, tipo de serviços utilizados, estadia de negócios ou turismo, faixa etária, procedência).
• Gerar relatórios estatísticos (média de dias que o cliente hospeda, gastos médios, itens mais consumidos nos restaurantes).
• Serviços de mala direta (podendo selecionar os clientes e enviar mensagens via e-mail ou imprimir cartas para serem enviados posteriormente via correio.
Não-Funcionais
• Tempo de resposta desejável menor que 10 segundos para consultas de vagas em outros hotéis da rede.
• Utilização de computadores PC de mercado. • Sistema operacional Windows XP ou mais recente. • Utilização da linguagem JAVA. • Portabilidade para novos hardwares e sistemas operacionais
(quando forem lançadas novas versões de sistema operacional).
Requisitos de Desenvolvimento e Manutenção
• O produto pode ser desenvolvido em etapas, mas deverá ter as funcionalidades básicas na primeira versão (gerenciar reservas e ocupação de apartamentos, cadastro de clientes, controle de pagamento, emissão de relatórios, e reservas pela Web).
• O prazo de desenvolvimento para as funcionalidades básicas é de 6 meses. • Após o desenvolvimento das funcionalidades básicas, o sistema deverá ser
colocado em operação por 3 meses antes de se iniciar o desenvolvimento de outras funcionalidades.
• Após os 3 meses de funcionamento, o produto deverá ser reavaliado para inserir melhorias, corrigir falhas do sistema e implementar as novas funcionalidades.
Requisitos de Desenvolvimento e Manutenção
• O prazo estimado para implementação desta segunda fase é de 6 meses. • Após o desenvolvimento da segunda fase, o sistema deverá ser colocado
em operação e terá 3 meses para corrigir eventuais falhas. • Garantia: o desenvolvedor do produto deverá dar suporte gratuito
durante um ano após a entrega do produto para casos de mau funcionamento do sistema.
• Deverá fornecer treinamento aos usuários. • Deverá fornecer o manual de usuário, do produto e de manutenção.