Processo de

Eng. Requisitos
Tarik Ponciano
Processo

Os processos de engenharia de requisitos podem incluir quatro atividades de

alto nível.

Elas visam avaliar se o sistema é útil para a empresa (estudo de viabilidade),

descobrindo requisitos (elicitação e análise), convertendo-os em alguma forma-
padrão (especificação), e verificar se os requisitos realmente definem o sistema
que o cliente quer (validação).

Na prática, a engenharia de requisitos é um processo

iterativo em que as atividades são intercaladas
Processo

A quantidade de tempo e esforço dedicados a cada atividade em cada iteração

depende do estágio do processo como um todo e do tipo de sistema que está
sendo desenvolvido.

No início do processo, o esforço maior será a compreensão dos requisitos de

negócio e não funcionais em alto nível, bem como dos requisitos de usuário para
o sistema.

Mais tarde no processo, o esforço maior será dedicado a elicitar e compreender

os requisitos de sistema em detalhes.

Sendo a saída um documento de requisitos de sistema

Processo

Embora os métodos estruturados tenham um papel a desempenhar no processo

de engenharia de requisitos, existe muito mais para a engenharia de requisitos do
que o que é coberto por esses métodos.

Elicitação de requisitos, em particular, é uma atividade centrada em pessoas, e as

pessoas não gostam de restrições impostas por modelos rígidos de sistema.

Em praticamente todos os sistemas os requisitos mudam. As pessoas envolvidas

desenvolvem uma melhor compreensão do que querem do software, a
organização que compra o sistema também muda, modificações são feitas no
hardware, no software e no ambiente organizacional do sistema.
Processo
Processo
Elicitação - Ciclo

Os engenheiros de software trabalham com clientes e usuários finais do

sistema para obter informações sobre o domínio da aplicação, os serviços que o
sistema deve oferecer, o desempenho do sistema, restrições de hardware e assim
por diante.

As atividades do processo são:

Descoberta de requisitos: Essa é a atividade de interação com os stakeholders

do sistema para descobrir seus requisitos. Os requisitos de domínio dos
stakeholders e da documentação também são descobertos durante essa atividade.
Existem várias técnicas complementares que podem ser usadas para descoberta
de requisitos.
Elicitação - Ciclo

Classificação e organização de requisitos: Essa atividade toma a coleção de

requisitos não estruturados, agrupa requisitos relacionados e os organiza em
grupos coerentes. A forma mais comum de agrupar os requisitos é o uso
de um modelo de arquitetura do sistema para identificar subsistemas e associar
requisitos a cada subsistema. Na prática, a engenharia de requisitos e projeto da
arquitetura não podem ser atividades completamente separadas.

Priorização e negociação de requisitos: Inevitavelmente, quando os vários

stakeholders estão envolvidos, os requisitos entram em conflito. Essa atividade
está relacionada com a priorização de requisitos e em encontrar e resolver os
conflitos por meio da negociação de requisitos. Normalmente, os stakeholders
precisam se encontrar para resolver as diferenças e chegar a um acordo sobre os
requisitos.
Elicitação - Ciclo
Especificação de requisitos: Os requisitos são documentados
Elicitação - Ciclo

A elicitação e análise de requisitos é um processo iterativo, com feedback

contínuo de cada atividade para as outras atividades.

O ciclo do processo começa com a descoberta de requisitos e termina

com sua documentação. O entendimento do analista de requisitos melhora a
cada rodada do ciclo.

Quando se completa o documento de requisitos, o ciclo termina.

Elicitação - Desafios
Elicitar e compreender os requisitos dos stakeholders do sistema é um processo
difícil por várias razões:

• Exceto em termos gerais, os stakeholders costumam não saber o que querem

de um sistema computacional; eles podem achar difícil articular o que
querem que o sistema faça, e, como não sabem o que é viável e o que não é,
podem fazer exigências inviáveis.

• Naturalmente, os stakeholders expressam requisitos em seus próprios termos

e com o conhecimento implícito de seu próprio trabalho. Engenheiros de
requisitos, sem experiência no domínio do cliente, podem não entender esses
requisitos.
Elicitação - Desafios
• Diferentes stakeholders têm requisitos diferentes e podem expressar essas
diferenças de várias maneiras. Engenheiros de requisitos precisam descobrir
todas as potenciais fontes de requisitos e descobrir as semelhanças e
conflitos.

• Fatores políticos podem influenciar os requisitos de um sistema. Os gerentes

