Requisitos de Software Maria Augusta Constante Puget (Magu)

Apresentação em tema: "Requisitos de Software Maria Augusta Constante Puget (Magu)"— Transcrição da apresentação:

1 Requisitos de Software Maria Augusta Constante Puget (Magu)

2 2 Requisitos de software  Classificação básica: Funcionais. Não funcionais. De domínio.  Outra classificação: FURPS+

3 3 Requisitos Funcionais X Não Funcionais X de Domínio (1)  Requisitos funcionais Define uma função do software. Uma função é descrita como um conjunto de entradas, comportamento e saídas. Pode ser um cálculo, detalhes técnicos, manipulação de dados, processamento e outras funcionalidades que definem o que um sistema deve fazer.

4 4 Requisitos Funcionais X Não Funcionais X de Domínio (2)  Exemplos de requisitos funcionais Usuário pode pesquisar todo ou um sub- conjunto do banco de dados. Sistema deve oferecer visualizadores apropriados para o usuário ler documentos armazenados. Todo pedido deve ter associado a si um identificador único (PID).

5 5 Requisitos Funcionais X Não Funcionais X de Domínio (3)  Requisitos não-funcionais Especifica critérios que podem ser usados no modo em que um sistema opera, e não em comportamentos específicos do mesmo. Restrições nos serviços do sistema, tais como restrições de espaço, restrições de tempo, restrições no processo de desenvolvimento, padrões, etc. Requisitos de processo também podem especificar o uso de determinadas linguagens de programação, método de desenvolvimento.

6 6 Requisitos Funcionais X Não Funcionais X de Domínio (4)  Requisitos não-funcionais Requisitos não-funcionais são, em geral, mensuráveis. Assim, deve-se associar uma forma de medida/referência a cada requisito não- funcional elicitado.

7 7 Requisitos Funcionais X Não Funcionais X de Domínio (5)  Idealmente, os requisitos não funcionais deveriam ser expressos quantitativamente, utilizando-se métricas que possam ser objetivamente testadas.

8 8 Requisitos Funcionais X Não Funcionais X de Domínio (6) Classificação de requisitos não-funcionais  Requisitos do Produto Especificam o comportamento do produto: Desempenho (rapidez com que deve operar), memória requerida, confiabilidade (taxa aceitável de falhas), portabilidade e facilidade de uso.  Requisitos Organizacionais Conseqüência de políticas e procedimentos organizacionais: padrões de processo usados, requisitos de implementação (linguagem, método de projeto), requisitos de fornecimento (quando o produto deve ser entregue), etc..  Requisitos Externos Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento:Requisitos de interoperabilidade (como interage com outros sistemas), requisitos legais (opera de acordo com a lei), requisitos éticos.

9 9 Requisitos Funcionais X Não Funcionais X de Domínio (7) Exemplos de requisitos não-funcionais  Requisitos do Produto Toda consulta ao BD, baseada em código de barras, deve demorar, no máximo, 5 s.  Requisitos Organizacionais Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00.  Requisitos Externos O sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes, além de seus nomes e o número de referência (legislação de privacidade).

10 10 Requisitos Funcionais X Não Funcionais X de Domínio (8) Tipos de requisitos não-funcionais

11 11 Requisitos Funcionais X Não Funcionais X de Domínio (9) De maneira geral, requisitos funcionais especificam O QUE um sistema deve FAZER. Enquanto requisitos não- funcionais especificam COMO um sistema deve SER.

12 12 Requisitos Funcionais X Não Funcionais X de Domínio (10)  Requisitos do domínio Requisitos oriundos do domínio da aplicação do sistema e que refletem as características do domínio. Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas.

13 13 Requisitos Funcionais X Não Funcionais X de Domínio (11)  Requisitos do domínio - Problemas Entendimento:  Requisitos são descritos na linguagem do domínio da aplicação.  Não são compreendidos pelos engenheiros de software que vão desenvolver a aplicação. Implicitude:  Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos.

14 14 Requisitos Funcionais X Não Funcionais X de Domínio (12) Requisitos do domínio - Exemplo  A desaceleração do trem deve ser computada através da fórmula: D trem =D controle +D gradiente Onde D gradiente é 9.81m/s 2 * gradiente compensado/alfa e onde os valores de alfa são conhecidos para diferentes tipos de trens.

15 15 Modelo FURPS+ (1)  Modelo de categorização de requisitos proposto por Robert Grady, da Hewlett Packard (HP).  Ele pode auxiliar na identificação dos requisitos de um sistema e na sua organização e classificação.  As letras FURPS+ significam: Funcionalidade (Functionality). Usabilidade (Usability). Confiabilidade (Reliability). Desempenho (Performance). Suportabilidade (Supportability).

