Engenharia de requisitos

Resumo cap. 4

O que são requisitos?

Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços
oferecem e as restrições a seu funcionamento.
Requisitos de usuário x Requisitos de sistema:
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.
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 especificação funcional) deve definir exatamente o que deve ser implementado.
Pode ser parte do contrato entre o comprador do sistema e os desenvolvedores de software
Obs: Para a maioria dos sistemas de grande porte, ainda é o caso de existir uma fase da
engenharia de requisitos claramente identificável antes de se iniciar a implementação do
sistema. No entanto, a abordagem ágil de simultaneamente elicitar os requisitos enquanto o
sistema é desenvolvido é raramente utilizada para desenvolvimento de sistemas de grande
porte.

Requisitos funcionais x Requisitos não funcionais:

1. Requisitos funcionais. São declarações de serviços que o sistema deve fornecer, de como o
sistema deve reagir a entradas específicas e de como o sistema deve se comportar em
determinadas situações. Em alguns casos, os requisitos funcionais também podem explicitar o
que o sistema não deve fazer.
Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles dependem do
tipo de software a ser desenvolvido, de quem são seus possíveis usuários e da abordagem
geral adotada pela organização ao escrever os requisitos.
A imprecisão na especificação de requisitos é a causa de muitos problemas da engenharia de
software. É compreensível que um desenvolvedor de sistemas interprete um requisito
ambíguo de uma maneira que simplifique sua implementação. Muitas vezes, porém, essa não
é a preferência do cliente, sendo necessário, então, estabelecer novos requisitos e fazer
alterações no sistema. Naturalmente, esse procedimento gera atrasos de entrega e aumenta
os custos.
Em princípio, a especificação dos requisitos funcionais de um sistema deve ser completa e
consistente. Completude significa que todos os serviços requeridos pelo usuário devem ser
definidos. Consistência significa que os requisitos não devem ter definições contraditórias. Na
prática, para sistemas grandes e complexos, é praticamente impossível alcançar completude
e consistência dos requisitos. Uma razão para isso é que ao elaborar especificações para
sistemas complexos é fácil cometer erros e omissões. Outra razão é que em um sistema de
grande porte existem muitos stakeholders. Um stakeholder é uma pessoa ou papel que, de
alguma maneira, é afetado pelo sistema. Os stakeholders têm necessidades diferentes — e,
muitas vezes, inconsistentes.

2. Requisitos não funcionais. São restrições aos serviços ou funções oferecidos pelo sistema.
Os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo.
Os requisitos não funcionais, como o nome sugere, são requisitos que não estão diretamente
relacionados com os serviços específicos oferecidos pelo sistema a seus usuários.
Os requisitos não funcionais, como desempenho, proteção ou disponibilidade, normalmente
especificam ou restringem as características do sistema como um todo.
deixar de atender a um requisito não funcional pode significar a inutilização de todo o sistema.
Por exemplo, se um sistema de aeronaves não cumprir seus requisitos de confiabilidade, não
será certificado como um sistema seguro para operar.

1. Requisitos de produto: especificam ou restringem o comportamento do software.

Exemplos: os requisitos de confiabilidade que estabelecem a taxa aceitável de falhas, os
requisitos de proteção e os requisitos de usabilidade.
2. Requisitos organizacionais: são os requisitos gerais de sistemas derivados das políticas e
procedimentos da organização do cliente e do desenvolvedor. Exemplos: os requisitos do
processo de desenvolvimento que especificam a linguagem de programação, o ambiente de
desenvolvimento ou normas de processo a serem usadas, bem como os requisitos ambientais
que especificam o ambiente operacional do sistema.
3. Requisitos externos: abrange todos os requisitos que derivam de fatores externos ao
sistema e seu processo de desenvolvimento. Exemplos: requisitos legais, que devem ser
seguidos para garantir que o sistema opere dentro da lei; e requisitos éticos, que asseguram
que o sistema será aceitável para seus usuários e o público em geral.
- Os requisitos de sistema não apenas especificam os serviços ou as características necessárias
ao sistema, mas também a funcionalidade necessária para garantir que esses
serviços/características sejam entregues corretamente!

