ES 03 - Requisitos de Software

(1)

Requisitos de Software

(2)

Régis Simão 2/27

Requisitos de Software

Agenda

 Introdução

 Requisitos de software

 Requisitos de usuário e de sistema

 Requisitos funcionais e não funcionais

 Bibliografia

(3)

Requisitos de Software

Introdução

 Objetivos

 Introduzir os conceitos de requisitos de usuário e de sistema  Descrever requisitos funcionais e não funcionais

 Explicar duas técnicas para descrever requisitos de sistema

 Explicar como requisitos de software podem ser organizados em um

(4)

Régis Simão 4/27

Requisitos de Software

Introdução

Necessidades

Funcionalidades

Requisitos do Software

Domínio do Problema

Domínio da Solução

(5)

Requisitos de Software

Introdução

 Requisitos

 São as descrições e especificações das funções (serviços) e das

restrições do sistema

 Engenharia de requisitos

 É o processo de estabelecer os serviços que os cliente solicitam para um

sistema e as restrições sobre a qual eles devem operar e serem desenvolvidos

 É o processo de descobrir, analisar, documentar e verificar essas

(6)

Régis Simão 6/27

Requisitos de Software

 Os requisitos podem variar de declarações de alto nível de abstração de

um serviço ou de uma restrição de sistema até uma especificação

matemática detalhada das funções

 Os requisitos podem servir para duas funções:

 Subsidiar soluções: devem ser abertas para não conduzir a uma solução

predefinida; permitir que os fornecedores apresentem soluções

alternativas para os problemas (definições de alto nível de abstração)

 Tirar ambigüidades: devem ser detalhadas o suficiente para que não

hajam dúvidas para o fornecedor construir a solução e para o cliente validar a solução (especificação matemática detalhada)

(7)

Requisitos de Software

 Imprecisão dos Requisitos

 Problemas são levantados quando requisitos não são precisamente

declarados

 Requisitos ambíguos podem ser interpretados de diferentes maneiras por

desenvolvedores e usuários

 Completeza e Consistência dos Requisitos

 Em princípio, os requisitos devem ser ambos completos e consistentes  Completo

 Eles devem incluir descrições de todas a funcionalidades solicitadas

 Consistência

 Não Devem existir conflitos e contradições nas descrições das funcionalidades do sistema

 Na prática, é impossível produzir um documento de requisitos completo e

(8)

Régis Simão 8/27

Requisitos de Software

 Detalhamento dos Requisitos

 Requisitos do usuário

 São declarações, em linguagem natural em diagramas, sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar

 Requisitos de sistema

 Estabelecem detalhadamente as funções e restrições de sistema. Eles deves ser precisos. Podem servir como contrato

(9)

Requisitos de Software

Requisitos de Usuários

 Os requisitos de usuários devem descrever os requisitos funcionais e não

funcionais de forma que eles possam ser entendidos pelos usuários do

sistema que não têm conhecimento técnico detalhado

 Os requisitos de usuário são definidos usando linguagem natural, tabelas

e diagramas

 Problemas com a linguagem natural

 Falta de clareza

 Precisão é difícil sem fazer o documento ficar difícil de ler

 Confusão

 Requisitos funcionais e não funcionais tendem a ser misturados

 Fusão de requisitos

 Vários requisitos diferentes pode ser expressos juntos como um único requisito

(10)

Régis Simão 10/27

Requisitos de Software

Requisitos de Usuários

 Diretrizes para a escrita de requisitos:

 Invente um formato padrão e use-o para todos os requisitos

 Use a linguagem de forma consistente. Use DEVE para requisitos

obrigatórios e DEVERIA para requisitos desejados

 Use texto em destaque para identificar partes-chave dos requisitos  Evite usar jargões computacionais

(11)

Requisitos de Software

Requisitos de Sistema

 Especificações mais detalhadas dos requisitos dos usuários

 Servem como base para o projeto do sistema

 Podem ser usado como parte do contrato do sistema

 Existem diversos modelos de sistemas onde podem ser expressos os

requisitos de sistema: um deles é a especificação de casos de uso

(12)

Régis Simão 12/27

Requisitos de Software

Requisitos de Sistema

 Requisitos de Sistema e Projeto do Sistema

 Em princípio, os requisitos devem atestar o que o sistema deve fazer e o

