Requisitos de Software

Transcrição

1 Requisitos de Software

2 Roteiro Conceitos Engenharia de requisitos Artigo

3 Definições de requisitos Requisitos de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas restrições operacionais (SOMMERVILLE, 2007). Um requisito de um sistema é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004). Um requisito é alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006).

4 Requisitos Correspondem a qualquer desejo, necessidade, restrição ou expectativa dos clientes em relação a um produto de software. Estes requisitos devem ser levantados pela equipe do projeto, em conjunto com representantes do cliente, usuários chaves e outros especialistas da área de aplicação. Requisitos têm um papel central no processo de software, sendo considerados um fator determinante para o sucesso ou fracasso de um projeto de software. O processo de levantar, analisar, documentar, gerenciar e controlar a qualidade dos requisitos é chamado de Engenharia de Requisitos.

5 Problema-chave: comunicação

6 Tipos de requisitos Requisitos Funcionais: São declarações de serviços que o sistema deve prover, descrevendo o que o sistema deve fazer (SOMMERVILLE, 2007). Um requisito funcional descreve uma interação entre o sistema e o seu ambiente (PFLEEGER, 2004), podendo descrever, ainda, como o sistema deve reagir a entradas específicas, como o sistema deve se comportar em situações específicas e o que o sistema não deve fazer (SOMMERVILLE, 2007).

7 Tipos de requisitos Requisitos Não Funcionais: Descrevem restrições sobre os serviços ou funções oferecidos pelo sistema (SOMMERVILLE, 2007), as quais limitam as opções para criar uma solução para o problema (PFLEEGER, 2004). Neste sentido, os requisitos não funcionais são muito importantes para a fase de projeto (design), servindo como base para a tomada de decisões nessa fase. Têm origem nas necessidades dos usuários, em restrições de orçamento, em políticas organizacionais, em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislações (SOMMERVILLE, 2007).

8 Requisitos Não Funcionais Classificação quanto à origem (SOMMERVILLE, 2007) Requisitos de produto: Referem-se a atributos de qualidade que o sistema deve apresentar, tais como confiabilidade, usabilidade, eficiência e segurança Requisitos organizacionais: são derivados de metas, políticas e procedimentos das organizações do cliente e do desenvolvedor. Exemplos: restrições de tempo, custo, linguagem de programação a ser adotada, etc. Requisitos externos: requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Exemplos: requisitos legais, éticos, interoperabilidade com outros sistemas, etc.

9 Níveis de descrição de requisitos Os requisitos devem ser redigidos de modo a serem passíveis de entendimento pelos diversos interessados (stakeholders). Clientes, usuários finais e desenvolvedores são todos interessados em requisitos, mas têm expectativas diferentes. Enquanto desenvolvedores e usuários finais têm interesse em detalhes técnicos, clientes requerem descrições mais abstratas. Assim, é útil apresentar requisitos em diferentes níveis de descrição. Sommerville (2007) sugere dois níveis de descrição de requisitos.

10 Níveis de descrição de requisitos Requisitos de Usuário: são declarações em linguagem natural acompanhadas de diagramas intuitivos de quais serviços são esperados do sistema e das restrições sob as quais ele deve operar. Devem estar em um nível de abstração mais alto, de modo que sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico. Requisitos de Sistema: definem detalhadamente as funções, serviços e restrições do sistema. São versões expandidas dos requisitos de usuário usados pelos desenvolvedores para projetar, implementar e testar o sistema. Como requisitos de sistema são mais detalhados, as especificações em linguagem natural são insuficientes e para especificá-los, notações mais especializadas devem ser utilizadas.

11 Documentos de requisitos Uma vez que requisitos de usuário e de sistema têm propósitos e público alvo diferentes, é útil descrevê-los em documentos diferentes. Pfleeger (2004) sugere que dois tipos de documentos de requisitos sejam elaborados:

12 Documentos de requisitos Documento de Definição de Requisitos: deve ser escrito de maneira que o cliente possa entender, i.e., na forma de uma listagem do quê o cliente espera que o sistema proposto faça. Ele representa um consenso entre o cliente e o desenvolvedor sobre o quê o cliente quer. Documento de Especificação de Requisitos: redefine os requisitos de usuário em termos mais técnicos, apropriados para o desenvolvimento de software, sendo produzido por analistas de requisitos.

