Análise de Sistemas Orientada a Objetos

Aula 02 – Requisitos

Engenharia de Requisitos – análise e negociaçãoApós a identificação dos requisitos do sistema, segue-se à etapa de análise dos requisitos e negociação.

Algumas das atividades envolvidas na análise de requisitos incluem:

• classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para o sistema;

• resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível;

• priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); este pode ser um fator gerador de conflitos;

• confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade.

A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho.

Engenharia de Requisitos – análise e negociaçãoAs dificuldades encontradas na análise são de diversas naturezas:

• fatores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão, pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demais interessados que irão operar o sistema);

• o ambiente (econômico e/ou organizacional) em que a análise é feita possui fatores dinâmicos, e como tal, os requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos e orçamentos disponíveis).

Engenharia de Requisitos – análise e negociaçãoNa fase de negociação, tornam-se necessários alguns cuidados para que esta decorra sem problemas, chegando-se logo a consensos. Algumas sugestões são:

• saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde, fora de reunião), de preferência nunca tomando partidos;

• fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação;

• salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos;

• relaxar restrições, quando se torna óbvio que as atuais não levarão a um consenso.

Engenharia de Requisitos – especificação e documentaçãoÉ nesta fase que se dá a produção propriamente dita do Documento de Especificação de Requisitos.

Em todos os tipos de especificação há 2 tipos de requisitos a considerar:

• Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o usuário espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.

• Requisitos não-funcionais (de qualidade): referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.

Engenharia de Requisitos – especificação e documentaçãoExemplo de requisitos funcionais:

Engenharia de Requisitos – especificação e documentaçãoEXERCÍCIO:

Engenharia de Requisitos – especificação e documentaçãoRequisitos Não funcionais

• Demonstram qualidade acerca dos serviços ou funções disponibilizadas pelo sistema. Ex.: tempo, o processo de desenvolvimento, padrões, etc.

• Surgem conforme a necessidade dos usuários, em razão de orçamento e outros fatores.

• Podem estar relacionados à confiabilidade, tempo de resposta e espaço nas mídias de armazenamento disponíveis.

• Caso ocorra falha do não atendimento a um requisito não funcional, poderá tornar todo o sistema ineficaz. Ex.: requisito confiabilidade em um sistema de controle de voos.

Engenharia de Requisitos – especificação e documentaçãoClassificação dos Requisitos Não Funcionais

• Requisitos de produtos : Requisitos que especificam o comportamento do produto.Ex. portabilidade; tempo na execução; confiabilidade,mobilidade, etc.

• Requisitos da organização: Requisitos decorrentes de políticas e procedimentos corporativos. Ex. padrões, infra-estrutura,etc.

• Requisitos externos: Requisitos decorrentes de fatores externos ao sistema e ao processo de desenvolvimento. Ex. requisitos de interoperabilidade, legislação,localização geográfica etc.

• Requisitos de facilidade de uso. Ex.: usuários deverão operar o sistema após um determinado tempo de treinamento.

• Requisitos de eficiência. Ex.: o sistema deverá processar n requisições por um determinado tempo.

• Requisitos de confiabilidade. Ex.: o sistema deverá ter alta disponibilidade, p.exemplo, 99% do tempo.

Engenharia de Requisitos – especificação e documentaçãoClassificação dos Requisitos Não Funcionais

• Requisitos de portabilidade. Ex.: o sistema deverá rodar em qualquer plataforma.

• Requisitos de entrega.Ex.: um relatório de acompanhamento deverá ser fornecido toda segunda-feira.

• Requisitos de implementação.: Ex.: o sistema deverá ser desenvolvido na linguagem Java.

• Requisitos de padrões.: Ex. uso de programação orientada a objeto sob a plataforma A.

• Requisitos de interoperabilidade.:Ex. o sistema deverá se comunicar com o SQL Server.

• Requisitos éticos. Ex.: o sistema não apresentará aos usuários quaisquer dados de cunho privativo.

• Requisitos legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, etc.

• Requisitos de Integração. Ex.: o sistema integra com outra aplicação.

Engenharia de Requisitos – especificação e documentaçãoRequisitos de Domínio

Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e não de necessidades específicas dos usuários, podendo depois ser classificados como funcionais ou não-funcionais.

Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas. Dois exemplos de requisitos do domínio são:

• O calculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3)/5;

• Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pré-requisitos.

Engenharia de Requisitos – especificação e documentaçãoRequisitos de Domínio - Exemplos

Engenharia de Requisitos – especificação e documentaçãoRequisitos de Domínio - Exercício

Engenharia de Requisitos – especificação e documentaçãoRequisitos de Domínio – Respostas

Engenharia de Requisitos – especificação e documentaçãoA documentação produzida poderá ter diferentes destinatários e como tal diferentes objetivos. Podem-se distinguir três tipos de especificação:

• especificação de requisitos do usuário;

• especificação de requisitos do sistema;

• especificação do design da aplicação

A vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando "linguagens" que o usuário conheça).

Por exemplo, enquanto que nos requisitos do usuário apenas é feita uma abordagem de alto nível das funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas (esquemas).

Nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitos relativos à arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notações gráficos como diagramas de casos de uso).

Engenharia de Requisitos – especificação e documentaçãoOs requisitos do usuário destinam-se portanto aos vários níveis hierárquicos da organização na qual o sistema será implementado (desde gestores a usuários), pelo que são descritos usando apenas linguagem natural, formulários e diagramas muito simples. Obviamente, neste nível de especificação surgem algumas dificuldades:

• Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito longa ou de difícil compreensão.

• Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a distinção entre requisitos funcionais/não-funcionais e objetivos do sistema torna-se difícil.

• Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode tornar-se difícil separar claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo apenas um.

Engenharia de Requisitos – especificação e documentação• Algumas considerações úteis a ter em conta ao escrever uma

especificação de requisitos do utilizador:• Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a

verificação dos requisitos).

• Distinguir claramente entre comportamentos esperados e desejáveis do sistema através do uso de expressões como "O sistema permitirá criar (...)" ou "Deverá ser possível criar (...)" respectivamente. É importante deixar claro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões de forma consistente ao longo de todo o documento.

• Usar formatação de texto para salientar determinados aspectos do documento (usando negrito, por exemplo).

• Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessário usá-los.

Engenharia de Requisitos – especificação e documentaçãoRequisitos do sistema

• Os requisitos do sistema têm um carácter mais técnico;

• Descrição detalhada dos requisitos do usuário.

• Uso de linguagens estruturadas e notações gráficas.

• Estes requisitos, destinam-se ainda aos usuários do sistema (e particularmente aos engenheiros que trabalhem nessa organização) e destinam-se também às equipes de especificação de arquitetura do sistema e de desenvolvimento.

Engenharia de Requisitos – especificação e documentaçãoDesign da aplicação

• A especificação do design da aplicação consiste num documento usado pela equipe de desenvolvimento do sistema no qual estão definidos pormenores, em um nível mais técnico, acerca da implementação do sistema e sua arquitetura.

• A partir deste documento, um elemento que entre para a equipe de desenvolvimento no meio do projeto deverá ser capaz de "se situar" quando precisar de começar a codificar, compreendendo a forma como a implementação, em um nível global, está a ser feita, mas sem conhecer necessariamente os detalhes de implementação aprofundados.