REQUISITOS DE SISTEMAS

PROF. Horacio Ribeiro

Aula 05: DOCUMENTAO DE REQUISITOS DE

SOFTWARE

Entrevistas
A entrevista tradicionalmente mais simples de utilizar,
produz bons resultados na fase inicial de obteno de dados.
Organizar a entrevista:
- Os membros da equipe devem ter funoes : redator,
condutor, revisor....
O entrevistador d margem ao entrevistado para expor as
suas idias.
Ter um plano de entrevista para que seja mantido o foco no
cerne do assunto principal.
Evita que a entrevista fique longa, deixando o entrevistado
cansado e no produzindo bons resultados.

Entrevistas
boas prticas de entrevistas:
Desenvolver um plano geral de entrevistas;
Certificar-se da autorizao para falar com os usurios;
Planejar a entrevista para fazer uso eficiente do tempo.
Previamente o analista que far a entrevista deve procurar
est bem contextualizado, sendo mais assertivo e produtivo
O entrevistador deve coletar e estudar todos os dados
pertinentes, como formulrios, relatrios, documentos e
outros.
. No trmino, necessrio validar se o que foi documentado
est de acordo com a necessidade do usurio, que o usurio
no mudou de opinio e que o usurio entende a notao ou
representao grfica de suas informaes.

Entrevistas -termino

exemplos de como aferir a veracidade das informaes

levantadas na entrevista:
1 -Faa uma explanao sobre o relacionamento entre o que
est em discusso e as demais partes do sistema;
Informe do ponto de vista de outros usurios em relao ao
item que foi discutido;
Descreva informalmente a narrativa do item em que o
analista deseja obter informaes;
O analista deve dizer ao usurio o que acha que ouviu ele
dizer. e solicitar ao entrevistado confirmao do que foi dito.

Questionrios
Existem vrios tipos de questionrios :
mltipla escolha,
lista de verificao
questes com espaos em branco.
quando h diversos grupos de usurios que podem
estar em diversos locais diferentes do pas elaboramse pesquisas especficas de acompanhamento com
usurios selecionados, que a contribuio em potencial
parea mais importante, pois no seria prtico
entrevistar todas as pessoas em todos os locais.

Questionrios
Etapas
.preparo (fazer um prottipo)
Identifique todos os destinatrios que o recebero.
Realize a distribuio junto com instrues detalhadas sobre
seu preenchimento.
Defina e informe o prazo para devoluo do questionrio.
Documente o resultado da anlise e consolidao das
respostas dos participantes.
Envie uma cpia com as informaes levantadas para o
participante, como sendo uma forma de agradecimento e
considerao pelo tempo dedicado a pesquisa.

Brainstorming
Brainstorming uma tcnica para gerao de idias.
Uma idia preliminar gerada serve como incentivo para que
outras apaream, sejam concordantes ou no.
Pode ser estabelecida uma ou vrias reunies.
Os participantes devem ser encorajados a dar, e combinar
ou enriquecer as idias de outros e, para isso, necessrio
que todas as idias permaneam visveis a todos os
participantes.

Brainstorming
AS etapas necessrias para conduzir uma sesso de brainstorming
so:
Seleo dos participantes ou grupo de trabalho:
aconselhvel sempre a presena de pessoas que estejam sempre
bem informadas, sejam de diferentes grupos;
Prepara a sesso:
Durao e local do encontro, bem como o que ser tratado.
Explicar a tcnica e as regras a serem seguidas:
Definir as regras a serem seguidas durante a sesso;
Gerar ou produzir uma boa quantidade de idias:
Os participantes so convidados, um por vez, a dar uma nica idia.
Se algum tiver problema, passa a vez e espera a prxima rodada.
Analisar as idias: Revisar a produo de idias, destacando as mais
valiosas definidas pelo grupo e classificando-as com prioridades.

Prototipagem
Fazer um prottipo para explorar requisitos vinculados a um
produto que possua aspectos crticos.
Implementando de maneira mais rpida um pequeno subconjunto
de funcionalidades deste produto.