13 Engenharia de requisitos A Engenharia de Requisitos pode ser descrita como um processo, ou seja, um conjunto organizado de atividades que deve ser seguido para derivar, avaliar e manter os requisitos e artefatos relacionados. Uma descrição de um processo, de forma geral, deve incluir, além das atividades a serem seguidas, a estrutura ou sequência dessas atividades, quem é responsável por cada atividade, suas entradas e saídas, as ferramentas usadas para apoiar as atividades e os métodos, técnicas e diretrizes a serem seguidos na sua realização.

14 Engenharia de requisitos De maneira geral, o processo de Engenharia de Requisitos envolve as seguintes atividades

15 Levantamento de requisitos Nesta fase, os usuários, clientes e especialistas de domínio são identificados e trabalham junto com os engenheiros de requisitos para entender a organização, o domínio da aplicação, os processos de negócio a serem apoiados, as necessidades que o software deve atender e os problemas e deficiências dos sistemas atuais. Os diferentes pontos de vista dos participantes do processo, bem como as oportunidades de melhoria, restrições existentes e problemas a serem resolvidos devem ser levantados. O objetivo é entender o que o cliente espera do software. Resultados esperados: narrativa em linguagem natural dos requisitos do sistema.

16 Técnicas Entrevistas Oficinas (workshops) Reuniões de Brainstorming Prototipação Maquetes Análise de documentação existente Análise de sistemas existentes Observação de pessoas trabalhando Análise de mercado Etc

17 Cliente x Usuário Final Nem sempre o cliente é o usuário final Cliente Quem contrata e paga pelo serviço Ex.: Administrador de um hospital Usuário final Quem usa o software no dia a dia Ex.: Médicos e enfermeiros Importante Nunca deixe de elicitar requisitos com os usuários finais pois sem a colaboração deles, o software não será usado

18 Escolha dos usuários fonte Alguns sistemas serão utilizados por milhares ou milhões de usuários Escolha usuários fonte dos requisitos que sejam representativos Lembre-se que a regra de Pareto (80-20) aparenta ser válida 20% dos requisitos satisfazem a 80% dos usuários Escolher um usuário muito especialista pode levar a implementação de requisitos que nunca serão utilizados

19 Requisitos funcionais Narrativa livre O sistema deve mostrar uma mensagem de status em intervalos não menores que 60 segundos Lista de requisitos RF-1: Uma mensagem de status deve ser mostrada na área inferior da janela (desenho da Fig.1) RF-2: A mensagem deve ser atualizada a cada 60 segundos, com tolerância de 10 segundos para mais ou para menos RF-3: A mensagem deve estar sempre visível RF-4: Se a mensagem for referente a uma tarefa em andamento, o percentual de andamento deve ser mostrado RF-5: Se a mensagem for referente a uma tarefa já terminada, isso deve ser informado com o texto Finalizada

20 Requisitos não funcionais Sinônimo: atributos de qualidade Disponibilidade DS-1: O sistema deve ficar disponível por 99,5% do tempo nos dias úteis, das 6h às 22h, e 99,95% do tempo nos dias úteis, das 16h às 18h Eficiência EF-1: Em condições de pico de uso, deve ter uma reserva de 25% de capacidade de processamento e memória EF-2: O cálculo de interferência deve ser finalizado com sucesso em menos de 5 minutos EF-3: O módulo de parser de XML deve processar de documentos por segundo

21 Exercício Para a agenda eletrônica estudada no exercício anterior, relacione os requisitos funcionais e os não funcionais para a agenda eletrônica.

22 Análise de requisitos Visa estabelecer um conjunto acordado de requisitos consistentes e sem ambiguidades, que possa ser usado como base para as atividades subsequentes do processo de software. Para tal, diversos tipos de modelos são construídos. Assim, a análise de requisitos é essencialmente uma atividade de modelagem. A análise de requisitos pode incluir, ainda, negociação entre usuários para resolver conflitos detectados. O objetivo é explicitar o conhecimento obtido no levantamento, transformando narrativas de linguagem natural para UML Resultados esperados Casos de uso Classes conceituais

