Fundamentos de Engenharia de Software
Requisitos de Software
Fases do Desenvolvimento de SW
Viabilidade
Requisitos
Projeto
Cod. Módulos
Integração
Entrega
Manutenção
Requisitos de Software

A Software Requirements Specification (SRS) is a
complete description of the behavior of the system to be
developed. It includes a set of use cases that describe all of
the interactions that the users will have with the software.
Use cases are also known as functional requirements. In
addition to use cases, the SRS also contains nonfunctional
(or supplementary) requirements. Non-functional
requirements are requirements which impose constraints
on the design or implementation (such as performance
engineering requirements, quality standards, or design
constraints). (Wikipedia)
Tipos de requisitos

Funcionais


tratamento da informação
Não funcionais

outras características
Exemplos de categorias de requisitos
(IEEE-830)
Requisitos funcionais
Tecnologia utilizada
Processo de desenvolvimento
Desempenho
Operação
Manutenção e portabilidade
Backup e Recuperação
Legais
Treinamento
Qualidades de um bom MR

escalável


legível


funciona para modelos grandes
linguagem do usuário
robusto

fácil de ser mantido
Componentes do MR

Modelo de Casos de Uso

Maquete

Modelo de Classes do Domínio
Maquete
Modelo de Classes de Domínio
I- Requisitos de SW
Característica do SW que:

o usuário necessita para resolver um
problema ou alcançar um objetivo

satisfaz contrato, padrão, especificação
ou outra formalidade
Níveis de Requisitos

Negócio:


Mais abstratos, atendem aos interesses das partes
interessadas no negócio
Produto:

Mais detalhados, atendem aos interesses dos
desenvolvedores do SI
Requisitos do Negócio

Definem:



escopo e os objetivos do projeto
sua viabilidade financeira
estimativa de seus benefícios

Objetivo: ajudar o processo decisório

Formato: Business Case (BC)
Conteúdo de um BC
1.
2.
3.
4.
5.
6.
7.
Nome da intervenção
Descrever o problema ou oportunidade
Porque é um problema ou oportunidade
Qual a natureza da intervenção
Qual o resultado da intervenção
Quem serão os gestores/usuários
Estimativa do prazo
( 1 página)
Requisitos do Produto


Definidos nos estágios iniciais do
desenvolvimento de um Sistema de
Informação
Descrevem:


Comportamentos do sistema
Atributos
Exemplos




R1-O SI deve possuir comandos de correção de
ortografia
R2-O SI deve garantir o sigilo de todas informações
pessoais
R3-O Sensor de porta deve ser amostrado 10 vezes
por segundo
R4-O SI deve ser desenvolvido em .Net
II – Requisitos e CMMI





Capability Maturity Model Integration (CMMI)
Recomendações de práticas específicas e
genéricas
Organizadas por Área de Processo (AP)
Inclui práticas de planejamento, engenharia e
gerência
Organizado em níveis
Objetivos e práticas

Objetivos



Genérico: características que devem estar presentes para
satisfazer a institucionalização dos processo
Específicos: características que devem estar presentes para
satisfazer uma AP
Práticas


Genéricas:práticas que contribuem para a institucionalização
dos processos
Específicas: atividades que visam atingir um objetivo
específico
Requirements Management
RM- Requirements Management

Objetivos:


gerenciar todos os requisitos recebidos ou gerados
pelo projeto
Identificar inconsistências entre os requisitos e os
planos e produtos do projeto
Requirements Development
RD – Requirements Development

Objetivo: produzir e verificar os requisitos de:



clientes (SG-1)
produtos e componentes (SG-2)
analisar e validar requisitos (SG-3)
RD - SG 1: Desenvolver Requisitos do
Negócio

1.1-Elicitar necessidades das partes
interessadas


(identificar de forma pró-ativa requisitos necessidades, restrições e
interfaces para todas fases do ciclo de vida)
1.2-Desenvolver os requisitos dos clientes

(consolidar e resolver conflitos entre os desejos, expectativas das partes
interessadas; colocar num documento único com os requisitos dos clientes)
RD – SG 2: Desenvolver Requisitos do
Produto



