Especificao de

Sistemas e Especificao
de Requisitos

Universidade Federal do Estado do Rio de Janeiro

Centro de Cincias Exatas e Tecnologia
Escola de Informtica Aplicada
Curso: Bacharelado em Sistemas de Informao
Disciplina: Construo de Sistemas
Professor: Luiz Fernando Seibel
Grupo: Eduardo Henrique Cavalcante Fontanha de Oliveira
Pedro Nuno de Souza Moura

Apresentao
Tem este trabalho por objetivo funcionar como um guia apresentao
sobre Especificao de Sistemas e Especificao de Requisitos da disciplina
de Construo de Sistemas.
Assim sendo, cabe explicitar qual o objetivo da etapa de Especificao
de Sistemas. Esta tem como pilar sustentador a definio dos aspectos
concernentes ao sistema, ou seja, qual o processo atual empregado na
empresa, quais os problemas a serem resolvidos e a definio do escopo do
sistema. Dessa forma, deve-se, portanto, descrever no s tais propriedades,
como tambm quais tecnologias sero utilizadas no desenvolvimento do
sistema e a prpria metodologia de trabalho.
Analogamente, a etapa de Especificao de Requisitos visa elicitao,
isto , ao levantamento dos requisitos funcionais que o sistema deve ter, bem
como s restries impostas sobre como o sistema deve executar tais
funcionalidades, ou seja, os requisitos no-funcionais. Ademais, salutar
discriminar os no-requisitos (requisitos no-contemplados), aqueles que no
sero atendidos pelo sistema.
A fim de que o texto e, conseqentemente, a apresentao, se torne
claro e de fcil compreenso, os assuntos compreendidos pela etapa de
Especificao de Sistemas sero abordados em tpicos:

Viso Geral do Problema

Num primeiro momento, aps serem definidos o nome do sistema e o

propsito deste, deve-se obter a viso geral do problema a ser resolvido.
Sendo assim, feita uma descrio do processo atual da empresa. Nesta, o
processo de negcio da empresa detalhadamente descrito, a fim de que
sejam entendidas as necessidades do cliente e o prprio domnio. Alm disso,
devem ser identificadas outras reas ou empresas, isto , entidades externas,
que tambm estaro envolvidas no projeto. recomendvel e interessante
utilizar um Diagrama de Atividades para representar tal processo de negcio,
facilitando, assim, a visualizao do fluxo de processo da empresa. Como
exemplo, segue na prxima pgina um Diagrama de Atividades que descreve o
processo de negcio de um ambiente de gerncia de tarefas em uma empresa
de desenvolvimento de software.

Alm disso, devem ser levantados os problemas atualmente

encontrados. devido, pois, descrever o referido problema, quais os afetados,
quais as conseqncias e sugerir possveis solues.
Acima de tudo, obteve-se, portanto, uma descrio do processo de
negcio da empresa e de seu domnio. A descrio dos problemas a que o
sistema se prope a tratar so de grande valia, dado que auxiliam na definio
dos requisitos de negcio e fornecem uma viso aplicada do sistema.

Identificao dos Envolvidos

Nesta parte, procura-se definir os perfis dos usurios que iro no s

utilizar a verso executvel do sistema, como tambm auxiliar o analista a
destrinchar o domnio sendo estudado. Desse modo, conveniente descrever
os perfis dos usurios, apontando suas responsabilidades, os resultados
esperados e os critrios de sucesso, e o ambiente destes, delineando
restries fsicas e sistemas/plataformas utilizados atualmente ou que possam
ser utilizados no futuro.
Esta atividade de extrema utilidade, visto que as informaes aqui
obtidas se faro necessrias especificao de Requisitos No-Funcionais e
etapa de Implantao, em que o sistema ser delineado ao ambiente do
usurio descrito j nesta parte.

Requisitos de Negcio

Durante a etapa de Especificao de Sistemas, diversas visitas ao

