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.