Conceitos : Especificao de requisitos.

A especificao de requisitos tem como objetivo obter produtos de software de melhor qualidade que satisfaam s reais necessidades dos clientes dentro de prazo e oramento adequados. Podemos entender requisito como uma funo, restrio ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer s necessidades do usurio do sistema. ( Descreve um servio ou uma limitao) Esta comprovado : a maior parte dos problemas , os de maior impacto nega tivo e os mais onerosos tem origem nas etapas iniciais do desenvolvimento de software. Justamente nas etapas de especificao dos requisitos onde as principais atividades so definidas e onde os requisitos do produto devem ser identificados e mapeados co m objetividade e clareza. Podemos dizer que as principais causas para o fracasso dos projetos de software so: especificao de requisitos mal formulada e alteraes constantes nos requisitos. Por serem atividades bases do processo de desenvolvimento de so ftware as falhas cometidas nas atividades de definio e validao de requisitos iro originar documentos de requisitos inconsistentes afetando as etapas seguintes de projeto , implementao e testes e gerando produtos de softwares de baixa qualidade. Embora no exista um modelo padro consagrado para gerenciar requisitos podemos definir alguns passos para um processo de especificao de requisitos :(Soares, 2005) ( Os processos devem ser adaptados a cada necessidade/conjuntura )

1. Descoberta dos requisitos - consultas , documentos, pesquisas, entrevistas, JAD(Joint Application Design); 2. Anlise dos requisitos identificados com refinamento e detalhamento dos mesmos; 3. Modelagem e Validao dos requisitos verificando sua consistncia (Documento de requisitos); 4. Acompanhamento dos requisitos;
Ao final deste processo deve -se ter um documento de requisitos bem definido e entendido por todos os intervenientes do processo: Clientes, desenvolvedores, lderes, analistas, gerentes, patrocinadores, etc. (stakeholders) Mas o que especificar um requisito ? Especificar um requisito implica em compreender exatamente o que deve ser feito e que se espera receber como resultado. Podemos classificar os requisitos em :
y y

Funcionais - descrevem as funcionalidades do sistema deseja das pelos clientes ou seja O QUE se espera que o software faa; No-funcionais - So as qualidades e restries globais do sistema relacionados com manuteno , uso, desempenho, custo , interface, etc...

Exemplos de requisitos funcionais: y O sistema deve possibilitar o cadastramento dos dados pessoais dos clientes; y O sistema deve emitir relatrios gerenciais;

y O sistema deve permitir a baixa automtica do estoque quando da venda de um produto; A Norma ISO / IEC 9126 define seis caractersticas de qualidade de software que devem ser avaliadas:
y y y y y y

Funcionalidade (finalidade do produto); Usabilidade (esforo para utilizar, aprender o produto); Confiabilidade (freqncia de falhas, recuperabilidade) ; Eficincia (caracterstica relacionada ao desempenho); Manutenibilidade (esforo necessrio para modificar); Portabilidade (capacidade de transferir o produto para outros ambientes).

