Conheça

Os requisitos de redação representam um desafio significativo há muitas décadas, e uma das principais razões para isso é a linguagem usada para expressá-los. É essencial escrever os requisitos de forma abrangente e facilmente compreensível, especialmente quando os leitores são proprietários de negócios, usuários finais ou partes interessadas. Isso significa usar uma linguagem “natural” livre de jargões técnicos e terminologia complexa. No entanto, a linguagem natural é inerentemente imprecisa e pode facilmente ser mal interpretada ou mal compreendida, levando a mais complicações.

Infelizmente, muitos analistas resistem a qualquer tipo de estrutura na redação de seus requisitos, preferindo, em vez disso, contar com parágrafos descritivos e sentenças que podem implicar em requisitos adicionais. Embora essa abordagem possa ser mais atraente para seus leitores, geralmente leva a confusão e mal-entendidos quando os requisitos são entregues a desenvolvedores ou analistas de sistemas. Isso, por sua vez, pode resultar em longas discussões e atrasos ao tentar esclarecer o que os requisitos realmente significam.

Durante a entrevista com a Visure Solutions, Jordan Kyriakidis, o estimado cofundador e CEO da QRA Corp, compartilhou suas percepções sobre vários aspectos da engenharia de requisitos. Durante esta entrevista, discutimos alguns assuntos bastante interessantes, incluindo

• Elementos Essenciais de Grandes Requisitos
• EAsy Aabordagem para REquirements Ssintaxe Abordagem
• IA ganhando força na digitalização da engenharia de requisitos
• Dicas e truques para escrever requisitos excelentes
• E muito mais!

Quem é Jordan Kyriakidis?

Jordan Kyriakidis é um líder renomado no campo de projeto e verificação de sistemas críticos de segurança. É co-fundador e CEO da QRA Corp, empresa que fornece soluções de ponta para empresas e governos identificarem e mitigar riscos em projetos complexos envolvendo novas tecnologias em setores regulados. Com quase duas décadas de experiência liderando equipes de alto desempenho, Jordan é um cientista talentoso com inúmeras publicações internacionais em seu currículo.

Jordan possui um Ph.D. em Teoria Quântica pela Universidade de Basel, Suíça, e viveu e trabalhou em vários países do mundo, incluindo Europa, Estados Unidos e Canadá. Sua experiência em engenharia de requisitos, juntamente com sua paixão pelo avanço do campo, fizeram dele um palestrante requisitado e um líder de pensamento no setor. Jordan é conhecido por sua abordagem visionária para alavancar a IA e as melhores práticas para escrever requisitos em indústrias críticas, e ele tem sido fundamental na digitalização da engenharia de requisitos.

O que é a especificação de requisitos?

A especificação de requisitos é o processo de definir e documentar claramente os requisitos funcionais e não funcionais de um sistema, aplicativo de software ou produto. O objetivo da especificação de requisitos é capturar as necessidades e expectativas das partes interessadas, incluindo clientes, usuários finais e outras partes interessadas, de maneira clara e concisa. Esta documentação é usada como um modelo para o projeto, desenvolvimento, teste e implementação do sistema ou produto. 

A especificação de requisitos normalmente inclui uma descrição da funcionalidade pretendida do sistema ou produto, desempenho, usabilidade, confiabilidade, segurança e outras características importantes. Também pode incluir quaisquer restrições, suposições ou dependências que possam afetar o projeto ou a implementação do sistema ou produto. A especificação de requisitos é um componente essencial do ciclo de vida de desenvolvimento de software e serve como base para comunicação e colaboração eficazes entre as partes interessadas do projeto.

Importância de Escrever Grandes Requisitos

Escrever grandes requisitos é crucial para o sucesso de qualquer projeto de desenvolvimento de software. Aqui estão algumas razões do porquê:

1. Comunicação clara: Requisitos bem escritos ajudam a garantir que todas as partes interessadas do projeto tenham uma compreensão clara e compartilhada do que se espera do sistema ou produto que está sendo desenvolvido. Essa clareza garante que todos estejam na mesma página, reduzindo o risco de mal-entendidos e falhas de comunicação que podem levar a erros, retrabalho e atrasos no projeto.
2. Foco nas necessidades do usuário: Grandes requisitos concentram-se nas necessidades dos usuários finais e clientes, garantindo que o sistema ou produto que está sendo desenvolvido atenda às suas expectativas e requisitos. Essa abordagem aumenta a satisfação do cliente e reduz o risco de falha do projeto devido à incompatibilidade entre o produto e as necessidades do usuário.
3. Gerenciamento de riscos: Os requisitos podem identificar riscos e problemas potenciais no início do processo de desenvolvimento, permitindo que estratégias de mitigação proativas sejam implementadas. Ao identificar problemas em potencial com antecedência, as equipes podem evitar retrabalho, atrasos e falhas dispendiosos no futuro.
4. Eficiência: Grandes requisitos ajudam a agilizar o processo de desenvolvimento, fornecendo um roteiro claro para os desenvolvedores seguirem. Esse roteiro garante que os desenvolvedores trabalhem nos recursos e requisitos mais importantes, evitando desperdício de esforços em tarefas menos importantes.
5. Garantia De Qualidade: Por ter requisitos bem definidos, fica mais fácil garantir que o sistema ou produto que está sendo desenvolvido atenda aos padrões de qualidade exigidos. Grandes requisitos tornam mais fácil testar, validar e verificar o sistema ou produto que está sendo desenvolvido, garantindo que seja entregue no prazo, dentro do orçamento e com o nível de qualidade esperado.

Características dos Grandes Requisitos

Grandes requisitos são essenciais para a entrega de projetos de desenvolvimento de software bem-sucedidos que atendam às expectativas do cliente, sejam entregues no prazo e dentro do orçamento. Aqui estão algumas características de grandes requisitos:

1. Claro e conciso: Grandes requisitos são fáceis de entender, com linguagem clara e concisa que evita ambiguidade ou confusão.
2. Completo: Grandes requisitos devem capturar todos os aspectos funcionais e não funcionais necessários do sistema ou produto que está sendo desenvolvido, não deixando espaço para interpretações ou mal-entendidos.
3. Preciso: Grandes requisitos devem ser precisos e verificáveis, sem discrepâncias entre o que está escrito e o que se espera que o sistema ou produto faça.
4. Testável: Grandes requisitos devem ser testáveis, o que significa que deve ser possível criar testes que possam verificar se o sistema ou produto atende aos requisitos.
5. Priorizado: Grandes requisitos devem ser priorizados para garantir que os recursos e funcionalidades mais importantes sejam desenvolvidos primeiro.
6. Viável: Grandes requisitos devem ser viáveis, o que significa que são técnica e praticamente atingíveis dentro do prazo e das restrições orçamentárias.
7. Rastreável: Grandes requisitos devem ser rastreáveis, o que significa que há um vínculo claro entre cada requisito e sua origem, incluindo a parte interessada que o solicitou.
8. Consistente: Grandes requisitos devem ser consistentes com outras documentações do projeto, incluindo o plano do projeto, a declaração do escopo e outras documentações relevantes.
9. Inequívoco: Grandes requisitos devem estar livres de ambiguidade ou confusão, garantindo que haja um entendimento claro do que se espera do sistema ou produto que está sendo desenvolvido.

Desafios ao escrever requisitos

Existem vários desafios que as pessoas enfrentam ao escrever requisitos.

Documentação ruim - Em algumas organizações, a documentação dos processos é inexistente ou não está à altura. Nesse caso, a coleta de requisitos torna-se um processo de duas etapas: primeiro fazer engenharia reversa do processo existente e depois identificar as áreas que precisam de melhoria e otimização. Para confirmar que os requisitos são detalhados e precisos, é fundamental identificar as principais partes interessadas e especialistas no assunto, envolvendo-os diretamente. Desenhar mapas de processos de negócios e visualizar fluxos de trabalho são duas maneiras excelentes de fazer isso. Isso ajuda na eliminação de suposições incorretas, ao mesmo tempo em que fornece uma imagem completa. Desenhar mapas de processo e exibir processos são duas abordagens úteis para esse propósito.