ambiente de trabalho da empresa sero feitas, dado que se faz necessrio
conhecer o processo de negcio, entender os problemas correntes, iniciar o
entendimento do domnio e outros aspectos. Contudo, faz-se imperiosa uma
reunio com os gerentes da empresa a fim de que sejam definidos os
Requisitos de Negcio. Tais requisitos so necessidades que o fluxo de
processo atual da empresa demanda, ou seja, so problemas de que os
gerentes da empresa tm conhecimento e procuram resolv-los.
Para cada requisito apontado e analisado na reunio, devem ser
discriminadas as razes de cada problema, como so resolvidos atualmente
(soluo atual) e qual a soluo que o cliente deseja ou precisa (soluo
proposta). Note-se que tal soluo proposta sob a ptica dos clientes.
recomendvel, ainda, listar tais requisitos de maneira que os de maior
prioridade, ou seja, os que foram apontados mais vezes, venham antes. Tornase de fcil percepo, portanto, que deve ser feita uma entrevista tanto com os
clientes quando com os usurios. Ademais, o responsvel por esta parte deve
ser o Analista de Negcio, mais experiente e treinado para efetuar visitas ao
ambiente da empresa e levantar problemas e necessidades.

Tecnologia/Restries Tecnolgicas

Esta parte constitui o pilar sobre o qual a fase de Especificao de

Sistemas est consolidada. Nesta, devem ser listadas e descritas
minuciosamente quais as tecnologias que sero empregadas no
desenvolvimento do sistema. Dessa forma, deve-se citar a linguagem,
ferramentas CASE, ambientes de desenvolvimento integrado (IDE), arquitetura
e outros a serem utilizados. Frameworks de desenvolvimento tambm devem
ser citados.
Alm de tais aspectos, devem ser citadas restries tecnolgicas que o
prprio domnio da aplicao imponha.

Viso da Soluo

Aps tais etapas de compreenso do problema, definio dos macrorequisitos e especificao das tecnologias a serem empregadas, deve-se
descrever o sistema de uma maneira mais incisiva. A viso da soluo o
cerne disto. Esta pode ser decomposta em:
o Descrio do Sistema: Listagem e descrio das caractersticas do
sistema a ser implementado. Note-se que no ainda devem ser
listados aqui os requisitos funcionais. recomendado esboar um
Diagrama de Atividades com o fluxo para a possvel soluo para o
sistema.
o Escopo do Sistema: O que ser abrangido, isto , delineado pelo
sistema. Dentre os Requisitos de Negcio apontados, citar aqueles
que sero tratados pelo sistema.
o Fronteira do Sistema: Fazer um desenho que mostre a interface do
sistema com pessoas, entidades externas ou outros sistemas. Faz-se
de extrema importncia na definio dos atores dos Casos de Uso.
o Benefcios Esperados: Listagem e descrio do conjunto de
benefcios que so esperados com a soluo proposta.
o Impactos do Sistema: Quais mudanas so esperadas acontecer
no ambiente de operao do sistema.
o Critrios de Aceite: Critrios definidos pelos clientes que sero
utilizados para validar se o sistema est atendendo s expectativas e
faz tudo aquilo que lhe foi proposto.

Riscos

Deve-se destinar ateno especial aos riscos do projeto. Estes podem

atrapalhar em demasia o andamento de um projeto ou at mesmo impedir a
concluso deste. Logo, os riscos do projeto devem ser listados e descritos. A
sua descrio consiste no impacto que podem causar.
Postos tais preceitos sobre a etapa de Especificao de Sistemas, devese analisar a etapa de Especificao de Requisitos. Esta tem como objetivo
levantar/coletar os requisitos do sistema, que so as caractersticas, as
propriedades, necessrias no sistema.
Algumas tcnicas para elicitao de requisitos so:
o Entrevistas Individuais: Consiste em entrevistas com os gerentes,
bem como com os usurios do sistema. Por meio de tal fato, busca-

se extrair os problemas correntes no processo de negcio, as

necessidades de tais pessoas e seus desejos.
o

Brainstorming e Brainwriting: O Brainstorming se caracteriza por

uma sesso de discusso da equipe de desenvolvimento em
conjunto com os clientes e usurios, a fim de que idias sejam
geradas e sejam identificadas as necessidades dos clientes.
O Brainwriting similar ao Brainstorming, porm, em vez de utilizar o
meio oral, as pessoas expem as suas idias em pedao de papel.
Posteriormente, um membro da equipe l todos os papis, que no
esto identificados, em voz alta e, ento, a idia debatida. A
vantagem que pessoas mais tmidas podem participar de maneira
ativa, ao passo que no Brainstorming no o podem. Alm disso, no
Brainstorming boas idias so geradas, mas, pelo fato de ningum
tomar nota, so esquecidas.

o Reutilizao de requisitos de projetos anteriores: Caso a

