Slide 2 - Introdução À Engenharia de Requisitos

Engenharia de
Requisitos de
Software
Jordana S. Salamon
[email protected]
[email protected]
DEPARTAMENTO DE INFORMÁTICA
CENTRO TECNOLÓGICO
UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO
Revisão
 Processo de Software
 Envolve atividades de Desenvolvimento, Gerência e

Garantia da Qualidade:
Revisão
 Atividades de Desenvolvimento
Revisão - Processo de Desenvolvimento
 O processo de desenvolvimento de software engloba as atividades que

contribuem diretamente para o desenvolvimento do produto de software a ser
entregue ao cliente, incluindo a sua documentação. De maneira geral, o
processo de desenvolvimento de software envolve as seguintes atividades:
Análise e Especificação de Requisitos, Projeto, Implementação, Testes, Entrega e
Implantação do Sistema.
 Mas o que é feito em cada etapa do processo?

 Análise e Especificação de Requisitos
 Na Análise e Especificação de Requisitos, o foco está no levantamento,

compreensão e especificação dos requisitos que o produto de software deve ser
capaz de satisfazer.
 Para entender a natureza do software a ser construído, o engenheiro de
software tem de compreender o domínio do problema, bem como a
funcionalidade e o comportamento esperados para o sistema.
 Uma vez capturados os requisitos do sistema, estes devem ser modelados,
avaliados e documentados. Uma parte vital desta fase é a construção de
modelos descrevendo o quê o software tem de fazer (e não como fazê-lo), ditos
modelos conceituais.
 Projeto
 A fase de Projeto é responsável por incorporar requisitos tecnológicos aos

requisitos essenciais do sistema e, portanto, requer que a plataforma de
implementação seja conhecida.
 Basicamente, envolve duas grandes etapas: projeto da arquitetura do sistema e
o projeto detalhado. O objetivo da primeira etapa é definir a arquitetura geral
do software, tendo por base o modelo construído na fase de análise de
requisitos. Essa arquitetura deve descrever a estrutura de nível mais alto da
aplicação e identificar seus principais componentes. O propósito do projeto
detalhado é detalhar o projeto do software para cada componente identificado
na etapa anterior. Os componentes de software devem ser sucessivamente
refinados em níveis maiores de detalhamento, até que possam ser codificados e
testados.
 Implementação
 O projeto deve ser traduzido para uma forma passível de execução pela
máquina. A fase de implementação realiza esta tarefa, isto é, cada unidade de
software do projeto detalhado é implementada.
 Testes
 A fase de Testes inclui diversos níveis de testes, a saber, teste de unidade, teste
de integração e teste de sistema. Inicialmente, cada unidade de software
implementada deve ser testada. A seguir, os diversos componentes devem ser
integrados sucessivamente até se obter o sistema. Finalmente, o sistema como
um todo deve ser testado.
 Entrega e Implantação
 Uma vez testado, o software deve ser colocado em produção. Para tal, contudo,
é necessário treinar os usuários, configurar o ambiente de produção e, muitas
vezes, converter bases de dados. O propósito da fase de Implantação e Entrega é
disponibilizar o software para o cliente, garantindo que o mesmo satisfaz os
requisitos estabelecidos. Isto requer a instalação do software e a condução de
testes de aceitação. Quando o software tiver demonstrado prover as
capacidades requeridas, ele pode ser aceito e a operação iniciada.
Especificação e Análise de Requisitos
Em um desenvolvimento de
software, a primeira coisa a
ser feita é capturar os
requisitos que o sistema a ser
desenvolvido tem de tratar.
• Um entendimento dos requisitos do software é essencial para o sucesso de

um projeto de desenvolvimento de software.
Engenharia de Requisitos de Software
 O processo de levantar, analisar, documentar, gerenciar e

controlar a qualidade dos requisitos é chamado de
Engenharia de Requisitos.
Especificação e
Análise dos
Requisitos
Que requisitos o Projeto
software deve atender? Implementação e

Teste de Unidade
Testes
Entrega e
Implantação
• Quem são os envolvidos?

• Quais são suas necessidades em relação ao
software?
Mas...
O que é um requisito?
Requisitos
Requisitos são descrições dos serviços que devem ser providos pelo
sistema e de suas restrições operacionais (SOMMERVILLE, 2007).
Um requisito é uma característica do sistema ou a descrição de algo

que o sistema é capaz de realizar para atingir seus objetivos
(PFLEEGER, 2004).
Um requisito é alguma coisa que o produto tem de fazer ou uma

qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON,
2006).
Requisitos
Os requisitos de um sistema definem o que o sistema deve fazer e