podem exigir requisitos específicos, porque estes lhes permitirão aumentar
sua influência na organização.

• O ambiente econômico e empresarial no qual a análise ocorre é dinâmico. É

inevitável que ocorram mudanças durante o processo de análise. A
importância dos requisitos específicos pode mudar. Novos requisitos podem
surgir a partir de novos stakeholders que não foram inicialmente consultados.
Elicitação - Desafios
Inevitavelmente, os diferentes stakeholders têm opiniões diferentes sobre a
importância e prioridade dos requisitos e, por vezes, essas opiniões são
conflitantes.

Durante o processo, você deve organizar as negociações

regulares dos stakeholders, de modo que os compromissos possam ser
cumpridos.

É completamente impossível satisfazer a todos os stakeholders, mas, todas as

opiniões devem ser devidamente consideradas.
Elicitação - Desafios
No estágio de especificação de requisitos, aqueles que foram elicitados até esse
momento são documentados de forma a ajudar na descoberta de novos
requisitos.

Nesse estágio, uma versão inicial do documento de requisitos do sistema pode

ser produzida com seções faltantes e requisitos incompletos.

Como alternativa, os requisitos podem ser documentados de uma forma

completamente diferente (por exemplo, em uma planilha ou em cartões).

Escrever os requisitos em cartões pode ser muito eficaz, pois são fáceis para os
stakeholders lidarem, mudarem e organizarem.
Elicitação
Elicitação
Descoberta de Requisitos
É o processo de reunir informações sobre o sistema requerido e os sistemas
existentes e separar dessas informações os requisitos de usuário e de sistema.

Fontes de informação durante a fase de descoberta de requisitos incluem

documentação, stakeholders do sistema e especificações de sistemas similares.

Você interage com os stakeholders por meio da observação e de entrevistas e

pode usar cenários e protótipos para ajudar os stakeholders a compreenderem o
que o sistema vai ser.

Os stakeholders variam desde os usuários finais, passando pelos gerentes do

sistema até stakeholders externos, como reguladores, que certificam a
aceitabilidade do sistema.
Descoberta de Requisitos

Por exemplo, os stakeholders de um sistema de informação da saúde mental de

pacientes incluem:

1. Os pacientes cujas informações estão registradas no sistema.

2. Os médicos responsáveis pela avaliação e tratamento dos pacientes.

3. Os enfermeiros que, alinhados com os médicos, coordenam as consultas e

administram tratamentos.

4 . Recepcionistas dos médicos, que gerenciam as consultas dos pacientes.

Descoberta de Requisitos

5 . A equipe de TI, responsável pela instalação e manutenção do sistema.

6. Um gerente de ética médica, que deve garantir que o sistema atenda às diretrizes
éticas atuais no atendimento ao paciente.

7. Gerentes de saúde, que obtêm informações de gerenciamento a partir do sistema.

8. A equipe de registros médicos, responsável por garantir que as informações do

sistema sejam mantidas e preservadas, e que os procedimentos de manutenção dos
registros sejam devidamente implementados.
Descoberta de Requisitos
Além dos stakeholders do sistema, já vimos que os requisitos também podem vir a
partir do domínio da aplicação e de outros sistemas que interagem com o sistema
especificado.

Durante o processo de elicitação de requisitos, todos esses devem ser considerados.

Descoberta de Requisitos
https://www.devmedia.com.br/tecnicas-para-levantamento-de-requisitos/9151

Descoberta de Requisitos
Entrevistas
Entrevistas formais ou informais com os stakeholders do sistema são parte da maioria
dos processos de engenharia de requisitos. Nessas entrevistas, a equipe de engenharia
de requisitos questiona os stakeholders sobre o sistema que usam no momento e sobre o
sistema que será desenvolvido. Requisitos surgem a partir das respostas a essas
perguntas. As entrevistas podem ser de dois tipos:

Entrevistas fechadas, em que o stakeholder responde a um conjunto predefinido de

perguntas.

Entrevistas abertas, em que não existe uma agenda predefinida. A equipe de engenharia
de requisitos explora uma série de questões com os stakeholders do sistema e, assim,
desenvolve uma melhor compreensão de suas necessidades.
Entrevistas
Na prática, as entrevistas com os stakeholders costumam ser uma mistura de ambos os
tipos. Você poderá ter de obter a resposta a determinadas questões, mas é comum que
estas levem a outras, discutidas de forma menos estruturada.

