Análise de Requisitos de Software

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!
Introdução à 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 - Defi nição de requisitos
 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 é 
certa: faltou a defi nição de requisitos para que não houvesse 
tantos problemas, concorda?
Quando falamos, especifi camente, acerca dos requisitos 
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 
algo concreto, ou seja, desejos e necessidades bem defi nidos 
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 
de usuário’, para expressar os requisitos 
abstratos de alto nível, e ‘requisitos de sistema’, 
para expressar a descrição detalhada do que 
o sistema deve fazer. Requisitos de usuário 
e requisitos de sistema podem ser defi nidos 
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.
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, 
chamado especifi cação funcional) deve defi nir 
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 
mais detalhadas. Vejamos uma defi nição sobre requisitos de 
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. 
Esses requisitos refl etem as necessidades dos 
clientes para um sistema que serve a uma 
fi nalidade determinada, como controlar um 
dispositivo, colocar um pedido ou encontrar 
informações. O processo de descobrir, 
analisar, documentar e verifi car esses serviços e 
restrições é chamado engenharia de requisitos 
(RE, do inglês requirements engineering) 
(SOMMERVILLE, 2013. p. 58).
Figura 2 – Leitores de diferentes tipos de especificação 
de requisitos.
Fonte: SOMMERVILLE, 2011, p. 59.
Outra classifi cação que podemos adotar é entre 
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 
específi cas e como o sistema deve se comportar diante de 
situações específi cas. O segundo diz respeito às restrições a 
serviços ou funções ofertados pelo sistema, como restrições 
de timing, no processo de desenvolvimento e as impostas pelas 
normas (SOMMERVILLE, 2013).
Exemplifi cando: Pensando em um sistema comercial 
qualquer, ele possui o seguinte requisito funcional: Ao fi nal 
de uma venda o sistema deve gerar nota fi scal. Analisando 
o requisito percebe-se que para gerar a nota fi scal ele deve 
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 
geração da nota fi scal. 
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 - Especifi cação de software ou 
engenharia de requisitos
A especifi cação de requisitos diz respeito ao processo 
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 
requisitos de maneiras diversas, o que gera confl itos no que 
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 
e devem consistir em uma especifi cação 
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 
necessário para especifi car completamente um 
sistema de software complexo, é praticamente 
impossível eliminar todas as informações de 
projeto (SOMMERVILLE, 2013, p. 66). 
A especifi cação de software, ou engenharia de requisitos, 
refere-se ao processo de compreensão e de defi nição dos 
serviços que são requisitados do sistema. Na sequência, esses 
serviços são identifi cados no que tange às restrições relativas à 
operação, bem como ao desenvolvimento do sistema. Quando 
abordamos a especifi cação de software, nos referimos a um 
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 
propósito, então, é de elaborar um documento que especifi que 
um sistema que satisfaça os requisitos dos stakeholders. Há dois 
níveis por meio dos quais devem ser apresentados: os usuários 
fi nais e clientes recebem uma declaração de requisitos de 
alto nível; já os desenvolvedores de sistemas recebem uma 
especifi cação mais detalhada do sistema. Para Sommerville, 
há quatro atividades principais do processo de engenharia de 
requisitos. Vejamos:
Introdução à Engenharia de Software 36
1. Estudo de viabilidade. É feita uma 
estimativa acerca da possibilidade de se 
satisfazerem as necessidades do usuário 
identificado usando-se tecnologias 
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 
a ser especifi cado.
3. Especifi cação de requisitos. É a atividade 
de traduzir as informações obtidas durante 
a atividade de análise em um documento 
que defi na um conjunto de requisitos. 
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 
e usuário fi nal do sistema; requisitos de 
sistema são uma descrição mais detalhada 
da funcionalidade a ser provida.
4. A validação de requisitos. Essa 
atividade verifi ca os requisitos quanto 
a realismo, consistência e completude 
(SOMMERVILLE, 2013, p. 24-25).
Ao serem seguidas cada uma dessas etapas, todos os 
erros verifi cados no documento de requisitos são descobertos. 
Assim, então, é possível modifi cá-los para eventuais 
correções. Certamente, não há uma sequência defi nida para 
realizar as atividades no processo de requisitos, até mesmo 
porque, durante a análise de requisitos, novos requisitos 
irão surgir: “Portanto, as atividades de análise, defi nição e 
especifi cação são intercaladas. Nos métodos ágeis, como 
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
A refl exão acerca dos processos 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, na verdade, 
a usuários fi nais. 
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 
e, fi nalmente, os usuários. Para que a relação dê certo, é 
importante que o profi ssional tenha em mente que os desejos 
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 
algumas difi culdades, tais como:
• Difi culdade dos clientes de entender aspectos 
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.
O documento de requisitos terá suas especifi cações 
defi nidas pelo tipo de sistema e pelo processo usado. Em casos 
de sistemas críticos, é necessário haver requisitos detalhados. 
Em caso de sistemas desenvolvidos por uma companhia 
separada, tais especifi cações devem ser bem detalhadas e 
precisas. Já quando o processo interno tem desenvolvimento 
interativo, não são necessários tantos detalhes.
Sommerville mostra um exemplo de Documento de 
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 
Especificação de Requisitos de Software (SRS — do inglês Software 
Requirements Specification), é uma declaração oficial do que os 
desenvolvedores do sistema devem implementar. Deve incluir tanto 
os requisitos de usuário para um sistema quanto uma especificação 
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 
outros, os requisitos de usuário são definidos em uma introdução 
à especificaçã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.
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, 
abordagens como a Extreme Programming (BECK, 1999) coletam 
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 
companhia separada (por exemplo, através de outsourcing), 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.
A Tabela (representada na próxima figura) mostra uma possível 
organização de um documento de requisitos baseada em uma 
norma IEEE para documentos de requisitos (IEEE, 1998). Essa é uma 
norma genérica que pode ser adaptada para usos específicos. Nesse 
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 é 
adotada para um produto de software (por exemplo), o documento 
de requisitos deixará de fora muitos dos capítulos detalhados 
sugeridos. O foco será sobre a definição de requisitos de usuário e 
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 
e software, geralmente é necessário definir os requisitos em um 
alto nível de detalhamento. Isso significa que esses documentos de 
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.
Figura 4 – A estrutura de um documento de requisitos.
Fonte: SOMMERVILLE, 2011, p. 65.
Introdução à Engenharia de Software 38
Sommerville (2011) deixa claro que a informação 
incluída em um documentode 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 
a defi nição de requisitos de usuários e sobre requisitos 
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, 
fi nalizamos a nossa quinta aula. Na próxima aula, falaremos 
sobre a Verifi cação e Validação de Software. Até mais!
Retomando a aula
Chegamos ao fi nal da quinta aula. Vamos, 
então, recordar?
1 - DEFINIÇÃO DE REQUISITOS
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.
2 - ESPECIFICAÇÃO DE SOFTWARE OU 
ENGENHARIA DE REQUISITOS
Nesta seção, abordamos a especifi cação de software. 
Entendemos que ela diz respeito ao processo de compreensão 
e de defi nição dos serviços que são requisitados do sistema. 
Na sequência, esses serviços são identifi cados no que se 
refere às restrições relativas à operação, bem como ao 
desenvolvimento do sistema.
3 - PROCESSOS DE COMUNICAÇÃO E 
DOCUMENTAÇÃO
Nesta seção, vimos que a refl exão acerca dos processos 
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, 
na verdade, a usuários fi nais.
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: 
introdução e certifi cação. DevMedia, 2013. Disponível 
em: <https://www.devmedia.com.br/engenharia-de-
requisitos-introducao-e-certifi cacao/28058>. 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 
abordagem profi ssional. 8. ed. São Paulo: McGraw-Hill; 
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