requisitos

desenvolver

validar

acertar
fim

prottipo aconselhado para:

1.Estudar as alternativas de interface do usurio;
2.Problemas de comunicao com outros produtos;
3.A viabilidade de atendimento dos requisitos de desempenho.
principais benefcios :
redues dos riscos na construo do sistema,
Validaoes de especificaoes
.
elementos para o sucesso na elaborao dos prottipos:
1.Seleo do ambiente de prototipagem;
2.Compreender os objetivos do prottipo por parte de todos os
interessados no projeto;
3.Focar em reas que estejam com maior dificuldade na
compreenso;
4.Rapidez na construo.

JAD (Joint Application Design).

uma tcnica destinada a promover cooperao, entendimento
e trabalho em grupo entre os usurios desenvolvedores.
A idia criar uma viso compartilhada do produto de software .
Ela ajuda os usurios e desenvolvedores a formular problemas e
explorar solues, no escopo do projeto a ser desenvolvido.

JAD (Joint Application Design).

Possui quatro princpios bsicos:
Dinmica de grupo: so realizadas reunies com um lder
experiente, analista, usurios e gerentes, para despertar a fora e
criatividade dos participantes. O resultado final ser a
determinao dos objetivos e requisitos do sistema;
Uso de tcnicas visuais: para aumentar a comunicao e o
entendimento;
Manuteno do processo organizado e racional: o JAD
emprega a anlise top down e atividades bem definidas.
Utilizao de documentao padro: preenchida e assinada
por todos os participantes. Este documento garante a qualidade
esperada do projeto e promove a confiana dos participantes.

JAD -participantes
Lder da sesso: um facilitador dos encontros. Deve ser competente,
com bom relacionamento pessoal e qualidades gerenciais de liderana.
Engenheiro de requisitos: um participante experiente nas questes
tcnicas, diretamente responsvel pela produo dos documentos de
sada das sesses JAD.
Executor: o responsvel pelo produto sendo construdo.
Representantes dos usurios: So pessoas na empresa que tero
incumbncia de utilizar o produto de software.
Representantes de produtos de software: So pessoas que esto
familiarizadas com as capacidades dos produtos de software, capazes
de mediar os usurios na compreenso entre o que possvel e
razovel no sistema.
Especialista: a pessoa que pode fornecer informaes detalhadas
sobre um tpico especfico.

REQUISITOS DE SISTEMAS

Contedo Programtico desta aula

Aprender sobre o documento de requisitos.

Reconhecer a importncia da elaborao do
documento de requisitos.
Verificar os pontos prioritrios e a ateno na
redao de um documento.
Compreender quem so os envolvidos no
processo de criao de um documento de
requisitos.
Verificar a composio de um documento de
requisitos.

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

O requisito precisa ser documentado de uma forma

organizada.
O documento de requisitos um documento formal utilizado
para comunicar os requisitos aos clientes, engenheiros e
gestores, alm de outros envolvidos que necessitem acessar
este documento.
importante conhecer o que deve conter e a quem e como
ser utilizado, que permita uma viso geral do sistema,
necessidades de negcio suportadas pelo sistema

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

Utilizao:
A documentao de requisitos:
- importante para o desenvolvimento de software,
- muito til na anlise e seleo de fornecedores de
aplicaes comerciais j desenvolvidas.
-- fundamental para a manuteno do sistema

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

Documentao de requisitos

REQUISITOS DE SISTEMAS

A documentao registra todo o contedo extrado no levantamento de

requisitos.
Retrata as especificaes a serem seguidas no desenvolvimento de
software.
Este o que denominamos que documento de requisitos de software.
Existem templates para desenvolver estes documentos.
Modelos de PRAXIS _RUP _ PROPRIETRIOS

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

De acordo com Sommerville (2009),

o documento de requisitos de software, s vezes chamado de
Especificao de Requisitos de Software (SRS do ingls Software
Requerimento Specification), uma declarao oficial do que os
desenvolvedores do sistema devem implementar.

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

