Aula 05

Fazer download em pdf ou txt
Fazer download em pdf ou txt
Você está na página 1de 19

ENGENHARIA DE REQUISITOS -

Documentação

Prof. Ian Santos


Processos da Engenharia de Requisitos
Engenharia de Requisitos

Especi cação de Requisitos Gestão dos Requisitos

• Levantamento e Análise • Controle de mudanças


• Documentação • Versionamento
• Validação • Rastreabilidade
fi
Processos da Engenharia de Requisitos
Especi cação de requisitos: representa todas as atividades realizadas para
identificar, analisar, especificar e definir as necessidades do sistema, as quais veremos,
com mais detalhes, a seguir: levantamento/elicitação e análise, negociação,
documentação, validação e verificação.

Gestão de requisitos: atividades responsáveis pela documentação, versionamento,


controle de mudanças e qualidade dos requisitos levantados na fase de especificação.
fi
Esse processo da Engenharia de
Requisitos, na prática, é um processo
iterativo cujas atividades são
intercaladas, conforme apresentado
na figura ao lado. Elas são
organizadas em torno de uma espiral,
e o resultado do processo é um
documento de requisitos de sistema.
(Sommerville, 2011)

Fonte: Sommerville, 2011, p. 70


Processos da Engenharia de Requisitos
Quando se inicia o processo de Engenharia de Requisitos, dedicamos a maior parte
do esforço a compreender os requisitos do negócio, seguindo para um estudo de
viabilidade, em seguida, os requisitos do usuário do sistema. Em etapas mais
avançadas do processo, Sommerville (2011) destaca, nos anéis mais externos da
espiral, o seguinte: “mais esforço será dedicado à elicitação e à compreensão dos
requisitos não funcionais e dos requisitos de sistema mais detalhados”.
O que é Documentação de Requisitos?
O Documento de Requisitos de Software, possui a função de documentar o que foi
acordado entre quem solicita e quem desenvolve, estabelecendo, também, o escopo
do software, ou seja, o conjunto de funcionalidades que ele deverá oferecer. Além de
servir de referência a desenvolvimento, testes, manutenção e evolução do sistema
(mudanças), esse documento garante, ainda, a rastreabilidade mínima dos requisitos,
ao longo do ciclo de vida do software.
O documento de requisitos de software, às vezes chamado Especi cação de Requisitos de Software (SRS — do inglês
Software Requirements Speci cation), é uma declaração o cial de o que os desenvolvedores do sistema devem
implementar. Deve incluir tanto os requisitos de usuário para um sistema quanto uma especi cação detalha- da dos
requisitos de sistema. Em alguns casos, os requisitos de usuário e de sistema são integrados em uma única descrição.
Em outros, os requisitos de usuário são de nidos em uma introdução à especi cação de requisitos de sistema. Se
houver um grande número de requisitos, os requisitos detalhados de sistema podem ser apresentados em um
documento separado. (Sommerville, 2011)
fi
fi
fi
fi
fi
fi
Quais os interessados?
A diversidade de possíveis usuários é um indicativo de que o documento de
requisitos precisa ser um compromisso com a comunicação dos requisitos para os
clientes, a definição dos requisitos em detalhes precisos para os desenvolvedores e
testadores e a inclusão de informações sobre a possível evolução do sistema.
Informações sobre mudanças previstas podem ajudar os projetistas de sistema a evitar
decisões de projeto restritivas, além de ajudar os engenheiros de manutenção de
sistema que precisam adaptar o sistema aos novos requisitos.
Clientes do sistema: especificam os requisitos e os leem, para conferir se satisfazem às
suas necessidades. Os clientes especificam mudanças nos requisitos.

Gerentes: usam o documento de requisitos para planejar uma proposta ao sistema e


planejar o seu processo de desenvolvimento.

Engenheiros de sistema: usam os requisitos a fim de compreender qual sistema deve ser
desenvolvido.

Engenheiros de testes: usam os requisitos com o intuito de desenvolver testes de


validação do sistema.

Engenheiros de manutenção: usam os requisitos para entender o sistema e as relações


entre as suas partes.

Fonte: Adaptação do Sommerville, 2011, p. 64


Qual o nível de detalhamento?

Segundo Summerville (2011), o nível de detalhes que você deve incluir em um


documento de requisitos depende do tipo de sistema em desenvolvimento e o
processo usado. Os sistemas críticos precisam ter requisitos detalhados, porque a
segurança e a proteção devem ser analisadas em detalhes. Quando o sistema está
sendo desenvolvido por uma companhia separada, as especificações de sistema
devem ser detalhadas e precisas. Se um processo interno de desenvolvimento iterativo
é usado, o documento de requisitos pode ser muito menos detalhado e quaisquer
ambiguidades podem ser resolvidas durante o desenvolvimento do sistema.
Qual o modelo da documentação?
Em primeiro lugar, o documento deve ser capaz de garantir o entendimento dos
stakeholders.
Em segundo lugar, a equipe técnica precisa estar ciente de que esse documento é a
única garantia que atende às solicitações do cliente, portanto, ele necessita estar,
sempre, atualizado. Qual modelo ou padrão usar? Há vários modelos os quais são,
também, adaptáveis. O ideal é você definir, junto com a equipe, qual o modelo ou
padrão que utilizarão à documentação dos requisitos do projeto.
As informações contidas em um documento de requisitos dependerão do tipo de
software a ser desenvolvido e da metodologia que está sendo usada para o processo
de desenvolvimento. O importante, independentemente do tipo de software, é incluir,
no documento, conteúdo para todos os leitores e interessados serem capazes de
encontrar e entender, facilmente, todas as informações acerca do sistema.
O que o documento deve ter?
1. Escopo do software: a descrição do conjunto de funcionalidades que ele deverá ter e os
atributos de qualidade que o sistema suportará bem como o conjunto de características técnicas,
ou seja, a descrição completa dos Requisitos Funcionais e Não Funcionais.

