Modelagem conceitual com UML (Linguagem de Modelagem Unificada) - Bsico

Engenharia de Requisitos

Caro aluno,

dentro da Engenharia de Software (ES), temos uma especialidade que a Engenharia

de Requisitos(ER), que segundo Sommerville (2003), o processo de descobrir,
analisar, documentar e verificar as funes e restries do sistema. Mas afinal o que
um Requisito de Sistema?

Requisitos de um sistema, segundo Sommerville (2011), so descries do que o

Sistema DEVE fazer, os servios que oferece e as restries a seu funcionamento. Esses
requisitos refletem a necessidade dos clientes e para um sistema que serve a uma
finalidade determinada, como controlar um dispositivo, colocar um pedido ou
encontrar informaes. Veja o Processo de Engenharia de Requisitos na figura 1
abaixo:

Figura 1 Processo de Engenharia de Requisitos

Fonte: Sommerville (2007, p.96)

Vamos esclarecer esse processo?

I. Estudo de viabilidade

O estudo de viabilidade consiste num estudo preliminar de requisitos de negcios,

no qual decidido se vale a pena desenvolver o sistema proposto. Um estudo breve
verifica se:

O sistema contribui para os objetivos da organizao?

O sistema pode ser implementado com a tecnologia atual e dentro do

oramento?

O sistema pode ser integrado com outros sistemas em operao?

A realizao do estudo de viabilidade envolve desde a avaliao de

informaes, coleta de dados e elaborao de um relatrio. Durante esta fase podemos
consultar os engenheiros de software, especialistas em tecnologia e os usurios finais
para coletarmos as informaes, levando em mdia de 02 (duas) a 03 (trs) semanas
para concluir as atividades.

II. Elicitao e anlise de requisitos

Nesta atividade, os engenheiros trabalham em conjunto com os usurios finais do

sistema no intuito de entender o domnio da aplicao. Para tal, envolvem vrias
pessoas da organizao, que so denominadas stakeholders. Voc sabe o que um
stakeholder?

Curiosidade: O termo Stakeholder aplicado a qualquer pessoa que ter influnc

indireta sobre os requisitos do sistema, podendo ser usurios finais, pessoal de um
organizao que venham a ser afetado pelo sistema, engenheiros envolvidos no de
ou manuteno do sistema (e/ou outros sistemas relacionados),gerentes de negci
especialistas no domnio da aplicao e at representantes de sindicatos.

E os membros da equipe tcnica trabalham com o cliente e os usurios para descobrir

mais informaes sobre o domnio da aplicao, servios do novo sistema, desempenho
e as restries operacionais.

III. Problemas com a anlise de requisitos

Durante o processo de elicitao e anlise dos requisitos, encontramos alguns

problemas para realizar a atividade, pois:

Pessoas diferentes podem ter requisitos conflitantes;

Pessoas expressam os requisitos usando termos prprios;

Fatores polticos podem influenciar os requisitos do sistema;

Os requisitos se alteram durante o processo de anlise, pois o ambiente

econmico e de negcios dinmico.

Vamos assistir agora um breve vdeo "O Cometa Halley e as prolas da comunicao".

O que voc achou do vdeo?

Como voc enxerga o problema de comunicao:

no momento de levantar os requisitos?

no momento de apresentar os requisitos a equipe de desenvolvimento?

o que voc e sua equipe tem feito para resolvere este problema?

IV. Processo de elicitao e anlise de requisitos

Podemos verificar que cada organizao ter a sua prpria verso de um modelo para a
obteno e anlise de requisitos, dependendo de fatores locais, nvel de conhecimento
da equipe, tipos do sistema a ser desenvolvido e aos padres dos usurios.

As atividades do processo so:

Obteno de requisitos - um processo que visa coletar requisitos, em que os

requisitos de domnio tambm so descobertos durante esta atividade.

Classificao e organizao de requisitos envolve a coleta de requisitos no

estruturados, agrupando e organizando em conjuntos coerentes.

Priorizao e negociao de requisitos atividade relacionada priorizao de

requisitos, devido a requisitos conflitantes (quando h vrios stakeholder
atuando), procura e resoluo de conflitos por meio de negociaes.

Documentao de requisitos so documentados e colocados na prxima volta

da espiral, podendo ser produzidos documentos de requisitos formais ou
informais.

V. Especificao e documentao de requisitos