requisitos de sistemas tem total ligao com o fator qualidade para o

desenvolvimento de software.
o documento de requisitos trata ento de indicar e detalhar sobre os
componentes a serem inseridos no sistema que est sendo
construdo.
E se comportar como uma bssola que NORTEIA TODO O
PROJETO e quais as ferramentas a serem estabelecidas ao trmino
do projeto.

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

criar um documento no editor de texto e digitar os itens e seus

respectivos conceitos. No o ideal
preciso ter disciplina e orientao para alcanar um documento
que seja acessvel e entendido pelos diversos participantes do
projeto, evitando que ele seja o primeiro recurso de desentendimento
e dificuldade para a compreenso .

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

Uma especificao de requisitos no apenas um documento

tcnico, que ser lido apenas pelos analistas de sistemas e os
programadores.
Sommerville (2009) esclarece sobre tal realidade, tratando
claramente sobre a diversidade do perfil de usurios, que vo
desde a cpula organizacional at aqueles vinculados
tecnologia da informao e comunicao.
(todos os tipos e stakeholders)

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

Sommerville (2009)
a diversidade de possveis usurios um indicativo de que o
documento de requisitos precisa ser um compromisso com a
comunicao dos requisitos para o cliente, a definio dos requisitos
em detalhes precisos para os desenvolvedores e testadores e a
incluso de informaes sobre a possvel evoluo do sistema.

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

Premissa:
compreensvel deve ser uma tnica para o grupo que est
responsvel por gerar o documento de requisitos.
o documento referncia:
-presente (quanto se est em pleno desenvolvimento),
-Futuro quando na fase de manuteno.
No tocante a compreenso o texto utilizado precisa ser organizado
com nvel adequado aos respectivos leitores.

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

exemplo abaixo, retirado do livro do PFLEEGER (Engenharia de

Software Teoria e Prtica 2 Edio, pg. 140):
Em 1995, a Organizao Australiana de Defesa e Tecnologia
relatou os resultados de uma pesquisa sobre problemas com
especificao de requisitos na Marinha.
Um dos problemas destacados foi a disparidade no nvel das
especificaes.
-alguns requisitos foram especificados em um nvel alto
- outros em um nvel muito baixo.

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

Analistas:
Algumas vezes, os analistas de requisitos utilizaram diferentes
estilos de escrita, especialmente em rea diferentes do sistema.
A diferena de experincia entre os analistas levou a diferentes
nveis de detalhes nos requisitos.
Na tentativa de reutilizar os requisitos a partir de sistemas
anteriores, os analistas empregaram diferentes formatos e estilos
de escrita.
Os analistas, algumas vezes, mesclaram requisitos com solues
parciais, levando a srios problemas para o projeto de uma soluo
com boa relao custo-benefcio.

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

REQUISITOS DE SISTEMAS

Analistas:
Freqentemente
os
requisitos
foram
excessivamente
especificados, quando os analistas identificaram tipos especficos
de computadores e linguagens de programao assumiram uma
soluo especfica ou impuseram processos e protocolos no
apropriados.
Algumas vezes, os requisitos foram pouco especificados,
especialmente ao descreverem o ambiente de operao,
manuteno,
simulao
para
treinamento,
computao
administrativa e tolerncia a falhas.

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5

Sommerville (2009) na Figura 1, so estes exemplos de usurios de um

documento de requisitos de software:

perfil de um documento de requisitos,

Vamos analisar sobre:
-a sua estrutura,
- o que pode ser considerado para a sua criao.
-- modelos

Segundo estrutura Sommerville (2009)

Captulo

Descrio

Prefcio

Deve definir os possveis leitores do documento e

descrever seu histrico de verses, incluindo uma
justificativa para a criao de uma nova verso e um
resumo das mudanas feitas em cada verso.

Introduo

Deve descrever a necessidade para o sistema. Deve

descrever brevemente as funes do sistema e explicar
como ele vai funciona com outros sistemas. Tambm
deve descrever como o sistema atende aos objetivos
globais do negcio ou estratgicos da organizao que
encomendou o software.