Discussões totalmente abertas raramente funcionam bem. Você geralmente tem de fazer
algumas perguntas para começar e manter a entrevista centrada no sistema que será
desenvolvido.

Entrevistas são boas para obter uma compreensão global sobre o que os stakeholders
fazem, como eles podem interagir com o novo sistema e as dificuldades que eles
enfrentam com os sistemas atuais.
Entrevistas
Na prática, as entrevistas com os stakeholders costumam ser uma mistura de ambos os
tipos. Você poderá ter de obter a resposta a determinadas questões, mas é comum que
estas levem a outras, discutidas de forma menos estruturada.

Discussões totalmente abertas raramente funcionam bem. Você geralmente tem de fazer
algumas perguntas para começar e manter a entrevista centrada no sistema que será
desenvolvido.

Entrevistas são boas para obter uma compreensão global sobre o que os stakeholders
fazem, como eles podem interagir com o novo sistema e as dificuldades que eles
enfrentam com os sistemas atuais.
Entrevistas
Entrevistas
https://chat.openai.com/share/8f4c36ca-15a0-4ff1-9f37-
93243c7bf3f1
Entrevistas

Pode ser difícil elicitar conhecimento do domínio por meio de entrevistas por
duas razões:

Todos os especialistas em aplicações usam terminologias e jargões específicos

para um domínio. Para eles, é impossível discutir os requisitos de domínio essa
terminologia. Eles normalmente usam a terminologia de forma precisa e sutil, o
que dificulta a compreensão dos engenheiros de requisitos.

O conhecimento de domínio é tão familiar aos stakeholders que eles têm

dificuldade de explicá-lo, ou pensam que é tão fundamental que não vale a pena
mencionar. Por exemplo, para um bibliotecário, não é necessário dizer que
todas as aquisições são catalogadas antes de serem adicionadas à biblioteca.
No entanto, isso pode não ser óbvio para o entrevistador, e acaba não sendo
levado em conta nos requisitos
Cenários

As pessoas geralmente acham mais fácil se relacionar com exemplos da vida

real do que com descrições abstratas.

Elas podem compreender e criticar um cenário de como elas podem interagir

com um sistema de software.

Engenheiros de requisitos podem usar a informação obtida a partir deste debate

para formular os requisitos do sistema atual.

https://www.devmedia.com.br/artigo-engenharia-de-software-16-
cenarios-e-casos-de-uso-fundamentos-e-conceitos/14186
Cenários

Os cenários podem ser particularmente úteis para adicionar detalhes a uma

descrição geral de requisitos.

Trata-se de descrições de exemplos de sessões de interação. Cada cenário

geralmente cobre um pequeno número de interações possíveis.

Diferentes cenários são desenvolvidos e oferecem diversos tipos de informação

em variados níveis de detalhamento sobre o sistema.

https://chat.openai.com/share/dc2393bb-99eb-4d7c-88e9-8f4aeb712288

https://cwi.com.br/blog/user-stories-estruturacao-e-dicas-extras/
Cenários
Cenários
Cenários
Cenários

Um cenário começa com um esboço da interação. Durante o processo de

elicitação, são adicionados detalhes ao esboço, para criar uma descrição
completa dessa interação. Em sua forma mais geral, um cenário pode incluir:

1. Uma descrição do que o sistema e os usuários esperam quando o cenário se

iniciar.
2. Uma descrição do fluxo normal de eventos no cenário.
3. Uma descrição do que pode dar errado e como isso é tratado.
4. Informações sobre outras atividades que podem acontecer ao mesmo tempo.
5. Uma descrição do estado do sistema quando o cenário acaba.

https://chat.openai.com/share/ddc8683f-1add-4c52-be73-145e2d807eab
Cenários

A elicitação baseada em cenários envolve o trabalho com os stakeholders para

identificar cenários e capturar detalhes que serão incluídos nesses cenários.

Os cenários podem ser escritos como texto, suplementados por diagramas,

telas etc.

Outra possibilidade é uma abordagem mais estruturada, em que cenários de

eventos ou casos de uso podem ser usados.
Cenários

Quando um novo paciente vai a uma clínica, um novo registro é criado por uma
recepcionista, e suas informações pessoais (nome, idade etc.) são
acrescentadas nessa ficha.

Em seguida, uma enfermeira entrevista o paciente e coleta seu histórico médico.