A especificao de requisitos uma etapa essencial do processo de desenvolvimento

de software, que compreende uma definio completa do comportamento externo de
software do sistema ou parte do sistema.

Requisitos do usurio

So declaraes, em linguagem natural e diagramas, sobre os servios que o sistema

oferece e as restries para a sua operao. So escritos para os clientes.

Requisitos do sistema

Estabelecem detalhadamente as funes e restries do sistema. O documento de

requisitos, chamado de especificao funcional, pode servir como um contrato entre
cliente e desenvolvedor.

Especificao de software

Trata de uma especificao abstrata e precisa do software, indicando o que ele deve
fazer (sem dizer como) que serve de base para o design e implementao. Acrescenta
mais detalhes especificao funcional e escrito para a equipe de desenvolvimento.

Ao descrever os requisitos, necessitamos nos atentar s seguintes situaes, pois:

a. A especificao dos requisitos deve ser completa (deve descrever tudo o que
necessrio), consistente (no deve haver conflitos e contradies) e no-ambgua
(no deve levar a interpretaes diferentes por desenvolvedores e usurios).
b. difcil de atingir, considerando que existem diferentes tipos de requisitos
envolvidos.
c. Depende da preciso da linguagem utilizada, visto que a linguagem natural,
informal mais apropriada para os requisitos do usurio e do sistema, j as
linguagens grficas, semi formais, so apropriadas para os requisitos do sistema
e do software, e as linguagens formais so mais apropriadas para uma
especificao formal de software em mtodos formais.

Os requisitos de software so frequentemente classificados como requisitos funcionais

e no funcionais, veremos na Prxima Etapa.

Parabns voc chegou ao final do nvel Bsico.

Aguardo voc no Prximo Nvel!

REFERNCIAS

SOMMERVILLE, Ian. Engenharia de software. 8. ed. So Paulo: Pearson, 2007.

SOMMERVILLE, Ian. Engenharia de software. 9. ed. So Paulo: Pearson, 2011.

Modelagem conceitual com UML (Linguagem de Modelagem Unificada) Intermedirio
Caro aluno, seja bem vindo ao nvel Intermedirio.

Conforme apresentado no final do Nve Bsico, agora daremos sequncia aos

Requisitos funcionais e No funcionais.

:: Requisitos Funcionais::
So declaraes de servios que o sistema DEVE fornecer, como o mesmo deve reagir
a entradas especficas e como o sistema deve se comportar em determinadas situaes,
sendo que em muitas vezes tambm podem explicar como o sistema DEVE ou no
fazer.
Exemplo:

o software deve possibilitar o clculo dos gastos dirios, semanais,

mensais e anuais com pessoal.

o software deve emitir relatrios de compras a cada quinze dias.

os usurios devem poder obter o nmero de aprovaes, reprovaes e

trancamentos em todas as disciplinas por um determinado perodo de
tempo.

I. Especificao dos Requisitos Funcionais utilizando Casos de Uso

Para realizarmos a especificao desses requisitos podemos criar nossos prprios
templates, nossas prprias regras ou podemos contar com os vrios templates existente
no mercado ou podemos contar com o apoio dos Casos de Uso e sua especificao, que
segundo Sommerville (2011), so tcnicas de descoberta de requisitos introduzida
inicialmente no mtodo Objectory (Jacobson et al., 1993), que se tornaram uma
caracterstica fundamental da linguagem de modelagem unificada (UML do ingls
Unified modeling language).
Os casos de uso so documentos utilizados pelos Diagramas de Caso de Uso da UML e
representaro as funcionalidades do sistema.

Pense no seguinte cenrio:

O dono do salo de beleza Glamour solicitou um Sistema de Cabeleireiro para sua
empresa de desenvolvimento AllDesenvol, mas inicialmente ele quer apenas poder
controlar o cadastro dos seus clientes, servios fornecidos e os produtos que o
futuramente comear a vender e os profissionais que realizaro os servios. E disse
tambm que quem manipular essas informaes no sistema a secretria, ou seja, para
cada uma das funcionalidades acima ela realizar o CRUD (ver definio).
Vamos verificar como modelar isso utilizando o diagrama de caso de uso na
Figura 1 abaixo?
Figura 1 - Diagrama de Caso de Uso

Fonte: Autor

Vamos entender o Diagrama:

A secretria, representada por um homem palito, o Ator do sistema,