Segundo estrutura Sommerville (2009)

Captulo

Descrio

Glossrio

Deve definir os termos tcnicos usados no documento.

No deve conter suposies sobre o conhecimento ou
experincia do leitor.

Definio de Deve descrever os servios oferecidos ao usurio. Os

requisitos de requisitos no funcionais do sistema tambm devem ser
usurio

descritos nessa seo.

Essa descrio pode usar

linguagem natural, diagramas ou outras notaes

compreensveis para os clientes. Normas produtos que
devem ser seguidos devem sem especificados.
Modelos
sistema

do Pode incluir modelos grficos do sistema que mostram

relacionamentos entre os componentes do sistema, o
sistema e seu ambiente.

Segundo estrutura Sommerville (2009)

Captulo

Descrio

Evoluo do Deve descrever os pressupostos fundamentais em que

sistema

o sistema se baseia, bem como quaisquer mudanas

previstas, em decorrncia da evoluo do hardware, de
mudanas nas necessidades do usurio, etc. Essa
seo til para projetistas de sistemas, pois pode
ajud-los a evitar decises capazes de restringir
possveis mudanas futuras no sistema.

Segundo estrutura Sommerville (2009)

Captulo

Descrio

Apndices

Deve fornecer informaes detalhadas e especificas em

relao aplicao em desenvolvimento, alm das
descries de hardware e banco de dados, por
exemplo. Os requisitos de hardware definem as
configuraes mnimas do sistema. Requisitos de
banco de dados, definem a organizao lgica dos
dados usados pelo sistema e os relacionamentos entre
esses dados.

ndice

Vrios ndices podem ser includos no documento.

Pode haver, alm de um ndice alfabtico normal, um
ndice de diagramas, de funes, dentre outros que
sejam pertinentes.

essa proposta no nica e definitiva, podendo sofrer

adaptaes, incluses e excluses, a depender da
necessidade do cliente dos responsveis pela sua
criao e de padres de documentao das empresas

Ficha Tcnica
Equipe Responsvel pela Elaborao
<nome>
<identificao: carga, setor, diviso, regio>
<nome>
<identificao: carga, setor, diviso, regio>
<nome>
<identificao: carga, setor, diviso, regio>
<nome>
<identificao: carga, setor, diviso, regio>
Pblico Alvo
Este manual destina-se a <especifique o pblico alvo deste documento>
Verso <x.y> - <local>, <ms> de <ano>
Dvidas, crticas e sugestes devem ser encaminhadas por escrito para o
seguinte endereo postal:
<especifique o endereo para correspondncia>
Ou para o seguinte endereo eletrnico:
<especifique o e-mail para contato>
Recomendamos que o assunto seja identificado com o ttulo desta obra.
Alertamos ainda para a importncia de se identificar o endereo e o nome
completos do remetente para que seja possvel o envio de respostas.

Sumrio
INTRODUO P2
Viso geral deste documento P2
Convenes, termos e abreviaes

P2

CAPTULO 1 - DESCRIO GERAL DO SISTEMA

C1 . P2

Abrangncia e sistemas relacionadosC1 . P2

Descrio dos usurios
C1 . P2
1.<Opcional> <Nome de um tipo especfico de usurio> C1 . P2
2.<Opcional> <Nome de outro tipo especfico de usurio >
C1 . P2
3.
C1 . P2

CAPTULO 2 - REQUISITOS FUNCIONAIS (CASOS DE USO) C2 . P2

<Nome de subseo para agrupar casos de uso correlacionados> C2 . P2
[RF001] <Nome do caso de uso>
C2 . P2
Fluxo de eventos principal
C2 . P2
<Opcional> Fluxos secundrios (alternativos e de exceo)
C2 . P2
[RF] <Nome de outro caso de uso> C2 . P2
<Nome de outra subseo para agrupar outros casos de uso
correlacionados>
C2 . P2

C2 . P2

Usabilidade
C3 . P2
[NF001] <Nome do requisito>
[NF] <Nome do requisito>

