aula05

Prévia do material em texto

5ºAula
ANÁLISE DE REQUISITOS
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• saber o que é a definição de requisitos;
• entender o que é o processo de levantamento de requisitos.
Olá pessoal, como estão?
Agora, vamos para a quinta aula da nossa disciplina. Nesta 
aula, vamos ver os aspectos de uma atividade muito importante 
no desenvolvimento de software: a análise de requisitos. É 
por meio dela que vamos saber o que o sistema irá fazer para 
satisfazer um cliente. 
Lembre-se de ler atentamente esta aula. Se tiver qualquer 
dúvida, nos avise por meio das ferramentas da área do aluno.
Bons estudos!
97
Introdução a Engenharia de Software 34
1. 
Seções de estudo
 Definição de requisitos
2. Especificação de software ou engenharia de requisitos
3. Processos de comunicação e documentação
1
 Até agora, já pudemos perceber que o desenvolvimento lida com o processo de se transformar um desejo em um produto 
que satisfaça tais desejos. Para isso, precisamos ouvir aqueles que vão usar o sistema. Parece complexo? Vejam a imagem:
Figura 1 – As diferentes maneiras de ser entendido um problema.
Fonte: ROCHA, 2013.
A imagem traz à tona diferentes modos de se compreender 
um produto a ser desenvolvido. O que muda, certamente, é 
de quem é o olhar diante do produto. Porém, uma coisa é 
tantos problemas, concorda?
de software, chegamos a um ponto que pode decidir o 
sucesso do projeto. Independentemente de qual software 
vai ser projetado, caso a análise de requisitos não seja feita 
adequadamente, não teremos um bom resultado.
No contato com o cliente, precisamos tentar chegar a 
para termos uma função e um desempenho adequado em 
relação ao produto a ser desenvolvido. Sommerville ressalta 
isso:
Alguns dos problemas que surgem durante o 
processo de engenharia de requisitos são as 
falhas em não fazer uma clara separação entre 
esses diferentes níveis de descrição. Faço uma 
distinção entre eles usando o termo ‘requisitos 
para expressar a descrição detalhada do que 
o sistema deve fazer. Requisitos de usuário 
como segue:
1. Requisitos de usuário são declarações, em 
uma linguagem natural com diagramas, de 
quais serviços o sistema deverá fornecer a seus 
usuários e as restrições com as quais este deve 
operar.
98
35
2. Requisitos de sistema são descrições mais 
detalhadas das funções, serviços e restrições 
operacionais do sistema de software. O 
documento de requisitos do sistema (às vezes, 
exatamente o que deve ser implementado. 
Pode ser parte do contrato entre o comprador 
do sistema e os desenvolvedores de software 
(SOMMERVILLE, 2013. p. 58).
Perceberam a diferença entre requisitos de usuário e 
de sistema? O primeiro diz respeito às declarações menos 
sistematizadas e o segundo está relacionado às declarações 
Sommerville (2013): 
Os requisitos de um sistema são as descrições 
do que o sistema deve fazer, os serviços que 
oferece e as restrições a seu funcionamento. 
clientes para um sistema que serve a uma 
dispositivo, colocar um pedido ou encontrar 
informações. O processo de descobrir, 
restrições é chamado engenharia de requisitos 
(RE, do inglês requirements engineering) 
(SOMMERVILLE, 2013. p. 58).
de requisitos.
Fonte: SOMMERVILLE, 2011, p. 59.
Requisito funcional e Requisito não funcional. O 
primeiro diz respeito às declarações de serviços que o sistema 
deve fornecer; de que modo o sistema deve reagir a entradas 
serviços ou funções ofertados pelo sistema, como restrições 
de timing, no processo de desenvolvimento e as impostas pelas 
normas (SOMMERVILLE, 2013).
respeitar as normas impostas pela Receita Federal, portanto, o 
requisito não funcional seria “a necessidade do conhecimento 
relativo as normas”. Caso as normas não fossem seguidas, 
poderia gerar uma inconsistência dos dados ou até a não 
Para tanto, é fundamental entender quais são as etapas 
da análise de requisitos. Esse será o assunto de nossa próxima 
seção.
2
engenharia de requisitos
de escrita dos requisitos de usuário e de sistema em um 
documento, chamado de documento de requisitos. Ele deve 
ser claro, com uma linguagem simples, sem contradições, 
mas consistente e completo. Esse paralelo é difícil de ser 
alcançado, tendo em vista que os stakeholders entende os 
tange aos requisitos.
No que diz respeito aos requisitos de usuário, eles devem 
descrever os requisitos funcionais e não funcionais de modo 
que sejam acessíveis aos usuários do sistema, mesmo que estes 
não tenham um conhecimento teórico e técnico a respeito do 
assunto:
Os requisitos de sistema são versões 
expandidas dos requisitos de usuário, usados 
por engenheiros de software como ponto 
de partida para o projeto do sistema. Eles 
acrescentam detalhes e explicam como os 
requisitos de usuário devem ser atendidos pelo 
sistema. Eles podem ser usados como parte 
do contrato para a implementação do sistema 
completa e detalhada de todo o sistema.
Os requisitos do sistema devem descrever 
apenas o comportamento externo do sistema 
e suas restrições operacionais. Eles não devem 
se preocupar com a forma como o sistema 
deve ser projetado ou implementado. No 
entanto, para atingir o nível de detalhamento 
sistema de software complexo, é praticamente 
impossível eliminar todas as informações de 
projeto (SOMMERVILLE, 2013, p. 66). 
serviços que são requisitados do sistema. Na sequência, esses 
operação, bem como ao desenvolvimento do sistema. Quando 
estágio bastante crítico e importante do processo de software: 
caso sejam cometidos erros nessa fase, ocorrerão problemas 
no sistema no que tange ao projeto e à implementação. O 
um sistema que satisfaça os requisitos dos stakeholders. Há dois 
níveis por meio dos quais devem ser apresentados: os usuários 
alto nível; já os desenvolvedores de sistemas recebem uma 
há quatro atividades principais do processo de engenharia de 
requisitos. Vejamos:
99
Introdução a Engenharia de Software 36
1. Estudo de viabilidade. É feita uma 
estimativa acerca da possibilidade de se 
satisfazerem as necessidades do usuário 
atuais de software e hardware. O estudo 
considera se o sistema proposto será 
rentável a partir de um ponto de vista de 
negócio e se ele pode ser desenvolvido no 
âmbito das atuais restrições orçamentais. 
Um estudo de viabilidade deve ser 
relativamente barato e rápido. O resultado 
deve informar a decisão de avançar ou 
não, com uma análise mais detalhada.
2. Elicitação e análise de requisitos. Esse é 
o processo de derivação dos requisitos 
do sistema por meio da observação 
dos sistemas existentes, além de 
discussões com os potenciais usuários 
e compradores, análise de tarefas, entre 
outras etapas. Essa parte do processo 
pode envolver o desenvolvimento de um 
ou mais modelos de sistemas e protótipos, 
os quais nos ajudam a entender o sistema 
3. 
de traduzir as informações obtidas durante 
a atividade de análise em um documento 
Dois tipos de requisitos podem ser 
incluídos nesse documento. Requisitos 
do usuário são declarações abstratas 
dos requisitos do sistema para o cliente 
sistema são uma descrição mais detalhada 
da funcionalidade a ser provida.
4. A validação de requisitos. Essa 
a realismo, consistência e completude 
(SOMMERVILLE, 2013, p. 24-25).
Ao serem seguidas cada uma dessas etapas, todos os 
realizar as atividades no processo de requisitos, até mesmo 
porque, durante a análise de requisitos, novos requisitos 
extreme programming, os requisitos são desenvolvidos de forma 
incremental, de acordo com as prioridades do usuário, e a 
elicitação de requisitos é feita pelos usuários que integram a 
equipe de desenvolvimento” (SOMMERVILLE, 2013, p. 25).
3 - Processos de comunicação e 
documentação
entender de que forma se dá a criação de um software. 
Nesse caminho, é importante entender que, por mais que 
um software seja desenvolvido para atender às necessidades 
expressas por um determinado cliente, nem sempre esse 
cliente irá utilizar tal software, que será destinado, na verdade,Nessa perspectiva, pensando na questão da comunicação 
nos processos de desenvolvimento de software, temos três 
partes principais envolvidas: o cliente, o desenvolvedor 
expressos pelo cliente sejam compatíveis com as possíveis 
necessidades dos usuários do sistema. Certamente, é preciso 
muita atenção por parte do desenvolvedor, tendo em vista 
• 
relativos aos softwares, ou ao processo de 
desenvolvimento de um programa.
• O desenvolvedor, certas vezes, não conhece o 
sistema que o software irá executar. Para tanto, 
destaca-se a importância dos documentos no que 
diz respeito à comunicação com o cliente acerca das 
possíveis problemáticas.
Figura 3 – Usuários de um documento de engenharia de 
requisitos.
Fonte: SOMMERVILLE, 2011, p. 64.
de sistemas críticos, é necessário haver requisitos detalhados. 
Em caso de sistemas desenvolvidos por uma companhia 
precisas. Já quando o processo interno tem desenvolvimento 
interativo, não são necessários tantos detalhes.
Sommerville mostra um exemplo de Documento de 
100
37
Requisitos. Vejamos no quadro a seguir:
O Documento de Requisitos, na visão de Sommerville
O documento de requisitos de software, às vezes chamado 
desenvolvedores do sistema devem implementar. Deve incluir tanto 
detalhada dos requisitos de sistema. Em alguns casos, os requisitos 
de usuário e de sistema são integrados em uma única descrição. Em 
número de requisitos, os requisitos detalhados de sistema podem 
ser apresentados em um documento separado.
Documentos de requisitos são essenciais quando um contratante 
externo está desenvolvendo o sistema de software. Entretanto, os 
métodos ágeis de desenvolvimento argumentam que os requisitos 
mudam tão rapidamente que um documento de requisitos já está 
ultrapassado assim que termina de ser escrito. Portanto, o esforço 
é, em grande parte, desperdiçado. Em vez de um documento formal, 
os requisitos de usuário de forma incremental e escrevem-nos 
em cartões como estórias de usuário. O usuário então prioriza os 
requisitos para implementação no próximo incremento do sistema.
[...]
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 
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.
organização de um documento de requisitos baseada em uma 
caso, eu estendi a norma para incluir informações sobre a evolução 
prevista do sistema. Essa informação ajuda os engenheiros de 
manutenção de sistema e permite que os projetistas incluam suporte 
para futuros recursos do sistema.
Naturalmente, a informação incluída em um documento de requisitos 
depende do tipo de software a ser desenvolvido e da abordagem de 
desenvolvimento que está em uso. Se uma abordagem evolutiva é 
de requisitos deixará de fora muitos dos capítulos detalhados 
os requisitos não funcionais de alto nível de sistema. Nesse caso, os 
projetistas e programadores usam seu julgamento para decidir como 
atender aos requisitos gerais de usuário para o sistema.
No entanto, quando o software é parte de um projeto de um sistema 
de grande porte que inclui interações entre sistemas de hardware 
requisitos podem ser muito longos e devem incluir a maioria ou todos 
os capítulos mostrados na Tabela [...]. É particularmente importante 
incluir uma tabela completa, abrangendo conteúdo e índice de 
documentos, para que os leitores possam encontrar as informações 
de que necessitam.
Fonte: SOMMERVILLE, 2011, p. 65.
101
Introdução a Engenharia de Software 38
Sommerville (2011) deixa claro que a informação 
incluída em um documento de requisitos dependerá de qual 
tipo de software será desenvolvido. Também dependerá 
da abordagem de desenvolvimento em uso. Em caso de 
abordagens evolutivas, o documento de requisitos excluirá 
muitos capítulos detalhados, e o enfoque se dará sobre 
não funcionais de alto nível de sistema. Nesse caso, são os 
projetistas e programadores que decidirão como atender aos 
requisitos gerais de usuário para o sistema.
Maiores detalhes a respeito desta matéria serão abordados 
na disciplina de Engenharia de Requisitos. E com isso, 
Retomando a aula
então, recordar?
Na primeira seção, estudamos o conceito de requisitos de 
um sistema. Vimos que eles são as descrições do que o sistema 
deve fazer, os serviços a serem oferecidos e as restrições para 
seus funcionamentos.
Entendemos que ela diz respeito ao processo de compreensão 
refere às restrições relativas à operação, bem como ao 
desenvolvimento do sistema.
de comunicação permite entender de que forma se dá a criação 
de um software. Nesse caminho, é importante entender que, 
por mais que um software seja desenvolvido para atender 
às necessidades expressas por um determinado cliente, nem 
sempre esse cliente irá utilizar tal software, que será destinado, 
CANTÚ, Márcia Regina Simm. Artigo Engenharia de 
Software 24 - A Comunicação no Processo de Software. 
DevMedia, 2010. Disponível em: < https://www.devmedia.
com.br/artigo-engenharia-de-software-24-a-comunicacao-
no-processo-de-software/16807>. Acesso em: 28 nov. 
2018.
ROCHA, Fabio Gomes. Engenharia de Requisitos: 
em: <https://www.devmedia.com.br/engenharia-de-
. Acesso em: 
28 nov. 2018.
Vale a pena acessar
Vale a pena
ENGHOLM JR., Hélio. Engenharia de software na 
prática. São Paulo: Novatec, 2015.
PAULA FILHO, Wilson de Pádua. Engenharia de 
software: fundamentos, métodos e padrões. 3. ed. Rio de 
Janeiro: LTC, 2012.
PEDRYCZ, Witold; PETERS, James F.; GARCIA, 
Ana Patrícia Machado de Pinho. Engenharia de software: 
teoria e prática. Rio de Janeiro: Campus, 2001.
PRESSMAN, Roger S.; FECCHIO, Mário Moro; 
GRIESI, Ariovaldo. et al. Engenharia de software: uma 
Porto Alegre: Bookman; Santana: AMGH Editora, 2016.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. 
São Paulo: Pearson Addison Wesley, 2011.
Vale a pena ler
Minhas anotações
102