wiki

Requisitos de software

Revisão de 15h58min de 29 de abril de 2014 por GustavoDomingos (discussão | contribs)
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 é?

*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.


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


Disponível em “http://3.143.69.156/wiki/index.php?title=Requisitos_de_software&oldid=25536”