Requisitos Contraditórios - Quando as partes interessadas têm prioridades diferentes para seus objetivos de negócios, isso leva a requisitos conflitantes entre si. Em casos como esses, a responsabilidade de um analista de negócios é documentar detalhadamente todos os requisitos, identificar quais solicitações se opõem e permitir que as partes interessadas tenham a oportunidade de decidir o que é prioritário.

Você não pode tomar decisões sem ouvir a opinião das partes interessadas e, como analista de negócios, pode ter algumas ideias sobre o que deve ser priorizado. Ainda é crucial ouvir a perspectiva das partes interessadas. A criação de uma pesquisa pode ser um dos métodos para obter clareza sobre o que é mais importante para a maioria das partes interessadas.

Indisponibilidade de entrada do usuário - Alguns motivos podem contribuir para a indisponibilidade dos usuários finais e cada um requer sua própria resolução. Por exemplo, às vezes os usuários finais estão tão preocupados com seu trabalho diário que não querem participar das atividades de coleta de requisitos.

Nesses casos, o melhor que um analista de negócios pode fazer é limitar o número e a duração dos compromissos. Antes da reunião, fazer o máximo de pesquisa possível ajudará a tornar a discussão mais organizada e informativa. É quase como transformar a coleta de requisitos em sessões de validação de requisitos. definir grupos focais e identificar os usuários finais mais adequados para cada grupo

Focando na interface em vez da experiência – Muitas partes interessadas e usuários finais têm uma visão clara de como a nova solução deve aparecer, mas não sabem o que ela deve realizar. A interface de usuário de qualquer sistema é crucial, mas não deve definir ou interferir na funcionalidade.

Os analistas de negócios devem sempre se lembrar de manter o design e os requisitos funcionais separados em sua documentação. Ao usar ferramentas mais gerais, como diagramas, histórias de usuários ou protótipos de baixa fidelidade, em vez de rascunhos de design, eles podem manter o foco nos aspectos funcionais da coleta de requisitos.

Contribuições das Partes Interessadas - Quando as partes interessadas ou os usuários finais tentam dizer aos projetistas como o sistema deve funcionar, em vez do que o sistema deve fazer, isso pode levar a projetos abaixo do ideal. Para evitar isso, valide cada potencial 'requisito falso' perguntando 'por quê?' até chegar ao problema real que precisa ser resolvido.

Problemas de comunicação - Entre os problemas que podem levar à falta de comunicação entre um analista de negócios e outras partes estão as barreiras linguísticas, suposições erradas, vocabulário insuficientemente explicado e uso excessivo de termos técnicos.

A abordagem ideal para evitar esse problema é interagir com frequência e desenvolver conversas bidirecionais. Documente as necessidades que você descobriu e envie-as para revisão e crítica por pares a uma variedade de especialistas no assunto, crie um glossário de jargões e verifique novamente as premissas.

Erros comuns ao escrever requisitos

Escrever requisitos pode ser uma tarefa desafiadora, e erros comuns podem ser cometidos e podem afetar o sucesso do projeto de desenvolvimento de software. Aqui estão alguns erros comuns ao escrever requisitos:

1. Ambiguidade: Um dos erros mais comuns ao escrever requisitos é o uso de linguagem ambígua, que pode levar a mal-entendidos e erros. Isso pode ser evitado usando uma linguagem clara, concisa e inequívoca.
2. Requisitos incompletos ou inconsistentes: Requisitos incompletos ou inconsistentes podem levar a confusão e erros no processo de desenvolvimento de software. Isso pode ser evitado revisando e validando os requisitos para garantir que estejam completos e consistentes com outras documentações do projeto.
3. Falta de Priorização: Sem a devida priorização, os requisitos podem ser desenvolvidos de maneira aleatória, levando a atrasos e a um produto que não atende às expectativas do cliente. A priorização de requisitos pode garantir que os recursos e funcionalidades mais importantes sejam desenvolvidos primeiro.
4. Requisitos pouco claros ou não verificáveis: Requisitos pouco claros ou não verificáveis ​​podem levar a mal-entendidos e dificuldades na validação de que o sistema ou produto atende aos requisitos. Isso pode ser evitado garantindo que os requisitos sejam claros e verificáveis.
5. Folheado a ouro: Gold-plating ocorre quando recursos ou funcionalidades adicionais são adicionados ao sistema ou produto que não foram especificados nos requisitos. Isso pode levar a atrasos, custos adicionais e um produto que não atende às necessidades do cliente.
6. Falta de envolvimento das partes interessadas: A falta de envolvimento das partes interessadas pode levar a requisitos que não atendem às necessidades dos clientes e outras partes interessadas. Envolver as partes interessadas em todo o processo de desenvolvimento de software pode garantir que os requisitos estejam alinhados com suas necessidades e expectativas.
7. Excesso de confiança na tecnologia: A confiança excessiva na tecnologia pode levar a requisitos que não se alinham com os recursos do sistema ou produto que está sendo desenvolvido. Isso pode ser evitado garantindo que os requisitos sejam viáveis ​​e alinhados com a tecnologia que está sendo usada.
8. Falta de considerações de teste: O teste é um aspecto importante do desenvolvimento de software, e a falta de consideração pelo teste nos requisitos pode levar a um produto difícil de testar ou que não atenda aos padrões de qualidade.