Metas estabelecem boas intenções, mas podem causar problemas para os desenvolvedores do
sistema, uma vez que deixam margem para interpretação e, consequentemente, para
disputas, quando da entrega do sistema. A meta do sistema apresentado a seguir, por
exemplo, é típica de como um gerente pode expressar requisitos de usabilidade:
“O sistema deve ser de fácil uso pelo pessoal médico e deve ser organizado de tal maneira
que os erros dos usuários sejam minimizados.” errado
Reescrevi apenas para mostrar como essa meta poderia ser expressa como um requisito não
funcional ‘testável’. É impossível verificar objetivamente a finalidade do sistema, mas na
descrição a seguir é possível incluir pelo menos a instrumentação de software para contar os
erros cometidos pelos usuários quando estão testando o sistema.
“A equipe médica deve ser capaz de usar todas as funções do sistema após quatro horas de
treinamento. Após esse treinamento, o número médio de erros cometidos por usuários
experientes não deve exceder dois por hora de uso do sistema.” Correto

O documento de requisitos de software:

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 de o
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.
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.

Especificação de requisitos:
A especificação de requisitos é o processo de escrever os requisitos de usuário e de sistema
em um documento de requisitos.
Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não
funcionais de modo que sejam compreensíveis para os usuários do sistema que não tenham
conhecimentos técnicos.
O documento de requisitos não deve incluir detalhes da arquitetura ou projeto do sistema.
Consequentemente, se você está escrevendo requisitos de usuário, não deve usar o jargão de
software, notações estruturadas ou notações formais; você deve escrever os requisitos de
usuário em linguagem natural, com tabelas simples, formas e diagramas intuitivos.
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
especificar completamente um sistema de software complexo, é praticamente impossível
eliminar todas as informações de projeto. Existem várias razões para isso:
1. Você pode precisar projetar uma arquitetura inicial do sistema para ajudar a estruturar a
especificação de requisitos. Os requisitos de sistema são organizados de acordo com os
diferentes subsistemas que compõem o sistema.
2. Na maioria dos casos, os sistemas devem interoperar com os sistemas existentes, que
restringem o projeto e impõem requisitos sobre o novo sistema. 3. O uso de uma arquitetura
específica para atender aos requisitos não funcionais (como programação N-version para
alcançar a confiabilidade, discutida no Capítulo 13) pode ser necessário.

Para minimizar os mal-entendidos ao escrever requisitos em linguagem natural, recomendo

algumas diretrizes simples:

1. Invente um formato-padrão e garanta que todas as definições de requisitos aderem a esse

formato. A padronização do formato torna menos prováveis as omissões e mais fácil a
verificação dos requisitos.

2. Use uma linguagem consistente para distinguir entre os requisitos obrigatórios e os

desejáveis. Os obrigatórios são requisitos aos quais o sistema tem de dar suporte e geralmente
são escritos usando-se ‘deve’. Requisitos desejáveis não são essenciais e são escritos usando-
se ‘pode’.

3. Use uma forma de destacar as partes fundamentais do requisito (negrito, itálico ou cores).

4. evitar o uso de jargões, siglas e acrônimos.

5. Sempre que possível, tente associar uma lógica a cada um dos requisitos de usuário.

Especificações estruturadas:
A linguagem natural estruturada é uma forma de escrever os requisitos do sistema na qual a
liberdade do escritor dos requisitos é limitada e todos os requisitos são escritos em uma
forma-padrão.

Processos de engenharia de requisitos:

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).

Elicitação e análise de requisitos:

Após um estudo inicial de viabilidade, o próximo estágio do processo de engenharia de
requisitos é a elicitação e análise de requisitos.

As atividades do processo são:

1. 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.
2. 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.

3. Priorização e negociação de requisitos. Essa atividade está relacionada com a priorização de

requisitos e em encontrar e resolver os conflitos por meio da negociação de requisitos.

4. Especificação de requisitos. Os requisitos são documentados e inseridos no próximo ciclo da

espiral. Documentos formais ou informais de requisitos podem ser produzidos.

- 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

