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.

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.

Atividades desenvolvidas ELICITAR ANALISAR MODELAR UdeI Documento de Requisitos do Software Decisões da Análise Métodos, Técnicas e Ferramentas Modelo de Análise do Sistema Ambiente do negócio

Elicitação Faz Coleta de Fatos 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

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

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

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.

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.

Métricas para especificar requisitos não-funcionais

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

Documento de requisitos 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.

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 contexto 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.

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.