Requisitos de redação usando métodos de linguagem natural

Escrever requisitos usando métodos de linguagem natural envolve o uso da linguagem cotidiana para comunicar os requisitos de maneira clara, concisa e fácil de entender. Essa abordagem é frequentemente usada no desenvolvimento de software e em outros setores em que há necessidade de capturar e documentar requisitos que sejam facilmente compreensíveis por todos os interessados, independentemente de seus conhecimentos técnicos.

Linguagem natural é a linguagem que usamos em nossa comunicação cotidiana, como inglês, francês, espanhol e assim por diante. Escrever requisitos usando linguagem natural envolve usar a mesma linguagem que as partes interessadas usam em sua comunicação diária, em vez de usar jargão técnico ou linguagem especializada que pode não ser familiar para as partes interessadas não técnicas.

Quando comparada a outras linguagens para requisitos de redação, a linguagem natural tem a vantagem de ser mais fácil de entender para as partes interessadas não técnicas. O uso de linguagem natural pode ajudar a garantir que os requisitos sejam comunicados de forma eficaz a todas as partes interessadas, levando a um resultado de projeto mais bem-sucedido. Por outro lado, outras linguagens para escrever requisitos, como linguagens de especificação formal, podem ser mais precisas e inequívocas, mas podem ser mais difíceis de entender para os interessados ​​não técnicos.

Para escrever requisitos usando métodos de linguagem natural, é importante usar uma linguagem simples e cotidiana que seja fácil de entender. Os requisitos devem ser específicos, mensuráveis ​​e verificáveis, e devem evitar o uso de termos vagos ou jargões técnicos. O uso de modelos, exemplos e visuais também pode ajudar a tornar os requisitos mais claros e concisos.

Modelo EARS

O modelo EARS (Easy Approach to Requirements Syntax) é um modelo de coleta e documentação de requisitos que fornece uma maneira estruturada de capturar e documentar requisitos. É comumente usado em setores como aeroespacial, defesa e desenvolvimento de software, onde há a necessidade de capturar e documentar requisitos complexos e frequentemente técnicos. O modelo EARS pode ser usado para requisitos funcionais e não funcionais.

O modelo EARS consiste em quatro seções principais:

1. Meio Ambiente: Esta seção descreve o contexto no qual o sistema irá operar, incluindo quaisquer restrições ou dependências que devem ser consideradas.
2. Ator: Esta seção descreve os diferentes tipos de usuários ou sistemas que irão interagir com o sistema, incluindo suas funções e responsabilidades.
3. Requisito: Esta seção descreve os requisitos específicos para o sistema, incluindo requisitos funcionais e não funcionais. Cada requisito é definido de forma clara e concisa usando uma sintaxe padronizada.
4. Estímulo: Esta seção descreve as entradas que acionarão o sistema para executar determinadas ações ou respostas e as saídas ou respostas esperadas.

