FAPS 2010 02

Fundamentos de Análise e

Projeto de Sistemas

Fábio Gondim

2

Requisitos

• Descrição das funções e restrições para o sistema.

• A análise de requisitos é fundamental para o desenvolvimento de sistemas por tratar justamente de descobrir o que o cliente quer com o sistema.

• A análise de requisitos está associada ao processo de descobrir quais são as operações que o sistema deve realizar e quais são as restrições que existem sobre elas.

Requisitos

• “Definir com precisão os requisitos de um software permite que todos os recursos da empresa e a energia da equipe de

desenvolvimento sejam direcionados a um fim claro. Sem uma definição precisa daquilo que se pretende construir, perde-se tempo, mais erros são cometidos e a qualidade do produto final é incerta.”

André Koscianski e Michel dos Santos Soares no livro “Qualidade de Software” publicado pela editora Novatec.

Requisitos

• A fase de levantamento de requisitos é

decisiva para o sucesso do projeto

– A satisfação do usuário só poderá ser atingida se suas necessidades forem compreendidas.

– Um levantamento de requisitos mal feito pode comprometer o andamento do projeto.

• “Não importa quão bem projetado ou quão bem codificado seja, um programa mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor” [Pressman]

Requisitos

• A participação e colaboração efetiva do cliente são imprescindíveis para o um bom

levantamento e compreensão dos requisitos. Tanto o desenvolvedor como o cliente desempenham um papel ativo na análise e especificação de requisitos.

• “A análise e especificação de requisitos pode parecer uma tarefa relativamente simples, mas as aparências enganam. O conteúdo de comunicação é muito elevado. Abundam as chances de interpretações errôneas e informação falsas. A ambigüidade é provável.”

[Pressman]

Requisitos

• “As principais causas de falhas em projetos são relativas aos requisitos. Essas falhas se devem às dificuldades em entender o que o usuário quer, descrições incompletas e mudanças não controladas de requisitos, conforme estudo empírico com 8.380 projetos [Standish Group, 1995]. Portanto, realizar corretamente o levantamento e a administração de requisitos é vital para a qualidade do software.”

Falha na comunicação

(autoria desconhecida)

Requisitos - Classificações

• Quanto ao nível de abstração os

requisitos são classificados como:

– Requisitos do Usuário – Requisitos de Sistema

– Especificação de Projeto de Software

Requisitos - Classificações

– Abstratos e de alto nível;

– Declarações em linguagem natural e diagramas sobre as funções que o sistema deve fornecer; – O documento é utilizado por pessoas que não têm

conhecimento técnico do sistema (Ex: usuários finais, clientes, etc);

– Jargões de informática e termos técnicos devem ser evitados, mas termos do domínio da aplicação devem ser incluídos;

– Devem ser separados em obrigatórios e desejáveis.

Requisitos - Classificações

– Descrição detalhada do que o sistema deverá fazer; – Devem ser precisos e sem ambigüidade;

– Podem servir de contrato entre o comprador do sistema e o desenvolvedor do software;

– O documento é utilizado pelo cliente e também pelos profissionais técnicos e gerentes de projeto; – Uso de linguagem natural estruturada (Ex: formulário

com campos padrão).

Requisitos - Classificação

• Especificação de Projeto de Software

– Acrescenta detalhes técnicos ao documento de Requisitos do Sistema;

– É o documento que servirá de base para a implementação do sistema e será utilizado por desenvolvedores, arquitetos, analistas, etc.

Natureza dos Requisitos

• Quanto à natureza, os requisitos são

classificados como:

– Funcionais – Não funcionais

Requisitos Funcionais

• Requisitos funcionais: descrevem a

funcionalidade ou os serviços que se

espera que o sistema forneça.

Correspondem a listagem de tudo que o

sistema deve fazer.

– Ex.: Registrar empréstimos, calcular descontos, etc.

Requisitos Não Funcionais

os serviços ou as funções oferecidas pelo sistema. Entre eles destacam-se restrições de tempo, restrições sobre o processo de desenvolvimento e padrões de qualidade. Muitos consideram que os requisitos não funcionais são mais críticos que os requisitos funcionais, pois geralmente afetam o sistema como um todo.

Requisitos Não Funcionais

barra para que as operações sejam mais ágeis, o sistema deve ser acessível pela web, um cliente poderá ter no máximo cinco dependentes, após três entradas inválidas de uma senha o cartão do cliente deverá ser bloqueado, etc.

Requisitos de Domínio

• Requisitos de Domínio (Regras de

Negócio)

– São requisitos, que tal como o nome indica derivam do domínio e não de necessidades específicas dos utilizadores, podendo depois ser classificados como funcionais ou não-funcionais;

