Por que os requisitos são importantes na engenharia de software?

Neste artigo, examinamos a importância dos requisitos no desenvolvimento de software e os motivos pelos quais negligenciar o estágio de requisitos não é uma ideia inteligente ao construir um aplicativo.

“ Software de trabalho sobre documentação abrangente. ” Esta é uma parte do Manifesto Ágil.

Superficialmente, esta declaração pode parecer implicar que os requisitos são inconseqüentes e não são dignos do tempo. Alguns desenvolvedores e seus clientes renunciam à documentação adequada. Mas isso é um erro.

Vamos começar com uma pequena explicação de quais são os requisitos em termos de desenvolvimento de software.

Quais são os requisitos no desenvolvimento de aplicativos?

Não é como se a definição de requisitos mudasse significativamente quando aplicada ao desenvolvimento de software. Os requisitos simplesmente especificam quais recursos um produto deve incluir e como esses recursos devem funcionar. Como você os aborda é o que importa.

Coletar e analisar requisitos é um dos estágios iniciais do processo de desenvolvimento de software nas metodologias Agile e Waterfall. Durante a fase de requisitos do estágio de validação da ideia, um acordo deve ser alcançado entre o cliente e o desenvolvedor sobre o que exatamente o produto final deve fazer e como. Os requisitos no desenvolvimento de aplicativos geralmente são bem detalhados.

Como definir requisitos de software

Pode haver vários tipos de requisitos no desenvolvimento de software.

Requisitos de negócio

Por que o cliente precisa do aplicativo? À primeira vista, essas informações podem parecer desnecessárias ou mesmo redundantes. Afinal, você tem um cliente que deseja pagar para construir um aplicativo. Por que você deveria se preocupar com os motivos deles?

Bem, se você se orgulha do que faz e se esforça para construir produtos de qualidade, deve se preocupar com os porquês tanto quanto se preocupa com o que e como.

A importância dos requisitos de negócios é que eles fornecem uma visão do objetivo final. Com o objetivo em vista, os desenvolvedores podem definir prioridades. Eles também podem aplicar seus conhecimentos para oferecer as melhores soluções para atingir esses objetivos. Há uma razão pela qual a análise de negócios é incluída no processo de desenvolvimento na maioria das empresas.

Sem requisitos de negócios claros, decisões ruins podem ser tomadas. Decisões que retardarão o desenvolvimento, interromperão os prazos e resultarão em estágios de desenvolvimento adicionais.

Requisitos de software

Existem dois tipos de requisitos: funcionais e não funcionais. Em termos simples, a distinção é a seguinte:

Requisitos funcionais são quais requisitos - O que este sistema foi projetado para fazer? Como o nome sugere, eles descrevem a funcionalidade do software.

Requisitos não funcionais são os requisitos de como - Como este sistema fará o que foi projetado para fazer? Esses requisitos descrevem como cada recurso deve se comportar sob quais condições, quais limitações devem existir e assim por diante.

Os dois vão de mãos dadas. Os requisitos não funcionais complementam e definem os requisitos funcionais. Por exemplo, vamos imaginar que estamos fazendo um aplicativo de mensagens.

Os principais requisitos funcionais, neste caso, seriam:

1. O aplicativo deve ser capaz de enviar mensagens.
2. O aplicativo deve suportar transferência de arquivos e mídia.
3. Etc.

Eles são bem diretos e fáceis de entender por que os requisitos funcionais são importantes: eles descrevem a funcionalidade. Neste exemplo, o os requisitos não funcionais podem ser os seguintes :

1. O serviço deve oferecer funcionalidade total em todos os principais navegadores: Microsoft Edge, Google Chrome (duas versões mais recentes), Mozilla Firefox (duas versões mais recentes), Opera, Safari (duas versões mais recentes).
2. Layouts móveis devem ser suportados.
3. Etc.

Como você pode ver, requisitos funcionais são basicamente uma lista de funcionalidades que devem ser incluídas no sistema . Por outro lado, os requisitos não funcionais são específicos. Eles são necessários para definir as condições de desenvolvimento e teste.

É verdade que o processo ágil iterativo envolve a possibilidade de introduzir mudanças em qualquer estágio de desenvolvimento , mas isso não implica em requisitos anteriores completamente. Você só precisa torná-los flexíveis.

Sem parâmetros precisos especificados, é impossível entender se um recurso foi projetado exatamente como deveria ser.

Os requisitos devem ser cuidadosamente analisados ​​e documentados. Porque? Porque muitas coisas podem dar errado se não forem.

A espada de Dâmocles dos requisitos não documentados

A importância dos requisitos de software é melhor compreendida por especialistas em garantia de qualidade. Quando os requisitos do projeto não são definidos corretamente, os QAs recebem o maior golpe. Imagine tentar determinar se o software é implementado corretamente sem diretrizes claras sobre o que deve ser feito e como deve ser feito. É uma loucura total.

No entanto, esse problema não afeta apenas os testadores. Não ter especificações oficiais significa o seguinte:

• Não há um entendimento claro sobre o que constitui um produto acabado ou mesmo um recurso.
• O cliente não sabe o que esperar ao final do desenvolvimento e quanto está pagando.
• Os desenvolvedores são deixados de lado, tendo que descobrir as especificações dos recursos com base no que foi dito e como eles próprios o compreenderam.
• Insetos. Eles estão por toda parte.