ou seja, o responsvel pela a interao com o sistema. Mas, um ator
pode ser uma pessoa (papis) ou outros sistemas.

E os casos de uso, Controlar Cliente, Controlar Produto,, Controlar

Servio e Manter Profissionais esto representados por uma elipse,
sendo essas as funcionalidades do sistema, ou seja, aquilo que o
sistema DEVE fazer.

E para especificao desses requisitos podemos utilizar um template, chamado

Especificao de Requisitos de Software clique aqui para visualizar. Este template
fornecido pelo RUP (Processo Unificado da Rational).
O RUP baseado nos conceitos da UML (saiba mais no Aprofundando Conhecimento),
foi desenvolvido nos laboratrios da Rational e posteriormente a Rational foi
adquirida pela IBM.
Quando nos referimos a este documento como um template porque o usurio ter a
opo de acrescentar ou retirar informaes. Veja um novo exemplo de especificao
criado a partir do modelo do RUP, clique aqui.
Nota: Criamos um documento de especificao para cada Caso de Uso aqui
representado, neste nosso exemplo teramos que criar 4 documentos.
Links importantes:

http://www.tiespecialistas.com.br/2011/02/rup-primeiros-passos/

http://pt.slideshare.net/renancristiano/visao-geral-rup-presentation

http://www.macoratti.net/07/12/net_fer.htm

:: Requisitos no-funcionais ::
So restries aos servios ou funes oferecidas pelo sistema, que incluem restries
de tempo, no processo de desenvolvimento e tambm restries impostas por
normas/leis. Os requisitos no funcionais, muitas vezes, aplicam-se ao sistema como um
todo.
So exemplos de requisitos no-funcionais:

a base de dados deve ser protegida para acesso apenas de usurios

autorizados.

o tempo de resposta do sistema no deve ultrapassar 30 segundos.

o software deve ser operacionalizado no sistema Linux.

o tempo de desenvolvimento no deve ultrapassar seis meses.

II. Validao de requisitos

o processo pelo qual se verifica se os requisitos elicitados definem o sistema
que o cliente realmente quer. A validao tambm importante, uma vez que o custo
para remover erros de requisitos grande, quando descobertos tardiamente.
Durante o processo de validao de requisitos, diferentes tipos de verificao
devem ser efetuados com os requisitos no documento de requisitos. Essas
verificaes incluem:
1.

Validade - O sistema fornece as funes que melhor atendem as

necessidades de todos os usurios?

2.

Consistncia - Existem conflitos de requisitos?

3.

Completeza - Todas as funes necessrias foram includas?

4.
5.

Realismo - Os requisitos podem ser implementados com a tecnologia

e oramento disponveis?
Verificabilidade - Os requisitos podem ser checados?

Uma srie de tcnicas de validao podem ser usadas individualmente ou em

conjunto, tais como:

1.

Revises de requisitos - feita uma anlise manual sistemtica dos

requisitos;

2.

Prototipao - um modelo executvel do sistema demonstrado

para os usurios finais para checar os requisitos;

3.

Gerao de casos de teste - os requisitos devem ser testveis, para

tal deve- se desenvolver testes para os requisitos a fim de verificar a
testabilidade.

APROFUNDANDO CONHECIMENTO
Na dcada de 90, Booch, Rumbaugh e Jacobson, conhecido como
os 3 amigos, motivaram para criar uma linguagem de modelagem
unificada, unindo as melhores caractersticas dos mtodos citados e
criaram a UML, no laboratrio da Ratinal, conforme dito acima. Veja
o experimento.
Mas afinal o que a UML?
uma linguagem grfica para visualizao, especificao,
construo e documentao de artefatos de sistemas complexos de
software (BOOCH, 2000). Segundo Bezerra (2007) uma linguagem visual
para modelar sistemas orientados a objetos. Independente tanto de
linguagem de programao quanto de processo de desenvolvimento de SW.
A UML possui 13 diagramas para apoiar no Processo de
Desenvolvimento de Software, sendo estes divididos em Estruturais
e Comportamentais. Saiba mais
E que a Orientao a Objetos?
Segundo Rumbaugh (1996) orientao a objeto trata-se de uma
nova maneira de pensar os problemas utilizando modelos
organizados a partir de conceitos do mundo real, sendo o principal
componente o objeto, que combina dados e comportamento.
Histrico da linguagens orientadas a objetos:

1966 SIMULA (Kristen Nogaard, Noruega);

1980 SMALLTALK (Xerox);

1986 C++ (AT&T), SMALLTALK V , OBJECTIVE-C;

1988 EIFFEL (Meyer, Frana);

1989 Turbo Pascal 5.5 (Borland);

1995 JAVA;

Caractersticas da OO:

Reusabilidade: Reutilizao de componentes de software e

diminuio do tempo de desenvolvimento.

Manutebilidade: Mudanas bem localizadas, no

acarretando propagaes descontroladas.

Confiabilidade: O encapsulamento permite um maior

controle e segurana s classes dos objetos.

Extensibilidade: Extensibilidade a medida da facilidade em

se adicionar novas funcionalidades (operaes) a um componente de
uma modelagem existente.
Saiba mais>>

Parabns voc chegou ao final do nvel Intermedirio. No nvel Avanado falaremos

sobre "Gerencimento de Requisitos".
Te aguardo no Prximo Nvel!

REFERNCIAS

SOMMERVILLE, Ian. Engenharia de software. 8. ed. So Paulo: Pearson, 2007.

SOMMERVILLE, Ian. Engenharia de software. 9. ed. So Paulo: Pearson, 2011.
Modelagem conceitual com UML (Linguagem de Modelagem Unificada) Avanado
Caro aluno, seja bem vindo ao nvel Avanado.
Gerenciamento de Requisitos
O gerenciamento de requisitos o processo de controlar as mudanas nos requisitos
durante o processo de engenharia de requisitos e desenvolvimento. Torna-se necessrio
manter o acompanhamento dos requisitos individuais e manter as ligaes entre os
requisitos dependentes de modo que possa avaliar os impactos das mudanas de
requisitos.
Considerando que os requisitos so inevitavelmente incompletos e inconsistentes, novos
requisitos surgem durante o processo de desenvolvimento e os diferentes pontos de vista
que esses requisitos possuem frequentemente so contraditrios.
Existem vrias razes pelas quais as mudanas so inevitveis dentre as quais destacase:

A prioridade dos requisitos de diferentes pontos de vista se modifica;

As pessoas que pagam pelo sistema podem especificar os requisitos de maneira

conflitantes com os requisitos das pessoas que iro utilizar o sistema;

A empresa e o ambiente tcnico do sistema se modificam durante o seu

desenvolvimento.

Evoluo dos requisitos

Do ponto de vista da evoluo, os requisitos dividem-se em duas classes:
1. Requisitos permanentes
So requisitos estveis, derivados da atividade principal da organizao. Ex. Em um
hospital sempre haver requisitos relativos aos pacientes, aos mdicos, s enfermeiras a
aos tratamentos.
2. Requisitos volteis
So requisitos que se modificam durante o desenvolvimento ou quando o sistema est
em uso. Requisitos resultantes de polticas governamentais. Ex: planos de assistncia
mdica.
Os requisitos volteis podem ser classificados em:

a) Requisitos mutveis - Requisitos que se modificam por causa do ambiente do

sistema que est operando.
b) Requisitos emergentes - Requisitos que surgem medida que a compreenso do
sistema pelo cliente progride durante o desenvolvimento do sistema.
c) Requisitos consequentes - Requisitos que resultam da introduo do sistema de
computador, onde pode criar novas formas de trabalho que geram novos requisitos de
sistema.
d) Requisitos de compatibilidade - Requisitos que dependem de outros sistemas ou
processos de negcio especficos dentro da organizao.
Gerenciamento de mudanas de requisitos
A figura abaixo mostra o processo de gerenciamento de requisitos, o qual deve ser
aplicado a todas as mudanas propostas aos requisitos. A vantagem de usar um mtodo
formal para gerenciar mudanas est no fato de que as propostas so tratadas
consistentemente e a documentao dos requisitos feita de maneira controlada.
Figura 1 Gerenciamento de Mudana de Requisitos

Fonte:Sommerville (2011, p. 79)

Existem trs estgios no processo de gerenciamento de mudanas que so:

Anlise do problema e especificao da mudana.

Discute-se os problemas com os requisitos e prope-se mudanas.

Anlise e custo da mudana.

Avalia-se os efeitos da mudana em outros requisitos do sistema.

Implementao das mudanas.