– Geralmente são expressos com o uso de linguagens que são específicas do domínio da aplicação o que pode vir a dificultar a compreensão pelos desenvolvedores.

Questões

1. Considerando uma aplicação de comércio eletrônico

de livros e cds, classifique os requisitos abaixo quanto à natureza:

– Cada consulta deve demorar no máximo 1 minuto para

retornar resultados.

– O sistema não deve permitir que um usuário realize um nova

compra se estiver inadimplente.

– Cadastrar usuário.

– Consultar livro por autor.

– Exibir menus com poucos itens e em cores diferenciadas.

– Compras feitas no cartão de crédito podem ser parceladas em

até 3 pagamentos sem juros.

– As páginas devem ser desenvolvidas em Java e o banco de

dados devem ser MySQL. – Exibir lista de CDs mais vendidos.

2. Quais seriam outros exemplos de requisitos, em cada

categoria, para o sistema da questão anterior?

Requisitos Funcionais Evidentes

• Os requisitos funcionais evidentes são aqueles efetuados com o conhecimento do usuário. Geralmente correspondem a eventos e

respostas do sistemas, ou seja, quaisquer troca de informações que ocorram pela interface do sistema com o meio exterior.

Requisitos Funcionais Ocultos

• Os requisitos funcionais ocultos são

aqueles efetuados pelo sistema sem o

conhecimento explícito do usuário.

– Ex.: Enviar, automaticamente, e-mail aos clientes cadastrados informando sobre o lançamento de novos produtos.

Requisitos funcionais obrigatórios e

Requisitos funcionais desejáveis

• Requisitos funcionais obrigatórios:

devem ser obtidos de qualquer maneira.

• Requisitos funcionais desejáveis:

Podem ser obtidos caso não causem

maiores transtornos ao processo de

desenvolvimento.

Classificação

dos requisitos não funcionais

• Visando uma melhor organização os requisitos não funcionais podem ser classificados por atributo. A seguir algumas categorias comumente usadas:

– Especificação

• Ex.: A cada três Dvd’s locados em uma segunda-feira, o de menor valor terá uma locação grátis.

– Interface

• Ex.: Todas as funções relacionadas a empréstimos devem ser efetuadas em uma única janela.

– Performance

• Ex.:O tempo para registro da operação deverá ser inferior a cinco segundos.

Classificação

dos requisitos não funcionais

– Segurança

• Ex.: A função só pode ser acessada por um usuários com um perfil de operador ou superior.

– Confiabilidade

• Ex.: O sistema deve ser tolerante a algumas falhas: falta de energia, falha de comunicação ou na mídia de gravação, etc. – Implementação

• Ex.: O cliente pode pedir um banco de dados específico por já possuir licenças de uso.

– Configuração

• Elementos que poderão ser configurados pelo usuário sem a necessidade de modificar e/ou recompilar o sistema. Ex.: escolher a moeda do país, definir limites em operações, etc. – Etc.

Desempenho

• Martin Fowler sugere algumas definições e medidas de desempenho bastante objetivas e úteis que podem ser utilizadas na especificação dos requisitos não funcionais. Vejamos

algumas:

– Tempo de resposta: quantidade de tempo que o sistema leva para processar uma solicitação externa; – Agilidade de resposta: diz respeito ao quão

rapidamente o sistema reconhece uma solicitação (em oposição ao tempo que leva para processá-la).

• Ex.: Fornecer uma barra de progresso durante uma cópia de arquivo melhora a agilidade de resposta da interface com o usuário, embora não melhore o tempo de resposta;

Desempenho

– Latência: tempo mínimo requerido para obter qualquer forma de resposta, mesmo se o trabalho a ser feito for inexistente. Geralmente é a grande questão em sistemas remotos.

• Ex.: “Se eu pedir a um programa para não fazer nada, mas para me avisar quando tiver terminado de fazer nada, então devo receber uma resposta quase instantânea se o programa rodar no meu laptop. Entretanto, se o programa rodar em um computador remoto, pode demorar alguns segundos devido ao tempo gasto para que a solicitação e a resposta cheguem aos seus destinos através da conexão.”

Requisitos não funcionais

transitórios e permanentes

Sistemas de Informação Orientados a Objetos sugere que os requisitos não funcionais podem, ainda, ser classificados como transitórios e permanentes:

– “Uma última classificação útil para os requisitos não funcionais indicará se são permanentes ou transitórios. O requisito permanente nunca mudará com o tempo (por exemplo, a interface feita por meio de janelas), já o requisito transitório poderá sofrer alterações no futuro (por exemplo, a forma de calcular impostos)