Então, o paciente faz uma consulta inicial com o médico, que faz um diagnóstico
e, se for o caso, recomenda um tratamento. O cenário mostra o que acontece
quando o histórico médico é coletado.
Cenários
Casos de Uso

Em sua forma mais simples, um caso de uso identifica os atores

envolvidos em uma interação e dá nome ao tipo de interação.

Essa é, então, suplementada por informações adicionais que descrevem a

interação com o sistema.

A informação adicional pode ser uma descrição textual ou um

ou mais modelos gráficos, como diagrama de seqüência ou de estados da UML.
Casos de Uso
Casos de Uso

Os casos de uso são documentados por um diagrama de casos de uso de alto

nível. O conjunto de casos de uso representa todas as possíveis interações que
serão descritas nos requisitos de sistema.

Atores, que podem ser pessoas ou outros sistemas, são representados como
figuras 'palito'.

Cada classe de interação é representada por uma elipse. Linhas fazem a

ligação entre os atores e a interação.

Opcionalmente, pontas de flechas podem ser adicionadas às linhas para

mostrar como a interação se inicia.
Casos de Uso
Casos de Uso
Casos de Uso

Não há distinção entre cenários e casos de uso que seja simples e rápida.
Algumas pessoas consideram cada caso de uso um cenário único.

Encapsulam um conjunto de cenários em um único caso de uso.

Cada cenário é um segmento através do caso de uso. Portanto, seria um

cenário para a interação normal além de cenários para cada possível exceção.
Você pode, na prática, usá-los de qualquer forma.

Os casos de uso identificam as interações individuais entre o sistema e seus

usuários ou outros sistemas. Cada caso de uso deve ser documentado com
uma descrição textual.

Esta, por sua vez, pode ser ligada a outros modelos UML que desenvolverão o
cenário com mais detalhes.
Casos de Uso
 Casos de Uso

Agenciar a consulta permite que dois ou mais

médicos de consultórios diferentes possam ler o
mesmo registro ao mesmo tempo.

Um médico deve escolher, em um menu de lista de

médicos on-line, as pessoas envolvidas.

O prontuário do paciente é então exibido em suas

telas, mas apenas o primeiro médico pode editar o
registro.

Além disso, umo janela de mensagens de texto é

criada para ajudar a coordenar as ações.

Supõe-se que uma conferência telefônica para

comunicação por voz será estabelecida
separadamente.
 Casos de Uso

Cenários e casos de uso são técnicas eficazes para elicitar requisitos dos
stakeholders que vão interagir diretamente com o sistema.

Cada tipo de interação pode ser representado como um caso de uso. No entanto,
devido a seu foco nas interações com o sistema, eles não são tão eficazes para
elicitar restrições ou requisitos de negócios e não funcionais em alto nível ou para
descobrir requisitos de domínio.

A UML é, de fato, um padrão para a modelagem orientada a objetos, e assim, casos

de uso e elicitação baseada em casos de uso são amplamente usados para a
elicitação de requisitos.
Etnografia
 Etnografia
Os sistemas de software não existem isoladamente.
Eles são usados em um contexto social e
organizacional, e requisitos de software do sistema
podem ser derivados ou restringidos desse contexto.

Geralmente, satisfazer a esses requisitos sociais e

organizacionais é crítico para o sucesso do sistema.

Uma razão pela qual muitos sistemas de software

são entregues, mas nunca são usados, é que seus
requisitos não levam devidamente em conta a forma
como o contexto social e organizacional afeta o
funcionamento prático do sistema.
 Etnografia

Etnografia é uma técnica de observação que pode ser usada para compreender os
processos operacionais e ajudar a extrair os requisitos de apoio para esses
processos.

Um analista faz uma imersão no ambiente de trabalho em que o sistema será

usado.

O trabalho do dia a dia é observado e são feitas anotações sobre as tarefas reais
em que os participantes estão envolvidos.

O valor da etnografia é que ela ajuda a descobrir requisitos implícitos do sistema

que refletem as formas reais com que as pessoas trabalham, em vez de refletir
processos formais definidos pela organização.
 Etnografia
Frequentemente, as pessoas acham muito difícil expressar os
detalhes de seu trabalho, pois isso é secundário para elas.

Elas entendem o próprio trabalho, mas não compreendem sua

relação com outros trabalhos na organização.

Fatores sociais e organizacionais que afetam o trabalho, mas que

não são óbvios para os indivíduos, podem ficar claros apenas
quando analisados por um observador imparcial.

