Requisitos de Software

Não se pode pensar em engenharia de software, ciclo de vida de sistemas, desenvolvimento de programas sem se preocupar com os requisitos. Afinal, são os justamente os requisitos que permitem identificar quis são características necessárias para o desenvolvimento do software. Para facilitar o entendimento sobre o assunto, Pressman (2016) apresenta o seguinte panorama (Figura 01) no capítulo 8 “Entendendo os requisitos”:

Esse panorama permite ter uma visão geral dos requisitos. O que eles são, quem são os envolvidos, quais etapas estão relacionadas, que artefato é gerado e como garantir que o trabalho está correto. Pressman (2016) indica que “O amplo espectro de tarefas e técnicas que levam a um entendimento dos requisitos é chamado de engenharia de requisitos”.

Para entender um pouco sobre os processos de engenharia em geral Acesse a página https://www.nasa.gov/audience/foreducators/best/edp.html onde é possível encontrar a definição de um “Processo de Projeto de Engenharia” conforme descrito a seguir e apresentado na Figura 02. (Sugiro assistir o vídeo explicativo disponível no link – Se alguém puder recriar a Figura 02, agradeço, envie para [email protected]).

• ASK/PERGUNTE: Identifique o problema, os requisitos que devem ser atendidos e as restrições que devem ser consideradas.
• IMAGINE: Debata soluções e idéias de pesquisa. Identifique o que os outros já fizeram.
• PLA/PLANO: Escolha de duas a três das melhores idéias de sua lista e esboce possíveis projetos. Defina qual é o melhor para implementar.
• CREATE/CRIAR: Construa um modelo de trabalho, ou protótipo, alinhado com os requisitos e dentro das restrições.
• EXPERIMENT/TESTE: Realize testes para avaliar a solução; colete e analise os dados; indique os pontos fortes e fracos revelados no teste.
• IMPROVE/MELHORAR: Com base nos resultados de seus testes, realize melhorias em seu projeto.

A Figura 03 apresenta quais atividades tem algum impacto relacionado ao levantamento de requisitos e a importância de se ter um processo de engenharia de requisitos bem definido.

Sobre a importância dos requisitos, Fred Brooks, citado por Pressman (2026) destaca que “A parte mais difícil ao se construir um sistema de software é decidir o que construir. Nenhuma parte do trabalho afeta tanto o sistema resultante se for feita a coisa errada. Nenhuma outra parte é mais difícil de consertar depois”. Se ainda não se convenceu do quanto identificar os requisitos do software é importante, relembre As aventuras da Alice no país das maravilhas:

Alice asks the cat: “Which road should I take?”

In reply, the cat says: “Where are you going?”

To that, Alice says: “I don’t know.”

“Then it doesn’t matter which road you take,” the cat says in response.

(DODGSON, 1865) pseudônimo Lewis Carroll
Tradução
Alice pergunta ao gato: “Que caminho devo seguir?”
Em resposta, o gato diz: “Onde você está indo?”
Então, Alice diz: “Eu não sei”.
“Então não importa qual caminho você seguir”, diz o gato em resposta.

O levantamento de requisitos pode ocorrer em diferentes fases do ciclo de vida conforme já estudado. Além disso, de acordo com a cultura empresarial adotada, esse levantamento pode ocorrer de diferentes formas com uso de diversos modelos e ferramentas disponíveis. Neste post, são apresentados conceitos relacionados que podem iluminar seu caminho na definição de como prosseguir com o levantamento de requisitos para o projeto. Independente de modelo de ciclo de vida adotado ou formato de trabalho da equipe.

Embora o processo de engenharia de requisitos como um todo possa ser manipulado de diferentes formas e em diferentes fases em cada situação/projeto. A lista a seguir, apresentada pela maioria dos autores da área, inclusive Pressman (2016) define as tarefas mais comuns do processo de engenharia de requisitos.

