Requisitos de software

Os requisitos de software são a descrição dos recursos e funcionalidades do sistema de destino. Os requisitos transmitem as expectativas dos usuários do produto de software. Os requisitos podem ser óbvios ou ocultos, conhecidos ou desconhecidos, esperados ou inesperados do ponto de vista do cliente.

Engenharia de Requisitos

O processo de reunir os requisitos de software do cliente, analisá-los e documentá-los é conhecido como engenharia de requisitos.

O objetivo da engenharia de requisitos é desenvolver e manter um documento sofisticado e descritivo de 'Especificação de Requisitos do Sistema'.

Processo de Engenharia de Requisitos

É um processo de quatro etapas, que inclui -

Estudo de viabilidade
Recolha de requisitos
Especificação de Requisitos de Software
Validação de Requisitos de Software

Vamos ver o processo brevemente -

Estudo de viabilidade

Quando o cliente se aproxima da organização para desenvolver o produto desejado, ele tem uma ideia geral sobre quais funções o software deve executar e quais recursos são esperados do software.

Com base nessas informações, o analista faz um estudo detalhado sobre se o sistema desejado e sua funcionalidade são viáveis de desenvolver.

Este estudo de viabilidade é voltado para o objetivo da organização. Este estudo analisa se o produto de software pode ser materializado na prática em termos de implementação, contribuição do projeto para a organização, restrições de custos e de acordo com os valores e objetivos da organização. Ele explora aspectos técnicos do projeto e do produto, como usabilidade, facilidade de manutenção, produtividade e capacidade de integração.

O resultado desta fase deve ser um relatório de estudo de viabilidade que deve conter comentários e recomendações adequados para a gerência sobre se o projeto deve ou não ser realizado.

Recolha de requisitos

Se o relatório de viabilidade for positivo para a realização do projeto, a próxima fase começa com a coleta de requisitos do usuário. Analistas e engenheiros se comunicam com o cliente e os usuários finais para saber suas idéias sobre o que o software deve fornecer e quais recursos eles desejam que o software inclua.

Especificação de Requisitos de Software

SRS é um documento criado pelo analista de sistema depois que os requisitos são coletados de várias partes interessadas.

SRS define como o software pretendido irá interagir com o hardware, interfaces externas, velocidade de operação, tempo de resposta do sistema, portabilidade do software em várias plataformas, capacidade de manutenção, velocidade de recuperação após travamento, Segurança, Qualidade, Limitações, etc.

Os requisitos recebidos do cliente são escritos em linguagem natural. É responsabilidade do analista de sistema documentar os requisitos em linguagem técnica para que possam ser compreendidos e úteis pela equipe de desenvolvimento de software.

O SRS deve apresentar os seguintes recursos:

Os requisitos do usuário são expressos em linguagem natural.
Os requisitos técnicos são expressos em linguagem estruturada, que é usada dentro da organização.
A descrição do projeto deve ser escrita em pseudo código.
Formato de formulários e impressões de tela da GUI.
Notações condicionais e matemáticas para DFDs etc.

Validação de Requisitos de Software

Depois que as especificações dos requisitos são desenvolvidas, os requisitos mencionados neste documento são validados. O usuário pode solicitar uma solução ilegal e impraticável ou os especialistas podem interpretar os requisitos incorretamente. Isso resulta em um grande aumento no custo, se não for cortado pela raiz. Os requisitos podem ser verificados de acordo com as seguintes condições -

Se eles podem ser implementados de forma prática
Se eles são válidos e de acordo com a funcionalidade e domínio do software
Se houver alguma ambigüidade
Se eles estão completos
Se eles podem ser demonstrados

Processo de Elicitação de Requisito

O processo de elicitação de requisitos pode ser descrito usando o diagrama a seguir:

Requirements gathering - Os desenvolvedores discutem com o cliente e usuários finais e conhecem suas expectativas em relação ao software.
Organizing Requirements - Os desenvolvedores priorizam e organizam os requisitos em ordem de importância, urgência e conveniência.
Negotiation & discussion - Se os requisitos forem ambíguos ou houver alguns conflitos nos requisitos de várias partes interessadas, se forem, isso será negociado e discutido com as partes interessadas. Os requisitos podem ser priorizados e razoavelmente comprometidos.