C3 . P2
C3 . P2

Confiabilidade C3 . P2
[NF] <Nome do requisito>

C3 . P2

Desempenho C3 . P2
[NF] <Nome do requisito>

C3 . P2

Segurana
C3 . P2
[NF] <Nome do requisito>

C3 . P2

Distribuio C3 . P2
[NF] <Nome do requisito>

C3 . P2

Padres
C3 . P2
[NF] <Nome do requisito>

C3 . P2

Hardware e software C3 . P2
[NF] <Nome do requisito>
C3 . P2

CAPTULO 4 - <OPCIONAL> DESCRIO DA INTERFACE COM O USURIO

C4 . P2
<Identificador de uma interface>
1.<Opcional> Crticas da interface

C4 . P2
C4 . P2

<Identificador de outra interface>

C4 . P2

C4 . P2

Introduo
<Este espao deve ser usado para descrever os objetivos deste
documento e o pblico ao qual ele se destina. Complete e/ou
adapte o texto abaixo para fornecer essas informaes.>
Este documento especifica o sistema <Nome do sistema>,
fornecendo aos desenvolvedores as informaes necessrias para
o projeto e implementao, assim como para a realizao dos
testes e homologao do sistema.

Viso geral deste documento

<Esta seo fornece uma breve descrio de como o resto deste
documento est organizado. Complete e/ou adapte o texto abaixo para
fornecer essa informao.>
Contemple com as informaes necessrias para fazer um bom uso deste
documento, abrangendo a maioria dos objetivos e das convenes a
serem adotadas no texto, bem como uma lista de referncias para outros
documentos relacionados.
Para as demais sees, siga orientao como descrito abaixo.
Seo 2 Descrio geral do sistema: apresenta uma viso geral do
sistema, caracterizando qual o seu escopo e descrevendo seus usurios.
Seo 3 Requisitos funcionais (casos de uso): especifica todos os
requisitos funcionais do sistema, descrevendo os fluxos de eventos,
prioridades, atores, entradas e sadas de cada caso de uso a ser
implementado.
Seo 4 Requisitos no funcionais: especifica todos os requisitos no
funcionais do sistema, divididos em requisitos de usabilidade,
confiabilidade, desempenho, segurana, distribuio, adequao a
padres e requisitos de hardware e software.
Seo 5 Descrio da interface com o usurio: apresenta desenhos,
figuras ou rascunhos de telas do sistema.

Convenes, termos e abreviaes

<Esta subseo deve descrever as convenes, termos e abreviaes
necessrios para interpretar apropriadamente este documento. As
explicaes necessrias podem ser fornecidas diretamente nesta
seo ou atravs de referncias para outros documentos ou para
apndices deste documento. Complete e/ou adapte o texto abaixo
para fornecer essas informaes.>
A correta interpretao deste documento exige o conhecimento de
algumas convenes e termos especficos, que so descritos a seguir.

Identificao dos Requisitos

Por conveno, a referncia a requisitos feita atravs do nome da
subseo onde eles esto descritos, seguido do identificador do requisito,
de acordo com o esquema abaixo:
[nome da subseo.identificador do requisito]
Por exemplo, o requisito [Recuperao de dados.RF016] est descrito em
uma subseo chamada Recuperao de dados, em um bloco
identificado pelo nmero [RF016].
J o requisito no funcional [Confiabilidade.NF008] est descrito na
seo de requisitos no funcionais de Confiabilidade, em um bloco
identificado por [NF008].

Prioridades dos Requisitos

Para estabelecer a prioridade dos requisitos foram adotadas as
denominaes essencial, importante e desejvel.
Essencial o requisito sem o qual o sistema no entra em
funcionamento. Requisitos essenciais so requisitos
imprescindveis, que tm que ser implementados impreterivelmente.
Importante o requisito sem o qual o sistema entra em
funcionamento, mas de forma no satisfatria. Requisitos
importantes devem ser implementados, mas, se no forem, o
sistema poder ser implantado e usado mesmo assim.
Desejvel o requisito que no compromete as funcionalidades
bsicas do sistema, isto , o sistema pode funcionar de forma
satisfatria sem ele. Requisitos desejveis so requisitos que
podem ser deixados para verses posteriores do sistema, caso
no haja tempo hbil para implement-los na verso que est
sendo especificada