Requisitos não documentados levam a falhas de comunicação em todos os lados. Não é raro que um cliente e um desenvolvedor entendam os mesmos termos de maneira diferente. Especialmente se estivermos falando de uma empresa de desenvolvimento de terceirização que não está intimamente familiarizada com o negócio do cliente.

A falta de comunicação, por sua vez, estabelece um caminho direto para constantes retrabalhos, mudanças e correções de bugs. Há uma chance de que tudo corra conforme planejado sem requisitos documentados, mas é escasso. Normalmente, essa cadeia termina com prazos interrompidos e custos que disparam.

Para garantir um desenvolvimento tranquilo do projeto, todas as partes do produto e o processo de seu desenvolvimento devem ser compreendidos por todos os membros da equipe da mesma maneira. Para garantir que os desenvolvedores vejam cada recurso do produto exatamente como o cliente, uma especificação de requisitos de software (SRS) é feita.

O diabo está nos detalhes: o que constitui uma boa especificação de requisitos de software?

Agora, as especificações reais dos requisitos de software podem ser excepcionalmente detalhadas ou podem ser apenas um esboço dos recursos. O nível de detalhe depende de vários fatores.

Requisitos de alta qualidade são facilmente compreendidos por todos os envolvidos no projeto. Isso inclui o cliente, que pode ou não ser bem versado em aspectos técnicos. Algumas empresas exigem uma lista de requisitos excepcionalmente técnica e cheia de detalhes, enquanto outras preferem requisitos em termos leigos.

Independentemente de como sua documentação será preenchida com tecnologia, existem regras gerais para gerenciar os requisitos de software. Existe até um padrão oficial: IEEE Std 830-1998, “Prática Recomendada para Especificações de Requisitos de Software”. Aqui está o que um bom SRS deve ser, de acordo com o padrão:

• Correto . Este é fácil. A exatidão do SRS é verificada pelo cliente e desenvolvedor com base no acordo que eles têm. A SRS deve estar em conformidade com as especificações técnicas e todas as outras documentações que regem o projeto.

• Não ambíguo . Um dos principais objetivos de um SRS é eliminar falhas de comunicação. É por isso que toda especificação de requisito deve ser escrita para ter apenas uma interpretação possível. Não é incomum que um SRS inclua um glossário.

• Completo . Quanto mais complexo o aplicativo, mais detalhado o SRS precisa ser. Um SRS completo cobre todos os lados, desde os requisitos de desempenho até a funcionalidade. Ele também define certos limites para o design. No entanto, ele nunca especifica um design exato. Ele apenas oferece parâmetros.

• Consistente . Consistência interna significa que nenhuma declaração em uma SRS contradiz outras declarações na mesma SRS. Este é outro motivo para incluir um glossário - de forma que qualquer objeto, processo e especificação dentro do documento seja designado com um termo preciso.

• Classificado por importância e / ou estabilidade . Na maioria dos casos, existem requisitos obrigatórios e requisitos semelhantes. É importante que as especificações dos requisitos de software identifiquem claramente os dois tipos. Isso ajudará os desenvolvedores e gerentes de projeto a criar um plano passo a passo para o projeto.

• Verificável . Deve haver uma maneira de testar cada requisito incluído no SRS. Para serem considerados verificáveis, os requisitos devem conter conceitos mensuráveis ​​e concretos.

• Modificável . Isso se refere à estrutura SRS. Para não interromper o fluxo de trabalho do projeto quando você precisar implementar mudanças, o SRS precisa ser claro e fácil de mudar, e os requisitos não devem ser repetidos.

• Rastreável . Deve ser fácil identificar a origem de cada requisito estabelecido na SRS.

Estas são recomendações . Na realidade, as empresas podem prescindir de alguns desses pontos dependendo do projeto, do cliente e da equipe. Mas é sempre bom ter alguma orientação.

Os requisitos são úteis se você é especializado em desenvolvimento de aplicativos iOS e Android ou desenvolvimento web. Eles são documentação de uso geral. E sua aparência geralmente depende dos desenvolvedores e de seus clientes.

Uma vez que um SRS deve ser fácil de entender para todas as partes envolvidas, a melhor maneira de projetá-los também é discutível. Alguns preferem tabelas, alguns preferem listas. Existem desenvolvedores que preferem suas especificações na forma visual, como diagramas e gráficos de fluxo de dados. Não há uma maneira certa de fazer um documento de especificação de requisitos.

Conclusão

Aqui estão os pontos mais comuns quando os requisitos de software são úteis:

• Entendendo a meta
• Estimando custos de desenvolvimento
• Criação de uma programação abrangente
• Definindo prioridades

Documentar os requisitos é algo que cada desenvolvedor decide por si. E o valor dos requisitos varia dependendo da escala do projeto. Na Mind Studios, preferimos ter as coisas em ordem, por isso documentamos todos os requisitos . Se você estiver interessado em como fazemos isso ou tiver dúvidas sobre o valor dos requisitos em geral, entre em contato conosco por meio de nosso formulário de contato .