O documento de requisitos e outros documentos so alterados de forma a refletir
as mudanas.

Tcnicas de Requisitos

A seguir apresentaremos algumas tcnicas para Elicitao ( levantamento) e anlise de

requisitos:

Levantamento baseado em pontos de vista;

Entrevistas;

Cenrios de utilizao do sistema;

Etnografia (anlise do ambiente de trabalho dos usurios).

1. Levantamento baseado em pontos de vista

As abordagens baseadas em pontos de vista tem como ponto forte o reconhecimento de
vrias perspectivas, fornecendo um framework para descobrir conflitos nos requisitos
propostos por diferentes stakeholder. Lembra o que era Stakeholder, certo?
Sistemas mdios e grandes possuem diferentes tipos de usurios finais:

Pessoas envolvidas com o sistema possuem diferentes interesses e pontos de

vista a respeito do sistema;

A anlise desta multi-perspectiva importante para descobrir e esclarecer os

requisitos conflitantes, propostos por diferentes usurios.

2. Entrevistas
Fazem parte da maioria dos processos de engenharia de requisitos. Nestas entrevistas a
equipe de engenheiros formula questes para os stakeholders sobre o sistema a ser
desenvolvido.
As entrevistas podem ser abertas, em que o stakeholder responde um conjunto de
perguntas predefinidas ou fechadas, nas quais no h um roteiro definido, onde o
engenheiro explora vrios assuntos com os stakeholders no sistema, desenvolvendo
assim uma maior compreenso das necessidades dos mesmos.
As entrevistas so teis para obter um entendimento geral sobre o que os stakeholders
fazem, como eles podem interagir com o sistema e as dificuldades que enfrentam com o
sistema atual, porm no so eficientes para elicitao de conhecimento sobre os
requisitos e suas restries.
3. Cenrios de utilizao do sistema
Geralmente, as pessoas consideram mais simples relatar exemplos da vida real que
abstrair descries, desta forma os cenrios podem ser descritos e criticados por eles
como uma forma de interao com o sistema de software.

Os cenrios so teis para adicionar detalhes a um esboo da descrio de requisitos,

onde cada cenrio abrange uma ou mais interaes possveis. Assim sendo, diversos
cenrios foram desenvolvidos, cada um dos quais fornecendo diferentes tipos de
informaes sobre o sistema em diversos nveis de detalhamento.
Descries de cenrios incluem:

Estado do sistema no incio do cenrio;

Fluxo normal de eventos no cenrio;

O que pode sair errado e como lidar com isso;

Outras atividades concorrentes;

Estado do sistema no final do cenrio.

4. Etnografia (anlise do ambiente de trabalho dos usurios)

uma tcnica de observao que pode ser usada na compreenso dos requisitos sociais
e organizacionais, na qual um analista se insere no ambiente de trabalho onde o sistema
ser usado, observa o trabalho do dia-a-dia e anota as tarefas reais nas quais os
participantes esto envolvidos.
Denota-se o valor desta tcnica na ajuda prestada aos analistas para descobrir os
requisitos implcitos de sistemas que refletem os processos reais, e no os formais no
qual as pessoas esto envolvidas.
A etnografia particularmente eficaz para descobrir:

Requisitos derivados da maneira como as pessoas realmente trabalham ao

invs da maneira pela qual as definies de processo dizem o que deveria fazer.

Requisitos derivados da cooperao e do conhecimento das atividades de

outras pessoas.

A etnografia pode e dever ser combinada com a prototipao, pois informa o

desenvolvimento do prottipo de tal forma que poucos ciclos de refinamento sejam
necessrios.
Uma vantagem da etnografia que ela pode revelar detalhes importantes do processo,
que frequentemente so ignorados por outras tcnicas, porm no apropriada para
obter os requisitos organizacionais e de domnio. Assim sendo, a etnografia no uma
abordagem completa para a elicitao de requisitos, ento devendo ser usada como
complemento de outra abordagens como, por exemplo, a de cenrios.
Os membros da equipe tcnica trabalham com o cliente e os usurios para descobrir
mais informaes sobre o domnio da aplicao, servios do novo sistema, desempenho

e as restries operacionais.
Parabns voc chegou ao final deste desafio!

REFERNCIAS
SOMMERVILLE, Ian. Engenharia de software. 8. ed. So Paulo: Pearson, 2007.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. So Paulo: Pearson, 2011.