Exemplos de requisitos no-funcionais: y tempo de resposta do sistema no deve ultrapassar 10 segundos; y software deve ser operacionalizado no sistema Windows; y O banco de dados usado dever ser o Oracle; Obs: "Os requisitos no-funcionais so crticos para o sucesso de sistemas de software e esto diretamente relacionados com a satisfao dos usurios. Devido a essa importncia, alguns requisitos funcionais podem ser sacrificados para atender s restries imp ostas pelos requisitos no-funcionais" O documento de requisitos de sistema - DRS - pode ser entendido como a descrio formal e oficial onde descrita e comunicada os requisitos a todos os envolvidos no processo de desenvolvimento de software ((stakeholders). Ele basicamente composto de:

1. 2. 3. 4. 5.

os servios e funes que o sistema deve prover; as limitaes sobre as quais o sistema deve operar; definies de outros sistemas com os quais o sistema deve integrar; limitaes no processo usado para desenvolver o sistema; descries sobre o hardware no qual o sistema ir executar

Os requisitos podem ser modelados e validados atravs de casos de uso que incluem o diagrama de casos de uso e a especificao do caso de uso. Um caso de uso representa uma funcionalida de completa, conforme percebida pelo ator e definido como "um conjunto de seqncias de aes que um sistema executa que produzem um resultado observvel por um particular ator". Os casos de uso uma das tcnicas usadas para descrever claramente todos os requisitos de um dado sistema, esta tcnica foi proposta por Ivar Jacobson em sua metodologia de desen volvimento de sistemas orientados a objetos , visando identificar os requisitos de um sistema.(Wikipdia). O Diagrama de Casos de Uso fornece um modo de descrever a viso externa do sistema e suas interaes com o mundo exterior, representando uma viso de alto nvel da funcionalidade do sistema mediante uma requisio do usurio.(Wikipdia). O modelo de casos de uso um formato gil para capturar requisitos de software. Ele contrasta com documentos maiores e descritivos que tentam conter todos os requerimentos possveis antes do incio da construo de um novo sistema, mas falham completamente neste intento. Os principais benefcios dos casos de uso na modelagem de requisitos so:

1. os casos de uso podem ser facilmente adicionados ao projeto de software e removidos do projeto de software assim que as prioridades mudarem; 2. os casos de uso podem tambm servir como base para estimar, escalonar e validar esforos;

3. uma razo porque os casos de uso se tornaram populares: so fceis de entender por pessoas da rea de negcio e assim provaram ser uma excelente ponte entre quem desenvolve o software e os utilizadores finais.
Os casos de uso tambm tm as suas dificuldades. So excelentes para capturar os requisitos funcionais de um sistema, mas no tm tanto sucesso em capturar os no -funcionais. importante notar que os modelos de casos de uso no descrevem como o soft ware dever ser construdo, e sim, como ele dever se comportar. As descries de casos de uso normalmente evitam o uso de termos tcnicos, preferindo a linguagem do usurio final. Normalmente, os casos de uso so feitos por quem desenvolve o software e/ou por quem vai utilizar esse mesmo software. Propsitos bsicos:

1. 2. 3. 4.

decidir e descrever os requisitos funcionais do sistema; prover uma descrio clara e consistente do que o sistema deve fazer; prover a base para a realizao de testes que validam e verif icam o sistema; prover facilidades para rastrear requisitos funcionais dentro das classes e operaes do sistema.

Principais Componentes do Modelo de Casos de Uso :

y y y

Caso de uso: especifica uma funcionalidade completa do sistema. sempre iniciado por um ator (direta ou indiretamente ordena ao sistema a execuo de um caso de uso); Ator: entidade externa que interage com os casos de uso; Sistema: conjunto de casos de uso

A seguir temos a sequncia que pode ser usada para construir o modelo de casos de us o: y y y y y Definir o sistema (conjunto de casos de uso); encontrar os atores; encontrar e descrever os casos de uso; definir os relacionamentos entre os casos de uso; validar o modelo.

Como identificar um ator ? As respostas s seguintes perguntas podem auxiliar na identificao dos atores:

1. 2. 3. 4. 5. 6.

Quem utiliza a principal funcionalidade do sistema? Quem vai precisar de suporte do sistema para realizar suas tarefas dirias? Quem precisa manter, administrar e deixar o sistema "rodando"? Quais dispositivos de hardware o sistema precisa manipular? Com quais outros sistemas o sistema precisa interagir? Quem ou o qu tem interesse nos resultados produzidos pelo sistema?

Propriedades de um caso de uso

y y y y

A descrio resumida do caso de uso uma breve descrio do caso de uso. Fluxo principal descreve o fluxo natural seguido pelo caso de uso se todas as hipteses foram verdadeiras e se nenhum erro tiver ocorrido. Os fluxos alternativos representam os desvios alcanados pela execuo do caso de uso, causados pelos atores, por condies intrnsecas ao caso de uso ou por erros ou excees. Os pontos de extenses so somente rtulos que indicam, nos fluxos, a extenso do caso de uso. Podem existir vrios pontos de extenses no mesmo fluxo.

Como identificar um caso de uso ? As respostas s perguntas abaixo podem auxiliar a identificar os Casos de Uso.

1. Quais funes o ator requer do sistema? O que o ator precisa fazer? 2. Ator precisa criar, ler, destruir, modificar ou armazenar algum tipo de informao dent ro do sistema? 3. Ator precisa ser notificado de eventos do sistema? O ator precisa notificar o sistema sobre algum evento? 4. Trabalho dirio do ator poderia ser simplificado ou tornado mais eficiente por meio de novas funcionalidades do sistema? 5. Quais entradas e sadas o sistema precisa? 6. Quais os principais problemas com o atual sistema?
Mesmo ainda nesta fase do processo de desenvolvimento de software, atravs de uma especificao de requisitos bem elaborada e documentada atravs dos casos de u so pode-se usar a mtrica Pontos por Caso de Uso - PCU - (Use Case Points ) para realizar estimativas de tamanho, prazo e custo em projetos de software. O processo de contagem da mtrica PCU constituda por seis passos descritos a seguir:

1. 2. 3. 4. 5. 6.

Contar os atores e atribuir o grau de complexidade; Contar os casos de uso e atribuir a complexidade; Somar o total dos atores com o total de casos de uso para obter o PCU no ajustado; Determinar a complexidade do fator tcnico; Determinar a complexidade do fator a mbiente; Calcular o PCU ajustado;

A tcnica de anlise de Pontos por Casos de Uso foi criada para permitir que seja possvel estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando -se dos prprios documentos gerados nesta fase de anlise como subsdio para efetuar estimativas de tamanho, prazo e custo de software. Naturalmente existe um grau de incerteza inerente a fase inicial do processo e as definies de requisitos da ordem de 45%. Referncias:
y y y y y

Estudo de Caso de Aplicao da Mtrica de Pontos de Casos de Uso Medio de Pontos por Funo a Partir da Especificao de Requisitos Quanto vale o software que voc produz ? VB.NET - Estimativa de tamanho e preo com Anlise de Pontos de Funo - APF Pontos de Funo ou Pontos por Caso de Uso? Como Estimar Projetos ...

Jos Carlos Macoratti