Requisitos de software

Esta pesquisa foi realizada por alunos de turmas anteriores e não foi revisada, portanto
sua missão é revisar com cuidado e alterar/complementar este post sempre anotando as 
referëncias (fontes) na parte inferior. Náo se esqueça de que não deve ser um Copy/Paste
e sim uma síntese das pesquisas que fizer.

O que é?

É o detalhamento de todas as propriedades, restrições e funcionalidades, que um software deve ter para suprir e manter o que lhe foi requerido. Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projeto, determinam se este é ou não viável. 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

A interação entre os envolvidos no projeto deve sanar perguntas como:

• O sistema contribui para os objetivos da organização?
• Dadas as restrições tecnológicas, organizacionais e temporais associadas ao projeto, será que o sistema pode ser implementado?
• É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)? Com que facilidade é que se consegue partilhar informação entre estes sistemas?

A partir da análise dos dados extraídos, avalia-se a continuidade do projeto de maneira consciente quanto as restrições e os requisitos.

Identificação

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

Objetivo dos requisitos

• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer;
• Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema;
• 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

A análise é a etapa seguinte a identificação dos requisitos, inclui atividades como:

• Classificação: 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).

Especificação e documentação

Especificações dos requisitos de sistema

É nesta fase que se dá a produção propriamente dita do documento de especificação de requisitos. Em todos os tipos de especificação há 2 tipos de requisitos a considerar:

Funcionais

• Descrevem a funcionalidade ou os serviços do sistema.
• Dependem do tipo de software, das expectativas dos usuários e do tipo de sistema que está sendo desenvolvido.
• Requisitos funcionais do usuário são descritos de forma bem geral, mas os requisitos funcionais de sistema descrevem a função de sistema detalhadamente.

Não funcionais

• Definem as propriedades de sistemas e restrições, por ex: confiabilidade, tempo de resposta e espaço em disco;
• Requisitos não funcionais dizem respeito ao sistema como um todo. Alguns podem restringir o processo que é utilizado para desenvolver o sistema;
• Podem ser mais críticos que requisitos funcionais. A falha em atender um requisito não funcional de sistema pode inutilizar o sistema.

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

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

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/