Por exemplo, um grupo de trabalho pode se auto-organizar de

maneira que os membros conheçam mutuamente seus trabalhos
e, em caso de ausência de
algum deles, possam dividir as tarefas.

Essa informação pode não ser mencionada durante uma

entrevista, pois o
grupo não a percebe como parte integrante de seu trabalho.
 Etnografia
Suchman (1987) foi pioneira no uso da etnografia na análise do trabalho de
escritório.

Ela constatou que as práticas de trabalho eram muito mais ricas, mais complexas e
mais dinâmicas do que os modelos simples assumidos pelos sistemas de automação
de escritório.
A diferença entre o trabalho presumido e o real foi a
razão mais importante por que esses sistemas de
escritório não causaram efeitos significativos sobre a
produtividade.
 Etnografia
A etnografia é particularmente eficaz para descobrir dois tipos de requisitos:

1. Requisitos derivados da maneira como as pessoas realmente trabalham, e não da

forma como as definições dos processos dizem que deveriam trabalhar.

Por exemplo, controladores de tráfego aéreo podem desligar um sistema de alerta de

conflitos que detecta aeronaves com rotas em colisão, embora os procedimentos de
controle normal especifiquem que ele deve ser usado.

Eles deliberadamente colocam a aeronave em caminhos conflitantes, por um curto

período, para ajudar no gerenciamento do espaço aéreo.

Sua estratégia de controle é projetada para assegurar que os aviões sejam

afastados dessa rota conflitante antes que surjam problemas, e eles acham que o
alarme de alerta distrai seu trabalho.
 Etnografia
A etnografia é particularmente eficaz para descobrir dois tipos de requisitos:

2. Requisitos derivados da cooperação e conhecimento das atividades de outras

pessoas.

Por exemplo, controladores de tráfego aéreo podem usar conhecimento do trabalho

de outros controladores para prever o número de aeronaves que entrarão em seu
setor de controle.

Eles, então, modificam suas estratégias de controle, dependendo do volume de

trabalho previsto.

Portanto, um sistema ATC automatizado deve permitir aos controladores de um setor

alguma visibilidade do trabalho em setores adjacentes.
 Etnografia
A etnografia pode ser combinada com prototipação. A etnografia informa o
desenvolvimento do protótipo, para que menos ciclos de refinamento do protótipo
sejam necessários.

Além disso, a prototipação dá foco para a etnografia, ao identificar problemas e

questões que podem ser discutidos com o etnógrafo. Esse profissional deve procurar
as respostas para essas perguntas durante a próxima fase do estudo do sistema.

Estudos etnográficos podem revelar detalhes críticos de processo que, muitas vezes,
são ignorados por outras técnicas de elicitação de requisitos. Contudo, uma vez que
o foco é o usuário final, essa abordagem nem sempre é apropriada para descobrir
requisitos organizacionais ou de domínio.

Eles nem sempre podem identificar novos recursos que devem ser adicionados ao
sistema. A etnografia, portanto, não á uma abordagem completa para elicitaçâo e
deve ser usada para complementar outras abordagens, como análise de casos de
uso.
Etnografia
Conclusão
Não existe uma técnica padrão para o processo de levantamento de requisitos.
Para alcançar um levantamento de requisitos mais preciso é importante o
conhecimento de diversas técnicas para saber que técnica de levantamento aplicar
em cada situação.

É necessário o analista de sistema possuir a capacidade de:

● Compreender conceitos abstratos, organizá-los em divisões lógicas e

sintetizar soluções baseadas em cada divisão;
● Absorver fatos pertinentes de fontes conflitantes ou confusas;
● Entender os ambientes do usuário/cliente;
● Aplicar elementos do sistema de hardware e/ou software aos
elementos do usuário/cliente;
● Comunicar bem nas formas escrita e verbal e entender o objetivo
global do software.

https://www.devmedia.com.br/tecnicas-para-levantamento-de-
requisitos/9151
Referências
Engenharia de Software, Ian Sommerville

http://www.inf.ufes.br/~jssalamon/wp-content/uploads/disciplinas/engreq/slides/Slide%202%20-%2
0Introdu%C3%A7%C3%A3o%20%C3%A0%20Engenharia%20de%20Requisitos.pdf
https://www.devmedia.com.br/tecnicas-para-levantamento-de-requisitos/9151

https://en.wikipedia.org/wiki/Lucy_Suchman
Obrigado!!