projeto descreve como os requisitos devem ser implementados

 Na prática, os requisitos e projeto são inseparáveis:

 A arquitetura do sistema pode ser projetada para estruturar os requisitos  O sistema pode interagir como outros sistemas, o que gera outros requisitos

de projeto

(13)

Requisitos de Software

Requisitos de Sistema

 Especificação em Linguagem Natural

Notation Description

Structured natural language

This approach depends on defining standard forms or templates to express the requirements specification.

Design description languages

This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system.

Graphical notations

A graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT (Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) have been used. I discuss these in the following chapter. Mathematical

specifications These are notations based on mathematical conceptssuch as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don’t understand formal specifications and are reluctant to accept it as a system contract. I discuss formal specification in Chapter 9.

(14)

Régis Simão 14/27

Requisitos de Software

Requisitos de Sistema

 Especificação em Linguagem Natural

 Ambigüidade

 Os leitores e documentadores de requisitos devem interpretar as mesmas palavras da mesma forma. A linguagem natural é naturalmente ambígua

 Sobrecarga de flexibilidade

 A mesma coisa pode ser dita várias maneira na especificação

 Falta de modularização

 As estruturas da linguagem natural são inadequadas para estruturar requisitos de sistema

(15)

Requisitos de Software

Requisitos de Sistema

 Especificações em Linguagem Estruturada

 Uma forma limita de linguagem natural pode ser usada para expressar

requisitos

 Desta forma, remove-se alguns dos problemas resultantes da

ambigüidade e da flexibilidade, e impõe um grau de uniformidade na especificação

(16)

Régis Simão 16/27

Requisitos de Software

Requisitos de Sistema

E C L I P S E / W o r k s t a t i o n / T o o l s / D E / F S / 3 . 5 . 1 F u n c t i o n A d d n o d e D e s c r i p t i o n A d d s a n o d e t o a n e x i s t i n g d e s i g n . T h e u s e r s e l e c t s t h e t y p e o f n o d e , a n d i t s p o s i t i o n . W h e n a d d e d t o t h e d e s i g n , t h e n o d e b e c o m e s th e c u r r e n t s e l e c t i o n . T h e u s e r c h o o s e s t h e n o d e p o s i t i o n b y m o v i n g t h e c u r s o r t o t h e a r e a w h e r e t h e n o d e i s a d d e d . I n p u t s N o d e t y p e , N o d e p o s i t i o n , D e s i g n i d e n t i fi e r . S o u r c e N o d e t y p e a n d N o d e p o s i t i o n a r e i n p u t b y t h e u s e r , D e s i g n i d e n t i fi e r fr o m t h e d a t a b a s e . O u t p u t s D e s i g n i d e n t i fi e r . D e s t i n a t i o n T h e d e s i g n d a t a b a s e . T h e d e s i g n i s c o m m i t t e d t o t h e d a t a b a s e o n c o m p l e t i o n o f t h e o p e r a t i o n . R e q u i r e s D e s i g n g r a p h r o o t e d a t i n p u t d e s i g n i d e n t i fi e r . P r e - c o n d i t i o n T h e d e s i g n i s o p e n a n d d i s p l a y e d o n t h e u s e r ' s s c r e e n . P o s t - c o n d i t i o n T h e d e s i g n i s u n c h a n g e d a p a r t fr o m t h e a d d i t i o n o f a n o d e o f t h e s p e c i fi e d t y p e a t t h e g i v e n p o s i t i o n . S i d e - e f f e c t s N o n e D e f i n i t i o n : E C L I P S E / W o r k s t a t i o n / T o o l s / D E / R D / 3 . 5 . 1

(17)

Requisitos de Software

O Documento de Requisitos de Software (DRS)

 É uma declaração oficial do que é solicitado aos desenvolvedores do

sistema

 Deveria incluir a definição e a especificação de requisitos

 Deve dizer o que o sistema deve fazer e não o como fazer

 Requisitos para o documento de requisitos:

 Especificar o comportamento externo do sistema  Especificar as restrições de implementação

 Fácil de alterar

 Servir como ferramenta de referência para manutenção (rastreabilidade)

 Documentos que compreendem o DRS:

 Documento de Visão, Glossário, Especificação de Casos de Uso, de

(18)

Régis Simão 18/27

Requisitos de Software