23 Documentação de requisitos É a atividade de representar os resultados da Engenharia de Requisitos em um documento (ou conjunto de documentos), contendo os requisitos do software e os modelos que os especificam. O objetivo é produzir a especificação de requisitos Especificação de requisito engloba Requisitos funcionais Requisitos não funcionais

24 Verificação e Validação de requisitos A verificação de requisitos avalia se os requisitos estão sendo tratados de forma correta, de acordo com padrões previamente definidos, sem conter requisitos ambíguos, incompletos ou, ainda, requisitos incoerentes ou impossíveis de serem testados. Já a validação diz respeito a avaliar se os requisitos do sistema estão corretos, ou seja, se os requisitos e modelos documentados atendem às reais necessidades de usuários e clientes. O objetivo é assegurar que a especificação de requisitos está consistente Problemas comuns: ambigüidade, inconsistência, omissão, erro

25 Exemplos de ambiguidade A janela deve abrir rapidamente O sistema deve ser flexível O cálculo deve ser eficiente A interface com o usuário deve ser melhor que a atual Não devem ser mostradas muitas mensagens de erro A exibição do mapa de navegação deve ser amigável

26 Gerência de requisitos Se preocupa em gerenciar as mudanças nos requisitos já acordados, manter uma trilha dessas mudanças e gerenciar os relacionamentos entre os requisitos e as dependências entre requisitos e outros artefatos produzidos no processo de software, de forma a garantir que mudanças nos requisitos sejam feitas de maneira controlada e documentada.

27 As atividades de requisitos no processo de software Em relação ao processo de software, das cinco atividades do processo de Engenharia de Requisitos anteriormente listadas, apenas as três primeiras fazem parte do processo de desenvolvimento (Levantamento, Análise e Documentação de Requisitos). A atividade de Verificação e Validação de Requisitos é uma importante atividade do processo de Gerência da Qualidade e um instrumento fundamental para a garantia do projeto como um todo, tendo em vista que os requisitos são a base para o sucesso de um projeto de software. A atividade de Gerência de Requisitos pode ser vista como a Gerência de Configuração aplicada a requisitos.

28 10 princípios de engenharia de requisitos Primeiro passo para se resolver um problema é entender o problema Não basta comunicar, é necessário entender! Princípio 1: Escute Tente prestar a atenção no que o interlocutor fala Evite interromper a linha de raciocínio do interlocutor Peça detalhes de algo que não ficou claro Não desestimule seu interlocutor com gestos ou palavras

29 10 princípios de engenharia de requisitos Princípio 2: Se prepare antes da reunião Tente entender o problema antes da reunião Tente compreender qual é o jargão utilizado no domínio Elabore uma agenda para a reunião Princípio 3: É importante ter um mediador O mediador é responsável por manter a reunião com foco apropriado O mediador é responsável por resolver conflitos Princípio 4: Comunicação face a face é o ideal Na comunicação face a face é possível perceber gestos A dedicação na comunicação face a face é maior

30 10 princípios de engenharia de requisitos Princípio 5: Tome nota das decisões Em pouco tempo, não será possível saber por que uma decisão foi tomada É fundamental documentar as razões de cada decisão Princípio 6: Estimule colaborações Duas ou mais mentes pensam melhor que uma Colaborações geram cumplicidade na equipe Princípio 7: Mantenha o foco Evite que a reunião se desvie muito do seu objetivo Lembre às pessoas o que ainda precisa ser visto

31 10 princípios de engenharia de requisitos Princípio 8: Se algo estiver obscuro, desenhe! Representações visuais ajudam a uniformizar idéias Faça uso de papel e quadro branco em abundância Princípio 9: Siga em frente! Se concordarem, sigam em frente Se discordarem, sigam em frente Se estiverem em dúvida e não for possível tirar a dúvida no momento, sigam em frente Princípio 10: Negociação não é um jogo Busque por soluções boas para ambas as partes Ceda em aspectos que não são fundamentais Brigue somente pelas batalhas que valem a pena