Os requisitos vêm de várias partes interessadas. Para remover a ambigüidade e os conflitos, eles são discutidos para fins de clareza e correção. Requisitos irrealistas são comprometidos razoavelmente.
Documentation - Todos os requisitos formais e informais, funcionais e não funcionais são documentados e disponibilizados para o processamento da próxima fase.

Técnicas de Elicitação de Requisitos

Elicitação de requisitos é o processo para descobrir os requisitos para um sistema de software pretendido, comunicando-se com o cliente, usuários finais, usuários do sistema e outros que tenham interesse no desenvolvimento do sistema de software.

Existem várias maneiras de descobrir os requisitos

Entrevistas

As entrevistas são um meio forte para coletar os requisitos. A organização pode realizar vários tipos de entrevistas, como:

Entrevistas estruturadas (fechadas), onde todas as informações a serem coletadas são decididas com antecedência, elas seguem o padrão e o assunto de discussão firmemente.
Entrevistas não estruturadas (abertas), onde as informações a serem coletadas não são decididas com antecedência, mais flexíveis e menos tendenciosas.
Entrevistas orais
Entrevistas escritas
Entrevistas individuais realizadas entre duas pessoas do outro lado da mesa.
Entrevistas em grupo que são realizadas entre grupos de participantes. Eles ajudam a descobrir qualquer requisito ausente, pois várias pessoas estão envolvidas.

pesquisas

A organização pode conduzir pesquisas entre várias partes interessadas, questionando sobre suas expectativas e requisitos do sistema que está por vir.

Questionários

Um documento com um conjunto predefinido de questões objetivas e respetivas opções é entregue a todos os stakeholders para resposta, as quais são recolhidas e compiladas.

Uma deficiência dessa técnica é que, se uma opção para algum problema não for mencionada no questionário, o problema pode ser deixado de lado.

Análise de tarefas

A equipe de engenheiros e desenvolvedores pode analisar a operação para a qual o novo sistema é necessário. Caso o cliente já possua algum software para realizar determinada operação, ele é estudado e os requisitos do sistema proposto são coletados.

Análise de Domínio

Todo software se enquadra em alguma categoria de domínio. Os especialistas no domínio podem ser de grande ajuda na análise de requisitos gerais e específicos.

Debate

Um debate informal é realizado entre várias partes interessadas e todas as suas entradas são registradas para posterior análise de requisitos.

Prototipagem

A prototipagem é a construção da interface do usuário sem adicionar funcionalidade de detalhes para o usuário interpretar os recursos do produto de software pretendido. Ajuda a dar uma ideia melhor dos requisitos. Se não houver software instalado na extremidade do cliente para referência do desenvolvedor e o cliente não estiver ciente de seus próprios requisitos, o desenvolvedor cria um protótipo com base nos requisitos inicialmente mencionados. O protótipo é mostrado ao cliente e o feedback é anotado. O feedback do cliente serve como uma entrada para a coleta de requisitos.

Observação

Equipe de especialistas visita a organização ou local de trabalho do cliente. Eles observam o funcionamento real dos sistemas instalados existentes. Eles observam o fluxo de trabalho no final do cliente e como os problemas de execução são tratados. A própria equipe tira algumas conclusões que ajudam a formar os requisitos esperados do software.

Características de Requisitos de Software

Reunir os requisitos de software é a base de todo o projeto de desenvolvimento de software. Portanto, devem ser claros, corretos e bem definidos.

As especificações completas dos requisitos de software devem ser:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Fonte confiável

Requisitos de software

Devemos tentar entender que tipo de requisitos podem surgir na fase de elicitação de requisitos e que tipos de requisitos são esperados do sistema de software.

Em termos gerais, os requisitos de software devem ser categorizados em duas categorias:

Requisitos funcionais

Requisitos, que estão relacionados ao aspecto funcional do software, se enquadram nesta categoria.

Eles definem funções e funcionalidades dentro e a partir do sistema de software.

Exemplos -

Opção de pesquisa dada ao usuário para pesquisar a partir de várias faturas.
O usuário deve ser capaz de enviar qualquer relatório para a gerência.
Os usuários podem ser divididos em grupos e os grupos podem receber direitos separados.
Deve cumprir as regras de negócios e funções administrativas.
O software é desenvolvido mantendo a compatibilidade com versões anteriores intacta.

Requisitos não Funcionais

Os requisitos, que não estão relacionados ao aspecto funcional do software, se enquadram nesta categoria. Eles são características implícitas ou esperadas do software, que os usuários fazem suposições.

