Transcript Aula6 – Requisitos de Software

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.
3
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
UdeI
Ambiente do
negócio
ELICITAR
UdeI
Documento de Requisitos
do Software
ANALISAR
Decisões da
Análise
MODELAR
Métodos,
Técnicas e
Ferramentas
Modelo de
Análise do
Sistema
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
6
Identificação das fontes de informação
•
UdeI  Contém toda informação necessária
–
•
Outras fontes de Informação:
–
–
–
–
–
–
•
Agentes (Atores, Usuários)
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
7
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
8
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
9
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.
Req u i rem en ts d efi n iti on
1 . Th e s oft w are m u st pro v id e a m eans o f repr e sen ti ng an d
1 . access in g ex ternal fi les creat ed by other t oo ls .
Req u i rem en ts s p ecifi cati on
1 .1
1 .2
1 .2
1 .2
1 .3
1 .2
1 .4
1 .2
1 .5
1 .2
1 .2
The us er sh ou ld b e pro v id ed w it h facili ti es to defi ne th e ty pe of
ex ternal fi les.
Each ex ternal fi le t yp e m ay hav e an ass oci at ed t oo l w h ich m ay be
ap pl ied to th e fi le.
Each ex ternal fi le t yp e m ay be represen ted as a s peci fic i con o n
t he u ser’s di sp lay.
Facil it ies s ho ul d b e p rov id ed fo r th e ico n repr esen ti ng an
ex ternal fi le t yp e t o b e d efin ed by th e us e r.
W h en a u ser sel ects an ico n repr esen ting an ex ternal fi le, th e
effect of th at s elect io n is to ap pl y t he to ol ass oci ated w it h t he ty pe o f
t he ex tern al fil e to t he fi le repres ent e d b y th e sel ected i con .
Us er req ui rem ent s
C l ient m an ag ers
S y st em end -us ers
C l ient en gi ne ers
C o nt racto r m an ag ers
S y st em archi tect s
S y st em requ irem ent s
S y st em end -us ers
C l ient en gi ne ers
S y st em archi tect s
S o ftware d ev elo pers
S o ftware d esi gn
s pecifi cat io n
C l ient en gi ne ers (perh ap s)
S y st em archi tect s
S o ftware d ev elo pers
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.
No n-fu nct io nal
requ ir em ent s
P ro du ct
requ ir em ent s
Ef fici ency
requ ir em ent s
R eli ab il it y
requ ir em ent s
Us ab il it y
requ irem ent s
P erfo rm ance
requ irem ent s
Or g an izat io nal
requ ir em ent s
Po rt abil it y
requ irement s
Del ivery
requ irem ent s
S p ace
requ ir em ent s
Ex tern al
requ irem ent s
Int ero perab il it y
requ irem ent s
Im pl em ent at io n
requ ir em ent s
Et hi cal
requ irem ent s
S t and ard s
requ irem ent s
Leg is lat ive
requ irem ent s
P riv acy
requ irem ent s
S afety
requ irem ent s
Métricas para especificar requisitos nãofuncionais
Property
Speed
Size
Ease of use
Reliability
Robustness
Portability
Measure
Processed transactions/second
User/Event response time
Screen refresh time
K Bytes
Number of RAM chips
Training time
Number of help frames
Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Percentage of target dependent statements
Number 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
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 email 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.