as circunstâncias sob as quais deve operar.
Ou, em outras palavras...
São as funções que um sistema deve incorporar e as restrições

que devem ser satisfeitas.
Requisitos
Uma das principais medidas do sucesso de um sistema de

software é o grau no qual ele atende aos requisitos para os
quais foi construído.
Tipos de Requisitos
Funcionais: são declarações de serviços que o sistema deve prover,

descrevendo o que o sistema deve fazer (SOMMERVILLE, 2007). Um
requisito funcional descreve uma interação entre o sistema e o seu
ambiente (PFLEEGER, 2004), podendo descrever, ainda, como o sistema
deve reagir a entradas específicas, como o sistema deve se comportar em
situações específicas e o que o sistema não deve fazer (SOMMERVILLE,
2007).
Ex.: O sistema deve registrar locações, indicando o cliente, os itens

locados, a data da locação, a data de devolução e o valor da locação.
Tipos de Requisitos
Não Funcionais: descrevem restrições sobre os serviços ou funções

oferecidos pelo sistema (SOMMERVILLE, 2007), as quais limitam as
opções para criar uma solução para o problema (PFLEEGER, 2004).
Neste sentido, os requisitos não funcionais são muito importantes
para a fase de projeto (design), servindo como base para a tomada
de decisões nessa fase.
Ex.: A consulta ao acervo da locadora deve estar disponível pela

Internet, a partir dos principais navegadores disponíveis no
mercado. (requisito de portabilidade)
Tipos de Requisitos
Os requisitos não funcionais têm origem nas necessidades dos

usuários, em restrições de orçamento, em políticas organizacionais,
em necessidades de interoperabilidade com outros sistemas de
software ou hardware ou em fatores externos como regulamentos e
legislações (SOMMERVILLE, 2007).
Assim, os requisitos não funcionais podem ser classificados quanto

à sua origem.
Tipos de Requisitos
• Requisitos de produto: especificam o comportamento do produto

(sistema). Referem-se a atributos de qualidade que o sistema deve
apresentar, tais como confiabilidade, usabilidade, eficiência,
portabilidade, manutenibilidade e segurança.
• Requisitos organizacionais: são derivados de metas, políticas e

procedimentos das organizações do cliente e do desenvolvedor.
Incluem requisitos de processo (padrões de processo e modelos de
documentos que devem ser usados), requisitos de implementação
(tal como a linguagem de programação a ser adotada), restrições
de entrega (tempo para chegar ao mercado - time to market,
restrições de cronograma etc.), restrições orçamentárias (custo,
custo-benefício) etc.
Tipos de Requisitos
• Requisitos externos: referem-se a todos os requisitos derivados de

fatores externos ao sistema e seu processo de desenvolvimento.
Podem incluir requisitos de interoperabilidade com sistemas de
outras organizações, requisitos legais (tais como requisitos de
privacidade) e requisitos éticos.
Tipos de Requisitos
Além desses requisitos, é importante considerar também Requisitos

de Domínio.
Requisitos de domínio (ou regras de negócio) são provenientes do

domínio de aplicação do sistema e refletem características e restrições
desse domínio. Eles são derivados do negócio que o sistema se propõe a
apoiar e podem restringir requisitos funcionais existentes ou estabelecer
como cálculos específicos devem ser realizados, refletindo fundamentos do
domínio de aplicação (SOMMERVILLE, 2011).
Ex.: Em um sistema de matrícula de uma universidade, uma importante regra de

negócio diz que um aluno só pode se matricular em uma turma de uma disciplina se
ele tiver cumprido seus pré-requisitos.
Requisitos Funcionais (o que o sistema deve fazer?)
Ex:
Regras de Negócio (regras que devem ser obedecidas pelo sistema)
Ex:
Requisitos Não Funcionais (tipicamente, restrições a serem obedecidas

em relação a: segurança, portabilidade, desempenho, usabilidade,
interoperabilidade,…)
 Os requisitos devem ser redigidos de modo a serem passíveis de

entendimento pelos diversos interessados (stakeholders).
 Clientes, usuários finais e desenvolvedores são todos interessados

em requisitos, mas têm expectativas diferentes. Enquanto
desenvolvedores e usuários finais têm interesse em detalhes
técnicos, clientes requerem descrições mais abstratas.
 Assim, é útil apresentar requisitos em diferentes níveis de

descrição.
 Existem dois níveis de descrição de requisitos:
 • Requisitos de Cliente ou de Usuário: são declarações em linguagem

