[Seminário] Boas Praticas na Engenharia de Requisitos

Bruno Luiz ra: 0919440340

Ronaldo Cesar ra: 0901395323

Boas Praticas na Engenharia de Requisitos

Introdução

Com os avanços tecnológicos que vem ocorrendo nas últimas décadas e a visível diminuição do custo do hardware, a informação passa a ser um recurso estratégico das empresas. O software se tornou, então, a força motora desta nova era. A integridade das informações oferecidas por um software pode diferenciar uma empresa de suas concorrentes.

O software é capaz de manipular o produto mais importante para uma empresa – a informação, e por isso é tão caro. Para evitar que a parte mais cara dos sistemas computadorizados fosse desenvolvida com baixa qualidade e pouca previsibilidade de custo e recursos, surgiram técnicas de Engenharia de Software. A Engenharia de Software surgiu com o objetivo de definir e aplicar métodos que pudessem ajudar no processo de construção, manutenção e implantação de software.

A Engenharia de Requisitos

A Engenharia de requisitos tem por objetivo definir os requisitos de um sistema em Construção e apresenta duas atividades principais: o levantamento e análise de requisitos.

O processo de engenharia de requisitos é composto por quatro atividades de alto nível

1. Identificação.

2. Análise e negociação.

3. Especificação e documentação.

4. Validação.

O Documento de Especificação de Requisitos de Software

O DERS auxilia o clientes de software a descrever com precisão o que eles desejam, e aos desenvolvedores a entender exatamente o que o cliente deseja

Para a elaboração do DERS existe alguns padrões e praticas:

* Propósito: deve delinear o propósito particular e especificar para quem esta sendo feito esse documento

* Escopo especificar o produto a ser produzido, falando o que o produto irá fazer .

* Definições, siglas e abreviaturas: deve prover todas as definições de todos os termos, siglas e abreviaturas que são necessárias para o DERS.

* Referencias: lista de locais do DERS informando por autor, titulo, data, editora, organização, e outros atributos quando aplicáveis.

* Visão Global: explicar o que os capítulos restante irão tratar .

* Perspectiva do produto: deve colocar o produto na perspectiva de outros produtos relacionados. Se é independente. Caso contrário, se é um componente de um sistema maior, o que ocorre frequentemente, relatar as interfaces entre esse software e o sistema, e os requisitos do sistema maior para a funcionalidade deste software.

Funções do produto: um índice das principais funções que o software irá executar.

Características do usuário: descrever as características gerais do usuário do produto.

Restrições: descrever qualquer item que limite as opções do produto, como políticas de controle, limitações de hardware, interface com outras aplicações, controle de segurança, entre outros itens que forem relevantes.

Pressupostos e Dependências: listar todos os fatores que afetem os requisitos definidos

Requisitos Específicos: definição dos requisitos de software.

Todos esses tens anteriores formam os padrões indicados para a elaboração do DERS com práticas recomendadas para especificação de requisitos de software.

Requisitos Específicos: Contem a definição dos requisitos de software. É o principal capitulo do DERS, pois é nesta seção que os requisitos funcionais e não funcionais estarão definidos.

Diagrama de Casos de Uso

O Diagrama de Casos de uso tem por como objetivo mostrar graficamente todas as funções que um sistema precisara desempenhar, sempre obedecendo os padrões UML.

Objetivos

Um diagrama de casos de uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.

O cliente deve ver no diagrama de casos de uso as principais funcionalidades de seu sistema

Descrição dos Casos de Uso

Um caso de uso é escrito em linguagem natural e é constituído por uma seqüência de sentenças. Estes passos são compostos por ações simples, que descrevem o ator realizando uma tarefa ou passando informação para um outro ator. Um caso de uso tem normalmente, ao menos, dois finais possíveis, um de sucesso e outro de erro.

Um caso de uso sempre será responsável por implementar, pelo menos, um requisito funcional do sistema. Todos os requisitos funcionais do sistema devem estar ligados a um ou mais casos de uso. Essas ligações entre casos de uso e requisitos são necessárias para permitir a rastreabilidade dos requisitos.

Os fluxos são a partes principais do caso de uso. Um caso de uso deve conter todos os cenários, tanto de sucesso quanto de falha.

Algumas boas práticas para escrever um caso de uso de forma eficaz:

a) Utilizar gramática simples, pois o principal objetivo do UC é mostrar de forma clara o que sistema faz.

b) Mostrar claramente quem são os atores.

c) Incluir todas as ações, ou seja, todas as de sucesso e de falha.

d) Validar, pois deixa claro que o sistema irá validar os dados inseridos de acordo com as regras de negócio e restrições para os valores.

e) Mencionar o tempo apenas opcionalmente.

Inspeção do DERS

Inspeção do DERS (Documentos de Especificação de Requisitos de Software)

É um fator muito importante para o sucesso do DERS, avaliando o documento como um todo em busca de defeitos antes da validação junto com os clientes e usuários.

Alguns dos defeitos encontrados em um DERS:

Omissão: é todo erro relativo a alguma informação que não foi descrita.

Ambigüidade: ocorre sempre que alguma informação estiver descrita de poder causa dúvida ou confusão.

Inconsistência: é alguma sentença que contradiz algo que foi dito anteriormente no documento.

Fato Incorreto: é quando um fato descrito no DERS não é verdadeiro ou não pode ser executado.

Informação Estranha: são as informações que não pertence ao DERS.

Importante: é altamente recomendável que a inspeção seja feita por outro profissional e não pelo responsável pela criação do DERS.

Construção do DERS

O primeiro passo pra a construção do DERS é descrever todos os requisitos do sistema, logo após construir o diagrama de casos de uso que irá implementar estes requisitos antes da descrição de tais casos de uso. Após obter os requisitos, especificá-los e criar um diagrama de casos de uso, e é necessário descrever o caso de uso.

Considerações Finais

Quando um DERS é bem construído, através de sua avaliação junto aos stakeholders do projeto, é possível descobrir se os interesses dos mesmos foram corretamente entendidos, pois algumas boas praticas facilitam a criação de um caso de uso eficaz, que será capaz de fornecer aos interessados no projeto todas as informações que estes precisam, de maneira objetiva e completa.