16 16 Modelo FURPS+ (2)  O "+" em FURPS+ representa outros requisitos como: Restrições de design. Requisitos de implementação. Requisitos de interface. Requisitos físicos.

17 17 Modelo FURPS+ (3)  Funcionalidade (Functionality) O F representa todos os requisitos funcionais de um sistema. É a parte que mais está ligada com as regras de negócio (conjunto de diretrizes que determinam como determinado negócio deve funcionar) de um produto, pois representa a implementação das mesmas.

18 18 Modelo FURPS+ (4)  O F é a única letra que representa requisitos funcionais.  As demais letras representam requisitos não-funcionais.

19 19 Modelo FURPS+ (5)  Usabilidade (Usability) Abrange a parte visual de um sistema, a facilidade de interagir com o mesmo, a intuitividade. A acessibilidade também está incluída aí, assim como a parte estética da aplicação em questão. Uma imagem que não é carregada corretamente em um website, pode ser definida como um problema de usabilidade.

20 20 Modelo FURPS+ (6)  Confiabilidade (Reliability) Associada a aspectos como: Disponibilidade: Dependendo do sistema a disponibilidade deve ser 24x7. Exatidão. Recuperação após falhas: Talvez o mais importante, pois todo o sistema deve ter poder de recuperação imediato após uma falha crítica. De outra forma, o sistema ficaria indisponível por tempo indeterminado, causando transtorno aos seus usuários finais.

21 21 Modelo FURPS+ (7)  Desempenho (Performance) Diretamente ligada a tempos de respostas de um sistema. Relacionado também a quanto tal sistema suporta de carga de dados e também de usuários e suas ações. Testes de performance avaliam diversas capacidades de um sistema, como por exemplo se um sistema está lento ou está respondendo satisfatoriamente os usuários finais.

22 22 Modelo FURPS+ (8)  Suportabilidade (Supportability) Relacionado a quão prático é o processo de suporte ao sistema:  Facilidade de testar o sistema.  Adaptabilidade.  Facilidade de manutenção do sistema.  Portabilidade.  Facilidade de configuração.  Facilidade de customização... entre outros...

23 23 Modelo FURPS+ (9)  O + do FURPS+ O + representa os seguintes requisitos não-funcionais: Restrições de Design: Design, nesse caso, refere- se ao projeto e suas diretrizes e não a layout. Exemplo: A definição da utilização de um banco de dados relacional no projeto é uma restrição de design. Restrições de implementação: Relacionado a limites impostos a código e construções. Exemplo: A linguagem de programação a ser utilizada para a codificação do sistema.

24 24 Modelo FURPS+ (10)  O + do FURPS+ O + representa os seguintes requisitos não-funcionais: Restrições de interface: Diretamente ligadas à comunicação do sistema em questão com sistemas externos e quais protocolos deverão ser utilizados para tal comunicação ocorrer. Restrições físicas: Refere-se ao hardware onde o sistema vai ser alocado, como vai ser exibido, além de interface usuário-sistema através do hardware. Um exemplo de sistema em que se nota claramente a importância de restrições físicas são os sistemas feitos para aeronaves.

25 25 Ciclo de Requisitos de Software (1)

26 26 Elicitação de Requisitos (1)  Da perspectiva da engenharia de software, a “elicitação” de requisitos é talvez a parte mais crítica do processo de desenvolvimento de software.  Estudos indicam que requisitos só detectados depois do software ter sido implementado ou erros na análise de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.

27 27 Elicitação de Requisitos (2)

28 28 Elicitação de Requisitos (3)  A elicitação de requisitos corresponde a identificar junto aos clientes/usuários quais são os objetivos do sistema, o que deve ser acompanhado, como o sistema se encaixa no contexto das necessidades do negócio e, finalmente, como será a utilização do sistema no dia-a-dia. “A parte mais árdua na construção de um software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correções posteriores.” F. Brook

29 29 Elicitação de Requisitos (4)  Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas das razões desta dificuldade: 1. Problemas de escopo: Os limites do sistema são geralmente definidos de forma incompleta, ou os clientes/usuários especificam detalhes técnicos desnecessários; 2. Problemas de compreensão: Os clientes/usuários geralmente não estão completamente certos das necessidades, têm pouca compreensão do domínio do seu negócio ou omitem informações que julgam óbvias. 3. Problemas de volatilidade: Os requisitos mudam o tempo todo.

30 30 Elicitação de Requisitos (5) Objetivos da Elicitação de Requisitos:  Obter conhecimento relevante para o problema e prover o mais correto entendimento do que é esperado do software/sistema. Técnicas para Elicitação de Requisitos:  Cenários: Representar tarefas que executam e as que desejam executar.  Técnicas tradicionais: Questionários, entrevistas, análise de documentação existente.  Técnicas de elicitação de grupo: Dinâmica de grupo.  Prototipação: Quando existe alto grau de incerteza e necessita-se de um rápido feedback.

