OS REQUISITOS DO
S I S T E M A
Prof. Sabalo Luanda, Eng.º
OBJECTIVOS
• Entender o conceito de requisitos de um sistema.
• Conhecer técnicas de elicitação de requisitos.
• Usar o Diagrama de Caso de Uso para
especificação das principais funções do sistema.
Prof. Sabalo Luanda, Eng.º
FASES DE CONCEPÇÃO
• O início da construção de um sistema acontece na sua
fase de concepção.
• Fase de concepção é a etapa do projecto de um
software em que um sistema é concebido. Nessa fase,
após as necessidades dos utilizadores já terem sido
levantadas, projecta-se o produto (software) com um
escopo definido e se estuda um plano de negócio para
seu desenvolvimento e implantação.
Prof. Sabalo Luanda, Eng.º
• Algumas etapas da fase de concepção são:
• a) definir uma visão para o producto, ou seja, os objectivos actuais
e futuros que os utilizadores pretendem alcançar com a sua
utilização;
• b) produzir um plano de negócio para o desenvolvimento,
produção, implantação e teste do software;
• c) definir do escopo do projecto; ou seja, seus limites de interface
com os demais sistemas existentes na empresa;
• d) estimar o custo total aproximado do projecto para que os
utilizadores se capitalizem e se planejem para o projecto.
Prof. Sabalo Luanda, Eng.º
• O tamanho dessa fase depende do tipo de projecto. Por exemplo: um
projecto de comércio eletrónico (E-commerce) que pretende atingir o
mercado rapidamente e as actividades desenvolvidas durante a
concepção podem se reduzir a uma definição da visão geral, criando
um plano de negócio para obter financiamento. Quando se trata de um
projecto de defesa antiaérea, certamente a fase vai requer muito mais
trabalho, ou seja, uma análise de requisitos mais elaborada, definições
de projecto, estudos preliminares, etc.
• ATENÇÃO: É importante na fase de concepção termos certeza se o
projecto é viável, do ponto de vista financeiro e computacional, e se ele
trará algum benefício para a empresa. Caso não consigamos estar certos
dessas questões, é aconselhável que o projecto seja repensado. Prof. Sabalo Luanda, Eng.º
REQUISITOS DO SISTEMA
• Requisitos são as capacidades e condições a que o sistema deve atender.
• Para desenvolver um sistema, precisamos descobrir o que o nosso cliente deseja.
• Nosso objectivo é escrever o documento de requisitos de sistemas, que deve conter
de forma precisa e realista tudo o que deve ser feito, de modo a atender a uma ou
mais necessidades do nosso cliente.
• Esse documento também deve ser validado pelo cliente, isto é, o cliente deve ler o
documento e verificar se todas as suas necessidades estão atendidas.
• Para encontrar os requisitos do sistema, precisaremos conversar com nosso cliente.
Esse cliente não é necessariamente uma única pessoa e pode representar uma
empresa com milhares de funcionários!
Prof. Sabalo Luanda, Eng.º
• Assim, é muito útil a criação de um grupo de modelagem, que deve ser composto
de:
• a) investidor: (em inglês: Stakeholder): cliente/financiador do sistema;
• b) utilizadores: aqueles que irão utilizar directamente o sistema ou qualquer
pessoa que vá ser afectada pelo sistema;
• c) analistas ou desenvolvedores: equipa de técnicos e/ou engenheiros!
• d) facilitadores: pessoas que conhecem bem a empresa e possuem habilidade para
fazer reuniões; entendem o processo de modelagem dos requisitos e podem fazer
perguntas válidas e inteligentes;
• e) escribas: pessoas que devem escutar bem, possuir habilidade na comunicação
oral e escrever bem. São eles que irão anotar os requisitos durante as reuniões e
ajudar na escrita do documento de requisitos.
Prof. Sabalo Luanda, Eng.º
Técnicas de identificação de requisitos
• Para obtermos os requisitos de um sistema, utilizam-se duas técnicas
muito conhecidas:
• a) entrevistas;
• b) brainstorming (em português: “tempestade cerebral”): técnica em que
um grupo de pessoas discute um assunto e diz qualquer coisa relativa ao
assunto que lhe venha à mente sem a preocupação da relevância do que
foi dito para o assunto em questão.
• Quanto mais estudamos essas técnicas, mais requisitos conseguimos
levantar sobre o sistema a ser desenvolvido.
Prof. Sabalo Luanda, Eng.º
• Algumas recomendações são importantes para o sucesso dessas
técnicas:
• •Para realizar entrevistas:
• a) forneça uma agenda;
• b) esclareça aos participantes quais os motivos do projecto;
• c) faça as perguntas críticas em primeiro lugar;
• d) não assuma que você tem conhecimento do assunto;
• e) identifique o que é “necessário” e o que é “desejável”;
• f) termine a entrevista com um sumário dos pontos abordados.
Prof. Sabalo Luanda, Eng.º
• •Para realizar brainstorms:
• a) todas as ideias são boas: as ideias não são julgadas pelo grupo;
• b) todas as ideias são do grupo, ninguém é “dono” de uma ideia;
• c) todas as ideias são públicas, qualquer pessoa pode expandir ou
modificar uma ideia;
• d) sempre que surgir uma ideia, ela deve ser imediatamente
registada;
• e) antes da sessão, forneça ao grupo uma cópia das regras de
brainstorming.
Prof. Sabalo Luanda, Eng.º
O documento de requisitos
• Este documento deve conter a especificação do sistema, ou seja, uma
descrição das necessidades ou dos requisitos do sistema a ser
desenvolvido.
• Nele deve-se descrever:
• a) uma visão geral do sistema;
• b) quem são os clientes do sistema;
• c) quais os objetivos;
• d) quais as funções principais do sistema;
• e) quais os atributos necessários do sistema. Prof. Sabalo Luanda, Eng.º
• a) Funções do sistema
• As funções do sistema são “o que” se supõe que o sistema faça e devem ser
identificadas, listadas e agrupadas logicamente.
• Uma boa regra para verificar se uma expressão X é, de facto, uma função do
sistema, colocamos X na sentença “O sistema deveria fazer X” e essa
sentença deve fazer sentido.
• Exemplo: Num sistema de registo de notas escolares, poderemos duvidar se
“elaborar prova” é uma função do sistema. Colocamos então as palavras
“elaborar prova” na frase grifada acima: “O sistema de registo de notas
escolares deveria fazer a elaboração das provas”. Por experiência, sabemos
que as provas de uma escola são elaboradas pelos professores e não por
sistemas computacionais. Logo, “elaborar prova” não é uma função desse
sistema. Prof. Sabalo Luanda, Eng.º
• b) Atributos do sistema
• Os atributos do sistema são qualidades não funcionais do sistema.
• Em alguns projectos é conveniente construir um documento exclusivo
para os atributos do sistema. Esse documento fica separado do
documento que contém as funcionalidades do sistema.
• Exemplos de atributos do sistema:
• a) facilidade de uso: que tipo de interface o sistema possui com o
utilizador?
• b) tolerância a falhas: qual a expectativa aceitável para falhas no sistema?
• c) tempo de resposta: qual o tempo aceitável para a resposta do sistema?
Prof. Sabalo Luanda, Eng.º
Tipos de requisitos
• Para melhor entendermos os requisitos, é comum separá-los em grupos ou tipos.
• Os tipos de requisitos são:
• a) funcionalidade: descreve características, capacidades, segurança, etc., do sistema;
• b) usabilidade: descreve características relativas a factores humanos, ajuda on-line, documentação;
• c) confiabilidade: descreve necessidades do sistema quanto à frequência de falhas, recuperabilidade, etc;
• d) performance: descreve necessidades relativas a tempos de respostas, precisão, disponibilidade, utilização de
recursos, etc;
• e) suportabilidade: descreve necessidades relativas à adaptabilidade, manutenibilidade, internacionalização,
configurabilidade, etc;
• f) implementação: descreve limitações de recursos, linguagens e ferramentas, hardware, etc.;
• g) interface: descreve as restrições impostas pelo interfaceamento com sistemas externos;
• h) operação: descreve as necessidades relativas à administração do sistema em sua configuração operacional;
• i) aspectos legais: descrevem licenciamento, etc. Prof. Sabalo Luanda, Eng.º
CASOS DE USO
• Um instrumento muito útil no desenvolvimento de sistemas é
o caso de uso.
• Caso de uso é uma descrição detalhada de um conjunto de
interacções entre um utilizador e o sistema.
• Os casos de uso são escritos em um documento que serve para
orientar a construção dos demais elementos do projecto.
• Vamos conhecer os elementos e conceitos ligados aos casos de
uso.
Prof. Sabalo Luanda, Eng.º
Actores
• Na definição de casos de uso encontramos o termo “utilizador”. Nos
casos de uso o “utilizador” é chamado de actor.
• Temos dois tipos de actores:
• a) actor iniciador: é ele que inicia o caso de uso, geralmente, sendo
o seu actor principal. Por exemplo, se estamos fazendo um sistema
bancário, o caso de uso “retirar dinheiro” terá como actor iniciador o
actor cliente;
• b) actor participante: é aquele que de alguma forma participa do
caso de uso. Por exemplo, no caso de uso “comprar itens”, existe um
actor atendente que “atende” o actor cliente. Prof. Sabalo Luanda, Eng.º
• Um actor não precisa, necessariamente, ser uma pessoa. Um
actor pode representar:
• a) um grupo de pessoas. Por exemplo, clientes, estudantes, etc.;
• b) uma função de uma pessoa. Por exemplo, estudante
representante da turma;
• c) outro sistema externo;
• d) um conceito abstracto como hora, data, etc. Por exemplo,
o actor data pode iniciar um caso de uso chamado “cancelar
pedidos” para pedidos feitos há mais de seis meses.
Prof. Sabalo Luanda, Eng.º
• Um actor geralmente participa de mais de um caso
de uso e representa papéis.
• ATENÇÃO: Dê um nome ao actor de forma que
fique claro seu papel no sistema. Os nomes devem
ser condizentes com aqueles já usados na empresa.
Dessa forma, os clientes compreenderão com
maior facilidade o significado desse elemento do
caso de uso.
Prof. Sabalo Luanda, Eng.º
• Vamos precisar encontrar todos os actores envolvidos no sistema?
• A resposta a essa pergunta é SIM. E, se quiser, utilize as perguntas a seguir para auxiliá-lo nessa tarefa:
• a) Qual é o principal utilizador do sistema?
• b) Quem fornece as informações para o sistema?
• c) Quem obtém as informações do sistema?
• d) Quem instala o sistema?
• e) Quem opera o sistema?
• f) Quem desativa o sistema?
• g) Que outros sistemas interagem com o sistema?
• h) Algum processo acontece automaticamente em horas predeterminadas?
• i) Quem fornecerá, utilizará ou removerá informações do sistema?
• j) De onde o sistema obtém informações?
Prof. Sabalo Luanda, Eng.º
Tipos de casos de uso e sua descrição
• Já sabemos que um caso de uso é um documento narrativo
que descreve uma sequência de eventos de um actor (um
agente externo) que usa um sistema para completar um
processo.
• Com relação ao nível de detalhes dessa descrição, podemos
dividir os casos de uso em dois grupos:
• a) caso de uso de alto nível: descreve um processo de forma
muito breve, usualmente, em duas ou três sentenças. Contém
os dados: nome do caso de uso, actores, tipo, descrição.
Prof. Sabalo Luanda, Eng.º
• Exemplo de caso de uso de alto nível:
• Caso de uso: Comprar itens.
• Actores: Cliente, caixa.
• Tipo: Primário.
• Descrição: Um cliente chega a um ponto de pagamento,
com vários itens que deseja comprar. O caixa regista os
itens de compra e recebe o pagamento. Ao término, o
cliente deixa a loja com os itens.
Prof. Sabalo Luanda, Eng.º
• b) caso de uso expandido: descreve um processo com
mais detalhes que um caso de uso de alto nível. Contém
uma secção chamada sequência típica de eventos, que
descreve os eventos passo a passo. Os casos de uso no
formato expandido são muito úteis para uma melhor
compreensão dos processos e requisitos, já que eles
descrevem com detalhes todos os passos de uma operação
do sistema.
• Observe que a descrição da operação é bem simples e
directa. Prof. Sabalo Luanda, Eng.º
• Um caso de uso expandido contém os seguintes dados:
• 1. nome: Identificador do caso de uso: deve ser escrito em formato de verbo + substantivo e ser suficiente para se perceber a que
se refere o caso de uso;
• 2. descrição geral: curto resumo do caso de uso (um ou dois parágrafos, no máximo);
• 3. precondições: listagem das condições que se devem verificar quando se inicia o caso de uso. Não incluem triggers;
• 4. triggers (em português: “gatilhos”): eventos que ocorrem dando início ao caso de uso;
• 5. cenário de sucesso principal (linha de eventos): descreve o curso por uma sequência de eventos numerados;
• 6. percursos alternativos (extensões): descrição de percursos alternativos à linha de eventos principal;
• 7. pós-condições: descrição do estado do sistema após a execução do caso de uso;
• 8. regras de negócio: reservadas para informação adicional relativa à política da empresa ou restrições impostas pelo tipo de
negócio;
• 9. listas de variações tecnológicas: especificações dos métodos de entrada e saída de dados e quais formatos podem ser
utilizados no caso de uso;
• 10. frequência de ocorrência: frequência de ocorrência do caso de uso por dia, mês, hora, etc. (Influencia no projecto,
desenvolvimento ou implantação do sistema?);
• 11. notas: informações adicionais relativamente ao caso de uso, não cobertas pelos dados anteriores;
• 12. autor e data: listagem dos autores e datas das várias versões revistas. Prof. Sabalo Luanda, Eng.º
• a) Identificação dos casos de uso
• Os casos de uso são encontrados e descritos por meio de entrevistas. O
roteiro mais indicado para a aplicação dessas técnicas é:
• 1. identificação de todos os actores;
• 2. identificação de todos os casos de uso;
• 3. descrição simples de cada caso de uso;
• 4. desenho de um diagrama de casos de uso.
• ATENÇÃO: Não espere encontrar todos os casos de uso e actores na
primeira sessão. É natural aparecerem casos de uso e actores nas fases
seguintes do desenvolvimento, isto é, durante o processo de construção do
software. Prof. Sabalo Luanda, Eng.º
• Para ajudar na identificação dos casos de uso, as seguintes perguntas podem ser úteis:
• a) Quais as principais tarefas desse papel (ou actor)?
• b) O que os utilizadores nesse papel precisam ser capazes de realizar?
• c) Por que os utilizadores nesse papel precisam realizar essa tarefa?
• d) Quais informações os utilizadores nesse papel necessitam examinar, criar ou
alterar?
• e) Quais informações os utilizadores nesse papel necessitam saber pelo sistema?
• f) Quais informações os utilizadores nesse papel precisam informar ao sistema?
• ATENÇÃO: Um erro comum na identificação de caso de uso é representar como
casos de uso passos individuais, operações, ou transações. Um caso de uso é uma
descrição completa de um processo relativamente grande, que inclui, tipicamente,
muitos passos ou transações. Prof. Sabalo Luanda, Eng.º
• Exemplo de levantamento
• Supõe que estivesse levantando as informações sobre os casos de uso de um sistema
académico usado por funcionários da secretaria de uma escola. Para isso, você escolheu a
técnica de entrevista. Quais perguntas você colocaria no roteiro dessa entrevista?
Formulando apenas cinco perguntas, poderiam ser utilizadas as seguintes:
• 1. Quais informações sobre estudantes e professores vocês precisam guardar na secretaria
desta escola?
• 2. Quais as principais tarefas desempenhadas pelo funcionário responsável pela matrícula
de estudantes?
• 3. Quais as informações o director da escola precisa ter sobre professores e estudantes?
• 4. Por que a secretária escolar precisa cadastrar estudantes novatos apenas no início de
cada ano lectivo?
• 5. Quais as informações os professores precisam saber sobre suas turmas pelo sistema?
Prof. Sabalo Luanda, Eng.º
• b) Granularidade dos casos de uso
• Um aspecto que pode ser complicado para o iniciante é decidir a granularidade dos casos de
uso, ou seja, a qual nível de detalhamento devemos descer ao definirmos uma funcionalidade.
• Exemplo de levantamento:
• Em um sistema de Caixa Eletrónico, temos uma funcionalidade chamada “Retirar Dinheiro”.
Essa funcionalidade irá requerer as seguintes interacções:
• a) entrar cartão;
• b) entrar senha;
• c) seleccionar quantia desejada;
• d) confirmar quantia;
• e) remover cartão;
• f) retirar recibo.
Prof. Sabalo Luanda, Eng.º
• Cada uma dessas interacções deve ser um caso de uso?
• A resposta é NÃO. Esse é um erro clássico na construção de casos de uso. Os casos de
uso devem ser definidos para as funcionalidades do sistema e não para as interacções. Dessa
foram, mantemos a complexidade do caso de uso baixa.
• Uma boa regra é: um caso de uso deve satisfazer a um objectivo do utilizador.
• Aplicando essa regra simples ao exemplo acima, podemos fazer a seguinte pergunta:
Retirar Recibo (item 6) é um objectivo do utilizador? Ou seja, o objectivo do utilizador
desse sistema é apenas Retirar Recibo? A resposta é NÃO. Então, Retirar Recibo não
será um caso de uso.
• Aplicando essa regra aos outros itens da lista, vemos que a resposta é NÃO para todos
eles. O objectivo real do utilizador é retirar dinheiro, logo, Retirar Dinheiro deve ser o
caso de uso, isto é, o nome do caso de uso será Retirar Dinheiro.
Prof. Sabalo Luanda, Eng.º
• c) Relação entre casos de uso e funções do sistema
• As funções do sistema representam o que o sistema deve realizar. Assim, devemos ter
casos de uso que implementem essas funcionalidades.
• Algumas vezes uma função resultará em um único caso de uso; outras vezes, várias
funcionalidades resultarão em um único caso de uso.
• d) Ordem de implementação dos casos de uso
• Com o desenvolvimento iteractivo vamos implementar um caso de uso em cada ciclo
de desenvolvimento. Com casos de uso muito complexos, podemos implementar
versões simplificadas dele. Com casos de uso muito simples, podemos implementar
mais de um caso de uso em um único ciclo.
• Então surgem as perguntas: Que casos de uso devemos implementar primeiro? Qual
ordem de implementação dos casos de uso é melhor?
• Recomendamos que você implemente primeiro os casos de uso mais importantes.
Prof. Sabalo Luanda, Eng.º
• e) Diagrama de casos de uso
• Um diagrama de casos de uso é uma representação
gráfica dos casos de uso e dos actores envolvidos no
sistema em análise.
• Um diagrama de casos de uso mostra os actores e casos
de uso de forma gráfica. Seu objectivo é dar uma visão
geral dos casos de uso necessários ao sistema de forma a
facilitar a compreensão por todos os envolvidos na
equipe de desenvolvimento do novo software.
Prof. Sabalo Luanda, Eng.º
• Os símbolos utilizados são mostrados abaixo:
Prof. Sabalo Luanda, Eng.º
• Símbolo do diagrama de caso de uso:
Prof. Sabalo Luanda, Eng.º
• O diagrama de casos de uso é muito
interessante para dar uma visão geral do
sistema, com seus actores, casos de uso e a
relação entre eles.
• Com um diagrama, podemos ter uma ideia
do tamanho do sistema e da sua
complexidade de uma forma gráfica.
Prof. Sabalo Luanda, Eng.º
RESUMO
• Abordamos aqui os passos iniciais para desenvolver o projecto de um sistema. A
partir do levantamento dos requisitos, conseguimos identificar elementos
importantes, como casos de uso, actores e seus relacionamentos, de maneira que o
diagrama gerado por eles apresente uma visão geral do sistema e sua complexidade.
• Também vimos quais as técnicas mais comumente usadas para o levantamento dos
requisitos: entrevistas e brainstorming (tempestade cerebral). Pelo seu uso
conseguimos entender melhor quais as características de um sistema relatadas por
seus utilizadores.
• É importante não esquecermos que todo conhecimento gerado pelo levantamento
dos requisitos precisa ser documentado, e para isso produzimos o Documento de
requisitos e o Documento de casos de uso.
Prof. Sabalo Luanda, Eng.º
Actividades de aprendizagem
• 1. Em que situações devemos usar a descrição de caso de uso de
alto nível e expandido?
• 2. Cite um exemplo de responsabilidade do cliente/utilizador em
relação ao desenvolvimento de um sistema e explique sua
importância.
• 3. Desenhe três casos de uso de alto nível que mostrem funções de
um sistema de aluguel de fitas num vídeoclube (Por exemplo:
emprestar um vídeo, devolver um vídeo, pagar um aluguel, solicitar
reserva de vídeo, etc.). Descreva também os casos de uso
desenhados. Prof. Sabalo Luanda, Eng.º