An´ alise de Requisitos

Inspirada nos conceitos utilizados no desenvolvimento de software, a an´alise de requisitos tem como objetivo descrever o que o cliente espera que o sistema fa¸ca. Requisitos s˜ao os objetivos e as restri¸c˜oes relacionados ao sistema que se pretende desenvolver. O projetista deve ter em mente que esse conjunto de informa¸c˜oes pode ser definido como uma condi¸c˜ao ou uma fun¸c˜ao do SoC que ser´a respons´avel pela resolu¸c˜ao de problemas previamente especificados. A an´alise de requisitos est´a dividida em dois grandes est´agios. O primeiro apresenta os m´etodos utilizados para se construir uma vis˜ao global do sistema enquanto que o segundo especifica, detalha e prioriza as informa¸c˜oes obtidas.

Vis˜ao Global

O objetivo desse est´agio ´e a identifica¸c˜ao dos requisitos do SoC que se deseja desenvolver, fornecendo todas as informa¸c˜oes necess´arias para o entendimento do projeto por parte do desenvolvedor.

Abaixo est˜ao enumeradas a seq¨uˆencia de atividades que o projetista deve seguir a fim de obter este documento:

1. Capturar o m´aximo de informa¸c˜oes relevantes ao projeto por meio da entrevista com o cliente;

2. Revisar e verificar se algum ponto deixou de ser identificado;

3. Classificar as informa¸c˜oes em requisitos funcionais e n˜ao-funcionais;

4. Organizar as informa¸c˜oes em um documento relacionando os requisitos funcionais `as suas respectivas restri¸c˜oes;

O respons´avel pela entrevista deve ter em mente, ou em forma de question´ario, uma lista de perguntas necess´arias para se extrair o maior n´umero de informa¸c˜oes poss´ıveis do projeto com o cliente. Deve-se preocupar em n˜ao induzir o mesmo a tomar decis˜oes influenciadas pelo conhecimento pr´evio do entrevistador em rela¸c˜ao a implementa¸c˜ao do projeto e as ferramentas que ser˜ao utilizadas. O respons´avel deve fazer ainda uma r´apida

revis˜ao das quest˜oes que foram abordadas e verificar se algum ponto importante para a documenta¸c˜ao deixou de ser contemplado. A classifica¸c˜ao das informa¸c˜oes obtidas deve ser feita considerando os aspectos funcionais e n˜ao-funcionais dos requisitos segundo as descri¸c˜oes abaixo:

• Requisitos Funcionais - descrevem a funcionalidade desejada do SoC. Deve-se determinar o que se espera que o SoC fa¸ca sem a preocupa¸c˜ao de detalhar como isso deve ser feito:

– “o SoC deve ser capaz de gerar imagens”;

– “o SoC deve ser capaz de comunicar com a interface do LCD”; – “o SoC deve possibilitar a entrada de dados atrav´es de um teclado”; – “o SoC deve possibilitar o c´alculo da soma de dois n´umeros reais”;

• Requisitos N˜ao-Funcionais - descrevem as restri¸c˜oes impostas para a realiza¸c˜ao de um requisito funcional:

– “a imagem deve ser do tipo bmp”;

– “a imagem n˜ao deve ultrapassar a resolu¸c˜ao m´axima de 800x600”;

– “a interface com o LCD deve utilizar o protocolo OCP-IP para comunica¸c˜ao”; – “o tempo de resposta do SoC ao teclado n˜ao deve ultrapassar 10 ms”;

– “o SoC deve permitir a representa¸c˜ao de n´umeros reais com um m´aximo de 4 casas decimais”;

– “o cronograma de desenvolvimento n˜ao deve ultrapassar doze meses”;

A vis˜ao global ´e a etapa da an´alise de requisitos onde se definem exatamente quais s˜ao as principais funcionalidades do sistema.

Conforme apresentado anteriormente, o documento resultante desse est´agio ´e composto pelo conjunto de requisitos funcionais e suas respectivas restri¸c˜oes. Cada funcionalidade deve ser descrita de acordo com o modelo. (Ver FIG. 3.5)

Figura 3.5: Exemplo da organiza¸c˜ao das informa¸c˜oes identificadas

Especifica¸c˜ao

Ap´os a etapa de vis˜ao global deve-se analisar os requisitos a fim de refin´a-los e estrutur´a-los em um modelo que defina precisamente os atores e os casos de uso do sistema.

Por meio deste modelo ´e feita uma an´alise para identificar quais s˜ao os pontos considerados cr´ıticos no desenvolvimento do projeto. O resultado ´e um documento composto pela an´alise detalhada dos casos de uso e a descri¸c˜ao dos pontos cr´ıticos do projeto.

Para a gera¸c˜ao do documento desta etapa o projetista dever´a seguir a seq¨uˆencia de tarefas a seguir:

1. Identificar os atores

O ator ´e qualquer entidade que interaja com o sistema na realiza¸c˜ao de uma tarefa ou fun¸c˜ao. (m´odulos, interfaces, componentes e outros sistemas) Exemplos: LCD, teclado, interface OCP-IP.

2. Identificar os casos de uso

O caso de uso ´e um documento narrativo que descreve uma seq¨uˆencia de eventos (a¸c˜oes) que representa uma funcionalidade, ou seja, descreve uma tarefa a qual o sistema dar´a suporte. A maioria dos requisitos funcionais listados na vis˜ao global s˜ao candidatos a se tornarem casos de uso. Exemplos: Gerar Imagem bmp e Calcular Soma de N´umeros Reais

O projetista deve fazer uma an´alise e definir quais atores se relacionam com cada caso. A partir dessa an´alise ´e poss´ıvel detalhar a seq¨uˆencia de eventos realizada pelo caso em rela¸c˜ao a seus respectivos atores (FIG. 3.6). Os requisitos funcionais atendidos pelo caso tamb´em devem ser referenciados. Essa ´e uma forma de verificar se os requisitos solicitados pelo cliente est˜ao sendo atendidos.

Figura 3.6: Exemplo de Caso de Uso Detalhado

4. Identificar os pontos cr´ıticos

Por meio do detalhamento dos casos de uso e da experiˆencia do projetista ´e poss´ıvel selecionar (mensurar) quais s˜ao aqueles com a pior rela¸c˜ao entre custo, tempo gasto e benef´ıcio em seu desenvolvimento. Esses casos ter˜ao prioridade sobre os outros no decorrer do projeto e demandam aten¸c˜ao especial. O projetista deve descrever um documento apontando todas essas caracter´ısticas. O objetivo deste documento ´e auxiliar os projetistas a tomarem decis˜oes nos refinamentos futuros tais como: (1) Utilizar ou n˜ao um m´odulo pronto para determinada funcionalidade? (2) O desenvolvimento deste m´odulo realmente vale o investimento? Todas essas observa¸c˜oes dever˜ao ser feitas a t´ıtulo de compara¸c˜ao.