Requisitos de software

O que é?

• Segundo o IEEE
  • 1-Uma condição ou uma capacidade de que o usuário necessita, para solucionar um problema ou alcançar um objetivo.
  • 2-Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente.
  • 3- Uma representação documentada de uma condição ou capacidade

Tipos

• Requisito do usuário-Declarações, em língua natural e/ou diagramas, sobre as funções que o sistema deve fornecer e restrições sob as quais deve operar, são requisitos abstratos de alto nível.
• Requisitos do sistema-Funções e restrições do sistema, de uma forma mais detalhada. Normalmente classificados como funcionais e não funcionais.

Estudo

O processo de requisição de software é composto por 6 partes principais:

• Viabilidade;
• Identificação;
• Análise;
• Especificação e documentação;
• Validação;
• Gestão dos requisitos;

Viabilidade

O estudo da viabilidade permite que se decida se vale a pena ou não. Deve-se verificar se:

• O sistema contribui para os objetivos organizacionais.
• O sistema pode ser construído com a tecnologia corrente e com o orçamento disponível.
• O sistema pode ser integrado com os outros sistemas em utilização
• O sistema pode ajudar na solução

Identificação

O passo seguinte a validação da viabilidade do projeto é a identificação dos requisitos.

Objetivo dos requisitos

• Definir as técnicas de coleta de requisitos baseada em fatores operacionais, táticos e financeiros;
• Identificar os documentos e procedimentos que definem as politicas de negócios ;
• Definir as fronteiras do sistema;
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema;
• Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários;

Análise

Análise de requisitos pode ser um processo longo e árduo. Novos sistemas mudam o ambiente e a relação entre as pessoas, então é importante identificar todos os envolvidos, levando em conta todas as suas necessidades e assegurando que eles compreenderam as implicações dos novos sistemas. Os analistas podem empregar várias técnicas para elicitar os requisitos dos clientes. A análise é a etapa seguinte a identificação dos requisitos, inclui atividades como :

• Classificação;
• Resolução de conflitos;
• Priorização;
• Confirmação;

Classificação

A classificação dos requisitos é de extrema importância para a definição de prioridades, para a separação por níveis de importância, riscos, custos, etc e para validação por diferentes pessoas envolvidas. Podendo assim fazer um agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para o sistema.

Resolução de conflitos

Dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível;

• Priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um fator gerador de conflitos;
• Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema).

Priorização

O conhecimento sobre a Priorização de Requisitos ajudará a focar o processo de desenvolvimento e a uma maior eficiência e competência na gerência de projetos. Priorizando a análise de Requisitos poderemos ter vantagens como :

• Seleção informal de processos
• Não utilização de técnicas
• Não conhecimento da importância dos requisitos
• Custos e dificuldades técnicas associadas
• Determinar o grau de importância de cada requisito para o cliente
• Os requisitos mais críticos deverão ser implementados primeiro
• Identificar requisitos conflitantes
• Planejar revisões sucessivas do produto

Podemos citar diversos tipos de métodos e técnicas de Priorização de Requisitos, dos quais destacamos :

• QFD - Quality Function Deployment-introduzido no Japão por Yoji Akao em 1966,É uma forma de assegurar a qualidade do projeto, enquanto o produto está na fase de planejamento e quando apropriadamente aplicado o QFD demonstra uma redução do tempo de desenvolvimento de 1/2 para 1/3.
• AHP - Analytic Hierarchy Process- Desenvolvido por T. L. Saaty em 19, o AHP é baseado no domínio da hierarquização, onde o problema é decomposto em níveis hierárquicos

Especificação e documentação

Especificações dos requisitos de sistema

É nesta fase que sa a e dá a produção propriamente dita do documento de especificação de requisitos. tendo como normas e padrões :ANSI/IEEE STD 830-1993 e a – MIL-STD-2167A e MIL-STD-498 Em todos os tipos de especificação há 2 tipos de requisitos a considerar:

• Funcionais

Os requisitos funcionais são aqueles que fazem parte do sistema, como um relatório específico, um campo a mais em um cadastro, etc. Eles normalmente têm a finalidade de agregar valor ao usuário ou facilitar o trabalho que ele desenvolve. Requisitos funcionais serão implementados no próprio sistema e da junção desses requisitos o corpo do sistema será montado.

• Não funcionais

Requisitos não-funcionais são aqueles relacionados ao ambiente onde o sistema está inserido. Um servidor mais robusto, um firewall, ou um usuário especializado em determinado procedimento pode ser visto como requisitos não-funcionais. Eles não devem ser ignorados por não fazerem parte diretamente do sistemas, mas devem ser considerados por compor o ambiente onde o software irá rodar.

Podem-se distinguir três tipos de especificação:

especificação de requisitos do usuário ou utilizador;

especificação de requisitos do sistema;

especificação do design da aplicação.

A vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando "linguagens" que o utilizador conheça).Por exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de alto nível das funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas (esquemas), nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitos relativos à arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notações gráficos como diagramas de casos de uso).

Documento de Especificação de Requisitos

O resultado final da análise e especificação de requisitos e das outras atividades da fase de definção devem ser apresentados aos clientes para que eles possam validá-lo. Este documento oferece a concordância entre clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. É utilizando este documento que as atividades da fase de desenvolvimento (design e programação) serão validadas. Apesar da existência dos 3 tipos de especificação vistos nos itens anteriores, existe uma especificação que é a usada como declaração oficial dos requisitos do sistema. Este documento, normalmente chamado de Documento de Especificação de Requisitos (Software Requirements Specification ou SRS) inclui uma combinação dos requisitos do utilizador e do sistema e tem diferentes utilidades para diferentes pessoas (Kotonya e Sommerville, 1998): Clientes: confirmar a completude dos requisitos e propor alterações. Gestores: orçamentar o sistema e planejar o processo de desenvolvimento. Engenheiros: compreender o sistema a desenvolver. Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos. Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes.

Validação

Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende. A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído

Gestão dos requisitos

É o processo de compreender e controlar as mudanças nos requisitos do software, quando há alteração no software e depois nos requisitos faz com que a especificação e implementação se desajustem.Para manter a consistência entre as várias alterações pedidas, é importante que o processo de gestão de mudanças esteja definido de um modo formal, sendo que deverá incluir as seguintes três fases:

• Análise do problema e especificação da alteração a fazer: identificação do problema existente nos requisitos originais e proposta de alteração a fazer aos requisitos do sistema.
• Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas previamente, avaliação do impacto da alteração no sistema.
• Implementação da alteração: alteração no documento de requisitos e, conforme seja necessário, no design e implementação.

Bibliografia

• Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares. 2005.
• http://pt.wikipedia.org/wiki/Engenharia_de_requisitos
• http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula04.pdf
• http://sylverio.com.br/blog/2009/05/requisitos-de-software/
• http://www.dimap.ufrn.br/~jair/ES/c4.html
• http://www.ic.unicamp.br/~ariadne/mc436/1s2014/modulo2.pdf
• http://www.luis.blog.br/levantamento-analise-requisitos-funcionais-nao-funcionais.aspx
• http://analiserequisitos.blogspot.com.br/2011/05/importancia-da-classificacao-de.html