• 1) Concepção: Na concepção do projeto é estabelecido um entendimento básico do problema, as pessoas envolvidas, a natureza da solução desejada e a eficácia da comunicação e colaboração preliminares entre todos os envolvidos. A maioria dos projetos inicia se uma necessidade de negócio é identificada. Do lado do cliente/negócio (por exemplo, gerentes comerciais, pessoal de marketing, gerentes de produto) é definido um plano de negócio para a ideia, identificado o tamanho do mercado, realizada uma análise de viabilidade e realizada uma descrição operacional da abrangência do projeto.

• 2) Levantamento: O levantamento permite identificar quais são os objetivos do sistema, o que deve ser obtido, como o sistema atende às necessidades da empresa e como o sistema será utilizado no dia a dia. É necessário realizar o levantamento com atenção e esmero, pois são comuns os problemas nessa fase. Entre os problemas frequentemente listados pelos autores da área, encontram-se.
  • Problemas de escopo: Se os limites do sistema são definidos de forma precária ou quando são especificados detalhes técnicos desnecessários que podem confundir.
  • Problemas de entendimento: Se os clientes e usuários não sabem exatamente o que querem. Seja um entendimento errôneo das capacidades e limitações de seus ambientes, do domínio do problema, algum problema para transmitir suas necessidades, omissão de informações que acreditam ser “óbvias”, especificação requisitos em conflito com as necessidades de outros clientes e usuários…
  • Problemas de volatilidade: Se os requisitos mudam muito com o passar do tempo.
• 3) elaboração: “guiada pela criação e pelo refinamento de cenários que descrevem como o usuário (e outros atores) vão interagir com o sistema”. Classes, atributos e suas relações, entidades do domínio e serviços necessários também podem ser identificados.

• 4) Negociação:
• 5) Especificação: Pode ser no formato de um “documento por escrito, um conjunto de modelos gráficos, um modelo matemático formal, um conjunto de cenários de uso, um protótipo” ou qualquer outra formou combinação de formas que permitam especificar os requisitos. A Figura 04 apresenta o modelo de especificação apresentado por Pressman (2016). Diversos são os modelos propostos e encontrados na internet, desde modelos mais difundidos como ISO e IEEE até modelos já adequados para determinado ambiente e disponibilizados por empresas de desenvolvimento de software.
• 6) validação e
• 7) gestão.

Os requisitos são obtidos a partir de um domínio (parte do mundo real relevante ao software – Domínio do problema/Domínio do negócio…).

…

• Requisitos funcionais: definem as funcionalidades do sistema. O que o sistema deve fazer?
  • O sistema deve permitir que um estudante realize a matricula nas disciplinas oferecidas em um semestre letivo.
  • Os professores devem poder obter o tool de aprovações e reprovações em cada uma de suas disciplinas.
• Requisitos não-funcionais: definem as características de qualidade do sistema relacionadas às suas funcionalidades.
  • Medidas de confiabilidade, tempo médio entre falhas e recuperação, quantidade de erros aceitáveis a cada X linhas de código.
  • Tempo esperado de resposta para uma funcionalidade.
  • Portabilidade/segurança/usabilidade…
• Requisitos de domínio: restrições impostas sobre o desenvolvimento do sistema.
  • Orçamento, prazo, aspectos legais, tecnologia.

• 

Referências

VAZQUEZ, Carlos Eduardo e SIMÕES, Guilherme Siqueira. Engenharia de requisitos: Software orientado ao negócio. Rio de Janeiro: Brasport: 2016

https://www.nasa.gov/audience/foreducators/best/edp.html

Disponível de forma gratuita temporariamente OU com kindle unlimited em https://www.amazon.com.br/Alices-Adventures-Wonderland-AmazonClassics-English-ebook/dp/B071RSDB49/ref=sr_1_1?__mk_pt_BR=ÅMÅŽÕÑ&dchild=1&keywords=Alice%27s+adventure+in+wonderland&qid=1593730352&sr=8-1

Interessantes
http://portal.trt24.jus.br/documents/10184/199910/MPS-TRT24+_25_08_2016.pdf/dbc3c63f-94c5-4caf-a9aa-29e0e63d98e3

https://www.scielo.br/pdf/gp/v11n2/a06v11n2.pdf