quinta-feira, 14 de abril de 2011

Engenharia de Requisitos e Documentação

Engenharia de Requisitos e Documentação


Dhones Carlos Saragossa Paes RA:0953514534
Carlos Eduardo Domingos da Silva RA: 0950087

Engenharia de Requisitos

A Engenharia de Requisitos pode ser vista como uma subárea da Engenharia de Software e seu principal objetivo é a obtenção de uma especificação correta e completa dos requisitos, para isso é preciso criar e manter documentos de requisitos de sistemas, chamado de Documento de Especificações de Requisitos de Software (DERS).

No processo de Engenharia de Software conhecido como Ciclo de Vida Clássico, que também pode ser executado varias vezes como parte integrante de um ciclo de vida iterativo e incremental, a Engenharia de Requisitos se encontra na primeira fase, a fase de Análise.

A Engenharia de Requisitos se divide em três fases principais: Elicitação, especificação e validação, sendo que cada fase é subdividida em subfases, o processo de engenharia de requisitos é iterativo, ou seja, pode-se voltar a uma fase que já foi feita, como em uma espiral.

Quanto a Elicitação

Suas principais metas são: identificar os objetivos do sistema a ser construído (O que ele deve fazer, suas funções) e como ele se encaixa nas necessidades de negócio do cliente. Para isso as “primeiras perguntas” darão apenas um entendimento básico do problema, sendo assim é preciso utilizar abordagens mais sofisticadas, tais como:

· Elicitação Colaborativa;

· Implantação de Funções de Qualidade;

· Casos de Uso;

· Amostragem;

· Investigação;

· Entrevista;

· Questionário;

· Observação;

· Prototipação.

Quanto a Especificação

É o produto final da Engenharia de Requisitos e a base pra todas as fases seguintes do processo de Engenharia de Software.

Uma especificação pode ser:

· Um documento escrito;

· Modelos gráficos;

· Um modelo formal matemático;

· Um protótipo;

· Qualquer combinação dos itens acima.

As especificações podem incluir:

· Justificativa de necessidade e factibilidade;

· Definição do escopo;

· Stakeholders que participaram da elicitação;

· Requisitos e suas restrições de domínio;

· Condições de desempenho, segurança e etc.;

· Casos de uso;

· Protótipos.

Quanto a Validação

É a revisão do projeto para averiguar se:

· Todos os requisitos foram elencados sem ambiguidade;

· Inconsistências, omissões e erros foram detectados e corrigidos;

· Tudo está documentado de acordo com os padrões da empresa.

Para isso, é fundamental responder algumas perguntas como:

ü Os requisitos estão claramente descritos? Podem ser interpretados incorretamente?

ü As fontes dos requisitos foram identificadas? Elas validaram os requisitos?

ü Este requisito viola alguma restrição de domínio do sistema?

ü É possível testar esse requisito?

ü A especificação esta bem estruturada de forma a facilitar as próximas fases?

ü Etc.

Para produzir um Documento de Especificações de Requisitos do Software (DERS) bem estruturado foi criado um modelo padrão de documentação pelo IEEE.

DERS

DERS é a documentação que especifica os requisitos do sistema.

Segundo o IEEE (institute of Electrical and Eletronics Engineers), o DERS deve ser completo e não ambíguo. Ele deve auxiliar o cliente a descrever como precisão o que ele deseja, e ao desenvolvedor a entender o que o cliente deseja.

Além disso o DERS deve possuir algumas características especificas como:

· Acordar entre cliente e empresa fornecedora o que o software ira fazer.

· Reduzir o esforço do desenvolvimento.

· Prever e estimar os custos e o prazo.

· Facilitar a manutenção.

O DERS deve possuir padrões para sua elaboração. O IEEE elaborou um documento com padrões e praticas recomendadas.

INTRODUÇÃO

· Proposito = mostrar para que e para quem o software esta sendo feito.

· Escopo = especificar o software, nomeá-lo, explicar o que ira fazer, e ou, o que não ira, descrever as aplicações, benefícios, objetivos e metas.

· Definições siglas e abreviaturas = definir todos os termos, siglas e abreviaturas para entender o DERS.

· Referencias = listas os documentos referenciados no DERS, identificado por autor, titulo, data, editora, organização, entre outros.

· Visão global = apresentar de forma resumida o que os capítulos restantes do DERS ira tratar.

DESCRIÇÃO GERAL

· Perspectiva do produto = comparar o software com outros relacionados. Se for independente isso deve constar. Menções a sistemas maiores que o mesmo seja parte também deve-se constar.

· Funções do produto = criar um índice das principais funções do software.

· Restrições = descrever qualquer outro item que limite as opções do produto, como politicas de controle, limitações do hardware, interface com outros aplicativos, entre outros.

· Pressupostos e dependências = listar todos os fatores que afetam os requisitos definidos.

REQUISITOS ESPECIFICOS

· Conter a definição dos principais requisitos de software. Principal capítulo do DERS, pois, os requisitos funcionais e não funcionais aqui serão definidos.

Esse é o modelo do IEEE. Cockburn (2005) apresenta uma complementação a este modelo, incluindo um capitulo para casos de uso.

Casos de uso servem para interação entre o sistema e o usuário. Descritos geralmente em forma textual, mais também podem ser descritos através de fluxogramas, diagramas, entre outros.

INSPEÇÃO DO DERS

A inspeção do DERS é muito importante para o sucesso do mesmo. Deve-se avaliar o documento como um todo em busca de defeitos antes de ser validado junto ao cliente.

Os erros encontrados em um DERS podem ser:

· Omissão

· Ambiguidade

· Fato incorreto

· Informação estranha

A inspeção deve ser feita por uma pessoa que não esteja envolvida no projeto, para que este simule o cliente.

Nenhum comentário:

Postar um comentário