Sie sind auf Seite 1von 30
Universidade Federal Rural do Semi-Árido Prof. Joêmia Leilane Gomes de Medeiros Martins Disciplina: Processos e

Universidade Federal Rural do Semi-Árido

Prof. Joêmia Leilane Gomes de Medeiros Martins

Disciplina: Processos e Requisitos de Software

Engenharia de Requisitos

Análise de Viabilidade

l eilane.gomes@ufersa.edu.br

Angicos/RN

2016.2

Tipos de Requisitos

Requisitos de usuário

Declarações em linguagem natural com diagramas dos serviços que o sistema deverá fornecer e suas restrições operacionais. Escrito para os clientes.

Requisitos de sistema

Um documento estruturado estabelecendo descrições

detalhadas das funções do sistema, serviços e restrições operacionais. Define o que deve ser implementado assim, pode

ser parte de um contrato entre o cliente e o empreiteiro.

Requisitos de usuário e de sistema

Requisitos de usuário e de sistema
Requisitos de usuário e de sistema

Leitores de diferentes tipos de especificação de requisitos

Leitores de diferentes tipos de especificação de requisitos

Sistema de segurança de trem

Requisitos

Sistema de segurança de trem Requisitos Usuário = df Sistema Funcionais Não - funcionais Domínio Produto

Usuário

=

df

Sistema

segurança de trem Requisitos Usuário = df Sistema Funcionais Não - funcionais Domínio Produto

Funcionais

Não - funcionais

Domínio

de trem Requisitos Usuário = df Sistema Funcionais Não - funcionais Domínio Produto Organização Externo

Produto

Organização

Externo

Requisitos funcionais e não-funcionais

Requisitos funcionais

O sistema deve fornecer declarações de serviços, como o sistema deve reagir a

entradas específicas e como o sistema deve se comportar em determinadas

situações.

Pode explicitar o que o sistema não deve fazer.

Requisitos não-funcionais

Restrições aos serviços ou funções oferecidas pelo sistema, tais como restrições de tempo, restrições no processo de desenvolvimento, padrões.

Muitas vezes se aplica ao sistema como um todo ao invés de características

individuais ou serviços.

Requisitos de domínio

Restrições no sistema a partir do domínio de operação.

Requisitos Funcionais

Descrever a funcionalidade ou os serviços do sistema.

Depende do tipo de software, possíveis usuários e o tipo de sistema

em que o software é usado.

Requisitos funcionais dos usuários podem ser declarações de alto nível a respeito do que o sistema deve fazer.

Requisitos funcionais do sistema devem descrever detalhadamente os serviços do sistema.

Requisitos funcionais para o MHC-PMS

Sistema de Gerenciamento de Pacientes com Problemas de Saúde

Mental

Um usuário deve ser capaz de pesquisar as listas de agendamentos

para todas as clínicas.

O sistema deve gerar, a cada dia, para cada clínica, uma lista de

pacientes esperados para as consultas daquele dia.

Cada membro da equipe que usa o sistema deve ser exclusivamente

identificado pelo seu número de funcionário de 8 dígitos.

Imprecisão de requisitos

Problemas

definidos.

surgem

quando

os

requisitos

não

são

precisamente

Requisitos ambíguos podem ser interpretados de maneiras diferentes

por desenvolvedores e usuários.

Considere o termo 'pesquisa' no requisito 1

A intenção do usuário busca pelo nome de um paciente em todos as consultas em todas as clínicas;

Interpretação do desenvolvedor busca pelo nome de um paciente em uma clínica. O usuário escolhe a clínica e em seguida pesquisa.

Requisitos Não-funcionais

Esses

requisitos definem as propriedades e

as restrições do sistema

por

exemplo, confiabilidade, tempo de resposta e ocupação de área.

As restrições são capacidades de dispositivos de E/S, as representações do

sistema, etc.

Os requisitos de processo também podem ser especificados impondo o uso

de determinadas linguagens de programação ou método de desenvolvimento.

Os requisitos não-funcionais podem ser mais críticos do que os requisitos funcionais. Se esses não forem atendidos, o sistema pode ser inútil.

Tipos de requisitos não funcionais

velocidade de execução, confiabilidade, etc. padrões de processo usados, requisitos de implementação

etc. padrões de processo usados, requisitos de implementação requisitos de reguladores, requisitos legais

requisitos de reguladores, requisitos legais

Exemplos de requisitos não funcionais

Requisitos do Produto

[RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s.

Requisitos Organizacionais

[RNF002]

Todos

os

relatórios XYZ-00.

documentos

Requisitos Externos

[RNF003]

Informações

pessoais

operadores do sistema.

entregues

do

usuário

devem

seguir

o

não

devem

ser

padrão

de

vistas

pelos

Metas e requisitos

Requisitos não-funcionais podem ser muito difíceis de se definir precisamente e

requisitos imprecisos podem ser difíceis de se verificar.

Metas

A intenção geral do usuário, facilmente usável.

Requisito não-funcional mensurável. Uma declaração usando alguma métrica que pode ser objetivamente testada.

Metas são úteis para desenvolvedores quando exprimem as intenções dos usuários do sistema.

Requisitos de Usabilidade

O sistema deve

ser de

fácil uso

pelo

pessoal médico e deve ser

organizado de tal forma que os erros dos usuários sejam minimizados.

(Meta)

A equipe médica deve ser capaz de usar todas as funções do sistema

depois de quatro horas de treinamento.

Após esse treinamento, o número médio de erros cometidos pelos usuários experientes não deve exceder dois por hora de uso do sistema. (Requisito não-funcional testável)

Métricas para especificar requisitos não funcionais

Métricas para especificar requisitos não funcionais

Requisitos de Domínio

Desenvolver sistemas impõe requisitos ao sistema, ao qual vão muito

além de software e hardware. Por exemplo, um sistema de controle de trem deve levar em conta

as características de frenagem em diferentes condições climáticas.

Podemos ter que entender sobre: Contabilidade, Saúde, Supermercados, etc.

Requisitos de domínio criam novos requisitos funcionais, restrições

sobre requisitos existentes ou definem cálculos específicos.

Se os requisitos de domínio não forem satisfeitos, o sistema pode ser impraticável.

Problemas de requisitos de domínio

Compreensibilidade

Requisitos são expressos na linguagem do domínio da aplicação;

O que geralmente não é compreendido pelos engenheiros de

software que

Implicitude

desenvolvem o sistema.

Especialistas de domínio compreendem tão bem essa área que eles não pensam em tornar explícitos os requisitos de domínio.

ESTUDO DE VIABILIDADE

Estudo de Viabilidade O que é?

Estudo que indica se o esforço em desenvolver a ideia vale a pena

Visa tanto a tomada de decisão

Como a sugestão de possíveis alternativas de solução

Deve oferecer informações para ajudar na decisão

Se o projeto pode ou não ser feito

Se o produto final irá ou não beneficiar os usuários interessados

Escolha das alternativas entre as possíveis soluções

Há uma melhor alternativa?

Estudo de Viabilidade O Que Estudar?

Sistema organizacional apresentado

Usuários, políticas, funções, objetivos, etc.

Problemas com o sistema apresentado

Inconsistências, funcionalidades inadequadas, performance, etc.

Objetivos e outros requisitos para o novo sistema

O que precisa mudar?

Restrições

Incluindo requisitos não-funcionais do sistema (superficialmente)

Alternativas possíveis

Sistema atual é geralmente uma das alternativas

Vantagens e desvantagens das alternativas

Testes de Viabilidade

1.

Operacional

2.

Técnica

3.

Cronograma

4.

Econômica

Viabilidade Operacional

Medida do grau de adequação da solução para a organização.

Avaliação de como as pessoas se sentem sobre o sistema/projeto. Avalia a urgência do problema (visão e fases de estudo) ou a

aceitação da solução (definição, seleção, aquisição, e fases do projeto)

Há dois aspectos da viabilidade operacional a serem considerados

O problema vale a pena ser resolvido ou a solução proposta para o

problema funcionará? Como o usuário final e a gerência sentem-se sobre o problema (solução)?

Viabilidade Técnica

Avaliação

da

praticidade

de

uma

solução

técnica

específica

e

a

disponibilidade dos recursos técnicos e dos especialistas.

A solução ou a tecnologia proposta é prática?

Já possuímos a tecnologia necessária?

Já possuímos o conhecimento técnico necessário?

Viabilidade de Cronograma

Avaliação de quão razoável está o cronograma do projeto.

Dado

nosso

conhecimento

técnico,

os

prazos

dos

projetos

são

razoáveis?

 

Alguns projetos são iniciados com prazos específicos

 

Você

precisa

determinar

se

os

prazos

são

obrigatórios

ou

desejáveis Se são mais desejáveis que obrigatórios, o analista pode propor outros cronogramas

Estudo de Viabilidade Tipos de Custos

Custos de desenvolvimento de sistemas

Desenvolvimento e aquisição

Custos de instalação e de conversão

Custos operacionais (contínuo)

Manutenção

Pessoal

Análise Custo x Benefício

Há três técnicas principais

Análise do retorno financeiro (payback analysis)

Retorno do investimento (return of investments)

Valor atual líquido (Net present value)

Análise de Retorno do Investimento

A técnica de análise de Retorno do Investimento (ROI) compara os

benefícios das diferentes soluções ou projetos.

O ROI para uma solução ou projeto é a taxa percentual que mede a relação entre a quantia que a empresa obtém de retorno ao seu investimento e a quantia investida.

Análise de Retorno do Investimento

O ROI para uma solução ou projeto potencial é calculado como a

seguir:

ROI = (Benefícios totais - Custos totais) / Custos totais

ROI = valor atual líquido / Custos totais

Ex: ROI = (22508,64-17321,20)/ 17321,20= 29,95%

EX: ROI = 5187,44/ 17321,20 = 29,95%

A solução que oferecer o ROI mais alto é a melhor alternativa.

TAREFA DE CASA!!!!

TAREFA DE CASA!!!! PENSAR!!!!
PENSAR!!!!
PENSAR!!!!

FIM

15/03/2017