<Nome do Projeto>
Especificao de Requisitos de Software
Para <Subsistema ou Recurso>

Verso <1.0>

[Observao: O template a seguir fornecido para uso com o Rational Unified Process
(RUP). O texto em azul exibido entre colchetes e em itlico (style=InfoBlue) foi
includo para orientar o autor e deve ser excludo antes da publicao do documento.
Qualquer pargrafo inserido aps esse estilo ser definido automaticamente como
normal (estilo=BodyText).]

Histrico da Reviso

Data
<dd/mmm/aa>

Verso
<x.x>

Descrio
<detalhes>

Autor
<nome>

ndice Analtico
1. Introduo
1.1 Finalidade
1.2 Escopo
1.3 Definies, Acrnimos e Abreviaes
1.4 Referncias
1.5 Viso Geral
2. Descrio Geral
3. Requisitos Especficos
3.1 Funcionalidade
3.1.1 <Requisito Funcional Um>
3.2 Usabilidade
3.2.1 <Requisito de Usabilidade Um>
3.3 Confiabilidade
3.3.1 <Requisito de Confiabilidade Um>
3.4 Desempenho
3.4.1 <Requisito de Desempenho Um>
3.5 Suportabilidade
3.5.1 <Requisito de Suportabilidade Um>
3.6 Restries de Design
3.6.1 <Restrio de Design Um>
3.7 Requisitos de Sistema de Ajuda e de Documentao de Usurio Online
3.8

Componentes Comprados

3.9 Interfaces
3.9.1 Interfaces de Usurio
3.9.2 Interfaces de Hardware
3.9.3 Interfaces de Software
3.9.4 Interfaces de Comunicao

3.10 Requisitos de Licenciamento

3.11 Observaes Legais, de Direitos Autorais etc
3.12 Padres Aplicveis
4. Informaes de Suporte

Especificao de Requisitos de Software

1.

Introduo

[A introduo da Especificao de Requisitos de Software (SRS) deve fornecer uma

viso geral de toda a SRS. Ela deve incluir a finalidade, o escopo, as definies, os
acrnimos, as abreviaes, as referncias e a viso geral da SRS.]
[Observao: A Especificao de Requisitos de Software (SRS) captura todos os
requisitos de software do sistema ou de uma parte do sistema.. A seguir, h um esquema
de uma SRS tpica para um projeto que utiliza somente requisitos em estilo de
linguagem natural tradicional - sem modelagem de casos de uso. Essa SRS captura
todos os requisitos em um nico documento, com sees aplicveis inseridas a partir das
Especificaes Suplementares (que no sero mais necessrias). Para ter acesso a um
template de uma SRS que utilize a modelagem de casos de uso, que consiste em um
pacote contendo Casos de Uso do modelo de casos de uso e Especificaes
Suplementares aplicveis, assim como outras informaes de suporte, consulte o
arquivo rup_SRS-uc.dot.]
[ possvel organizar uma SRS de vrias maneiras diferentes. Consulte o padro
[IEEE830-1998] para obter explicaes mais detalhadas, assim como outras opes de
organizao da SRS.]

1.1 Finalidade
[Especifique a finalidade desta SRS. A SRS dever descrever totalmente o
comportamento externo do aplicativo ou do subsistema identificado. Ela tambm dever
descrever requisitos no funcionais, restries de design e outros fatores necessrios
para fornecer uma viso completa e abrangente dos requisitos do software.]

1.2 Escopo
[Uma breve descrio do aplicativo de software a que se aplica a SRS; o recurso ou
outro agrupamento de subsistemas; a que modelo(s) de Caso de Uso a SRS est
associada; e tudo o mais que seja afetado ou influenciado por este documento.]

1.3 Definies, Acrnimos e Abreviaes

[Esta subseo deve fornecer as definies de todos os termos, acrnimos e abreviaes
necessrias adequada interpretao da SRS. Essas informaes podem ser fornecidas
mediante referncia ao Glossrio do projeto.]

1.4 Referncias
[Esta subseo deve fornecer uma lista completa de todos os documentos mencionados
em qualquer outra parte da SRS. Cada documento dever ser identificado por ttulo,
nmero do relatrio (se aplicvel), data e organizao de publicao. Especifique as

fontes a partir das quais as referncias podem ser obtidas. Essas informaes podem ser
fornecidas por um anexo ou outro documento.]