Descrio geral do sistema

<Descreva aqui, em linhas gerais, os objetivos do sistema,
comunicando o propsito da aplicao e a importncia do projeto para
todas as pessoas envolvidas.
Se for necessrio apresentar detalhes mais tcnicos sobre o sistema,
voc tambm pode usar esta seo para descrever em linhas gerais a
arquitetura do sistema, indicando seus mdulos principais, o uso (se
existir) da Internet ou outra rede de comunicao, componentes on-line
e off-line, e a interao (se existir) com outros sistemas. Use um
diagrama se achar conveniente.>

Abrangncia e sistemas relacionados

<Nesta seo, descreva em linhas gerais o que o sistema ir fazer
(suas principais funcionalidades) e o que ele no ir fazer (escopo
negativo), deixando claro se o sistema ir interagir com outros sistemas
relacionados ou se ele independente e totalmente auto-contido.
As funcionalidades principais do sistema devem ser apenas citadas,
para dar uma idia geral ao leitor dos servios que sero fornecidos
pelo sistema. Os detalhes sero fornecidos posteriormente, na seo 3
deste documento. Funcionalidades que a princpio seriam da alada do
sistema e que no sero implementadas tambm devem ser listadas,
registrando-se o motivo pela qual elas no sero contempladas (porque
sero fornecidas por outros sistemas relacionados, por exemplo, ou
porque sero implementadas apenas em projetos futuros).
Se o sistema for independente e totalmente auto-contido diga isso
explicitamente, caso contrrio, liste e descreva brevemente os outros
sistemas com os quais este sistema deve interagir, explicando, de
maneira geral, quais os papis de cada um e o meio de comunicao
entre eles.>

Descrio dos usurios

<Para efetivamente prover produtos e servios que atendam s
necessidades dos usurios, necessrio entender os desafios que eles
enfrentam para executar suas funes. Esta seo deve descrever os
futuros usurios do sistema e os principais problemas que limitam sua
produtividade.
Descreva os aspectos gerais, relacionados a todos os usurios, aqui.
Depois, se for necessrio, descreva nas subsees abaixo as
caractersticas especficas de cada usurio.>
<Opcional> <Nome de um tipo especfico de usurio>
<Se for conveniente fornecer mais detalhes sobre um tipo especfico de
usurio, use esta subseo para descrev-lo.>
<Opcional> <Nome de outro tipo especfico de usurio >
<Prossiga no detalhamento das caractersticas dos usurios,
descrevendo todos os tipos de usurio que for necessrio, cada um em
uma subseo.>

Requisitos funcionais
<Nesta seo, apresente todos os requisitos funcionais, ou casos de uso,
do sistema. Em sistemas grandes comum haver muitos casos de uso e,
para facilitar a visualizao deste documento, voc pode agrup-los em
subsees de casos de uso correlacionados. Os nomes das subsees
devem ser nicos e pequenos (3 palavras no mximo) e podem ser
formados por palavras, nmeros e/ou abreviaes.
Cada um dos casos de uso deve ser descrito em um bloco especfico,
seguindo o modelo descrito abaixo. O identificador do bloco deve conter o
nmero do caso de uso (por exemplo, [RF001]) e o seu nome. Se os
casos de uso forem agrupados em subsees especficas, a numerao
deles deve ser reiniciada a cada subseo (dentro de uma mesma
subseo, todo caso de uso deve ter um nmero de identificao nico).
Quando a primeira verso deste documento for disponibilizada para a
equipe de desenvolvimento, os nomes das subsees e os nmeros dos
casos de uso no devem ser modificados ou reaproveitados, para no
invalidar referncias externas feitas a eles.>