Para usar o modelo EARS, o analista de requisitos ou equipe deve primeiro identificar o ambiente no qual o sistema irá operar, incluindo quaisquer restrições ou dependências. Em seguida, devem identificar os diferentes atores ou usuários que irão interagir com o sistema e suas funções e responsabilidades. Em seguida, devem identificar os requisitos específicos do sistema, utilizando a sintaxe padronizada definida no template. Por fim, eles devem identificar os estímulos que acionarão o sistema para executar determinadas ações ou respostas e as saídas ou respostas esperadas.

O modelo EARS foi projetado para fornecer uma maneira clara e concisa de documentar os requisitos, facilitando a compreensão e a verificação dos requisitos. É frequentemente usado em indústrias onde há necessidade de requisitos precisos e precisos, como aeroespacial, defesa e desenvolvimento de software. Ao usar o modelo EARS, os analistas de requisitos podem garantir que todos os requisitos relevantes sejam capturados e documentados de maneira consistente e estruturada.

Diretrizes INCOSE - Modelo

INCOSE, ou Conselho Internacional de Engenharia de Sistemas, é uma organização internacional sem fins lucrativos que fornece padrões e diretrizes para ajudar as organizações a criar melhores processos de engenharia de sistemas. O padrão de requisitos do sistema INCOSE (SRS) contém um conjunto de regras e padrões projetados para ajudar as organizações a avaliar as declarações de requisitos antes de serem implementadas. O SRS foi adotado por várias grandes corporações, bem como agências governamentais em todo o mundo e pode ser usado em muitos setores diferentes para várias aplicações. É importante que as partes interessadas, como desenvolvedores de software, analistas de negócios, gerentes de projeto, testadores, funcionários do departamento de TI e outros membros da equipe, tenham um forte entendimento desses requisitos antes de começar a trabalhar em qualquer projeto ou declaração de requisitos do sistema.

Em última análise, escrever bons requisitos envolve um equilíbrio cuidadoso entre ser detalhado e conciso, além de garantir que o requisito seja testável e viável. O INCOSE SRS oferece princípios e diretrizes para que as equipes possam escrever requisitos de boa qualidade e ajudar a garantir que seus projetos sejam bem-sucedidos. Isso ajudará a evitar erros dispendiosos durante o desenvolvimento ou após a implantação, ajudando assim as organizações a criar sistemas melhores em um período de tempo menor.

O que são as regras INCOSE?

As declarações de requisitos são avaliadas pelas regras do INCOSE. Esses padrões ajudam as organizações a avaliar a viabilidade e a qualidade dos requisitos antes de serem implementados. O processo de avaliação inclui quatro critérios principais:

• Claro - Os requisitos escritos devem ser claros, fáceis de ler e compreensíveis. Especifique claramente as informações usando frases afirmativas que serão trocadas entre os atores. Cada requisito deve descrever critérios de sucesso claros. Tente usar um vocabulário simples e evite abreviações. Por exemplo, “O usuário poderá visualizar o relatório de log de auditoria”.
• atômico - Cada requisito deve ser tratado como um caso de teste distinto. Conjunções como e, ou e assim por diante não devem ser usadas porque podem levar à omissão de requisitos. Isso é particularmente crucial, pois termos como esses podem fazer com que os desenvolvedores e testadores de software ignorem os requisitos. Dividir necessidades complicadas em partes menores até que cada uma possa ser testada separadamente é uma maneira de evitar que isso aconteça.
• Inequívoco - Requisitos pouco claros, incompletos ou contraditórios podem levar a erros e retrabalho. Para evitar que isso aconteça, os requisitos devem ser revisados ​​por todas as partes interessadas antes de serem finalizados. Isso ajudará a identificar quaisquer lacunas no início, que podem ser abordadas.
• Verificável - Todos na equipe de desenvolvimento devem ter acesso ao documento para que possam consultá-lo sempre que necessário. Como os requisitos devem ser claros, os membros da equipe não querem mais informações. Todos eles devem estar acessíveis no documento SRS.
• Necessário - Cada requisito deve documentar algo que os usuários realmente precisam ou algo que é necessário para atender a um padrão ou necessidade de integração devido à existência de uma interface externa. Além disso, é importante que cada requisito tenha uma fonte autorizada.
• Design Independente - Cada requisito deve definir o que é necessário, não como será implementado. Os requisitos devem definir as características do sistema que serão observadas externamente, não os detalhes internos.
• Viável - Cada requisito deve ser tecnicamente executável e deve ser implementado levando em consideração o orçamento, prazo e outras restrições que afetam o projeto. Os requisitos devem refletir a situação atual, incluindo custo, cronograma e tecnologia. Eles não devem depender de futuros avanços tecnológicos.
• Completo - O documento de requisitos deve incluir informações suficientes para que sua equipe de desenvolvimento e testadores concluam o produto e garantam que ele atenda aos requisitos do usuário sem erros.
• Correto - Os requisitos especificados nos documentos devem ser muito precisos para evitar qualquer tipo de confusão. Não devem conter brechas, ambiguidades, subjetividade, superlativos ou comparações. Portanto, para escrever requisitos corretos, devemos obter informações corretas e documentar corretamente as informações coletadas.

