Esta etapa inicial do desenvolvimento tem como objetivo a determinação dos objetivos, alternativas e restrições. Determina-se o que deverá ser desenvolvido, e para quem. O resultado final é a definição dos requisitos que o produto de software deverá possuir.
A análise busca o estudo e a compreensão do ambiente onde o sistema será inserido, o qual denomina-se domínio do problema.O domínio do problema é um campo de atividade sob
estudo ou consideração. Um dos maiores problemas encontrados pelos analistas de sistemas é o estudo do domínio do problema e a identificação de suas características (Coad e Yourdon,1992).
Erros nesta etapa inicial podem se mostrar críticos e terem um custo muito alto se forem detectados tardiamente no processo de desenvolvimento.
5.2.1 Levantamento dos Requisitos
⇒ Atividade: Levantamento de informações do Domínio do problema
O levantamento de informações do domínio do problema tem como resultado a descrição do problema, uma síntese após a compreensão em alto nível do domínio do problema. A descrição do problema é feita de forma narrativa e apresenta os razões e objetivos do projeto.
⇒ Atividade: Representar e analisar os processos relacionados
Os processos relacionados ao sistema que será desenvolvido devem ser representados e analisados. Nesta etapa os processos que não agregam valor ou muito simples e ou com baixo nível de automação devem ser analisados com cuidado pois podem ser aglutinados ou eliminados. Processos realizados em duplicidade devem ser eliminados.
⇒ Atividade: Levantamento dos requisitos de alto nível
Faz-se inicialmente o levantamento dos requisitos de forma narrativa produzindo o Documento de Requisitos, que serve como material de discussão e estudo. Neste documento faz- se a identificação das funcionalidades do sistema.
Nesta atividade o problema pode ser subdividido em módulos. Um módulo é uma funcionalidade bem definida do sistema maior, e que apresenta uma interface bem definida e normalmente pequena com os outros módulos. Este módulo irá se constituir de um pacote de classes associações, operações, eventos e restrições. As iterações em cada uma das fases são determinadas pela conclusão das atividades associadas a estes módulos. Uma iteração é um conjunto de atividades, com um plano básico e critérios de avaliação que resultam em uma versão da documentação ou do software.
O resultado deste trabalho é o documento de requisitos do sistema.
O texto deve ser revisado por todos os envolvidos no projeto e pelos potenciais usuários do sistema.
⇒ Atividade: Determinação dos casos de uso
Identifica-se inicialmente a partir do documento de requisitos os principais casos de uso e os atores do sistema. O resultado desta atividade é uma lista com os nomes de cada caso de uso suas descrições e respectivos atores associados.
Estes casos de uso representam os requisitos do sistema em alto nível e servem com unidade de trabalho e medida de sua evolução e entrega ao usuário.
⇒ Atividade: Primeira validação pelos usuários
A lista de casos de uso é apresentada aos usuários para validação, o usuário aprova os casos de uso ou reprova apresentando nestes casos as razões para tal.
⇒ Atividade: Correção dos casos de usos não aprovados
É feita uma análise e os erros são corrigidos ou as razões para a não correção são apresentadas. Este trabalho é apresentado ao usuário voltando a um novo ciclo de validação. Este ciclo iterativo irá até que os problemas sejam resolvidos. Ao final desta etapa é gerada a lista de casos de uso revisada. Os diagramas de casos de uso são desenvolvidos.
⇒ Atividade: Modelagem do domínio
A modelagem do Domínio é a tarefa de descobrir os objetos que representam as coisas e os conceitos que envolvem o domínio do problema do sistema em questão
O modelo do domínio é feito concomitantemente ao levantamento de requisitos.
Nesta modelagem se busca descobrir quais são as principais classes de objetos que formarão a estrutura do sistema. É essencialmente um trabalho de abstração do analista para descobrir as classes que representam as principais entidades e conceitos do sistema e como se
relacionam. O modelo do domínio serve como uma síntese da idéia do sistema e glossário para o levantamento de requisitos. O modelo do domínio é representado pelo Diagrama de Classes do sistema.
⇒ Atividade: Determinação do curso típico de eventos de cada caso de uso
A partir de cada caso de uso da lista são elaborados os cursos típicos de eventos que são compostos por interações entre o ator e o sistema. Um curso típico de ação sempre inicia com uma ação do ator e prossegue com a interação entre o ator e respectivas respostas do sistema. Podem surgir caminhos alternativos e exceções que devem ser considerados. Protótipos das interfaces com os usuários podem ser utilizados para facilitar a determinação da interação sistema usuário. Nesta etapa é interessante o uso de diagramas de seqüência.
⇒ Atividade: Segunda validação dos usuários
Todo o material elaborado é apresentado aos usuários para uma segunda validação. Assim o trabalho de análise e toda a modelagem poderão ser avaliados pelo usuário. Além das listas de casos de uso com suas descrições, interfaces, diagramas, são apresentados os respectivos cursos típicos de eventos e seus caminhos alternativos. É através dos cursos típicos de eventos que o usuário tomará conhecimento sobre o que é feito para se cumprir determinada funcionalidade do sistema, ou seja, quais passos devem ser seguidos para chegar-se a um dado objetivo.O usuário deverá aprovar os casos de usos ou reprová-los, neste caso apresentando as razões da reprovação.
⇒ Atividade: Correção dos casos de usos não aprovados
Após a correção dos erros, os casos de uso vão sendo reapresentados para novas tentativas de validação. Este ciclo irá até a completa compreensão e aprovação dos casos de uso.