1.5 Viso Geral

[Esta subseo descreve o que o restante da SRS contm e explica como o documento
est organizado.]

2.

Descrio Geral

[Esta seo da SRS deve descrever os fatores gerais que afetam o produto e seus
requisitos. Ela no deve especificar requisitos especficos. Em vez disso, deve fornecer
uma base para esses requisitos, que sero definidos detalhadamente na Seo 3, e
facilitar sua compreenso. Inclua itens como:
perspectiva do produto
funes do produto
caractersticas do usurio
restries
suposies e dependncias
subconjuntos de requisitos]

3.

Requisitos Especficos

[Esta seo da SRS deve conter todos os requisitos de software em um nvel de

detalhamento suficiente para possibilitar que os designers projetem um sistema que
satisfaa esses requisitos e que os testadores verifiquem se o sistema satisfaz esses
requisitos. Quando for utilizada a modelagem de casos de uso, esses requisitos sero
capturados nos Casos de Uso e nas especificaes suplementares aplicveis. Se a
modelagem de casos de uso no for utilizada, o esquema das especificaes
suplementares poder ser inserido diretamente nesta seo, conforme mostrado a
seguir.]

3.1 Funcionalidade
[Esta seo descreve os requisitos funcionais do sistema que so expressos no estilo de
linguagem natural. Para muitos aplicativos, este poder ser o volume do Pacote da SRS.
necessrio refletir muito para organizar esta seo. Normalmente, esta seo
organizada por recurso, mas outros mtodos de organizao tambm podero ser
adequados como, por exemplo, a organizao por usurio ou a organizao por
subsistema. Entre os requisitos funcionais podero estar includos conjuntos de
recursos, capacidades e segurana.

Quando as ferramentas de desenvolvimento de aplicativos, como ferramentas de

requisitos, ferramentas de modelagem, entre outras, forem utilizadas para capturar a
funcionalidade, esta seo far referncia disponibilidade desses dados, indicando o
local e o nome da ferramenta usada para capturar os dados.]
3.1.1

<Requisito Funcional Um>

[A descrio do requisito deve ser feita aqui.]

3.2

Usabilidade

[Esta seo deve incluir todos os requisitos que afetam a usabilidade. Por exemplo,
especifique o tempo de treinamento necessrio para que usurios normais e usurios
com conhecimentos avanados se tornem produtivos em operaes especficas
especifique perodos de tempo mensurveis para tarefas tpicas ou baseie os requisitos
de usabilidade do novo sistema em outros sistemas que os usurios conheam e gostem
especifique requisitos de forma que estejam em conformidade com padres comuns de
usabilidade como, por exemplo, os padres CUA da IBM ou os padres GUI da
Microsoft]
3.2.1

<Requisito de Usabilidade Um>

[A descrio do requisito deve ser feita aqui.]

3.3 Confiabilidade
[Os requisitos de confiabilidade do sistema devem ser especificados aqui. A seguir, h
algumas sugestes:
Disponibilidade - especifique a porcentagem de tempo disponvel ( xx.xx%), as horas
de uso, o acesso manuteno, as operaes de modo degradado, etc.
Tempo Mdio entre Falhas (MTBF) - normalmente especificado em horas, mas
tambm poder ser especificado em termos de dias, meses ou anos.
Tempo Mdio para Reparo (MTTR) - quanto tempo o sistema poder ficar sem
funcionar aps uma falha?
Exatido - especifique a preciso (resoluo) e a exatido (atravs de algum padro
conhecido) necessrias na sada do sistema.
Taxa Mxima de Erros ou Defeitos - geralmente expressa em termos de erros por
milhares de linhas de cdigo (erros/KLOC) ou de erros por ponto de funo
(erros/ponto de funo).

 Taxa de Erros ou Defeitos - categorizados em termos de erros pouco importantes,

importantes e crticos: o(s) requisito(s) devem definir o que se entende por um erro
"crtico"; por exemplo, a perda total de dados ou uma total incapacidade de usar
determinadas partes da funcionalidade do sistema.]
3.3.1

<Requisito de Confiabilidade Um>

[A descrio do requisito deve ser feita aqui.]