natural acompanhadas de diagramas intuitivos de quais serviços são
esperados do sistema e das restrições sob as quais ele deve operar.
 Devem estar em um nível de abstração mais alto, de modo que sejam

compreensíveis pelos clientes e usuários do sistema que não possuem
conhecimento técnico.
 • Requisitos de Sistema: definem detalhadamente as funções, serviços e

restrições do sistema. São versões expandidas dos requisitos de cliente
usados pelos desenvolvedores para projetar, implementar e testar o
sistema.
 Como requisitos de sistema são mais detalhados, as especificações em

linguagem natural são insuficientes e para especificá-los, notações mais
especializadas devem ser utilizadas.
 Requisitos de cliente são elaborados nos estágios iniciais do

desenvolvimento (levantamento preliminar de requisitos) e servem
de base para um entendimento entre clientes e desenvolvedores
acerca do que o sistema deve contemplar. Esses requisitos são,
normalmente, usados como base para a contratação e o
planejamento do projeto.
 Requisitos de sistema, por sua vez, são elaborados como parte dos
esforços diretos para o desenvolvimento do sistema, capturando
detalhes importantes para as fases técnicas posteriores do processo
de desenvolvimento, a saber: projeto, implementação e testes.
 Uma vez que requisitos de cliente e de sistema têm propósitos e

público alvo diferentes, é útil descrevê-los em documentos
diferentes. Existem dois documentos sugeridos pela literatura:
 • Documento de Definição de Requisitos: deve ser escrito de

maneira que o cliente possa entender, i.e., na forma de uma
listagem do quê o cliente espera que o sistema proposto faça. Ele
representa um consenso entre o cliente e o desenvolvedor sobre o
quê o cliente quer.
 • Documento de Especificação de Requisitos: refina os requisitos

de cliente em termos mais técnicos, apropriados para o
desenvolvimento de software, sendo produzido por analistas de
requisitos.
That’s all Folks!

Slide 2 - Introdução À Engenharia de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Slide 2 - Introdução À Engenharia de Requisitos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Slide 2 - Introdução À Engenharia de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de

 Envolve atividades de Desenvolvimento, Gerência e

 O processo de desenvolvimento de software engloba as atividades que

 Mas o que é feito em cada etapa do processo?

 Análise e Especificação de Requisitos

 Na Análise e Especificação de Requisitos, o foco está no levantamento,

 A fase de Projeto é responsável por incorporar requisitos tecnológicos aos

• Um entendimento dos requisitos do software é essencial para o sucesso de

 O processo de levantar, analisar, documentar, gerenciar e

Que requisitos o Projeto

software deve atender? Implementação e

• Quem são os envolvidos?

Um requisito é uma característica do sistema ou a descrição de algo

Um requisito é alguma coisa que o produto tem de fazer ou uma

Os requisitos de um sistema definem o que o sistema deve fazer e

Ou, em outras palavras...

São as funções que um sistema deve incorporar e as restrições

Uma das principais medidas do sucesso de um sistema de

Funcionais: são declarações de serviços que o sistema deve prover,

Ex.: O sistema deve registrar locações, indicando o cliente, os itens

Não Funcionais: descrevem restrições sobre os serviços ou funções

Ex.: A consulta ao acervo da locadora deve estar disponível pela

Os requisitos não funcionais têm origem nas necessidades dos

Assim, os requisitos não funcionais podem ser classificados quanto

• Requisitos de produto: especificam o comportamento do produto

• Requisitos organizacionais: são derivados de metas, políticas e

• Requisitos externos: referem-se a todos os requisitos derivados de

Além desses requisitos, é importante considerar também Requisitos

Requisitos de domínio (ou regras de negócio) são provenientes do

Ex.: Em um sistema de matrícula de uma universidade, uma importante regra de

Requisitos Não Funcionais (tipicamente, restrições a serem obedecidas

 Os requisitos devem ser redigidos de modo a serem passíveis de

 Clientes, usuários finais e desenvolvedores são todos interessados

 Assim, é útil apresentar requisitos em diferentes níveis de

 Existem dois níveis de descrição de requisitos:

 • Requisitos de Cliente ou de Usuário: são declarações em linguagem

 Devem estar em um nível de abstração mais alto, de modo que sejam

 • Requisitos de Sistema: definem detalhadamente as funções, serviços e

 Como requisitos de sistema são mais detalhados, as especificações em

 Requisitos de cliente são elaborados nos estágios iniciais do

 Uma vez que requisitos de cliente e de sistema têm propósitos e

 • Documento de Definição de Requisitos: deve ser escrito de

 • Documento de Especificação de Requisitos: refina os requisitos

Você também pode gostar