2. O documento deve ser elaborado de maneira precisa, detalhada, consistente e de acordo


com as necessidades do cliente, além de ser compreensível por todos stakeholders, isto é, os
interessados no sistema.

3. Guia de referência para validação, verificação e testes, além de manutenção e evolução do


sistema.
Exemplo de documento segundo padrão IEEE.
Capítulos Descrição

Prefácio Deve definir os possíveis leitores do documento e descrever seu histórico de versões, incluindo uma justificativa para a
criação de uma nova versão e um resumo das mudanças feitas em cada versão.

Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e explicar como ele vai
Introdução
funcionar com outros sistemas. Também deve descrever como o sistema atende aos objetivos globais de negócio ou
estratégicos da organização que encomendou o software.

Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e explicar como ele vai
Glossário
funcionar com outros sistemas. Também deve descrever como o sistema atende aos objetivos globais de negócio ou
estratégicos da organização que encomendou o software.

De nição de Deve descrever os serviços fornecidos ao usuário. Os requisitos não funcionais de sistema também devem ser descritos nessa
requisitos de seção. Essa descrição pode usar a linguagem natural, diagramas ou outras notações compreensíveis para os clientes. Normas
usuário de produto e processos que devem ser seguidos devem ser especificados.

Arquitetura Deve apresentar uma visão geral em alto nível da arquitetura do sistema previsto, mostrando a distribuição de funções entre
do Sistema os módulos do sistema. Componentes de arquitetura que são recusados devem ser destacados.

Fonte: Adaptação do Sommerville, 2011, p. 65


fi
Exemplo de documento segundo padrão IEEE.
Capítulos Descrição
Especi cação
Deve descrever em detalhes os requisitos funcionais e não funcionais. Se necessário, também podem ser adicionados mais
de requisitos
detalhes aos requisitos não funcionais. Interfaces com outros sistemas podem ser definidas.
do sistema

Pode incluir modelos gráficos do sistema que mostram os relacionamentos entre os componentes do sistema, o sistema e
Modelos do
seu ambiente. Exemplos de possíveis modelos são modelos de objetos, modelos de fluxo de dados ou modelos semânticos
sistema
de dados.

Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como quaisquer mudanças previstas, em
Evolução do
decorrência da evolução de hardware, de mudanças nas necessidades do usuário etc. Essa seção é útil para projetistas de
sistema
sistema, pois pode ajudá-los a evitar decisões capazes de restringir possíveis mudanças futuras no sistema.
Deve fornecer informações detalhadas e específicas relacionadas à aplicação em desenvolvimento, além de descrições de
hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configurações mínimas ideais para o
Apêndices
sistema. Requisitos de banco de dados definem a organização lógica dos dados usados pelo sistema e os relacionamentos
entre esses dados.

Vários índices podem ser incluídos no documento. Pode haver, além de um índice alfabético normal, um índice de
Índice
diagramas, de funções, entre outros pertinentes.

Fonte: Adaptação do Sommerville, 2011, p. 65


fi
Documento de Requisitos

Histórico de versões
Data Versão Descrição Responsável

O que foi inserido,


A cada nova modificação do
01/01/2023 1.0
modi cado, Quem realizou documento, uma nova versão deve
atualizado neste as alterações
documento
ser criada.
… … … …

Alterado
20/12/2023 2.4 João Paulo
validação

Esse documento de requisitos é apenas um exemplo.


Verificar documento disponível para download.
fi
Documento de Requisitos
Objetivo
Sobre que é o sistema? Para qual finalidade? Qual o propósito do sistema?

Objetivo do Documento
O que será apresentado no documento? Para que serve o documento?

Objetivo do Sistema
Descrição detalhada sobre o que o sistema irá fazer, como irá fazer e quais suas
restrições.
Documento de Requisitos
Termos e Abreviações
Identificar todas as siglas, abreviações ou palavras que necessitam de descrição.

Requisitos
Listar todos os Requisitos Funcionais e Não Funcionais do sistema.

Escopo não contemplado


Descrição do que ainda não será realizado na atual etapa do desenvolvimento.
Descrever funções ou melhorias que serão realizadas apenas no futuro.

Aprovação
Lista de assinaturas aprovando o documento
Documento de Requisitos
Tabela de requisitos

[Código do Requisito] Título do requisito

Descrição/Ação: campo para ser usado à descrição do requisito ou à ação que deve ser tomada.

Entrada: onde são descritas as entradas necessárias para o processamento da função do


requisito.

Saída: onde são descritas as saídas ou os resultados produzidos com o desenvolvimento do


requisito.

Pré-condições: campo que descreve o que deve ter ocorrido ou deve estar disponível antes da
execução/desenvolvimento do requisito.

Pós-condições: campo que descreve o que deve ser mostrado quando a execução do requisito se
completar.

Stakeholders: campo que identifica os stakeholders envolvidos no requisito.


Para ver depois…

https://youtu.be/PVLcTjHBmrM?si=7etQQlVSfYuUV4Vi
Referências

• PRESSMAN, R. S. Engenharia de software. 6.ed. McGraw-Hill, 2006.

• SOMMERVILLE, I. Engenharia de software. 9.ed. Pearson Prentice Hall, 2011.

• PROGRAME PARA ANDROID. PODCAST AdS #03 | Veja como fazer um levantamento de
requisitos completo DO ZERO!. Disponível em: https://youtu.be/PVLcTjHBmrM?
si=7etQQlVSfYuUV4Vi. Acesso em: 23 out. 2023.

Você também pode gostar