Análise de Requisitos

1. Análise de Requisitos ►METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS Prof. Dr. rer. nat. Daniel D. Abdala e-mail: abdala@das.ufsc.br

2. Objetivos Introduzir os conceitos de requisitos do usuário e do sistema; Definir requisitos funcionais e não-funcionais; Explicar duas técnicas para descrição de requisitos do sistema;

3. Plano Requisitos Funcionais e Não-Funcionais Requisitos do Usuário Requisitos do Sistema Documento de Requisitos

5. Engenharia de Requisitos • Processo sistemático para: • Identificação e registro das necessidades específicas dos stackholders; • Refinamento dos requisitos levantados; • Resolução de conflitos entre requisitos; • Identificação de interdependências entre requisitos;

6. O que são Requisitos? • Descrição de serviços e restrições do sistema; • Devem refletir a necessidade dos usuários do sistema; • Existem diferentes níveis: • Alto nível – usados por exemplo em propostas de contrato; • Detalhados – usados na redação de contratos. Definem precisamente o que deve estar presente no software

7. Abstração de Requisitos Sommerville “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”

8. Tipos de Requisitos • Requisitos do Usuário (Usuário) • afirmações em linguagem natural enriquecidos por diagramas descrevendo os serviços e funcionalidades que um sistema deve prover, assim como restrições na presença das quais ele deve operar. • Requisitos do Sistema (Eng. de Requisitos) • estabelece as funções do sistema, serviços e restrições em detalhes. O documento de requisitos do sistema (também chamado especificação funcional) deve ser preciso e detalhado. Ele deve definir exatamente o que deve ser implementado. Ele ainda pode ser usado como parte do contrato entre o comprador do sistema e os desenvolvedores. • Especificação do Software (Desenvolvedores) • Uma descrição detalhada do software que serve como base para o projeto e implementação

9. Definição e Especificação Definição de Requisitos O Software deve prover funcionalidade para impressão de todos os relatórios gerados . O software deve ser capaz de escolher uma dentre as várias impressoras disponíveis para impressão; A impressão de um relatório deve ser permitida em diferentes níveis de qualidade; Os níveis de qualidade são: (rascunho, normal e alta qualidade); Deve ser possível imprimir relatórios para arquivos .pdf. Especificação de Requisitos

10. Requisitos do Usuário • Requisitos funcionais e não-funcionais devem ser descritos de tal forma que eles possam ser entendidos por usuários que não possuem conhecimento; • Requisitos do Usuário são definidos usando Linguagem Natural (LN), tabelas e diagramas.

11. Problemas com Linguagem Natural • Falta de claridade • Alcançar precisão é difícil sem tornar o documento muito complexo • Confusão entre os Requisitos • Requisitos funcionais e não-funcionais tendem a se misturar • Combinação de Requisitos • Vários requisitos distintos podem vir a ser expressos conjuntamente

12. Database requirement 4.A.5O banco de dados deve permitir a geração e controle de objetos de configuração, isto é, objetos que são compostos pela combinação de outros objetos. As ferramentas de controle de configuração devem permitir acesso aos objetos em um grupo de versão por meio do uso de nomes incompletos.

13. Requisitos do Editor Grid 2.6 Gridfacilities Para auxiliar o posicionamento de entidades no diagrama, o usuário poderá habilitar a visualização do grid tanto em centímetros quanto em milímetros utilizando para tal um painel de controle. Inicialmente, o grid não deve estar habilitado. O grid pode ser habilitado e desabilitado a qualquer momento durante uma sessão de edição assim como poderá ser alterado entre cm e mm. Uma outra opção chamada “reduce-to-fit” , no entanto o número de linhas mostradas será reduzido de modo a evitar que diagramas pequenos sejam rearranjados para se ajustarem as linha do grid.

14. Problemas com osRequisitos • Os requisitos do database incluem tanto informações conceituais quanto detalhes de implementação • Descrevem o conceito de opções de controle de configuração • Incluem detalhes a respeito de como os objetos devem ser acessados (usando nomes incompletos) • Os requisitos do grid incluem três tipos de requisitos • Conceitual (a necessidade de um grid) • Não-Funcional (unidades de medida do grid) • Não Funcional IU (troca de tamanho do grid)

15. Quem lê os diferentes níveis de Requisitos?

16. Requisitos Funcionais e Não-Funcionais • Requisitos Funcionais • definições dos serviços que o sistema de prover; • define como o sistema deve reagir a diferentes tipos de entrada; • como o sistema deve se comportar em situações particulares. • definir explicitamente o que o sistema NÃO deve fazer; • Requisitos Não-Funcionais • Define restrições dos serviços oferecidos pelo sistema; • Restrições de tempo; • Restrições do processo de desenvolvimento; • Restrições (concordância) de padronização; • Geralmente são aplicáveis a todo o sistema.