2.1-Estabelecer requisitos de produtos e
componente
2.2-Alocar os requisitos ao produto
2.3-Identificar requisitos de interface do
produto com sistemas externos
III - Padrão IEEE-830


Documento com diretrizes para especificação
de requisitos de software
Composto de 3 partes



Introdução
Descrição geral
Requisitos específicos
Padrão IEEE-830 (2)

Introdução





Propósito
Escopo
Definições
Referências
Visão Geral
Padrão IEEE-830 (3)

Descrição geral





Perspectiva do produto
Funções do produto
Característica do usuário
Restrições
Condições e dependências
Padrão IEEE-830 (4)

Requisitos específicos




Interface externa
Funções
Desempenho
Projeto
IV - Qualidades dos requisitos








Correto
Sem ambigüidade
Completo
Consistente
Priorizado
Verificável
Modificável
Rastreável
Correto

Qualquer um dos requisitos representa algo
que deve estar presente no sistema

Os requisitos reais devem coincidir com os
requisitos identificados para o sistema.
Sem ambigüidade

Tem uma única interpretação por todos
os interessados

Interessados devem incluir tanto responsáveis
pelo negócio como os desenvolvedores
Completo

Reflete todas as necessidades de todas
as partes interessadas.

Necessidades incluem requisitos funcionais e nãofuncionais.
Consistente

Livre de assertivas contraditórias.

Sentenças contraditórias:


A deve ser verdadeira.
A deve ser falsa.
Priorizado

Contém uma relação de ordem de
importância entre os requisitos.

Ordem de importância dos requisitos auxilia na
definição da ordem de implementação.
Verificável

Existe uma forma efetiva de saber se a
implementação cumpre o requisito.

O requisito deve fornecer métricas e critérios que
auxiliem a avaliação do requisito.
Modificável


Alterações podem ser feitas de maneira
simples
Também chamado de robustez do modelo
Rastreável

Requisitos podem ser associados aos
artefatos produzidos pelo processo de
desenvolvimento de software
Processo de Requisitos

Elicitar

Modelar

Verificar e validar
V-Elicitação de requisitos


Elicitar requisitos: “extrair” os requisitos das
partes interessadas
É um processo construtivo: os requisitos não
“existem” antes da atividade
Elicitar requisitos



Elicitar requisitos é um problema inerentemente
complexo devido a psicologia de expressar desejos
incertos numa linguagem ambígua.
Computerworld relata que 95% de todos os
projetos de software não cumprem prazo e custo;
93% dos problemas advém de falhas de
comunicação.
Standish Group International relata que a falta de
envolvimento das partes interessadas é o principal
fator da falha dos projetos de SI.
Formas de elicitação





Entrevistas
Questionários
Prototipação
Estudo de documentos
JAD
Exemplos de Sessão de Requisitos
1.
2.
3.
4.
5.
Definir as maneira com que os usuários irão interagir com o novo
sistema (Casos de Uso). Coletar amostras das entradas e saídas
desejadas pelos usuários. Primeiramente mantenha-se nos
processos de negócio para depois detalhar os dados necessários.
Priorizar os Casos de Uso. Por exemplo, utilizando a técnica
Delphi.
Validar e rever os cenários dos Casos de Uso.
Especificar, usando técnicas de prototipagem, as interfaces (telas
e relatórios) do sistema.
Organizar os Casos de Uso, restrições, premissas e outros
requisitos num Documento de Especificação de Requisitos de
Software (DERS).
Processo de Requisitos

Elicitar

Modelar

Verificar e validar
V-Requisitos do Sistema

Funcionais

Comportamento do Sistema



Como o sistema age e reage, ou seja, a sua atividade
externamente observável e que pode ser validada.
Descrito na forma de Casos de Uso de Sistema (“system
use cases”).
Não-Funcionais



Segurança
Desempenho
Tecnologia
Caso de uso

Uma seqüência de passos



Executado por um (ou mais) ator(es)
Durante a interação com o sistema
Atende um objetivo (goal)
Conteúdo padrão de um Caso de Uso