Tendências Futuras: Requisitos de Redação com IA

A tecnologia de Inteligência Artificial (IA) tem o potencial de revolucionar a forma como os requisitos são escritos e gerenciados no desenvolvimento de produtos. Nos últimos anos, houve avanços significativos no processamento de linguagem natural (NLP) e no aprendizado de máquina (ML) que tornaram possível automatizar certos aspectos da engenharia de requisitos.

Uma possível tendência futura é o uso de chatbots com inteligência artificial, como ChatGPT e Jasper, para auxiliar na redação de requisitos. Esses chatbots usam algoritmos de NLP para analisar a entrada das partes interessadas e gerar requisitos de alta qualidade com base nessa entrada. Aproveitando essas ferramentas, as organizações podem simplificar o processo de engenharia de requisitos, reduzindo o tempo e o esforço necessários para desenvolver requisitos, levando a ciclos de desenvolvimento de produto mais rápidos e uso mais eficiente de recursos.

Outra tendência potencial é o uso de IA para identificar e extrair automaticamente requisitos de várias fontes de dados não estruturados, como feedback de clientes, postagens em mídias sociais e análises de produtos. Ao usar algoritmos de NLP para identificar e extrair automaticamente os requisitos relevantes dessas fontes, as organizações podem obter uma compreensão mais profunda das necessidades e preferências do cliente, levando a resultados de desenvolvimento de produtos mais bem-sucedidos.

A tecnologia de IA também pode ajudar a melhorar a qualidade e a consistência dos requisitos, identificando possíveis conflitos, ambiguidades ou redundâncias nos requisitos. Isso pode ajudar a reduzir o risco de erros e mal-entendidos, levando a uma melhor qualidade do produto e a menos custosos ciclos de retrabalho.

Dicas essenciais para requisitos de redação

1. Escrever em Camadas – Escrever requisitos em camadas significa dividir requisitos complexos em partes menores e mais gerenciáveis. Isso ajuda a tornar os requisitos mais compreensíveis, abrangentes e fáceis de implementar.
2. Um por vez - Cada requisito deve ser tratado como um caso de teste distinto. Conjunções como e, ou e assim por diante não devem ser usadas porque podem levar à omissão de requisitos. Isso é particularmente crucial, pois termos como esses podem fazer com que os desenvolvedores e testadores de software ignorem os requisitos. Dividir necessidades complicadas em partes menores até que cada uma possa ser testada separadamente é uma maneira de evitar que isso aconteça.
3. Fale “o quê” e não “como” – O foco deve estar no que o sistema fará, não em como ele faz. Além disso, evite se aprofundar demais em tópicos de design, como nomes de campo, objetos de linguagem de programação e objetos de software. Se você estiver discutindo esses tópicos no Documento de Especificação de Requisitos, dê um passo para trás – isso provavelmente significa que você está sendo muito específico.
4. Verificável - Outra coisa a ter em mente ao organizar os requisitos é que eles sempre devem ser testáveis. Isso significa que precisa ser possível verificar se o sistema atende ao requisito em questão. Isso também está vinculado ao nosso próximo ponto – rastreabilidade. Se um requisito estiver cheio de termos vagos, fica mais difícil analisar e verificar se o sistema realmente atende a esses padrões em termos de desempenho. Portanto, tanto quanto possível, busque clareza e precisão em sua linguagem para que a coleta de requisitos não seja um processo ambíguo.
5. Rastreabilidade – A rastreabilidade no gerenciamento de projetos refere-se à garantia de que os requisitos estão vinculados a outros componentes do projeto. Isso permite que gerentes de projeto, desenvolvedores e partes interessadas acompanhem todo o ciclo de vida de um requisito do começo ao fim em todas as direções, bem como com outras partes do sistema. Se você gerenciar a rastreabilidade adequadamente, poderá evitar código que não corresponda a nenhum requisito (código 'disperso') e garantir que cada caso de teste cubra pelo menos um requisito. Você pode tornar os requisitos rastreáveis ​​rotulando-os com um identificador exclusivo e fornecendo informações sobre sua origem em um repositório central acessível a todos os membros da equipe.
6. Os 3 Ws – Os requisitos devem se concentrar em atender às necessidades do usuário e não na solução. Portanto, é essencial entender os requisitos e pontos problemáticos do usuário antes de desenvolver os requisitos.
   1. O que? - O que estamos fazendo?
   2. Quem? – Quem será beneficiado?
   3. Por que? – Por que estamos fazendo isso?