Os requisitos não funcionais incluem -

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Recuperação de desastre
Accessibility

Os requisitos são categorizados logicamente como

Must Have : O software não pode ser dito operacional sem eles.
Should have : Aprimorando a funcionalidade do software.
Could have : O software ainda pode funcionar adequadamente com esses requisitos.
Wish list : Esses requisitos não correspondem a nenhum objetivo do software.

Ao desenvolver software, 'Deve ter' deve ser implementado, 'Deve ter' é uma questão de debate com as partes interessadas e negação, enquanto 'poderia ter' e 'lista de desejos' podem ser mantidos para atualizações de software.

Requisitos de interface do usuário

A IU é uma parte importante de qualquer software ou hardware ou sistema híbrido. Um software é amplamente aceito se for -

fácil de operar
resposta rápida
lidar eficazmente com erros operacionais
fornecendo interface de usuário simples, mas consistente

A aceitação do usuário depende principalmente de como o usuário pode usar o software. A IU é a única maneira de os usuários perceberem o sistema. Um sistema de software com bom desempenho também deve ser equipado com uma interface de usuário atraente, clara, consistente e responsiva. Caso contrário, as funcionalidades do sistema de software não podem ser utilizadas de forma conveniente. Um sistema é considerado bom se fornecer meios de usá-lo com eficiência. Os requisitos de interface do usuário são brevemente mencionados abaixo -

Apresentação de conteúdo
Navegação Fácil
Interface simples
Responsive
Elementos de IU consistentes
Mecanismo de retorno
Configurações padrão
Layout proposital
Uso estratégico de cor e textura.
Forneça informações de ajuda
Abordagem centrada no usuário
Configurações de visualização baseadas em grupo.

Analista de Sistema de Software

O analista de sistema em uma organização de TI é uma pessoa que analisa os requisitos do sistema proposto e garante que os requisitos sejam concebidos e documentados de forma adequada e correta. A função de um analista começa durante a fase de análise de software do SDLC. É responsabilidade do analista garantir que o software desenvolvido atenda aos requisitos do cliente.

Os analistas de sistema têm as seguintes responsabilidades:

Analisar e compreender os requisitos do software pretendido
Compreender como o projeto contribuirá nos objetivos da organização
Identifique as fontes de requisitos
Validação de requisito
Desenvolver e implementar plano de gerenciamento de requisitos
Documentação de requisitos comerciais, técnicos, de processo e de produto
Coordenação com clientes para priorizar os requisitos e remover a ambigüidade
Finalizando os critérios de aceitação com o cliente e outras partes interessadas

Métricas e medidas de software

Medidas de software podem ser entendidas como um processo de quantificar e simbolizar vários atributos e aspectos do software.

Software Metrics fornece medidas para vários aspectos do processo de software e do produto de software.

Medidas de software são requisitos fundamentais da engenharia de software. Eles não apenas ajudam a controlar o processo de desenvolvimento de software, mas também ajudam a manter a qualidade do produto final excelente.

De acordo com Tom DeMarco, um (Engenheiro de Software), “Você não pode controlar o que não pode medir.” Com suas palavras, é muito claro o quão importantes são as medidas de software.

Vamos ver algumas métricas de software:

Size Metrics - LOC (linhas de código), principalmente calculado em milhares de linhas de código-fonte entregues, denotado como KLOC.

A contagem de pontos de função é a medida da funcionalidade fornecida pelo software. A contagem de pontos de função define o tamanho do aspecto funcional do software.
Complexity Metrics - A complexidade ciclomática de McCabe quantifica o limite superior do número de caminhos independentes em um programa, que é percebido como complexidade do programa ou de seus módulos. É representado em termos de conceitos de teoria dos grafos usando o gráfico de fluxo de controle.
Quality Metrics - Defeitos, seus tipos e causas, consequência, intensidade de gravidade e suas implicações definem a qualidade do produto.

O número de defeitos encontrados no processo de desenvolvimento e o número de defeitos relatados pelo cliente após a instalação ou entrega do produto no cliente definem a qualidade do produto.
Process Metrics - Em várias fases do SDLC, os métodos e ferramentas usados, os padrões da empresa e o desempenho de desenvolvimento são métricas de processo de software.
Resource Metrics - Esforço, tempo e vários recursos usados representam métricas para medição de recursos.