Nome do caso
Atores
Pré e pós condições
Fluxo normal
Fluxos alternativos
Fluxos de Exceção
Nome do caso


Escolher nomes que expressem o processo
Nomes no infinitivo



emprestar
devolver
manter
Atores

Ator



Atores primários


quem interage com o sistema
humano ou máquina
para quem o sistema foi desenvolvido
Atores secundários

suportam a operação
Exemplo de atores
Exemplo de Diagrama de Caso de Uso
Pré-condição



Aquilo que deve ser verdadeiro antes do
caso ser iniciado
Exemplos:

Ao alugar um carro


existirem veículos na filial
Ao inscrever em disciplina

ser aluno matriculado
Pós-condição

Aquilo que se espera que seja o estado do mundo
ao fim do caso

Ao descontar cheque


saldo da conta corrente atualizada
Ao inscrever em disciplina

aluno esteja na lista da turma
Fluxos de casos de uso

descrevem caminhos que podem ser seguidos
durante o uso do do sistema.
A) Venda normal
B) Produto não está disponível
C) Cancelamento de Item
D) Cancelamento da Venda
Fluxo normal
Fluxo



Fluxo: seqüência de passos
Cada passo tem um número
Cada passo descreve:




envio de informação do ator para o sistema
resultado de um processamento pelo sistema
atualização realizada na memória interna
informação enviada pelo sistema ao ator
Elementos de um fluxo






Como e quando o caso de uso é iniciado

O caso de uso se inicia quando …… acontece.
A sequência de interações entre ator e sistema (Ação do ator x Resposta interna ou
externa)
Informações/eventos que são trocados entre um ator e o sistema

Cliente informa o número da agência e da conta corrente. (Ação do ator)

Sistema apresenta o saldo atual da conta. (Resposta externa)
Armazenamento/Atualização de informações no sistema

Sistema cria um novo pedido contendo o nome do criador, data de criação e
coloca o pedido na situação ‘Pendente’. (Resposta interna)
Indicação de validações realizadas pelo sistema

O Sistema verifica se o sócio pode fazer empréstimos
Como e quando o caso de uso termina

Quando ….. acontece, o caso de uso é encerrado
Exemplo de Fluxo Normal










1. Cliente informa período de locação;
2. Executar Caso de Uso "Verificar Disponibilidade";
3. Cliente seleciona o modelo desejado;
4. Executar Caso de Uso "Identificar Cliente";
5. Cliente seleciona forma de pagamento;
6. Executa Caso de Uso "Verificar Crédito";
7. Cliente informa dados do Motorista;
8. Sistema produz contrato;
9. Cliente assina contrato;
10. Cliente recebe chave do carro.
Dicas de escrita (1)







Voz ativa e com o tempo presente.
 Cliente informa produto desejado e quantidade
 Sistema inclui item no carrinho de compras do cliente.
Indicar quem realiza a ação.
 Cliente informa produto desejado e quantidade
Uso consistente de termos (Rapdis).
Evitar adjetivos e advérbios.
Cuidado com pronomes (seu, sua, dele, ...)
Estilo consistente e padronizado de descrição.
Independente de tecnologia
Dicas de escrita (2)

Explicitar informações enviadas, recebidas e
armazenadas:


Evite “sistema apresenta dados do produto”.
Evitar o detalhamento de dados e regras de negócio
nos fluxos.

Use documentos anexos devidamente referenciados.
Fluxos Alternativos (1)

Conjunto de caminhos que podem ser seguidos
durante o uso do sistema.
A) Venda normal
B) Cancelamento da venda
C) Cancelamento do item
Curso normal
Fluxos Alternativos (2)

Cada fluxo alternativo é descrito na seção fluxos
alternativos do caso de uso.




Defina o título do fluxo alternativo com uma frase que
denote o sub-objetivo que o usuário deseja com esse
fluxo.
Defina onde esse fluxo pode acontecer (em relação ao
fluxo normal).
Detalhe as interações entre o ator e o sistema, seguindo as
mesmas diretrizes do detalhamento do fluxo normal.
Defina o que ocorre ao final da execução do fluxo
alternativo.
Fluxos Alternativos (3)