Tipos de Requisitos

 Requisitos Funcionais

 Declarações de funções que o sistema deve fornecer  Como o sistema deve reagir a entradas específicas  Como deve comporta-se em determinadas situações

 Em alguns casos, deve-se declarar o que o sistema não deve fazer

 Requisitos Não Funcionais

 Restrições sobre as funções. Exemplo:

 Restrição de tempo

 Restrição sobre o processo de desenvolvimento  Padrões

 Requisitos de Domínio

 Requisitos que se originam do domínio de aplicação do sistema e que

refletem características desse domínio. Podem ser requisitos funcionais ou não funcionais

(19)

Requisitos de Software

Requisitos Funcionais e Não Funcionais

 Requisitos Não Funcionais

 O objetivo é definir as propriedades e restrições do sistema, por

exemplo: confiabilidade, tempo de resposta e requisitos de armazenamento

 Requisitos não funcionais podem ser mais críticos que os requisitos

funcionais. Se os requisitos não funcionais não forem satisfeitos, o sistemas será menos usado

(20)

Régis Simão 20/27

Requisitos de Software

Requisitos Funcionais e Não Funcionais

 Classificações de Requisitos Não Funcionais

 Requisitos do Produto

 São os requisitos que especificam que o produto entregue deve comportar-se de um modo particular, por exemplo: velocidade de execução, confiabilidade, etc

 Requisitos Organizacional

 São os requisitos que são uma consequência das políticas e procedimentos organizacionais, por exemplo: padrões de processos usados, requisitos implementados, etc

 Requisitos Externos

 São os requisitos que foram levantados de fatores que são externos ao

sistema e seu processo de desenvolvimento, por exemplo: interoperabilidade dos requisitos, requisitos legais, etc.

(21)

Requisitos de Software

Requisitos Funcionais e Não Funcionais

Requisitos não funcionais

Requisitos do produto

Requisitos

organizacionais Requisitosexternos Requisitos de facilidade de uso Requisitos de eficiência Requisitos de desempenho Requisitos de espaço Requisitos de confiabilidade Requisitos de portabilidade Requisitos de entrega Requisitos de implementação Requisitos de padrão Requisitos de interoperabilidade Requisitos éticos Requisitos legais Requisitos de privacidade Requisitos de segurança Requisitos não funcionais Requisitos do produto Requisitos

organizacionais Requisitosexternos Requisitos de facilidade de uso Requisitos de eficiência Requisitos de desempenho Requisitos de espaço Requisitos de confiabilidade Requisitos de portabilidade Requisitos de entrega Requisitos de implementação Requisitos de padrão Requisitos de interoperabilidade Requisitos éticos Requisitos legais Requisitos de privacidade Requisitos de segurança

(22)

Régis Simão 22/27

Requisitos de Software

Requisitos Funcionais e Não Funcionais

 Problemas com os Requisitos não Funcionais

 Os requisitos não funcionais podem ser difíceis de verificar

 Facilidade de uso, legibilidade

 Deve-se procurar métricas objetivas (ver quadro no próximo slide)  Requisitos não funcionais podem ser conflitantes

 Manutenibilidade e Desempenho

 Os requisitos funcionais e não funcionais são especificados em

documentos separados:

 Para documentar requisitos funcionais: Especificações de Casos de Uso

e de Regras de Negócio

 Para documentar requisitos não funcionais: Especificação de Requisitos

(23)

Requisitos de Software

Requisitos Funcionais e Não Funcionais

(24)

Régis Simão 24/27

Requisitos de Software

Requisitos Funcionais e Não Funcionais

 Requisitos de Domínio

 São derivados do domínio da aplicação e descrevem as características

dos sistemas que refletem o domínio, em vez de serem obtidos a partir das necessidades específicas dos usuários do sistema

 Podem ser requisitos funcionais, restrições sobre os requisitos

existentes ou definem processamentos computacionais específicos

 Se os requisitos de domínio não são satisfeitos, eles podem ser inútil

(25)

Requisitos de Software

Requisitos Funcionais e Não Funcionais

 Problemas dos Requisitos de Domínio

 Compreensibilidade

 Os requisitos são expressos na linguagem do domínio da aplicação

 Estes requisitos são freqüentemente não entendidos pelos engenheiros de software que desenvolvem a aplicação

 Subtendido

 Especialistas de domínio entendem tão bem determinada área que eles não pensam em fazer os requisitos do domínio explícitos