32 Um possível processo 1. Identifique os interessados no software 2. Se reunia com os interessados e faça perguntas genéricas sobre como funciona o sistema 3. Faça um diagnóstico de uma página sobre o escopo do projeto 4. Revise o diagnóstico com os interessados, visando validar a comunicação anterior 5. Faça reuniões técnicas com os interessados para descobrir os cenários de uso do sistema (entradas, saídas, características, funcionalidades e comportamentos) 6. Faça um breve relatório desses cenários 7. Refina com os interessados esse relatório 8. Priorize esses cenários com os interessados 9. Revise com os interessados o relatório de cenários 10.Inicie o planejamento das etapas de projeto, codificação e testes

33 De engenharia de requisitos para implantação A priorização dos requisitos determina o conteúdo de cada iteração de implantação do software Dependências entre requisitos pode influenciar nessa ordem Entregar mais que o prometido pode ser uma faca de dois gumes Alegra o cliente naquela iteração Chateia o cliente em iterações futuras se isso não se repetir Requisitos não funcionais podem implicar em custos pós-implantação Ex: Determinação de 4 horas para correção de defeitos

34 Engenharia de requisitos De maneira geral, o processo de Engenharia de Requisitos envolve as seguintes atividades

35 Técnicas de levantamento de requisitos Entrevistas - Por que: objetivos da entrevista - Quem: pessoas a serem entrevistadas - Quando: data, horário e duração - Onde: definir o local onde ocorrerá a entrevista - Como: definição do tipo das questões - Registro: gravação, filmagem, anotações

36 Técnicas de levantamento de requisitos Coleta colaborativa de requisitos. Diferentes abordagens de coleta, como: - Workshop de requisitos - JAD - Brainstorming Todas aplicam de alguma maneira as seguintes diretrizes básicas: (i) as reuniões envolvem representantes de diferentes grupos de interessados, sendo estabelecidas regras de preparação e participação; (ii) um facilitador, que pode ser o analista ou outro participante, controla a reunião;

37 Coleta colaborativa de requisitos (iii) mecanismos de anotação, tais como quadro branco, flipcharts, anotações em um computador projetadas para todos os participantes etc., são usados para registrar as ideias levantadas; (iv) a meta é identificar ou debater um problema, propor elementos da solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução.

38 Técnicas de levantamento de requisitos Questionários Questionário ou survey é uma técnica de levantamento de informações que permite ao analista capturar, de várias pessoas afetadas pelo sistema, atitudes, crenças, comportamentos e características. Atitudes referem-se a o que as pessoas na organização dizem querer; crenças referem-se a o que as pessoas pensam ser realmente verdade; comportamento é o que as pessoas fazem; características são propriedades de pessoas ou coisas

39 Técnicas de levantamento de requisitos Observação A etnografia é o estudo de pessoas em seu ambiente natural. A observação é uma das técnicas de etnografia mais usadas no levantamento de requisitos. O analista observa os usuários executando os processos, sem interferência direta. O analista se insere no ambiente de trabalho onde o sistema será usado, observa o trabalho do dia-a-dia e faz anotações acerca das tarefas reais nas quais os participantes estão envolvidos É empregada para compreender requisitos sociais e organizacionais, bem como para compreender como as tarefas são realizadas efetivamente.

40 Técnicas de levantamento de requisitos Prototipagem Muitas vezes as pessoas acham difícil visualizar como um requisito especificado na forma de uma sentença escrita ou por um conjunto de modelos vai se materializar em um sistema de software. Nesses casos, se um protótipo do sistema é desenvolvido para demonstrar requisitos, fica mais fácil para usuários e outros interessados encontrar problemas e sugerir como os requisitos podem ser melhorados. Um protótipo é uma versão inicial do sistema que é desenvolvido no início do processo de desenvolvimento.

41 Prototipagem Ao colocar o usuário na frente de uma porção inicial ou uma imitação do sistema, a prototipagem estimula os usuários a pensar e a estabelecer um diálogo sobre os requisitos. A prototipagem é muito útil quando os interessados estão pouco familiarizados com as soluções disponíveis. Este é o caso, por exemplo, da introdução de novas tecnologias.

42 Técnicas de levantamento de requisitos Investigação ou Análise de Documentos Em qualquer negócio, há vários documentos cuja interpretação pode ajudar no levantamento de informações, tais como relatórios usados na tomada de decisão, fichas e uma variedade de formulários. Formulários, assim como fichas, são muito úteis para o levantamento de requisitos de informação. Tais informações são difíceis de serem obtidas através de outras técnicas de levantamento de requisitos, como entrevistas e observação.

