Quais dessas são etapas da fase de especificação de um projeto levantamento de requisitos?

A especifica��o de requisitos tem como objetivo obter produtos de software de melhor qualidade que satisfa�am �s reais necessidades dos clientes dentro de prazo e or�amento adequados.

Podemos entender requisito como uma fun��o, restri��o ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer �s necessidades do usu�rio do sistema. (Descreve um servi�o ou uma limita��o)

Esta comprovado : a maior parte dos problemas , os de maior impacto negativo e os mais onerosos tem origem nas etapas iniciais do desenvolvimento de software. Justamente nas etapas de especifica��o dos requisitos � onde as principais atividades s�o definidas e onde os requisitos do produto devem ser identificados e mapeados com objetividade e clareza.

Podemos dizer que as principais causas para o fracasso dos projetos de software s�o: especifica��o de requisitos mal formulada e altera��es constantes nos requisitos.

Por serem atividades bases do processo de desenvolvimento de software as falhas cometidas nas atividades de defini��o e valida��o de requisitos ir�o originar documentos de requisitos inconsistentes afetando as etapas seguintes de projeto , implementa��o e testes e gerando produtos de softwares de baixa qualidade.

Embora n�o exista um modelo padr�o consagrado para gerenciar requisitos podemos definir alguns passos para um processo de especifica��o 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. An�lise dos requisitos identificados com refinamento e detalhamento dos mesmos;
3. Modelagem e Valida��o dos requisitos verificando sua consist�ncia (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, l�deres, 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 :

• Funcionais - descrevem as funcionalidades do sistema desejadas pelos clientes ou seja O QUE se espera que o software fa�a;
• N�o funcionais - S�o as qualidades e restri��es globais do sistema relacionados com manuten��o , uso, desempenho, custo , interface, etc...

Exemplos de requisitos funcionais:

A Norma ISO / IEC 9126 define seis caracter�sticas de qualidade de software que devem ser avaliadas:

• Funcionalidade (finalidade do produto);
• Usabilidade (esfor�o para utilizar, aprender o produto);
• Confiabilidade (freq��ncia de falhas, recuperabilidade);
• Efici�ncia (caracter�stica relacionada ao desempenho);
• Manutenibilidade (esfor�o necess�rio para modificar);
• Portabilidade (capacidade de transferir o produto para outros ambientes).

Exemplos de requisitos n�o funcionais:

Obs: "Os requisitos n�o funcionais s�o cr�ticos para o sucesso de sistemas de software e est�o diretamente relacionados com a satisfa��o dos usu�rios. Devido a essa import�ncia, alguns requisitos funcionais podem ser sacrificados para atender �s restri��es impostas pelos requisitos n�o funcionais"

O documento de requisitos de sistema - DRS - pode ser entendido como a descri��o 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. os servi�os e fun��es que o sistema deve prover;
2. as limita��es sobre as quais o sistema deve operar;
3. defini��es de outros sistemas com os quais o sistema deve integrar;
4. limita��es no processo usado para desenvolver o sistema;
5. descri��es sobre o hardware no qual o sistema ir� executar

Os requisitos podem ser modelados e validados atrav�s de casos de uso que incluem o diagrama de casos de uso e a especifica��o do caso de uso.

Um caso de uso representa uma funcionalidade completa, conforme percebida pelo ator e � definido como "um conjunto de seq��ncias de a��es que um sistema executa que produzem um resultado observ�vel por um particular ator".

Os casos de uso � uma das t�cnicas usadas para descrever claramente todos os requisitos de um dado sistema, esta t�cnica foi proposta por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos , visando identificar os requisitos de um sistema.(Wikip�dia).

O Diagrama de Casos de Uso fornece um modo de descrever a vis�o externa do sistema e suas intera��es com o mundo exterior, representando uma vis�o de alto n�vel da funcionalidade do sistema mediante uma requisi��o do usu�rio.(Wikip�dia).

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 poss�veis antes do in�cio da constru��o de um novo sistema, mas falham completamente neste intento. Os principais benef�cios dos casos de uso na modelagem de requisitos s�o:

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 tamb�m servir como base para estimar, escalonar e validar esfor�os;
3. uma raz�o porque os casos de uso se tornaram populares: s�o f�ceis de entender por pessoas da �rea de neg�cio e assim provaram ser uma excelente ponte entre quem desenvolve o software e os utilizadores finais.

Os casos de uso tamb�m t�m as suas dificuldades. S�o excelentes para capturar os requisitos funcionais de um sistema, mas n�o t�m tanto sucesso em capturar os n�o funcionais.

� importante notar que os modelos de casos de uso n�o descrevem como o software dever� ser constru�do, e sim, como ele dever� se comportar. As descri��es de casos de uso normalmente evitam o uso de termos t�cnicos, preferindo a linguagem do usu�rio final. Normalmente, os casos de uso s�o feitos por quem desenvolve o software e/ou por quem vai utilizar esse mesmo software.

Prop�sitos b�sicos:

1. decidir e descrever os requisitos funcionais do sistema;
2. prover uma descri��o clara e consistente do que o sistema deve fazer;
3. prover a base para a realiza��o de testes que validam e verificam o sistema;
4. prover facilidades para rastrear requisitos funcionais dentro das classes e opera��es do sistema.

Principais Componentes do Modelo de Casos de Uso:

• Caso de uso: especifica uma funcionalidade completa do sistema. � sempre iniciado por um ator (direta ou indiretamente ordena ao sistema a execu��o 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 sequ�ncia que pode ser usada para construir o modelo de casos de uso:

Como identificar um ator ?

As respostas �s seguintes perguntas podem auxiliar na identifica��o dos atores:

1. Quem utiliza a principal funcionalidade do sistema?
2. Quem vai precisar de suporte do sistema para realizar suas tarefas di�rias?
3. Quem precisa manter, administrar e deixar o sistema "rodando"?
4. Quais dispositivos de hardware o sistema precisa manipular?
5. Com quais outros sistemas o sistema precisa interagir?
6. Quem ou o qu� tem interesse nos resultados produzidos pelo sistema?

Propriedades de um caso de uso

• A descri��o resumida do caso de uso � uma breve descri��o do caso de uso.
• Fluxo principal descreve o fluxo natural seguido pelo caso de uso se todas as hip�teses foram verdadeiras e se nenhum erro tiver ocorrido.
• Os fluxos alternativos representam os desvios alcan�ados pela execu��o do caso de uso, causados pelos atores, por condi��es intr�nsecas ao caso de uso ou por erros ou exce��es.
• Os pontos de extens�es s�o somente r�tulos que indicam, nos fluxos, a extens�o do caso de uso. Podem existir v�rios pontos de extens�es no mesmo fluxo.

Como identificar um caso de uso ?

As respostas �s perguntas abaixo podem auxiliar a identificar os Casos de Uso:

1. Quais fun��es o ator requer do sistema? O que o ator precisa fazer?
2. Ator precisa criar, ler, destruir, modificar ou armazenar algum tipo de informa��o dentro do sistema?
3. Ator precisa ser notificado de eventos do sistema? O ator precisa notificar o sistema sobre algum evento?
4. Trabalho di�rio do ator poderia ser simplificado ou tornado mais eficiente por meio de novas funcionalidades do sistema?
5. Quais entradas e sa�das o sistema precisa?
6. Quais os principais problemas com o atual sistema?

Mesmo ainda nesta fase do processo de desenvolvimento de software, atrav�s de uma especifica��o de requisitos bem elaborada e documentada atrav�s dos casos de uso pode-se usar a m�trica 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 m�trica PCU � constitu�da por seis passos descritos a seguir:

1. Contar os atores e atribuir o grau de complexidade;
2. Contar os casos de uso e atribuir a complexidade;
3. Somar o total dos atores com o total de casos de uso para obter o PCU n�o ajustado;
4. Determinar a complexidade do fator t�cnico;
5. Determinar a complexidade do fator ambiente;
6. Calcular o PCU ajustado;

A t�cnica de an�lise de Pontos por Casos de Uso foi criada para permitir que seja poss�vel estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando-se dos pr�prios documentos gerados nesta fase de an�lise como subs�dio para efetuar estimativas de tamanho, prazo e custo de software.

Naturalmente existe um grau de incerteza inerente a fase inicial do processo e as defini��es de requisitos da ordem de 45%.

Assim,  a medida do tamanho, complexidade e riscos de um projeto de software vai depender da qualidade e coer�ncia dos requisitos definidos . � de vital import�ncia que a tarefa de  levantamento de requisitos seja executada de forma criteriosa e detalhada, pois uma falha nessa etapa do ciclo de vida do software vai gerar um projeto mal sucedido e a insatisfa��o do cliente.

Refer�ncias:

             Gostou ?  

Refer�ncias:

• Se��o VB .NET do Site Macoratti.net

• Super DVD .NET - A sua porta de entrada na plataforma .NET

• Super DVD V�deo Aulas - V�deo Aula sobre VB .NET, ASP .NET e C#

• Se��o C# do site Macoratti.net

• Super DVD C#

• Super DVD Visual Basic

• Curso B�sico VB .NET - V�deo Aulas

• Curso C# B�sico - V�deo Aulas

• Estudo de Caso de Aplica��o da M�trica de Pontos de Casos de Uso

• Medi��o de Pontos por Fun��o a Partir da Especifica��o de Requisitos

• Quanto vale o software que voc� produz ?
• VB.NET - Estimativa de tamanho e  pre�o com An�lise de Pontos de Fun��o - APF

• Pontos de Fun��o ou Pontos por Caso de Uso? Como Estimar Projetos ...

Jos� Carlos Macoratti

Quais as etapas do levantamento de requisitos?

Quais são as 5 etapas da análise de requisitos?

Quais são as técnicas de levantamento de requisitos?

Quais são as fases de um projeto de sistema?