– O que você acha disto? Acredita que algum requisito possa ser permanente? Justifique.

Requisitos não funcionais

suplementares

• Na maioria dos casos os requisitos não

funcionais estão associados a algum

requisito funcional. Por exemplo o

requisito funcional “registrar empréstimos”

poderia ser uma operação restrita a

usuários com perfil de operador ou

superior. Esta restrição representa um

requisito não funcional claramente

associada.

Requisitos não funcionais

suplementares

• Na maioria dos casos os requisitos não funcionais estão associados a algum requisito funcional. Por exemplo o requisito funcional “registrar empréstimos” poderia ser uma operação restrita a usuários com perfil de operador ou superior. Esta restrição representa um requisito não funcional associado ao requisito funcional descrito. • Os requisitos não funcionais suplementares são

aqueles que não estão associados a nenhum requisito funcional em particular.

– Ex.: O sistema deve ter suas interfaces implementadas para acesso em navegadores web.

Engenharia de Requisitos

• O objetivo da fase de Requisitos de um

projeto de desenvolvimento de sistemas é

gerar documentos contendo descrições

detalhadas do que o sistema deverá fazer;

• A Engenharia de Requisitos envolve todas

as atividades exigidas para criar e manter

esse documento de requisitos do sistema.

Documento de Requisitos

• André Koscianski e Michel dos Santos Soares na segunda edição do livro “Qualidade de Software” publicado pela editora Novatec, em 2007, descreve algumas boas práticas na elaboração de um documento de requisitos que resumimos a seguir:

– Alocar tempo:

• Diminui o números de erros.

• O tempo usado na escrita é economizado futuramente, ao serem evitados enganos de interpretação por parte de pessoas diferentes.

• O investimento é apontado pela maioria dos estudos como positivo, inclusive financeiramente.

Documento de Requisitos

– Consistência:

• Todos os leitores devem interpretar as funcionalidades de uma mesma forma.

• Deve-se evitar o uso de sinônimos desnecessários para evitar confusões ou até mesmo a implementação duplicada de funções. Ex.: Em um local se referir a “cadastro de compradores” e em outro a “cadastro de clientes”

– Concisão:

• Usar frases e parágrafos curtos com uma informação por frase. • Evitar o uso de adjetivos. Declarar que um sistema deve ser

rápido é inútil para um desenvolvedor. Ele precisa de dados quantitativos, como o número de requisições por hora a processar.

Sugestão de formatação de um documento

de requisitos (Raul Sidnei Wazlawick)

F1 Registrar empréstimos Oculto ( )

Descrição: O sistema deve registrar empréstimos de fitas, indicando o cliente e as fitas que foram emprestadas, bem

como a data do empréstimo e valor previsto para pagamento na devolução.

Requisitos Não Funcionais

Nome Restrição Categoria Desejável Permanente

NF1.1 Controle de Acesso

A função só pode ser acessada por usuário com perfil de operador ou superior.

Segurança ( ) (x)

NF1.2 Identificação de Fitas

As fitas devem ser identificadas por um código de barras

Interface ( ) (x)

NF1.3 Identificação do cliente

O cliente deverá ser identificado a partir de seu nome Interface ( ) ( )

NF1.4 Tempo de registro

O tempo para registro de cada fita deve ser inferior a um segundo.

Performance (x) ( )

NF1.5 Janela única Todas as funções relacionadas a empréstimos devem ser efetuadas em uma única janela

Interface (x) (x)

... ... ... ... ...

F2 Calcular descontos Oculto ( x )

Descrição: O sistema deve calcular descontos nos empréstimos em função da política da empresa.

Requisitos Não Funcionais

Nome Restrição Categoria Desejável Permanente

NF2.1 Desconto de fim de semana

Nos fins de semana, usuários que levam 4 fitas pagam apenas 3.

Especificação ( ) ( )

... ... ... ... ...

Sugestão de formatação de um documento

de requisitos (Raul Sidnei Wazlawick)

Nome Restrição Categoria Desejável Permanente

S1 Tipo de Interface As interfaces do sistema devem ser implementadas como formulários acessíveis em um browser html.

Interface ( ) ( )

S2 Armazenamento de dados

A camada de persistência deve ser implementada de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro

Persistência ( ) ( x )

S3 Perfis de usuário Os perfis de usuário para acesso ao sistema são: 3. Administrador - pode efetuar todas as operações.

2. Operador - pode efetuar as operações de empréstimo, devolução, pagamento e cadastramento.

1. Convidado - pode efetuar apenas consultas nos próprios dados (cliente).

Segurança ( ) ( )