43 Levantamento de requisitos Elementos a serem identificados: - Ter uma visão geral do negócio - Conhecer o cliente e suas expectativas - Serviços prestados pelo sistema - Restrições que devem ser obedecidas - Critérios de desempenho Produto principal dessa fase: Documento de requisitos - Narrativa em linguagem natural dos requisitos do sistema - Lista de requisitos do sistema

44 O documento de requisitos Os resultados do levantamento de requisitos têm de ser registrados em um documento, de modo que possam ser verificados, validados e utilizados como base para outras atividade do processo de software. Normalmente, requisitos são documentados usando alguma combinação de linguagem natural, modelos, tabelas e outros elementos. O Documento de Requisitos tem como propósito descrever os requisitos de usuário, tendo como público-alvo clientes, usuários, gerentes (de cliente e de fornecedor) e desenvolvedores.

45 O documento de requisitos Há muitos formatos distintos propostos na literatura para documentos de requisitos. Aqui, é proposta uma estrutura bastante simples para esse tipo de documento, contendo apenas quatro seções: Introdução: breve introdução ao documento, descrevendo seu propósito e estrutura. Descrição do Propósito do Sistema: descreve o propósito geral do sistema. Descrição do Minimundo: apresenta uma visão geral do domínio, do problema a ser resolvido e dos processos de negócio apoiados, bem como as principais ideias do cliente sobre o sistema a ser desenvolvido.

46 O documento de requisitos Requisitos de Usuário: apresenta os requisitos de usuário em linguagem natural. Três conjuntos de requisitos devem ser descritos nesta seção: requisitos funcionais, requisitos não funcionais e regras de negócio. As três primeiras seções não têm nenhuma estrutura especial, sendo apresentadas na forma de um texto corrido. A introdução deve ser breve e basicamente descrever o propósito e a estrutura do documento. A descrição do propósito do sistema deve ser direta e objetiva, tipicamente em um único parágrafo.

47 O documento de requisitos Já a descrição do minimundo é um pouco maior, algo entre uma e duas páginas, descrevendo aspectos gerais e relevantes para um primeiro entendimento do domínio, do problema a ser resolvido e dos processos de negócio apoiados. Contém as principais ideias do cliente sobre o sistema a ser desenvolvido, obtidas no levantamento preliminar e exploratório do sistema.

48 O documento de requisitos A Seção 4, por sua vez, não deve ter um formato livre. Ao contrário, deve seguir um formato estabelecido pela organização, contendo, dentre outros: identificador do requisito, descrição, tipo, origem, prioridade, responsável, interessados, dependências em relação a outros requisitos e requisitos conflitantes. Aqui sugerimos um padrão tabular

49 O documento de requisitos Os requisitos devem possuir identificadores únicos para permitir a identificação e o rastreamento na gerência de requisitos. Aqui, recomenda-se usar um esquema de numeração sequencial por tipo de requisito, sendo usados os seguintes prefixos para designar os diferentes tipos de requisitos: - RF requisitos funcionais; - RNF requisitos não funcionais; - RN regras de negócio: toda organização opera de acordo com um extenso conjunto de políticas corporativas, leis, padrões industriais e regulamentações governamentais. Tais princípios de controle são coletivamente designados por regras de negócio.

50 O documento de requisitos Descrição: O sistema deve <verbo indicando ação, seguido de complemento> ou O sistema pode <verbo indicando ação, seguido de complemento> Exemplos: - O sistema deve efetuar o controle dos clientes da empresa. (RF) - O sistema deve processar um pedido do cliente em um tempo inferior a cinco segundos, contado a partir da entrada de dados. (RF) - O sistema pode notificar usuários em débito. (RF) - O sistema não deve ficar inativo por mais de 1 hora. (RNF) - Todo pedido tem uma taxa de remessa. (RN)

51 O documento de requisitos Origem: a origem de um requisito deve apontar a partir de que entidade (pessoa, documento, atividade) o requisito foi identificado. Um requisito identificado durante uma investigação de documentos, p.ex., tem como origem o(s) documento(s) inspecionado(s). Prioridade: requisitos podem ter importância relativa diferente em relação a outros requisitos. Assim, é importante que o cliente e outros interessados estabeleçam conjuntamente a prioridade de cada requisito.