Remover cópia do aluguel
Durante a Identificação das Cópias:



Atendente seleciona uma ou mais cópias, e solicita a retirada das cópias
selecionadas do aluguel.
Sistema remove as cópias selecionadas do aluguel, atualizando o valor total
do aluguel. Caso de uso volta ao fluxo normal com o atendente podendo
informar novas cópias.
Cancelar o aluguel:
Enquanto o Pagamento não foi realizado


Atendente solicita o cancelamento do aluguel
Sistema cancela o aluguel, e o caso de uso se encerra.
Fluxos de Exceção (1)




Cada passo de um caso de uso tem um objetivo
Quando o objetivo não pode ser alcançado diz-se
que o caso falha
Toda falha deve ser recuperada
A recuperação envolve ações alternativas
Fluxos de Exceção (2)
Falhas são anotadas fora do roteiro
Notação:
<passo><letra> : <evento> <ação>
<passo> passo do caso
<letra> seqüencial para as exceções
<evento> causa da exceção
<ação> atividade de recuperação
Regras de Negócio (RN)

Regras





Foco do detalhamento dos casos de uso está nas
interações.
Existem regras que regem estas interações.
As regras são descritas em uma seção à parte.
As regras são capturadas na modelagem de negócio
ou no levantamento de requisitos do sistema.
Ex:

R2: Cálculo do Preço de Aluguel de uma Cópia:
lançamento (…), normal (…), promoção (…)
Definições de RN







Sentença que define ou restringe algum aspecto do negócio. Sua
intenção é afirmar a estrutura do negócio ou controlar ou influenciar o
comportamento do negócio. (BRG, 1995)
Diretiva que tenciona influenciar ou conduzir o comportamento do
negócio. Tais diretivas existem em suporte a política do negócio, a qual
é formulada em resposta aos riscos, ameaças ou oportunidades (BRG,
1998)
Sentença explícita de uma restrição que existe na ontologia do negócio
(Appleton D., 1984)
Condições que governam os eventos do negócio de tal forma que eles
ocorram numa forma aceitável para o negócio (von Halle, 2002)
Políticas recomendadas e obrigatórias que governam a interação entre
empregados, clientes, fornecedores e sistemas automatizados (von
Halle, 2002)
As regras são as decisões ... (von Halle)
...é uma sentença compacta a respeito de um aspecto do negócio. É
uma restrição, no sentido de que ela estabelece o que tem de ser o
caso ou o que tem de não ser o caso (Morgan, 2002)
Processo de Requisitos

Elicitar

Modelar

Verificar e validar
VI-Verificação / Validação
Verificação / Validação

Validação:


Estamos construindo o produto correto?
Verificação:

Estamos construindo o produto de forma correta?
Técnicas de validação

Storyboard:




Passivo: esboços de telas, relatórios (em papel ou
eletrônico), onde o usuário narra o cenário.
Ativo: animação (apresentação com slides ou outro
software), onde o software narra o cenário.
Interativo: permite a simulação da forma mais realista
possível, onde o usuário participa da execução do cenário.
Protótipo:



Mostra as informações essenciais e a navegação
Descartável
Sem preocupação com implementação
Check List














Todas as necessidades estão sendo cobertas pelos macro-requisitos?
Todo macro-requisito atende pelo menos uma necessidade?
Todos os atores foram identificados e corretamente definidos na
perspectiva do sistema?
Todo ator está associado a pelo menos um caso de uso?
Todos os casos de uso foram capturados?
Existe uma definição sucinta para cada caso de uso?
Todo caso de uso está associado a pelo menos um macro-requisito?
Todo macro-requisito está associado a pelo menos um caso de uso?
Todas as entradas e saídas estão especificadas?
O comportamento do sistema em todas as situações eventuais ou de
exceção está especificado?
Todas as regras envolvidas estão especificadas?
Todas as transformações de dados estão especificadas?
Todos os dados e suas regras de validação estão especificados?
Os critérios de especificação de casos de uso estão sendo corretamente
seguidos?