APLICAÇÃO DE ENGENHARIA DE REQUISITOS EM UM PROJETO DE SOFTWARE

...

Com base nestas informações começamos a desenvolver uma possível solução para estes requisitos ilustrados basicamente. Esta prévia de requisitos ajuda a criar uma documentação básica, mas que fará toda a diferença no projeto como um todo evitando assim gastos desnecessários, custos essessívos e assim criar um projeto "eficas e eficiente".

Este projeto aplica todas específicações que uma engenharia de software deve ter. Desde a confirmação dos requisitos até a modelagem e fluxo que as informações devem ter no sistema. Isto é o que viabilizará o projeto final para ser aprovado.

- Conceitos Gerais

3.1 Requisitos de Software

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema. Eles refletem as necessidades e expectativas das partes interessadas no projeto. Os requisitos de software são que dizem respeito a propriedades do software.Tipos de requisitos

- Requisitos do projeto- voltados para os requisitos do negócio, gerenciamento e entrega do produto.

- Requisitos do produto- voltados para os requisitos técnicos, de segurança, de desempenho, etc.

- Requisitos funcionais- estabelecem como o sistema deverá agir, e o que deverá fazer, e são ser descritos detalhadamente.

- Requisitos não funcionais- definem as propriedades do sistema e suas restrições.

3.2 Engenharia de Requisitos

A Analise de Requisitos ou Engenharia de Requisitos é essencial e de extrema importância no Gerenciamento de Projetos, pois coleta dada necessários e indispensável para solução de um problema, no qual o usuário consegue suprir suas necessidades e alcançar os objetivos em pauta, inclusive, consegue mapear as expectativas de um usuário para o produto.

Segundo a IEEE (1990) a análise de requisitos envolve o estudo das necessidades do usuário para se encontrar uma definição correta ou completa do sistema ou requisito de software.

Essa análise de requisitos é indispensável no desenvolvimento do sistema, pois é possível determinar se o projeto será bem sucedido. Os requisitos devem ser quantitativos, detalhados e relevantes para o projeto, pois eles fornecerão a referência para validar o produto final, estabelecerão o acordo entre cliente e fornecedor sobre o que e o software fará e consequentemente reduzirão os custos de desenvolvimento, pois requisitos mal definidos implicam num retrabalho.

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema. Eles refletem as necessidades e expectativas das partes interessadas no projeto. Os requisitos de software são que dizem respeito a propriedades do software.

A engenharia de requisitos coloca a disposição um mecanismo adequado para entender o que o cliente está buscando, analisar as necessidades, avaliar a exequibilidade, negociar soluções razoáveis, especificar uma solução sem riscos de ambiguidades, validar a especificação e administrar os requisitos, a medida que eles formam um sistema em operação. Pode-se descrever o processo de engenharia em cinco passos, de acordo com PRESSMAN (2002)

- Elicitação

- Análise e negociação

- Especificação

- Modelagem

- Validação

- Gestão

3.2.1 Elicitação

Primeira etapa a ser contemplada pela engenharia de requisitos, muito embora pareça simples, não o é, uma vez que engloba variáveis importantes, como o que precisa ser conseguido, como o sistema ou o produto se encaixa nas necessidades do negócio e como o produto vai ser usado no dia-a-dia. (NOGUEIRA, 2003)

PRESSMAN (2002), define alguns problemas que ajudam a entender as dificuldades da elicitação de requisitos:

- Problemas de Escopo: O limite do sistema é mal definido, com detalhes técnicos desnecessários que podem confundir os objetivos globais do sistema.

- Problemas de Entendimento: Os clientes não tem completa certeza do que é necessário, tem pouca compreensão das capacidades e limitações de seu ambiente computacional e tem dificuldade de se comunicar com os engenheiros, omitindo informações que consideram obvias, especificando requisitos que são ambíguos ou impossíveis de testar.

- Problemas de volatilidade, em que os requisitos mudam ao longo do tempo.

SOMMERVILLE (2003), propõe um conjunto de diretrizes detalhadas, para o processo de elicitação, que pode ser resumida em:

- Avaliar a viabilidade técnica e de negócios do sistema proposto

- Identificar as pessoas que auxiliarão na especificação de requisitos e que compreendam seu viés organizacional.

- Definir o ambiente técnico no qual o sistema ou produto será colocado.

- Identificar as “restrições de domínio”, fatores limitantes da funcionalidade e do desempenho do sistema ou produto a ser construído.

- Definir um ou mais métodos de elicitação de requisitos.

- Solicitar a participação de uma ou mais pessoas, de forma que os requisitos possam ser definidos sob vários pontos de vista. Neste ponto, é importante que a razão pela qual um requisito é identificado seja determinada.

- Identificar requisitos ambíguos para prototipagem.

- Criar cenários de uso para auxiliar clientes e usuários a identificar requisitos chave.

- Os produtos de trabalho da elicitação variam de acordo com o tamanho do sistema ou do produto a ser construído, normalmente incluindo, segundo NOGUEIRA (2003):

- Uma declaração da necessidade e da viabilidade.

- Uma declaração delimitada do escopo do sistema ou produto.

- Uma lista de usuários e interessados que participaram da elicitação de requisitos.

- Uma descrição do ambiente técnico do sistema.

-