Baixe o app para aproveitar ainda mais
Prévia do material em texto
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Definição de universo de informações A especificação de requisitos deve incluir não somente as especificações do domínio do problema, mas também qualquer tipo de informação que descreva o contexto do sistema. Esse contexto é conhecido como universo de informações, que é a realidade circunstanciada pelo conjunto de objetivos definidos pelos que demandam o software, e inclui todas as fontes de informação e todos os stakeholders. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Definição de domínio do problema • O domínio do problema é o domínio de atuação do software e inclui todos os elementos que interagem com ele. • O domínio do problema é, portanto, o ambiente de atuação do software. Neste ambiente principiam as atividades da engenharia de software, a definição das necessidades do software. • É tarefa dos engenheiros de requisitos entender o problema, na cultura e linguagem dos usuários, e definir um sistema que atenda às suas necessidades. Para tal, o engenheiro de requisitos deve descobrir e estabelecer o universo de informações, de onde obtém os recursos na tarefa de elucidação do problema. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Definição do domínio da solução • No domínio da solução é enfocada a definição da solução aos problemas dos usuários. • Os desenvolvedores do software aplicam seus conhecimentos em busca da especificação do sistema a ser desenvolvido. • Envolve as características da solução e os requisitos do sistema. • Uma característica é definida como um serviço que o sistema provê para cumprir uma ou mais necessidades dos stakeholders. • Uma vez estabelecido o conjunto de características com a concordância dos stakeholders, deve-se definir os requisitos mais específicos que serão necessários impor a solução. • Requisitos são propriedades que um sistema de software deve ter. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Requisitos • Funcionais – representam os comportamentos que um programa ou sistema deve apresentar diante de certas ações de seus usuários. • Não-funcionais – quantificam determinados aspectos do comportamento. (Ex: tempo de resposta, tempo médio entre falhas, etc.). Especificações dos requisitos: • Explícitos – são aqueles descritos em um documento que arrola os requisitos de um produto, ou seja, a especificação de requisitos. • Normativos – são aqueles que decorrem de lei, regulamentos e outros tipos de normas a que o produto deve obedecer. • Implícitos – são expectativas dos clientes e usuários, que são cobradas por esses, embora não documentadas. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Processo de Aquisição e Especificação de Requisitos Elicitação (Levantamento) de Requisitos – Fontes – Stakeholders • Clientes • Usuários • Desenvolvedores – Documentos – Livros – Sistemas de software (específico da organização ou software comercial) Levantamento de requisitos – Técnicas – Levantamento orientado a pontos de vista – Cenários ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Levantamento orientado a pontos de vista • Normalmente, há diferentes tipos de usuário final e, em função disso, diferentes pontos de vista. • Os pontos de vista podem ser organizados de forma hierárquica, como por exemplo: Todos os pontos de vista Cliente Pessoal do banco Caixa Gerente Engenheiro Não-titular da conta Titular da conta Serviços Consultar saldo Retirar dinheiro Serviços Pedir cheques Enviar mensagem Executar transação da lista Pedir extrato Transferir fundos Referência: Atributos: Eventos: Serviços: Subpontos de vista: Cliente Número da conta PIN Início da transação Selecionar serviço Cancelar transação Encerrar transação Retirada de dinheiro Consulta de saldo Titular da conta Não-titular da conta Referência: Razão: Especificações: Pontos de vista: Requisitos não funcionais: Provedor: Retirada de dinheiro Melhorar serviço do cliente e reduzir trabalho com papel Usuários escolhem o serviço pressionando o botão de retirada de dinheiro. Em seguida, informam a quantia solicitada. A operação é confirmada e, se o saldo permitir, o dinheiro é entregue. Cliente Entregar o dinheiro um minuto após ser confirmada e quantia. Preenchido posteriormente ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Levantamento orientado a pontos de vista (continuação) ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Cenários • Cada cenário aborda um ou um pequeno número de possíveis interações. • O cenário geralmente começa com um esboço da interação e, durante o levantamento de requisitos, são acrescentados detalhes para criar uma distribuição completa dessa interação. • O cenário pode incluir: • uma descrição de estado do sistema no início do cenário; • uma descrição do fluxo normal de eventos no cenário; • uma distribuição do que pode sair errado e de como lidar com isso; • informações sobre outras atividades que possam estar em andamento ao mesmo tempo; • uma descrição do estado do sistema no final do cenário. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Métodos de Coleta de Requisitos Algumas técnicas das ciências sociais, como psicologia e sociologia, têm sido estudadas e utilizadas nesta atividade, que envolve fatores comportamentais e de relacionamento humano. Entre os métodos mais comuns estão: • análise de documentos; • entrevistas (tutoriais, estruturadas, não-estruturadas, semi-estruturadas); • reuniões (Participatory Design, Joint Application Design e Brainstorming); • observações; • etnografia. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Análise de documentos • A análise de documentos é uma técnica usualmente aplicada na qual explora-se o conhecimento escrito encontrado no universo de informações. • A análise dos documentos permite um contato com o vocabulário utilizado no domínio do problema e auxilia na construção do glossário de termos especializados, que tem por objetivo definir os objetos e equalizar o conhecimento dos stakeholders. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Técnicas de entrevistas • Entrevista é uma técnica de interação entre entrevistado (especialista do conhecimento) e entrevistador (engenheiro de requisitos) buscando revelar conceitos, objetos e a organização do domínio do problema, além de buscar soluções ou projeções de soluções que comporão o domínio da solução. • Entrevistas tutoriais - o entrevistado fica no comando, praticamente lecionando sobre um determinado assunto. • Entrevistas informais (não estruturadas) - o entrevistador age espontaneamente, perguntando ao entrevistado sem obedecer a nenhuma organização. Esse tipo de entrevista oferece flexibilidade ao entrevistador e, normalmente, é utilizado no início do processo de elicitação. • Entrevistas estruturadas - são preparadas pelo entrevistador, que define previamente o andamento do procedimento de aquisição de conhecimento. • Entrevistas semi-estruturadas – são entrevistas que misturam as características das entrevistas estruturadas e das entrevistas não estruturadas. • Um fator importante a ser considerado nas entrevistas é o registro das informações coletadas, que pode ser realizado através de anotações ou gravações de áudio ou vídeo. O material produzido deve ser organizado e serve como base para a preparação da próxima entrevista. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOSTécnicas de reuniões Reunião - Permite uma interação mais natural entre os participantes e que podem oferecer múltiplas visões sobre a questão abordada. • Joint Application Design, Participatory Design e Brainstorming são metodologias de reuniões que enfatizam a participação coletiva na elicitação de requisitos. • Joint Application Design (JAD) - Baseia-se em sessões estruturadas e disciplinadas, onde os envolvidos reúnem-se para desenvolver juntos o sistema de software. Em linhas gerais, essas sessões possuem uma agenda detalhada, recursos visuais para auxiliar a exposição de idéias, um moderador e um relator que registra as especificações de acordo comum entre os membros do grupo. O produto final é um documento que contém definições do software. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Técnicas de reuniões (continuação) • Participatory Design (PD) é uma abordagem que concentra-se mais fortemente no envolvimento dos usuários, em relação ao Joint Application Design, por facilitar o processo de aprendizado entre desenvolvedores e usuários através de experiências conjuntas em situações de trabalho simuladas. Em linhas gerais, os usuários são introduzidos no ambiente dos desenvolvedores, conhecendo possibilidades técnicas e, da mesma maneira, os desenvolvedores colaboram com os usuários em suas tarefas. Ocorre um aprendizado mútuo que vem a contribuir no processo de definição dos requisitos. • Braistorming - A filosofia básica do brainstorming é procurar deixar que venham a tona todas as idéias possíveis, sem que estas sofram quaisquer críticas durante o processo de criação. Isto diminui os bloqueios, e permite que as idéias fluam melhor. Isto faz com que o inconsciente comece a desbloquear parte do raciocínio não-lógico que estava bloqueado e, quando bem aplicado, seja um poderoso instrumento de trabalho. Nesta reunião, a característica principal é a total ausência de crítica e o julgamento adiado. As idéias que surgirem serão anotadas, por mais loucas que possam parecer, e nunca sofrerão críticas na hora em que forem formuladas. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Técnica de observação • Observação é uma técnica na qual o engenheiro de requisitos procura ter uma posição sobre o domínio do problema, observando seus elementos e comportamentos. • Visa obter um entendimento inicial sobre o contexto em estudo. • As observações consistem em observar alguém no momento da realização de suas tarefas rotineiras no ambiente real. • O observador procura familiarizar-se com o domínio do problema e elicitar as informações necessárias para o seu entendimento. • A aquisição desse conhecimento pode ocorrer com interrupção ou não das atividades do observador. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Etnografia • Outra técnica que pode ser aplicada de forma complementar com o intento de permitir uma visão mais completa e ajustada do domínio do problema é a etnografia. • Etnografia é a coleta direta, e o mais minuciosa possível, dos fenômenos observados, por uma impregnação duradoura e contínua e um processo que se realiza por aproximações sucessivas. • É originária da antropologia, em observações de práticas das sociedades. • No contexto da engenharia de requisitos, é uma técnica que busca revelar informações sobre a estrutura, organização e práticas do domínio do problema. • A etnografia, segundo conclusão do projeto realizado, pode levar a obtenção de requisitos fechados à prática corrente, o conhecimento tácito. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Validação de Requisitos A validação de requisitos se ocupa em mostrar que os requisitos realmente definem o sistema que o cliente deseja. Principais verificações de requisitos: • Verificações de validade – O sistema deve conciliar as necessidades de todos os seus usuários. • Verificações de consistência – Os requisitos em um documento não devem ser conflitantes, ou seja, não devem existir restrições contraditórias. • Verificações de completeza – O documento de requisitos deve incluir requisitos que definam todas as funções e restrições exigidas pelo usuário do sistema. • Verificações de realismo – Um conjunto de verificações deve ser projetado para mostrar que o sistema entregue cumpre com seus requisitos. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Validação de Requisitos (continuação) Técnicas de validação de requisitos: • Revisões de requisitos – É um processo manual, que envolve muitos leitores, tanto do pessoal do cliente como do fornecedor, que verifica o documento de requisitos a fim de detectar anomalias ou omissões. • Prototipação – É fornecido um modelo do sistema para que o usuário possa verificar se o sistema atenderá às suas necessidades. • Análise automatizada da consistência - Utilização de ferramenta CASE para fazer a de consistência dos requisitos. Registro dos requisitos 1. Missão do Produto 2. Limites do Produto 3. Lista de requisitos funcionais • Nome e descrição do requisito • Identificação do ator • Necessidades e Benefícios • Estabilidade • Prioridade 4. Descrição dos atores 5. Regras de Negócio 6. Lista de requisitos não funcionais 7. Lista dos requisitos de persistência ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 1. Missão do Produto Descrever os objetivos do produto que deverá ser desenvolvido no projeto. De preferência, usar um único parágrafo que sintetize a missão a ser desempenhada pelo produto, ou seja, que valor o produto acrescenta para o cliente e os usuários. A declaração de missão deve cumprir os seguintes objetivos: • delimitar as responsabilidades do produto; • delimitar o escopo do produto; • sintetizar o comprometimento entre cliente e fornecedor. Exemplo: O produto Merci 1.0 visa a oferecer apoio informatizado ao controle de vendas, de estoque, de compra e de fornecedores da mercearia Pereira & Pereira. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 2. Limites do Produto Deve-se determinar o que o produto não fará. Isso evita falsas expectativas por parte dos clientes e usuários e podem ressaltar funções e atributos que serão implementados por outros componentes de um sistema maior, ou em versões futuras desse produto. Exemplo: 1. O sistema não fará vendas parceladas e só receberá pagamentos em dinheiro ou cheque. 2. O backup e a recuperação das bases de dados do sistema ficam a cargo da administração, não sendo providos pelo sistema. 3. O sistema não terá ajuda on-line. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 3. Lista de requisitos funcionais – Nome e descrição do requisito Os requisitos funcionais definem as ações fundamentais através das quais o produto aceita e processa as entradas especificadas, gerando as respectivas saídas. Exemplo: Número Requisito Descrição 1 Manter mercadoria Realizar o cadastro (inclusão, alteração, exclusão e consulta dos dados de uma mercadoria. 2 Manter pedido de compra Realizar o cadastro (inclusão, alteração, exclusão e consulta dos dados de umpedido de compra. 3 Abrir caixa Dar início às operações do caixa. 4 Fechar caixa Encerrar as operações do caixa. 3. Lista de requisitos funcionais – Identificação dos atores Na terminologia da UML, qualquer elemento externo que interage com o sistema é denominado ator. Note que um ator corresponde a um papel representado em relação ao sistema. Critérios para identificação dos atores: • quem está interessado em certo requisito; • quem se beneficiará diretamente do produto; • quem usará informação do produto; • quem fornecerá informação ao produto; • quem dará suporte e manutençãoao produto; • quais os recursos externos usados pelo produto; • quais os papéis desempenhados por cada usuário; • quais os grupos de usuários que desempenham o mesmo papel; • quais os sistemas legados com os quais o produto deve interagir; • o tempo, quando os casos de uso são disparados periodicamente, de forma automática. Exemplo: Caixa, Atendente, Sistema Financeiro, Setor de Cadastro, etc. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 3. Lista de requisitos funcionais – Identificação dos atores (continuação) Os atores podem ser classificados em: Ator Primário • É aquele que inicia uma seqüência de interações de um caso de uso; • É um agente externo para o qual o caso de uso traz benefício direto; • As funcionalidades principais do sistema são definidas tendo em mente os objetivos dos atores primários. Ator Secundário • É aquele que supervisiona, opera, mantém ou auxilia na utilização do sistema; • Existem apenas para que os atores primários possam utilizar o sistema. Exemplo-1: Considere um programa para navegar na Internet (browser). Para que o usuário (ator primário) requisite uma página ao programa, um outro ator (secundário) está envolvido: o Servidor Web. Exemplo-2: Quando um cliente precisa da ajuda do vendedor para registrar suas compras no sistema, o cliente é o ator primário e o vendedor o ator secundário. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 3. Lista de requisitos funcionais – Nome e descrição do requisito Os requisitos funcionais definem as ações fundamentais através das quais o produto aceita e processa as entradas especificadas, gerando as respectivas saídas. Exemplo: Número Requisito Descrição Ator 1 Manter mercadoria Realizar o cadastro (inclusão, alteração, exclusão e consulta dos dados de mercadorias. Gerente de Compras 2 Manter fornecedor Realizar o cadastro (inclusão, alteração, exclusão e consulta dos dados de fornecedores. Gerente de Compras 3 Manter pedido de compra Controlar os pedidos de compra feitos aos fornecedores. Gerente de Compras 4 Abrir caixa Dar início às operações do caixa. Caixa 5 Fechar caixa Encerrar as operações do caixa. Caixa 3. Lista de requisitos funcionais – Necessidades e Benefícios Deve-se identificar as necessidades que os requisitos atenderão e os benefícios que eles podem proporcionar. O levantamento dos benefícios é necessário para determinar se o valor dele compensará o investimento no projeto. Exemplo: ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Núm. Requisito Ator Necessidades Benefícios 1 Manter mercadoria Gerente de Compras Identificação das mercadorias. Fornecer dados para outras funções Agilidade na compra e venda de mercadorias. Melhoria do conhecimento dos produtos comercializados. 2 Manter fornecedor Gerente de Compras Atualizar os dados dos fornecedores. Atualizr a lista de produtos comercializados por cada fornecedor. Fornecer dados para outras funções Controle dos dados de fornecedores. Conhecimento do mercado de fornecedores. Avaliação da qualidade de fornecimento. 3 Manter pedido de compra Gerente de Compras Registro dos pedidos de compra. Controle de cancelamento de pedidos. Acompanhamento do prazo de entrega. Registro da recepção das mercadorias. Fornecer dados para outras funções Apoio na avaliação das melhores condições de preço e menores prazos de entrega. Eliminação da duplicidade de pedidos. Identificação de mercadorias não entregues. 4 Abrir caixa Caixa Colocar o caixa no modo de venda, informando o seu valor de abertura. Ter controle dos valores de cada abertura do caixa. Diminuição de erros na prestação de contas. 5 Fechar caixa Caixa Encerrar as operações do caixa, apurando o total das transações realizadas. Ter controle da movimentação do período. Diminuição de erros na prestação de contas. 3. Lista de requisitos funcionais – Prioridade Representa o valor atribuído ao requisito, pelo cliente, em função do(s) benefício(s) que ele lhe proporcionará. A prioridade é classificada em: • Essencial – O requisito é fundamental. Sua falta acarretará o não atendimento das necessidades do cliente. • Desejável – A existência do requisito contribuirá para o atendimento das necessidades do cliente, mas a sua falta é aceitável. • Opcional – A existência do requisito está condicionada a sobra de recursos, prazo, etc. Sua falta não prejudica o atendimento das necessidades do cliente. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 3. Lista de requisitos funcionais – Estabilidade Representa a probabilidade do requisito ser alterado no decorrer do projeto, com base na experiência de projetos correlatos. A estabilidade é classificada em: • Alta – O requisito tem pouca chance de mudar no decorrer do projeto. • Média – A probabilidade do requisito mudar no decorrer do projeto estaria em torno de 50% de chance. • Baixa – O requisito tem grande chance de mudar no decorrer do projeto. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Exemplo: Lista de requisitos funcionais – Prioridade e Estabilidade Número Requisito Funcional Ator Prioridade Estabilidade 1 Manter mercadoria Gerente de Compras Essencial Média 2 Manter fornecedor Gerente de Compras Essencial Baixa 3 Manter pedido de compra Gerente de Compras Opcional Baixa 4 Abrir caixa Caixa Essencial Média 5 Fechar caixa Caixa Essencial Média 4. Descrição dos Atores Para cada ator deve-se incluir uma descrição sucinta das responsabilidades do respectivo papel. Deve-se também identificar as características mais importantes do respectivo grupo de usuários. Exemplo de descrição dos atores: ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Ator Descrição Caixa Funcionário operador comercial do caixa. Gerente de Compras Funcionário responsável pela gestão dos cadastros de mercadorias e fornecedores, e pela emissão e acompanhamento de pedidos de compra. Sistema Financeiro Sistema de gestão financeira que recebe os detalhes financeiros das transações diárias, para utilização posterior pela administração financeira da mercearia. 5. Regras de Negócio Segundo o Business Rules Group (BRG) pode-se definir regra de negócio segundo dois aspectos: ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Sistemas de informação Negócio Regra de negócio é “uma sentença que define ou restringe algum aspecto do negócio (...) sua intenção é manter a estrutura do negócio, ou controlar ou influenciar algum aspecto do negócio”. Nesse contexto, as regras de negócio dizem respeito aos “dados que podem ser cadastrados em um sistema de informação”. Regras de negócio são “diretivas que visam influenciar ou guiar o comportamento do negócio. Tais diretivas existem como suporte a políticas de negócio, formuladas em resposta a riscos, ameaças ou oportunidades”. 5. Regras de Negócio (continuação) ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 5. Regras de Negócio (continuação) Classificação das Regras de Negócio: Regras de Rejeição (Rejector): são regras que rejeitam um evento porque ele conduz o sistema a um estado que não é permitido. As restrições de integridade em bancos de dados são exemplos desse tipo de regra. Ex1: “Uma conta não pode ter saldo negativo”. Ex2: “Um time não pode ter mais que 11 jogadores em campo”. Regras de Projeção (Projector): são regras que projetam o evento em outros eventos alterando os fluxos de execução. Ex1: “Ao criar um cliente, deve ser criada uma nova conta para ele”. Ex2: “Seuma conta tiver saldo maior que 5.000, enviar folheto sobre investimentos”. Regras de Produção (Productor): são regras que não respondem a eventos, elas apenas definem informações do negócio. Ex1: “Saldo é igual a crédito menos débito” Ex2: “Uma conta é “Ouro Especial” se seu saldo atual é superior a 30.000 e seu médio saldo médio é superior a 20.000.” ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 5. Regras de Negócio (continuação) Exemplo: ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Nome Condição para realização do pedido de compra (RN01) Descrição Somente serão aceitos pedidos de compra para fornecedores que tenham menos do que 3 ocorrências de entrega fora do prazo. Obs: Esta regra de negócio deverá ser aplicada no requisito Incluir pedido de compra. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Requisitos Não Funcionais Requisitos do produto Requisitos organizacionais Requisitos externos Requisitos éticos Requisitos de interoperabilidade Requisitos legais Requisitos de segurança Requisitos de privacidade Requisitos de implementação Requisitos de espaço Requisitos de desempenho Requisitos de eficiência Requisitos de facilidade de uso Requisitos de confiabilidade Requisitos de portabilidade Requisitos de entrega Requisitos de padrões 6. Lista de requisitos não funcionais Os requisitos não funcionais podem ser classificados segundo a seguinte estrutura hierárquica 6. Lista de requisitos não funcionais (continuação) Exemplos: ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS RNF01 O tempo de totalização da Operação de Venda (isto é, o intervalo de tempo entre qualquer alteração nos itens de venda e a exibição do total a pagar) não pode ser maior do que 2 segundos. RNF02 O tempo para realização de qualquer operação de pesquisa de usuários, mercadorias, fornecedores ou pedidos de compra não pode ser maior do que 10 segundos. RNF03 O leiaute do relatório Nota Fiscal deve ser previamente aprovado pela Secretaria de Receita. RNF04 O Merci deverá ser desenhado de forma que possa ser expandido para mais de um terminal. 7. Lista dos Requisitos de Persistência Requisitos de persistência são representados através das classes de entidade, com seus atributos e operações. Possíveis Notações para uma Classe na UML Nome da Classe Nome da classe Nome da classe Nome da classe Lista de atributos Lista de operações Lista de atributos Lista de operações Atributos – descrição dos dados armazenados pelos objetos de uma classe. Cada atributo de uma classe está associado a um conjunto de valores que esse atributo pode assumir. Operações – correspondem à descrição das ações que os objetos de uma classe sabem realizar. O nome de uma operação, normalmente, contém um verbo e um complemento e termina com um par de parênteses. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 7. Lista dos Requisitos de Persistência (continuação) Técnica para identificação das classes - procurar substantivos existentes nos fluxos dos casos de uso. • eliminar aspectos de implementação e conceitos irrelevantes quanto à missão do produto; • resolver ambigüidades da linguagem; • considerar também locuções verbais, desde que equivalentes a substantivos; • considerar que substantivos podem não resultar em classes, mas em objetos, relacionamentos ou atributos de classes; • permanecer no nível lógico, não incluindo detalhes da implementação; • permanecer dentro do escopo do produto, evitando classes não conexas com a missão. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 7. Lista dos Requisitos de Persistência (continuação) Especificação das classes • Deve-se escolher nomes significativos, isto é, substantivo no singular; • Deve-se evitar nomes vagos, assim como nomes reservados da própria metodologia (classe, tipo, etc.); • Deve-se utilizar nomes que façam parte do domínio do negócio. Ao longo da análise, a especificação das classes será completada com outros aspectos relevantes, como: • Operações necessárias para cumprir as responsabilidades; • Atributos necessários para cumprir as responsabilidades. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 7. Lista dos Requisitos de Persistência (continuação) Nomenclatura para o diagrama de classes na UML • Para identificadores – quaisquer espaços em branco e preposições do nome são removidos. • Para nomes de classes e nomes de relacionamentos – começar com letra maiúscula. Exemplo: Cliente, ItemPedido, Pedido, etc. • Para nomes de atributos e nomes de operações – escrever a primeira palavra do nome em minúsculas e as palavras subseqüentes, sem espaço em entre elas, começando com a letra em maiúsculo. No entanto, siglas são mantidas inalteradas. Exemplo: quantidade, precoUnitario, CPF, dataNascimento, etc. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 7. Lista dos Requisitos de Persistência (continuação) Exemplos de classes ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Nome da classe Descrição da classe Atributos da classe Fornecedor representa os fornecedores da empresa nome CNPJ contato telefone PedidoCompra representa os pedidos feitos pelos aos fornecedores da empresa dataPedido status Obs: A associação existente entre Fornecedor e PedidoCompra (um fornecedor fornece muitos pedidos e um pedido é fornecido por somente um fornecedor) só ficará evidente após a construção do diagrama de classes. Não pode existir nenhum atributo na classe PedidoCompra, nem na classe Fornecedor, que tente representar essa associação. 7. Lista dos Requisitos de Persistência (continuação) Diagrama de Objetos (ou Diagrama de Instâncias) • Podem ser vistos como instâncias de diagramas de classes, da mesma forma que objetos são instâncias de classes; • Assim como diagramas de classes, diagramas de objetos são estruturas estáticas. Um diagrama de objetos exibe uma “fotografia” do sistema em um certo momento; • Cada objeto é representado por um retângulo com dois compartimentos. • No compartimento superior, a identificação do objeto é exibida • No compartimento inferior, quando utilizado, exibe uma lista de pares da forma nome do atributo: valor do atributo; • A identificação do onjeto deve ser sempre sublinhada. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 7. Lista dos Requisitos de Persistência (continuação) Exemplo de Diagrama de Objetos: ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS Pedido1:Pedido data = 13/09/2002 status = “A” Item1:ItemPedido quantidade = 6 Item2:ItemPedido quantidade = 20 Item3:ItemPedido quantidade = 1 Mercadoria20:Mercadoria nome = “caderno M” descrição = “caderno em espiral tamanho médio” Mercadoria12:Mercadoria nome = “caneta esf” descrição = “caneta esferográfica 5 mm” Mercadoria07:Mercadoria nome = “esquadro” descrição = “esquadro de acrílico 20 cm Fornecedor10:Fornecedor nome = “Distribuidora XYZ” CNPJ = 30502231000129 contato = “Maria” telefone = 2126657588 Referências Bibliográficas Rocco, Giovanni Ely. Engenharia de Requisitos. Universidade de Caxias do Sul - Centro de Ciências Exatas e Tecnologia - Departamento de Informática. Alenquer , Pablo Lopes . Regras de Negócio para Análise em Ambientes OLAP. Disponível em http://genesis.nce.ufrj.br/dataware/DataWarehouse/Teses/Pablo/TesePablo.pdf Acesso em 02/11/2005. Bezerra, Eduardo. Princípios da Análise e Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, 2002. Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões.Rio de Janeiro: LTC, 2003. Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte III. Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003. ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Compartilhar