Nome de subseo para agrupar casos de uso correlacionados>

<Utilize este espao para descrever caractersticas comuns dos casos de
uso desta seo, explicitando o motivo do seu agrupamento em uma
seo nica.
Se todos os casos de uso desta seo estiverem relacionados com o
mesmo ator voc pode informar isso aqui, especificando qual o ator em
questo, e eliminar o campo Ator: das descries dos casos de uso
feitas nos blocos a seguir.>
[RF001] <Nome do caso de uso>
Essenci
Dese

Prioridade:
Importante
<Opcional fornea
uma pequena
explicao
do
propsito
al
jvel do caso de
uso (til quando o nome do caso de uso no deixa suficientemente claro
qual o seu objetivo) e o(s) seu(s) respectivo(s) ator(es). Em seguida,
substitua um dos smbolos abaixo por , para indicar a prioridade do
caso de uso.>
Ator: <informe o(s) ator(es) do caso de uso >
<Opcional>
Interface(s)
associada(s):
<inclua
aqui
o(s)
identificador(es) da(s) respectiva(s) interface(s) do caso de uso
(descrita(s) na Seo 5).>

Entradas e pr condies: <Liste aqui todas as entradas e/ou pr

condies do caso de uso. Pr condio de um caso de uso o estado
em que o sistema deve estar para realizar o caso de uso.>
Sadas e ps condies: <Liste aqui todas as sadas e/ou ps
condies do caso de uso. Ps condio de um caso de uso a lista de
possveis estados em que o sistema pode estar imediatamente aps o
trmino da realizao do caso de uso.>
Fluxo de eventos principal
<Descreva aqui o fluxo de eventos principal que ocorre durante a
Essenci
Dese

Importante
execuo do caso Prioridade:
de uso.>
al
jvel

<Opcional> Fluxos secundrios (alternativos e de exceo)

<Fluxo secundrio XXX>
<Use este espao para descrever o fluxo secundrio XXX do
caso de uso.>
<Fluxo secundrio YYY>
<Prossiga na descrio dos fluxos secundrios do caso de uso,
descrevendo cada um deles separadamente.>
[RF] <Nome de outro caso de uso>
<Utilize os mesmos campos mostrados no bloco anterior para
descrever este e os demais requisitos funcionais (casos de
uso) desta subseo.>
<Nome de outra subseo para agrupar outros casos de uso
correlacionados>
<Prossiga de maneira similar subseo anterior para
descrever quaisquer outras subsees que forem usadas para
agrupar requisitos funcionais.>

Requisitos no funcionais
<Esta seo deve conter os requisitos no funcionais do sistema.
Para uma melhor organizao deste documento, utilize as subsees
abaixo para agrupar os requisitos no funcionais relacionados.
Naturalmente, o nmero e tipo de subsees utilizadas depende do
sistema que est sendo especificado e no preciso utilizar todas
elas. Simplesmente elimine as subsees para as quais no for
encontrado nenhum requisito.
Os requisitos no funcionais devem ser identificados com um
identificador nico, da mesma maneira que os requisitos funcionais
(casos de uso). Inicie a numerao com o identificador NF001 e
prossiga incrementando os nmeros a medida que forem surgindo
novos requisitos no funcionais. Reinicie a numerao em cada
subseo. Fornea tambm um nome para o requisito, como foi feito
para os requisitos funcionais.
Descreva o requisito, assinale a sua prioridade e, em seguida, caso o
requisito esteja relacionado a um caso de uso ou a um grupo de
casos de uso especficos, utilize o campo Caso(s) de uso
associado(s):
para
identificar
o(s)
caso(s)
de
uso
correspondente(s). Se for um requisito no funcional do sistema
como um todo, esse campo no precisa ser utilizado.>

Usabilidade
Esta seo descreve os requisitos no funcionais associados facilidade
de uso da interface com o usurio, material de treinamento e documentao
do sistema.
[NF001] <Nome do requisito>
<Descreva o requisito no funcional e substitua um dos smbolos abaixo
por , para indicar a sua prioridade.>
<Opcional> Caso(s) de uso associado(s): <use este campo para
identificar a que caso(s) de uso o requisito de usabilidade est
relacionado.>
Essenci
Dese