empresa de desenvolvimento do software j tenha trabalhado com
um domnio similar, ento pode reaproveitar os requisitos levantados
para tal projeto. Desse modo, economiza tempo e utiliza requisitos
que indubitavelmente so consistentes.
o Estudo de documentos: Nesta abordagem, documentos do domnio
so estudados e analisados, a fim de que sejam identificadas as
necessidades e restries. Relatrios e formulrios da empresa
tambm so analisados.
Esta abordagem vantajosa quando utilizada em conjunto com a
Metodologia de Desenvolvimento Cleanroom, que destinada a
sistemas que possuem riscos de quebra de patente, e garante que os
programadores vo fazer aquilo que foi especificado.
o Observao do ambiente de implantao: Consiste em fazer
visitas ao ambiente da empresa e observar o seu processo de
negcio, como agem os seus funcionrios e quais lacunas existem.
Assim sendo, identifica os problemas e, conseqentemente, as
necessidades da empresa.
o JAD (Join Application Development): H um coordenador e um
anotador. O coordenadora vai entrevistando os clientes e debatendo
com eles acerca das funcionalidades, ao passo que o anotador vai
registrando aquilo que estiver sendo gerado.
Os requisitos podem ser classificados de duas maneiras:
o Requisitos Funcionais: Correspondem ao que o sistema deve
fazer, ou seja, suas funcionalidades; e
o Requisitos No-Funcionais: So restries impostas sobre como o
sistema deve realizar seus requisitos funcionais.

Os Requisitos Funcionais podem ser classificados de duas maneiras:

o Requisitos Funcionais Evidentes: So aqueles realizados com o
conhecimento explcito do usurio. Correspondem troca de
informao na fronteira do sistema, isto , com o meio exterior; e
o Requisitos Funcionais Ocultos: So aqueles efetuados pelo
sistema sem o conhecimento do usurio.
Por sua vez, os Requisitos No-Funcionais podem ser classificados de
duas maneiras: obrigatrios e desejados. Os obrigatrios so aqueles que
invariavelmente devem ser implementados. J os desejados so aqueles que
podem ser implementados caso no causem maiores transtornos ao projeto.
Alm disso, os requisitos no-funcionais podem ser classificados por
caractersticas: de interface, de implementao, de eficincia, de tolerncia a
falhas, etc. Tambm podem ser classificados como permanentes (nunca
mudar com o tempo) ou transitrios (pode sofrer alteraes no futuro).
Mais especificamente, os requisitos no-funcionais podem possuir as
seguintes categorias:
o Usabilidade: O sistema ser user-friendly, ser de fcil uso e
aprendizado. Desse modo, deve fornecer menus de ajuda para o
usurio e/ou manuais.
o Confiabilidade: o fato de o sistema possuir tratamento de falhas.
Especifica quais falhas o sistema ser capaz de gerenciar.
o Performance: So requisitos de eficincia e preciso que o sistema
apresenta.
o Configurabilidade: O que pode ser configurado no sistema.
o Segurana: So os nveis de acesso e a que funcionalidades cada
um tem acesso.
o Implementao: A linguagem a ser utilizada e que bancos de dados
estaro acessveis.
o Interface: Especifica como deve ser a interface.
o Empacotamento: Especifica a forma como o software deve ser
entregue ao usurio final.
o Legais: Quais os procedimentos que devem ser tomados para que
no sejam infringidas normas e regras da rea a que o sistema se
prope.
No que tange organizao dos requisitos, interessante dividi-los em:
o Casos de Uso: As funcionalidades do sistema para que os usurios
atinjam seus objetivos.
o Conceitos: Para cada conceito do domnio identificado, listar quais
as operaes que podem ser realizadas em relao a ele, ou seja,
incluso, excluso, alterao e consulta.
o Consultas: Acesso informao do sistema que no altera o dado
em si.

Dessa forma, o Diagrama de Casos de Uso passar a conter apenas as

funcionalidades necessrias para que os atores, de fato, atinjam seus
objetivos. Torna, pois, mais inteligvel o diagrama, facilitando a visualizao.
Cabe destaque aos No-Requisitos (Requisitos No-Contemplados),
que so aqueles que foram analisados e revisados com os usurios e no
sero implementados devido a problemas de custo, prazos ou outros.
importante ter isso documentado e assinado pelos clientes para que estes,
futuramente, no cobrem algo que foi anteriormente acordado em relao ao
no-desenvolvimento.
Por fim, a importncia da especificao de requisitos que esta
estabelece o entendimento entre clientes e fornecedores da soluo. Serve,
tambm, como referncia para a validao final dos produtos. Sabe-se, ainda,
que o investimento na verificao de uma especificao tende a reduzir o custo
total do projeto.
Ao trmino da especificao de requisitos, gerado o documento
conhecido como Documento de Requisitos de Software ou Especificao
de Requisitos de Software (Software Requirements Specification SRS).
O apndice Documento de Requisitos de Software serve como
exemplo de um documento que pode ser gerado nas etapas supracitadas, isto
, de especificao de sistemas e requisitos.
A criao de modelos de suma importncia em tais etapas, a fim de
seja obtido o entendimento do problema e que seja facilitada a comunicao
entre os envolvidos no projeto. Um modelo uma simplificao da realidade
que nos ajuda a entender um problema grande e complexo que no pode ser
compreendido como um todo. (Phillipe Krutchen, 2000).
Cabe citar os modelos gerados em tais etapas:

