Requisitos de Software

1. Requisitos de Software

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

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

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

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

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

13. Tipos de Requisitos • Funcionais • Não-funcionais • De Domínio

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

15. Requisitos Funcionais • Descrevem a função de sistema detalhadamente, suas entradas, saídas, exceções, etc.

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

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

19. Métricas para especificar requisitos não-funcionais

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

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

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

23. 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ó.

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

25. Exemplo 1 – Requisito Não-Funcional • RNF01 – Portabilidade com os sistemas operacionais Windows e Linux, através de browsers.

26. 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).

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

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

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

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

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

32. Exemplo • EscopoEste 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.

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

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

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

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

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

38. 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).

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

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