Importante
[NF] <Nome doPrioridade:
requisito>
al
jvel
<Utilize os mesmos campos mostrados no bloco anterior para descrever
este e os demais requisitos no funcionais de usabilidade.>
Confiabilidade
Esta seo descreve os requisitos no funcionais associados freqncia,
severidade de falhas do sistema e habilidade de recuperao das mesmas,
bem como corretude do sistema.
[NF] <Nome do requisito>
<Utilize os mesmos campos mostrados na seo 4.1 para descrever este e
os demais requisitos no funcionais de confiabilidade.>

Desempenho
Esta seo descreve os requisitos no funcionais associados eficincia,
uso de recursos e tempo de resposta do sistema.
[NF] <Nome do requisito>
<Utilize os mesmos campos mostrados na seo 4.1 para descrever este
e os demais requisitos no funcionais de desempenho.>
Segurana
Esta seo descreve os requisitos no funcionais associados
integridade, privacidade e autenticidade dos dados do sistema.
[NF] <Nome do requisito>
<Utilize os mesmos campos mostrados na seo 4.1 para descrever este
e os demais requisitos no funcionais de segurana.>
Distribuio
Esta seo descreve os requisitos no funcionais associados
distribuio da verso executvel do sistema.
[NF] <Nome do requisito>
<Utilize os mesmos campos mostrados na seo 4.1 para descrever este
e os demais requisitos no funcionais de distribuio.>

Padres
Esta seo descreve os requisitos no funcionais associados a padres
ou normas que devem ser seguidos pelo sistema ou pelo seu processo
de desenvolvimento.
<Se voc mencionar documentos relacionados, no esquea de list-los
na seo 1.3.>
[NF] <Nome do requisito>
<Utilize os mesmos campos mostrados na seo 4.1 para descrever este
e os demais requisitos no funcionais de adequao a padres.>
Hardware e software
Esta seo descreve os requisitos no funcionais associados ao
hardware e software usados para desenvolver ou para executar o
sistema.
[NF] <Nome do requisito>
<Utilize os mesmos campos mostrados na seo 4.1 para descrever este
e os demais requisitos no funcionais de hardware e software.>

<Opcional> Descrio da interface com o usurio

<Esta seo deve conter desenhos ou rascunhos das telas do
sistema que forem necessrios ou convenientes para esclarecer
algum dos requisitos do sistema. Para sistemas que possuem
prottipos ou verses j desenvolvidas possvel capturar as telas e
apresentar figuras das mesmas.
Use nomes e/ou nmeros para identificar cada interface e descrevaas em sees independentes.>
<Identificador de uma interface>
<Descreva a interface em questo, atravs de figuras, diagramas e/ou
texto.
<Opcional> Crticas da interface
<Voc pode fazer aqui a descrio de crticas simples de interface,
como o tamanho e mscara de campos, simplificando assim a
descrio dos fluxos de exceo.>
<Identificador de outra interface>
<Prossiga no detalhamento das interfaces do sistema, descrevendo
todas que for necessrio, cada uma em uma subseo.>

Existem outros modelos:

Recomendamos que voc pesquise na internet:
Modelo do prxis:
especificao do produto de software
especificao dos requisitos de software
Pode-se fazer uma pgina WEB para documentar requisitos para
um projeto

DESAFIO
EXERCITE:
PEGUE UM SISTEMA QUE VOCE CONHECE OU
EST ESPECIFICANDO E COLQUE NO
MODELO APRESENTADO

Na prxima aula:

faremos uma reviso da cinco primeiras aulas preparando-o

REQUISITOS DE SISTEMAS

Contactos e material complementar e exerccios

www.espacodoprofessor.com
Professor: Horacio ribeiro
Modulo Estcio 2012.1
Senha 222222

DOCUMENTAO DE REQUISITOS DE SOFTWARE AULA5