Descoberta de requisitos:
A descoberta de requisitos (às vezes, chamada elicitação 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. Os stakeholders variam desde os usuários finais,
passando pelos gerentes do sistema até stakeholders externos, como reguladores, que
certificam a aceitabilidade do sistema.

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:

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

perguntas.
2. Entrevistas abertas, em que não existe uma agenda predefinida.

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.

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

1. Todos os especialistas em aplicações usam terminologias e jargões específicos para um

domínio.

2. 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.

Entrevistadores eficazes têm duas características:

1. Eles estão abertos a novas ideias, evitam ideias preconcebidas sobre os requisitos e estão
dispostos a ouvir os stakeholders. Mesmo que o stakeholder apresente requisitos-surpresa,
eles estão dispostos a mudar de ideia sobre o sistema.

2. Eles estimulam o entrevistado a participar de discussões com uma questão-trampolim, uma

proposta de requisitos ou trabalhando em conjunto em um protótipo do sistema.

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.

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.

Casos de uso:
Os casos de uso são uma técnica de descoberta de requisitos introduzida inicialmente no
método Objectory (JACOBSON et al., 1993). Eles já se tornaram uma característica
fundamental da linguagem de modelagem unificada (UML — do inglês unified modeling
language).

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.

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; outros, como sugerido por Stevens e Pooley
(2006), encapsulam um conjunto de cenários em um único caso de uso.

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.

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.

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

Validação de requisitos:
A validação de requisitos é o processo pelo qual se verifica se os requisitos definem o sistema
que o cliente realmente quer. Ela se sobrepõe à análise, uma vez que está preocupada em
encontrar problemas com os requisitos. A validação de requisitos é importante porque erros
em um documento de requisitos podem gerar altos custos de retrabalho quando descobertos
durante o desenvolvimento ou após o sistema já estar em serviço.

O custo para consertar um problema de requisitos por meio de uma mudança no sistema é
geralmente muito maior do que o custo de consertar erros de projeto ou de codificação. A
razão para isso é que a ocorrência de mudança dos requisitos normalmente significa que o
projeto e a implementação do sistema também devem ser alterados. Além disso, o sistema
deve, posteriormente, ser retestado.

Existe uma série de técnicas de validação de requisitos que podem ser usadas individualmente
ou em conjunto:

1. Revisões de requisitos. Os requisitos são analisados sistematicamente por uma equipe de

revisores que verifica erros e inconsistências.
2. Prototipação. Nessa abordagem para validação, um modelo executável do sistema em
questão é demonstrado para os usuários finais e clientes. Estes podem experimentar o modelo
para verificar se ele atende a suas reais necessidades.

3. Geração de casos de teste. Os requisitos devem ser testáveis. Se os testes forem concebidos
como parte do processo de validação, isso frequentemente revela problemas de requisitos. Se
é difícil ou impossível projetar um teste, isso normalmente significa que os requisitos serão
difíceis de serem implementados e devem ser reconsiderados.

Gerenciamento de requisitos:
Os requisitos para sistemas de software de grande porte estão sempre mudando. Uma razão
para isso é que esses sistemas geralmente são desenvolvidos para enfrentar os problemas
‘maus’ — problemas que não podem ser completamente definidos.

Existem várias razões pelas quais a mudança é inevitável:

1. Após a instalação, o ambiente técnico e de negócios do sistema sempre muda.

2. As pessoas que pagam por um sistema e os usuários desse sistema raramente são os
mesmos.

3. Geralmente, sistemas de grande porte têm uma comunidade de diversos usuários, com
diferentes requisitos e prioridades, que podem ser conflitantes ou contraditórios.

Planejamento de gerenciamento de requisitos:

O planejamento é o primeiro estágio essencial no processo de gerenciamento de requisitos, e
determina o nível de detalhamento requerido no gerenciamento de requisitos. Durante o
estágio de gerenciamento de requisitos, você deve decidir sobre:

1. Identificação de requisitos.

2. Processo de gerenciamento de mudanças.

3. Políticas de rastreabilidade.

4. Ferramenta de apoio.

Gerenciamento de mudança de requisitos:

Após a aprovação do documento de requisitos, o gerenciamento de mudança de requisitos
deve ser aplicado a todas as mudanças propostas aos requisitos de um sistema. O
gerenciamento de mudanças é essencial, pois é necessário decidir se os benefícios da
implementação de novos requisitos justificam os custos de implementação.

Existem três estágios principais em um processo de gerenciamento de mudanças:

1. Análise de problema e especificação de mudanças.

2. Análise de mudanças e custos.

3. Implementação de mudanças.

- Há sempre a tentação de mudar o sistema e, em seguida, retrospectivamente modificar o

documento de requisitos. Esse procedimento deve ser evitado, pois quase inevitavelmente faz
com que a especificação de requisitos e a implementação do sistema fiquem defasadas.

- Processos ágeis de desenvolvimento, como Extreme Programming, foram concebidos para

lidar com requisitos mutáveis durante o processo de desenvolvimento. Nesses processos,
quando um usuário propõe uma mudança nos requisitos, a mudança não passa por um
processo formal de gerenciamento de mudanças. Pelo contrário, o usuário tem de priorizar
essa mudança e, em caso de alta prioridade, decidir quais recursos do sistema planejados para
a próxima iteração devem ser abandonados.