17. Exemplos de Requisitos Fucionais O usuário deve ser capaz de pesquisar tanto um conjunto inicial de bancos de dados como um sub grupo selecionado dos mesmos. O sistema deve prover métodos de visualização adequados de modo que o usuário possa ler os documentos disponíveis na loja de documentos. Deve ser atribuído um identificador único (ORDER_ID) a todos os documentos.

18. Tipos de Requisitos Não-Funcionais

19. Exemplos de Requisitos Não Funcionais • Requisitos do Produto • 4.C.8 Deve ser possível representar toda a comunicação entre o APSE e o usuário usando o conjunto de caracteres Ada. • Requisitos de organização • 9.3.2 O processo de desenvolvimento do sistema assim como todos os documentos entregáveis devem estar em concordância com o padrão definido em XYZCo-SP-STAN-95 • Requisitos Externos • 7.6.5 O sistema não deve publicar nenhuma informação pessoal dos clientes com exceção do nome e número de referência para o operador do sistema

20. Objetivos dos Requisitos • Requisitos não-funcionais podem ser difíceis de serem definidos claramente, e requisitos imprecisos podem ser difíceis de verificar. • Objetivos • São uma intenção geral do usuário, tal como facilidade de utilização • Requisitos funcionais verificáveis • Uma especificação de funcionalidade usando alguma forma de medida que pode ser testada objetivamente • Objetivos podem ser úteis aos desenvolvedores uma vez que estes representam as intenções dos usuários do sistema

21. Exemplos • Um objetivo do sistema • O sistema deve ser fácil de usar por controladores experientes e deve ser organizado de forma que os erros de utilização sejam minimizados • Um requisito não-funcional verificável • Controladores experientes dever ser capazes de usar todas as funções do sistema após um treinamento de duas horas. Uma vez que o treinamento tenha sido feito, o número médio de erros de utilização não deverá ultrapassar duas ocorrências por dia.

22. O documento de requisitos • O documento de requisitos é uma especificação formal do que é requerido dos desenvolvedores do sistema • Ele deve incluir tanto uma definição quanto a especificação de cada requisito • Ele NÃO é um documento de projeto. Tanto quanto possível ele deve definir o que o sistema deve fazer ao invés de COMO ele deve fazer

24. Requisitos do Sistema • Especificaçãodetalhada dos requisitos do usuário; • Serve como base para o projeto do sistema.

25. Projeto de Requisitos • Como princípio, requisitos devem informar o que o sistema deve fazer e projeto como deve ser feito • Na prática, requisitos e projeto são inseparáveis • Uma arquitetura do sistema deve ser projetada para estruturar os requisitos

26. Problemas com a especificasão usando LN • Ambigüidade • Os leitores e escritores dos requisitos podem vir a interpretar as mesmas palavras de maneiras diversas. LN é naturalmente ambigua • Muita Flexibilidade • A mesma idéia pode ser expressa de maneiras diferentes • Falta de Modularização • LN é inadequada para estruturação de requisitos do sistema

28. Alternativas a LN

29. LingugemEstruturada • Uma forma limitada de LN pode ser usadaparaexpressarrequisitos • Sana alguns dos problemasresultantesdaambiguidade e flexibilidade e impoe um certograu de uniformidadepara a especificação

30. Especificação Baseada em Formulários • Definição de função ou entidade • Descrição das entradas e de sua procedência • Descrição das saídas e seu destino • Indicação de dependência de outras entidades • Pre-condições e pós-condições

31. Especificação Baseada em Formulários

32. Especificação de Interfaces • Muitossistemasoperamemconjunto com outrossistemas. Interfaces entre taissistemasdevem ser especificadascomo parte dos requisitos • Trêstipos de interfaces podem ser definidas: • Interfaces de Procedimentos • Estruturas de dados queserãointercambiadas • Representação de dados • Notaçõesformaissãoumatécnicaefetivaparaespecificação de interfaces

33. Pontos Chave Requisitos especificam o que o sistema deve fazer e definem restrições quanto a sua operação e implementação; Requisitos funcionais especificam serviços que o sistema deve prover; Requisitos não-funcionais restringem o sistema sendo desenvolvido e/ou o processo de desenvolvimento; Requisitos do usuário são especificações de alto nível a respeito do que o sistema deve fazer;

34. Pontos Chave Requisitos do usuário devem ser escritos em linguagem natural, tabelas e diagramas; Requisitos do sistema tem como tarefa comunicar as funcionalidades que o sistema deve prover; Requisitos do sistema devem ser escritos em linguagem natural estruturada ou uma linguagem formal.

35. Referências R. S. Pressman, Engenharia de Software, McGraw Hill, 6a Ed., 2002. Chap. 7. I. Sommerville. Software Engineering. 7th Ed. Addison-Wesley, 2004. Chap. 5.