Diagrama de Atividades: Tem como objetivo fazer uma representao do

fluxo de trabalho (workflow) do processo de negcio da empresa a que o
sistema se prope a automatizar. Ademais, pode tambm ser utilizado para
descrever o fluxo principal de um Caso de Uso que tenha complexidade
considervel (crtico). Um exemplo de diagrama j foi exposto neste texto.

Diagrama de Casos de Uso: Representa interaes entre atores (pessoas,

entidades externas, perifricos ou outros sistemas) e o sistema em questo,
a fim de que seja realizada uma funcionalidade. Descreve, pois, os
requisitos funcionais do sistema.
Garante o entendimento do requisitos e pode ser utilizado como uma
espcie de contrato do sistema. Em outras palavras, ao trmino do
desenvolvimento, o sistema tem estar realizando todas as funcionalidades
que foram discriminadas no Diagrama de Casos de Uso. Um exemplo de tal
diagrama sobre um Sistema de Gerncia de Tarefas segue na prxima
pgina:

Modelo Conceitual: Descrevem os principais conceitos de um dado

domnio, bem como suas propriedades e associaes. Em uma viso mais
aplicada, descreve quais sero as informaes a serem guardadas no
banco de dados. Os modelos conceituais mais disseminados so o
Diagrama de Entidade-Relacionamento (DER) e o Diagrama de Classes
e Objetos. Um exemplo de Diagrama de Classes e Objetos referente a um
domnio de um Sistema de Gerncia de Tarefas segue abaixo:

Pela anlise realizada, torna-se fcil percepo que o investimento e a

aplicao em uma especificao de sistemas e de requisitos bem feita
extremamente aconselhvel, dado que tende a diminuir a incidncia de falhas
nas etapas posteriores do ciclo de vida de desenvolvimento. Ademais, seja
citada esta estatstica: custo de um erro na fase de projeto = 1 unidade; custo
de um erro no incio dos testes = 6.5 unidades; durante os testes = 15
unidades; depois de liberado o software = 60 a 100 unidades.

Bibliografia
1. BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML.
Rio de Janeiro: Campus, 2002.
2. WAZLAWICK, Raul Sidnei. Anlise e Projeto de Sistemas de Informao
Orientados a Objetos. Rio de Janeiro: Elsevier, 2004.
3. Material didtico do professor Asterio Tanaka, referente disciplina de
Modelagem de Sistemas, no perodo de 2005/2 do curso de Sistemas de
Informao da UNIRIO. Disponvel em: www.uniriotec.br/~tanaka/TIN0012.
4. Material didtico da professora Renata Arajo, referente disciplina de
Anlise e Projeto de Sistemas, no perodo de 2006/1 do curso de Sistemas de
Informao da UNIRIO. Disponvel em: www.uniriotec.br/~renata.araujo/APS.
5. Material didtico do professor Leonardo Azevedo, referente disciplina de
Projeto e Construo de Sistemas com Ambiente de Programao, no perodo
de 2006/2 do curso de Sistemas de Informao da UNIRIO. Disponvel em:
http://leogazevedo.googlepages.com/pcsap.
6. Notas de aula da disciplina de Modelagem de Sistemas, do curso de
Sistemas de Informao da UNIRIO, ministrada pelo professor Asterio Tanaka
no perodo de 2005/2.
7. Notas de aula da disciplina de Anlise e Projeto de Sistemas, do curso de
Sistemas de Informao da UNIRIO, ministrada pela professora Renata Arajo
no perodo de 2006/1.
8. Notas de aula da disciplina de Projeto e Construo de Sistemas com
Ambiente de Programao, do curso de Sistemas de Informao da UNIRIO,
ministrada pelo professor Leonardo Azevedo no perodo de 2006/2.