7. 1 Requisito para 1 Tarefa - Cada requisito deve indicar uma única ação e objetivo. Cuidado com o uso excessivo de “e” e “ou”. Por exemplo, “Se a última sexta-feira do mês e o pagamento vencer no dia 31, e se o dia 31 for a última sexta-feira do mês, enviar o pagamento nesse dia após as 6h, horário do leste, resultará em atraso no pagamento ”. Eu desafio você a entender isso!
8. Priorizar Requisitos – Priorize os requisitos com base em sua importância e impacto no sucesso do projeto. Isso ajuda a garantir que os requisitos mais importantes sejam entregues primeiro e que as necessidades das partes interessadas sejam atendidas.
9. Cláusula Sem Escape – Por exemplo, “O sistema deve determinar o número de tentativas de login, exceto quando o usuário digitou claramente um nome de usuário incorreto”.

De acordo com Jordan, o que separa os projetos bem-sucedidos dos malsucedidos?

De acordo com Jordan Kyriakidis, o que separa os projetos bem-sucedidos dos malsucedidos é a capacidade de gerenciar os requisitos com eficiência. Projetos bem-sucedidos têm um entendimento claro dos requisitos e são capazes de gerenciá-los durante todo o processo de desenvolvimento, desde o planejamento inicial até a entrega final. Por outro lado, projetos malsucedidos geralmente sofrem de gerenciamento de requisitos inadequado, o que pode levar a falhas de comunicação, atrasos e, por fim, falha no cumprimento das metas do projeto. Portanto, é crucial que as empresas invistam em práticas e ferramentas robustas de engenharia de requisitos para garantir o sucesso de seus projetos.

Onde encontrar mais sobre Jordan Kyriakidis?

Para saber mais sobre Jordan Kyriakidis e QRA Corp, confira a página do LinkedIn em https://www.linkedin.com/company/qra-corp/. Além disso, você pode encontrar Jordan Kyriakidis no LinkedIn em https://www.linkedin.com/in/jordankyriakidis/. A QRA Corp também tem vários whitepapers e estudos de caso disponíveis em seu site que fornecem insights sobre sua tecnologia e sua aplicação em vários setores.

Considerações Finais

Concluindo, Jordan Kyriakidis e a Visure Solutions compartilharam uma conversa esclarecedora sobre requisitos de redação. Exploramos a importância de escrever ótimos requisitos e abordamos os desafios ao escrever requisitos junto com os erros comuns. Examinamos diferentes métodos, como métodos de linguagem natural, modelo EARS e diretrizes INCOSE. A tecnologia AI também abriu muitas possibilidades para escrever requisitos, tornando mais fácil para as pessoas que estão começando a aprender a escrevê-los melhor. Por fim, também incluímos dicas importantes para ajudá-lo ao longo do caminho ao embarcar nessa jornada. Desde aprender sobre as regras da INCOSE até as tendências futuras nos requisitos de redação - há algo aqui para todos! Tire essas dicas essenciais e coloque-as em prática agora! Confira agora a entrevista completa!