31 31 Elicitação de Requisitos (6)  Documento (Artefato) desta etapa: “Documento de Visão”  Objetivo: Descrever a visão inicial do software.  Este documento, em geral, tem as seguintes seções: Declaração do problema e diagrama de contexto. Lista dos stakeholders. Lista dos requisitos. Lista de riscos. Lista das restrições.

32 32 Documento de Visão (1) Declaração do problema  É uma “descrição narrativa”, que apresenta de forma concisa e clara as necessidades dos usuários.  Esta narrativa também deve descrever o cenário atual e as necessidades futuras.  A linguagem usada neste documento pode ser técnica ou de negócios, entretanto, deve-se evitar o uso de jargões que não se enquadram no escopo do problema. Diagrama de Contexto :  Estabelece quais são as fronteiras do software e principais funcionalidades, ou seja, onde as responsabilidades do software começam e quando terminam.

33 33 Documento de Visão (2) Identificação dos stakeholders Que são “stakeholders”?  Stakeholders são pessoas ou entidades que influenciam a construção do software. Exemplos: Usuários, porque definem os requisitos. Gerentes, Diretores, Patrocinadores porque influenciam através de tomada de decisão.

34 34 Documento de Visão (3) Identificação dos requisitos  Identificar as funcionalidades do software para que ele atenda as necessidades do usuário.  Para identificar, fazer as seguintes perguntas: O que o software deve fazer ? Quais funcionalidades ele deve ter ?  Devemos identificar também as principais características do software como: Performance: Qual é tempo de resposta adequado ? Segurança: Quais são os requisitos de segurança que o software precisa atender? Usabilidade: O software deve seguir a identidade visual da empresa? Interfaces devem ser intuitivas e amigáveis...  Os requisitos encontrados não devem ser descritos neste momento, precisamos apenas identificá-los, ou seja, é uma informação de alto nível.

35 35 Documento de Visão (4) Identificação dos riscos  Os riscos são a principal razão de falha em um projeto de software.  Para um projeto ter sucesso é importante a identificação dos riscos o mais cedo possível. Assim poderemos criar um plano para reduzi-los.  No Documento de Visão precisamos apenas identificar e criar uma Lista de Riscos encontrados.

36 36 Documento de Visão (5) Identificação das restrições  Definem o conjunto de restrições impostas sobre o desenvolvimento do software.  Restrições definem, por exemplo, a adequação a custos e prazos, à plataforma tecnológica, a aspectos legais (licenciamento), limitações sobre a interface com usuário, componentes de hardware e software a serem adquiridos etc.  Nesta momento apenas identificamos as restrições e criamos uma Lista das Restrições.

37 37 Documento de Visão (6) Identificação das restrições  Esta lista podem ser divida nas seguintes partes: Restrições de Hardware. Restrições de Software. Restrições de Ambiente e Tecnologia. Exemplo de Restrição:  Projeto requer uma determinada tecnologia, tal como WebServices.  O software necessita de algum hardware ou software em específico, tal como um servidor exclusivo para banco de dados.

38 38 Documento de Visão (7)  Exemplo de template de Documento de Visão Exemplo de template de Documento de Visão  Exemplo de um Documento de Visão Exemplo de um Documento de Visão

39 39 Análise de Requisitos (1) Atividades da Análise de Requisitos  A análise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades do sistema, classificando e detalhando os requisitos encontrados na coleta.  Os requisitos funcionais serão descritos em detalhes.  E os requisitos não funcionais serão classificados. Documento (Artefato) desta etapa: “Documento de Requisitos”

40 40 Análise de Requisitos (2)

41 41 Análise de Requisitos (3) Detalhar requisitos funcionais

42 42 Análise de Requisitos (4) Classificar e detalhar requisitos não funcionais

43 43 Análise de Requisitos (5) Descrever usuários e entidades externas

44 44 Análise de Requisitos (6) Plano de mitigação de riscos  Precisamos elaborar um Plano de Mitigação de Risco, para os risco que já foram identificados.  Este plano deve detalhar como mitigar os riscos identificados.

45 45 Documento de Requisitos (1) Template para Documento de Requisitos

46 46 Especificação de Requisitos (1) Especificação de Requisitos com Casos de Uso

47 47 Especificação de Requisitos (2) Especificação de Requisitos com Casos de Uso  Caso de Uso é uma representação gráfica e semântica da interação do usuário com o sistema.  Os diagramas de caso de uso são usados para capturar os requisitos funcionais do sistema.  Ajuda o entendimento do contexto dos requerimentos do sistema.

48 48 Especificação de Requisitos (3) Especificação de Requisitos com Casos de Uso  Diagramas de Casos de Uso.  Narrativas de Casos de Uso.