52 O documento de requisitos É muito importante saber quem é o analista responsável por um requisito, bem como quem são os interessados (clientes, usuários etc.) naquele requisito. São eles que estarão envolvidos nas discussões relativas ao requisito, incluindo a tentativa de acabar com conflitos e a definição de prioridades. Um requisito pode depender de outros ou conflitar com outros. Quando as dependências e conflitos forem detectados, devem-se listar os respectivos identificadores nas colunas de dependências e conflitos.

53 O documento de requisitos É muito importante saber quem é o analista responsável por um requisito, bem como quem são os interessados (clientes, usuários etc.) naquele requisito. São eles que estarão envolvidos nas discussões relativas ao requisito, incluindo a tentativa de acabar com conflitos e a definição de prioridades. Um requisito pode depender de outros ou conflitar com outros. Quando as dependências e conflitos forem detectados, devem-se listar os respectivos identificadores nas colunas de dependências e conflitos.

54 Análise de requisitos Uma vez identificados os requisitos de usuário, é necessário detalhá-los, colocando-os no nível de descrição de requisitos de sistema. Este é o propósito da análise de requisitos. Durante a análise de requisitos, requisitos funcionais e não funcionais devem ser expressos em um nível de detalhes que permita guiar as etapas subsequentes do desenvolvimento de software (projeto, implementação e testes). Além disso, atenção especial deve ser dada às regras de negócio. Elas têm de ser capturadas e incorporadas às funcionalidades do sistema.

55 Análise de requisitos Grande parte das informações tratadas na análise de requisitos funcionais é melhor comunicada por meio de diagramas do que por meio de texto. Assim, a modelagem conceitual é uma atividade essencial da análise de requisitos. O produto de trabalho principal da análise de requisitos é o Documento de Especificação de Requisitos. Esse documento deve conter os requisitos funcionais e não funcionais descritos em nível de requisitos de sistema. Uma das técnicas mais comumente utilizadas para descrever requisitos funcionais como requisitos de sistema é a modelagem de casos de uso.

56 Análise de requisitos Objetivo: - Explicitar o conhecimento obtido no levantamento - Transformar narrativas de linguagem natural para UML Resultados esperados: - Documento de Especificação de requisitos Assim, discutiremos a análise de requisitos funcionais (modelagem conceitual) e não funcionais.

57 Modelo conceitual O modelo conceitual de um sistema é tipicamente composto de vários modelos, cada um deles enfocando uma perspectiva diferente. As duas grandes categorias onde eles se agrupam são: Modelos Estruturais: procuram capturar os principais conceitos do domínio, suas relações e propriedades. Dentre os tipos de modelos estruturais, destacam-se o Modelo de Entidades e Relacionamentos e o Diagrama de Classes. Modelos Comportamentais: especificam as ações que o sistema pode realizar e as mudanças válidas no estado do domínio (OLIVÉ, 2007). No desenvolvimento orientado a objetos destaca-se Modelos de Casos de Uso, Diagramas de Transição de Estados e Diagramas de Interação.

58 Especificação de requisitos não funcionais Assim como os requisitos funcionais precisam ser especificados em detalhes, o mesmo acontece com os requisitos não funcionais. Para os atributos de qualidade considerados prioritários, o analista deve trabalhar no sentido de especificá-los de modo que eles se tornem mensuráveis e, por conseguinte, testáveis. A ISO/IEC 9126 pode ser uma boa fonte de medidas. Essa norma apresentam diversas medidas que podem ser usadas para especificar objetivamente os requisitos não funcionais. Seja o exemplo de um sistema que tem como requisito não funcional ser fácil de aprender. Esse requisito poderia ser especificado conforme mostrado a seguir.

59 Especificação de requisitos não funcionais

60 O Documento de Especificação de Requisitos Os requisitos de sistema, assim como foi o caso dos requisitos de usuário, têm de ser especificados em um documento, de modo a poderem ser verificados e validados e posteriormente usados como base para as atividades subsequentes do desenvolvimento de software. O DER tem como propósito registrar os requisitos escritos a partir da perspectiva do desenvolvedor e, portanto, deve incluir os vários modelos conceituais desenvolvidos, bem como a especificação dos requisitos não funcionais detalhados. Aqui, propõe-se o uso de um único documento, contendo as seguintes informações:

61 O Documento de Especificação de Requisitos 1. Introdução: breve introdução ao documento, descrevendo seu propósito e estrutura. 2. Modelo de Casos de Uso: apresenta o modelo de casos de uso do sistema, incluindo os diagramas de casos de uso e as descrições de casos de uso associadas. 3. Modelo Estrutural: apresenta o modelo conceitual estrutural do sistema, incluindo os diagramas de classes do sistema. 4. Modelo Dinâmico: apresenta os modelos comportamentais dinâmicos do sistema, incluindo os diagramas de estados, diagramas de interação e diagramas de atividades. 5. Especificação dos Requisitos Não Funcionais: apresenta os requisitos não funcionais descritos no nível de sistema, o que inclui critérios de aceitação.

62 Um método de análise de requisitos funcionais Uma vez que tipicamente diversos modelos do sistema são produzidos, surgem algumas importantes questões: Que modelos produzir? Em que sequência? Quais as relações existentes entre esses modelos? Estas questões podem ser parcialmente respondidas pela adoção de um método de análise. Um método é composto por uma linguagem estabelecendo a notação a ser usada na elaboração dos artefatos a serem produzidos e de um processo descrevendo que artefatos construir e como construí-los.

63 Um método de análise de requisitos funcionais Vamos mostrar o método sugerido por (Falbo,2012) que adota UML como linguagem de modelagem. Na figura mostrada no próximo slide, as atividades de modelagem propriamente ditas estão destacadas em amarelo. As demais atividades correspondem a atividades de documentação e verificação e validação do Documento de Especificação de Requisitos. Deve-se frisar que, apesar da figura sugerir que os passos do método são sequenciais, na prática, isso não ocorre. Assim, as atividades mostradas na verdade podem ser paralelas e iterativas.

64

65 Especificação de requisitos não funcionais Assim como os requisitos funcionais precisam ser especificados em detalhes, o mesmo acontece com os requisitos não funcionais. Para os atributos de qualidade considerados prioritários, o analista deve trabalhar no sentido de especificá-los de modo que eles se tornem mensuráveis e, por conseguinte, testáveis. A ISO/IEC 9126 pode ser uma boa fonte de medidas. Essa norma apresentam diversas medidas que podem ser usadas para especificar objetivamente os requisitos não funcionais. Seja o exemplo de um sistema que tem como requisito não funcional ser fácil de aprender. Esse requisito poderia ser especificado conforme mostrado a seguir.

66 Especificação de requisitos não funcionais

67 O Documento de Especificação de Requisitos Os requisitos de sistema, assim como foi o caso dos requisitos de usuário, têm de ser especificados em um documento, de modo a poderem ser verificados e validados e posteriormente usados como base para as atividades subsequentes do desenvolvimento de software. O DER tem como propósito registrar os requisitos escritos a partir da perspectiva do desenvolvedor e, portanto, deve incluir os vários modelos conceituais desenvolvidos, bem como a especificação dos requisitos não funcionais detalhados. Aqui, propõe-se o uso de um único documento, contendo as seguintes informações:

68 O Documento de Especificação de Requisitos 1. Introdução: breve introdução ao documento, descrevendo seu propósito e estrutura. 2. Modelo de Casos de Uso: apresenta o modelo de casos de uso do sistema, incluindo os diagramas de casos de uso e as descrições de casos de uso associadas. 3. Modelo Estrutural: apresenta o modelo conceitual estrutural do sistema, incluindo os diagramas de classes do sistema. 4. Modelo Dinâmico: apresenta os modelos comportamentais dinâmicos do sistema, incluindo os diagramas de estados, diagramas de interação e diagramas de atividades. 5. Especificação dos Requisitos Não Funcionais: apresenta os requisitos não funcionais descritos no nível de sistema, o que inclui critérios de aceitação.

69 Bibliografia Engenharia de Software Notas de Aula Capítulo 3 Ricardo de Almeida Falbo Universidade Federal do Espírito Santo