3.4 Desempenho
[As caractersticas de desempenho do sistema devem ser descritas nesta seo. Inclua
tempos de resposta especficos. Quando aplicvel, faa referncia, por nome, aos Casos
de Uso relacionados.
tempo de resposta de uma transao (mdio, mximo)
taxa de transferncia como, por exemplo, transaes por segundo
capacidade como, por exemplo, o nmero de clientes ou de transaes que o sistema
pode acomodar
modos de degradao (o modo aceitvel de operao quando o sistema tiver sido
degradado de alguma maneira)
a utilizao de recursos como, por exemplo, memria, disco, comunicaes, etc.
3.4.1

<Requisito de Desempenho Um>

[A descrio do requisito deve ser feita aqui.]

3.5 Suportabilidade
[Esta seo indica todos os requisitos que aprimoraro a suportabilidade ou
manutenibilidade do sistema que est sendo criado, incluindo padres de codificao,
convenes de nomeao, bibliotecas de classes, acesso manuteno e utilitrios de
manuteno.]
3.5.1

<Requisito de Suportabilidade Um>

[A descrio do requisito deve ser feita aqui.]

3.6 Restries de Design

[Esta seo deve indicar todas as restries de design referentes ao sistema que est
sendo criado. As restries de design representam decises de design que foram
impostas e devem ser respeitadas. Entre os exemplos desse tipo de restrio esto
linguagens de software, requisitos de processo de software, uso prescrito de ferramentas
de desenvolvimento, restries de design e de arquitetura, componentes comprados,
bibliotecas de classes, etc.]

3.6.1

<Restrio de Design Um>

[A descrio do requisito deve ser feita aqui.]

3.7 Requisitos de Sistema de Ajuda e de Documentao

de Usurio On-line
[Descreva os requisitos, se houver, de documentao de usurio on-line, sistemas de
ajuda, observaes sobre ajuda, etc.]

3.8 Componentes Comprados

[Esta seo descreve todos os documentos comprados para serem usados com o sistema,
quaisquer restries de utilizao ou de licenciamento aplicveis, e quaisquer padres
associados de compatibilidade e de interoperabilidade ou de interface.]

3.9 Interfaces
[Esta seo define as interfaces que devem ser suportadas pelo aplicativo. Ele deve
conter especificidades, protocolos, porta e endereos lgicos adequados, entre outros,
para que o software possa ser desenvolvido e verificado em relao aos requisitos de
interface.]
3.9.1

Interfaces de Usurio

[Descreva as interfaces de usurio que devero ser implementadas pelo software.]

3.9.2

Interfaces de Hardware

[Esta seo define todas as interfaces de hardware que devem ser suportadas pelo
software, incluindo a estrutura lgica, os endereos fsicos, o comportamento esperado,
etc. ]
3.9.3

Interfaces de Software

[Esta seo descreve as interfaces de software com outros componentes do sistema de

software. Podero ser componentes comprados, componentes reutilizados de outro
aplicativo ou componentes que estejam sendo desenvolvidos para subsistemas fora do
escopo desta SRS, mas com os quais esse aplicativo de software deve interagir.]
3.9.4

Interfaces de Comunicao

[Descreva todas as interfaces de comunicao com outros sistemas ou dispositivos

como, por exemplo, redes locais, dispositivos seriais remotos, etc.]

3.10 Requisitos de Licenciamento

[Esta seo define todos os requisitos de imposio de licenciamento ou outros
requisitos de restrio de utilizao que devem ser exibidos pelo software.]

3.11 Observaes Legais, de Direitos Autorais etc

[Esta seo descreve todos os avisos legais necessrios, garantias, observaes sobre
direitos autorais, observaes sobre patentes, logomarcas, marcas comerciais ou
problemas de conformidade com logotipos referentes ao software.]

3.12 Padres Aplicveis

[Esta seo descreve, por meio de referncias, todos os padres aplicveis e as sees
especficas desses padres que se aplicam ao sistema que est sendo descrito. Entre
esses padres esto includos, por exemplo, padres reguladores, de qualidade e legais,
padres de indstria referentes usabilidade, interoperabilidade, internacionalizao,
compatibilidade com o sistema operacional, etc.]

4.

Informaes de Suporte

[As informaes de suporte facilitam o uso da SRS. Essas informaes incluem:

ndice analtico
ndice
Apndices
Podero estar includos roteiros de caso de uso ou prottipos da interface do usurio.
Quando forem includos apndices, a SRS dever especificar explicitamente se os
apndices devero ou no ser considerados parte integrante dos requisitos.]