Processo de Software e Propriedades de um Bom Software

Prévia do material em texto

Introdução aos Sistemas de Informação 
Aula 2 - Processo de Software 
Material elaborado pelas Profas. Junia e Rosângela 
 
Um processo de software – conjunto de atividades e resultados associados que geram um produto 
de software. Essas atividades são, em sua maioria, executadas por desenvolvedores sistemas.. 
Há 4 atividades fundamentais no processo de software: 
1. Especificação do Software – definição de requisitos e análise de requisitos - a 
funcionalidade do software e as restrições em sua operação devem ser definidas. 
2. Desenvolvimento do Software – projeto e implementação - o software deve ser produzido de 
modo que atenda a suas especificações. 
3. Validação do software – integração e teste - o software tem de ser validado para garantir que 
ele faz o que o cliente deseja. 
4. Evolução do software – o software deve evoluir para atender às necessidades mutáveis do 
cliente. 
 
MODELO DE PROCESSO DE SOFTWARE 
 
É a descrição simplificada de um processo de software, que é apresentada a partir de uma 
perspectiva específica. Os modelos são abstrações do processo real que está sendo descrito. Dentre 
os modelo de processo destacam-se atividades que são parte do processo de software, produtos de 
software e o papel das pessoas envolvidas na engenharia de software. 
Exemplos de tipos de processo. 
 
1. Um modelo de workflow – mostra a seqüência de atividade no processo, juntamente com 
suas entradas, saídas e dependências. As atividades, nesse modelo, representam ações 
humanas. 
2. Um modelo de fluxo de dados ou de atividade – representa o processo como um conjunto de 
atividades, cada uma das quais realiza alguma transformação de dados. Esse modelo mostra 
como a entrada para o processo, tal como uma especificação, é transformada em uma saída, 
como um projeto. As atividades podem estar em um nível inferior ao das atividades em um 
modelo de workflow. Elas podem representar transformações realizadas por pessoas ou 
computadores. 
3. Um modelo de papel/ação – representa papéis das pessoas envolvidas no processo de 
software e as atividades pelas quase elas são responsáveis. 
 
 
Custos da engenharia de software 
Depende do processo utilizado e do tipo de software que está sendo desenvolvido. O custo total de 
desenvolvimento de um complexo sistema de software como sendo de cem unidades de custo, a 
distribuição dessas unidades será semelhante ao mostrado nos esquemas a seguir. 
0 25 50 100 
 
Especificação Projeto Implementação Integração e teste 
 
Se uma abordagem não linear, mas iterativa, com refinamentos sucessivos for utilizada, não existe 
uma linha exata entre especificação projeto e desenvolvimento. 
 
 
 2 
0 25 50 75 100 
 
Especificação desenvolvimento cíclico e iterativo Teste de sistema 
 
Existem também os custos de evolução (manutenção), alteração do software depois que foi 
colocado em uso. 
0 25 50 100 
 
Desenvolvimento Evolução do Sistema 
 
 
 
O que é uma CASE – Computer-aided software engineering – refere-se a uma ampla gama de 
diferentes tipos de programas utilizados para apoiar as atividades de processo de software, como 
análise de requisitos, a modelagem de sistemas, a depuração e os testes. 
Ferramentas CASE podem também incluir um gerador de códigos que, automaticamente, origina 
código fonte a partir do modelo de sistema e alguma orientação de processo. 
 
Upper-CASE – destinada a dar apoio à análise e ao projeto. (apoio às fases iniciais) 
 
Lower-CASE – destinadas a dar apoio à implementação e aos testes, com os depuradores, sistemas 
de análise de programa, geradores de casos de testes e editores de programas. 
 
Propriedades de um Bom Software 
Os software devem ser controlados por propriedades intrínsecas a ele, como: tempo de resposta do 
software à consulta do usuário e a facilidade de compreensão do código do programa. 
Por exemplo: um sistema bancário tem de ser seguro, um jogo interativo deve ter uma resposta 
rápida, um sistema de controle de telefonia precisa ser confiável, etc.. Podem ser resumidos na 
Tabela 1. 
 
Tabela 1 – Atributos para um bom software 
Facilidade de Manutenção O software deve ser escrito de modo que possa evoluir para 
atender às necessidades mutáveis dos clientes. Essas 
mudanças estão relacionadas ao ambiente de negócios que 
pode ter constantes mutações 
Nível de Confiança Tem uma gama de características que incluem confiabilidade, 
proteção e segurança. O software confiável não deve ocasionar 
danos físicos ou econômicos, no caso de defeitos no sistema. 
Eficiência O software não deve desperdiçar os recursos do sistema, como 
memória e ciclos de processador. A eficiência, portanto, inclui 
a rapidez de resposta, o tempo de processamento, a utilização 
de memória, entre outros. 
Facilidade de Uso Deve ser utilizável, sem esforços indevidos, pelo tipo de 
usuário para quem foi projeto. Isso significa que ele deve 
dispor de uma interface apropriada com o usuário e de 
documentação adequada. 
 
O processo de desenvolvimento do software deve ser de qualidade, com essas propriedades 
garantidas, para que o produto também seja. 
 3
 
Responsabilidade Profissional e ética 
 
1. Confidencialidade – respeitar seus empregadores ou clientes, quer tenham ou não assinado 
um acordo formal, quanto ao sigilo de informações. 
2. Competência – não devem enganar quanto ao seu nível de competência, ou seja, não devem 
aceitar serviços que estejam fora do seu limite de competência. 
3. Direitos de propriedade intelectual – estar cientes das leis locais que regulam o uso da 
propriedade intelectual, como patentes e direitos autorais. Eles devem ser cuidadosos, a fim 
de assegurar que a propriedade intelectual de empregadores e clientes seja protegida. 
4. Má utilização de computadores – não empregar suas habilidades técnicas para o mau uso de 
computadores de outras pessoas. Abrange desde casos triviais – jogar no computador do 
cliente- até casos sérios – disseminação de vírus. 
 
Existem sociedade e instituições profissionais que desempenham importante papel a esse respeito – 
ACM (Association for Computing Machinery), o IEEE (Institute of Electrical am d Electronic 
Engineers) e a British computer Society – publicam um código de conduta profissional ou código 
de ética. 
 
Engenharia de Sistemas 
É a atividade de especificar, projetar, implementar, validar, implantar e manter os sistemas como 
um todo. Os engenheiros de sistema não se ocupam apenas com o software, mas com as interações 
de software, hardware e sistema com os usuários e seu ambiente. 
 
(recordar conceitos de sistemas) 
 
Propriedades emergentes de sistemas 
 
São as propriedades (atributos) do sistema como um todo, muitas vezes é difícil prever os valores 
dessas propriedades com antecedência. 
 
Tipos de propriedades: 
 
1. funcionais: que aparecem quando todas as partes de um sistema trabalham em conjunto para 
atingir algum objetivo. Ex: bicicleta propriedade funcional de ser um dispositivo de 
transporte. 
2. não funcionais: confiabilidade, desempenho, segurança e proteção. Essas propriedades se 
relacionam com o comportamento do sistema em seu ambiente operacional. 
 
EX: Confiabilidade de sistema – é um conceito complexo, deve-se levar em conta componentes 
individuais. Pode-se falar em: 
a) Confiabilidade de hardware – qual a probabilidade de um componente de hardware 
falhar e quanto tempo leva para reparar esse componente? 
b) Confiabilidade de software – qual é a probabilidade de que um componente de 
software venha a produzir uma saída incorreta? (diferente da falha de hardware, pois 
o software não se desgasta), ele pode prosseguir em operação mesmo depois que um 
resultado incorreto tenha sido produzido. 
c) Confiabilidade de operador– qual a probabilidade de que o operador de um sistema 
cometa um erro? 
 4 
 
Esses itens não podem ser pensados antecipadamente. 
 
Sistemas e seu ambiente 
Sistemas não são entidades independentes, mas existem em um ambiente. Esse ambiente afeta o 
funcionamento e o desempenho do sistema. A figura 1 mostra alguns dos sistemas que podem ser 
incorporados em um edifício de escritórios, subsistemas. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Figura 1 - Hierarquia de Sistemas 
 
O ambiente local do sistema de segurança, por exemplo, são os outros sistemas dentro do edifício. 
Enquanto que o ambiente total inclui todos os outros sistemas do lado de fora do edifício, na rua e 
na cidade, bem como os sistemas naturais. 
 
O sistema é concebido para produzir mudanças em seu ambiente. Assim, um sistema de 
aquecimento modifica seu ambiente, aumentando ou diminuindo a temperatura. O funcionamento 
correto do sistema, portanto, somente pode ser avaliado pelos efeitos sobre o ambiente. 
 
O funcionamento de um sistema pode ser afetado pelas mudanças de seu ambiente, exemplo: 
sistema elétrico em um edifício pode ser afetado por mudanças ambientais do lado de fora do 
edifício: cabo de força pode ser cortado e o edifício ficara sem energia. 
 
Como existe o ambiente físico, existe também o ambiente organizacional, que inclui políticas e 
procedimentos que são, por sua vez, regidos por questões políticas, econômicas, sociais e 
ambientais mais amplas. Fatores humanos e organizacionais provenientes do ambiente do sistema 
que afetam o projeto de sistema destacam-se: 
1. Mudanças no processo – O sistema requer mudanças nos processos de trabalho, no 
ambiente? Se sim, há necessidade de treinamento especifico. Se as mudanças forem 
significativas envolvendo pessoas e ate perda de empregos, os usuários podem resistir ao 
sistema. 
2. Mudanças nas tarefas – Os sistemas diminuem a habilidade dos usuários em um ambiente ou 
faz com que eles modifiquem o modo como trabalham? Se sim, eles podem resistir à 
introdução do sistema na organização. Projetos que envolvem gerentes que precisam mudar 
seu modo de trabalhar, para a adequação ao sistema de computadores, freqüentemente se 
ressentem disso. Gerentes podem achar que seu status na organização está sendo reduzido, 
em virtude desse sistema. 
Cidade
Rua
Edifício
Sistema de Sistema de Sistema de 
Aquecimento energia água 
 
Sistema de Sistema de Sistema de 
Segurança iluminação esgoto 
 5
3. Mudanças organizacionais - sistema modifica a estrutura de poder político em uma 
organização? Exemplo, se uma organização depende de um sistema complexo, aqueles que 
sabem operar o sistema têm bastante poder político. 
Modelagem de sistemas 
 
Como parte dos requisitos do sistema e da atividade de projetos, o sistema precisa ser modelado 
como um conjunto de componentes e de relações entre esses componentes Æ Modelo de 
arquitetura. 
 
A arquitetura do sistema é retratada como um diagrama de blocos, mostrando os subsistemas 
principais e as inter-conexões entre eles. Cada subsistema é representado por um retângulo, no 
diagrama de blocos; as flechas indicam a existência de uma relação entre eles (Figura 2). 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2 - Componentes principais do Sistema de alarme contra intrusos 
 
 
Tabela 2 - Funcionalidade de subsistemas no sistema de alarme 
Subsistema Descrição 
Sensor de movimento Detecta movimento nos cômodos monitorados pelo sistema 
Sensor de porta Detecta a abertura de porta nas portas externas do edifício 
Controlador de alarme Controla a operação do sistema 
Sirene Emite um aviso sonoro quando um intruso é detectado. 
Sintetizador de voz Sintetiza uma mensagem de voz dando a localização do possível 
intruso 
Discador de telefone Faz as chamadas externas para avisar a segurança, a policia, etc..
 
 
O sistema é decomposto em subsistemas. Cada subsistema pode ser representado da mesma maneira 
até que o sistema seja decomposto em componentes funcionais Æ única função, Tabela 2. 
 
Historicamente o modelo de arquitetura foi utilizado para identificar componentes de hardware e 
software que possam ser desenvolvidos em paralelo. Contudo, essa distinção (hardware/software) 
está se tornando irrelevante. Assim, atualmente, é mais apropriado classificar os subsistemas de 
acordo com sua função, antes de serem tomadas decisões sobre as vantagens e as desvantagens 
referentes a hardware/software. 
 
Componentes funcionais de sistemas 
Sensores de 
movimento Sensores de 
porta 
Controlador 
de alarme 
Sirene Sintetizador 
de voz 
Discador 
de telefone 
Centro de controle 
externo 
 6 
1. Componentes de sensores – coletam informações do ambiente do sistema. Exs: radares em 
um sistema de controle de tráfego aéreo, sensores de posicionamento de papel em uma 
impressora, um par termoelétrico em uma fornalha. 
2. Componentes de atuadores causam alguma mudança no ambiente do sistema. Exs: válvulas 
que se abrem e fecham para passagem de líquidos, superfícies de vôo em uma aeronave, que 
controlam o ângulo de vôo, e o mecanismo de alimentação de papel em uma impressora. 
3. Componentes de computação – aqueles que considerando alguma entrada realizam algumas 
computações sobre essa entrada e produzem uma saída. Ex: processador de ponto flutuante 
que realiza computações sobre os nros reais. 
4. Componentes de comunicação – aqueles cuja função é coordenar uma operação com outros 
componentes. Exs: um escalador em um sistema de tempo real, que decide quando os 
diferentes processos devem ser escalados para serem executados em um processador. 
5. Componentes de interface – que transformam a representação utilizada por um componente 
de sistema em uma representação empregada por outro componente. EX:um componente de 
interface humana, que considera algum modelo de sistema e o exibe para o operador 
humano. Conversor analógico-digital que converte uma entrada analógica em saída digital. 
 
Considerando esses componentes para o exemplo anterior tem-se a Tabela 3. 
 
Tabela 3 Componentes de sistemas e suas funções 
Tipos de componentes Componentes Função 
Sensor Sensor de movimento, 
sensor de porta 
Detecta movimento nos cômodos 
monitorados pelo sistema. Detecta a 
abertura de porta nas portas externas do 
edifício 
Atuador Sirene aviso sonoro quando um intruso é 
detectado 
Comunicação Discador de telefone Aciona o centro de controle externo 
para emitir um aviso de intrusão. 
Recebe comandos do centro de controle. 
Coordenação Controlador de alarme Coordena todos os componentes do 
sistema. Atua nos comandos do painel 
de controle e do cento de controle. 
Interface Sintetizador de voz Sintetiza mensagem dando a localização 
da intrusão. 
 
O processo de engenharia de sistemas 
 
Engenharia de sistemas x engenharia de software – existem importantes distinções: 
a) envolvimento interdisciplinar – diferentes disciplinas de engenharia podem estar envolvidas 
na engenharia de sistemas. Há uma imensa possibilidade de mal-entendidos devido à 
terminologia diferente utilizada por diferentes engenheiros. 
b) Possibilidade reduzida de refazer o trabalho durante o desenvolvimento de sistemas – altos 
custos para mudanças, por ex, mudar a localização de radares em um sistema de controle de 
trafego aéreo. Software se tornou importante para os sistemas, pois ele permite flexibilidade, 
devido às mudanças durante o desenvolvimento do sistema, em resposta a novos requisitos. 
 
Engenharia de sistemas Æ atividade interdisciplinar que envolve equipes com diferentes formações 
técnicas. As fases são as mostradas na Figura 3: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3 – Processo de engenharia de sistemas 
 
 
Especificação de RequisitosUm completo entendimento dos requisitos do software é essencial para o sucesso de um esforço de 
desenvolvimento de software. A atividade de especificação de requisitos é um processo de 
descoberta, refinamento, e modelagem. O escopo do software definido no planejamento do projeto é 
refinado em detalhe, as funções e o desempenho do software são especificados, as interfaces com 
outros sistemas são indicadas e as restrições que o software deve atender são estabelecidas. 
Modelos dos dados requeridos, do controle e do comportamento operacional são construídos. 
Finalmente, critérios para a avaliação da qualidade em atividades subseqüentes são estabelecidos. 
Os principais profissionais envolvidos nesta atividade são o engenheiro de software (muitas vezes 
chamado analista) e o cliente / usuário. 
A atividade a ser desenvolvida é capturar os requisitos sob uma perspectiva dos usuários, isto é, os 
modelos gerados procuram definir as funcionalidades e restrições que devem ser consideradas para 
atender às necessidades dos usuários; 
A etapa de Especificação de Requisitos é independente do modelo de processo escolhido, uma 
vez que trata os requisitos do sistema sob uma perspectiva externa. 
 
*************************** 
Definição de Requisitos gerais (funcionais e não funcionais) de um sistema 
 
Levantar os requisitos do sistema como um todo, envolve consultas com os clientes e usuários finais 
do sistema. 
Três tipos de requisitos compõem essa atividade: 
 
1- Requisitos funcionais abstratos – funções básicas que o sistema deve oferecer, definidas em 
um nível abstrato. A especificação detalhada de requisitos funcionais ocorre no nível de 
subsistema. Ex: controle de tráfego aéreo, essa atividade de definição de requisitos, 
provavelmente, identificaria a necessidade de uma base de dados de plano de vôo para 
armazenar os planos de vôos de todas as aeronaves que ingressarem no espaço aéreo 
controlado. 
Especificação 
de requisitos Desativação 
do sistema 
Projeto do 
sistema 
Desenvolvimento 
de subsistema 
Integração do 
sistema 
Instalação do 
sistema 
Evolução do 
sistema 
 8 
2- Propriedades de sistemas – são propriedades emergentes de sistemas não funcionais. Podem 
incluir propriedades como desempenho, segurança, entre outras. Afetam os requisitos de 
todos os subsistemas. 
3- Características que o sistema não deve exibir – especificar o que o sistema não deve fazer e 
quanto ele deve fazer. Por ex, no sistema de trafego aéreo, o sistema não deve apresentar 
muitas informações ao controlador. 
 
É importante: estabelecer os objetivos gerais que o sistema deve cumprir. 
 
EX: •Considere um sistema, para um prédio de escritórios, que deve oferecer proteção contra 
incêndios e detecção de intrusos. 
Declaração de Objetivos: 
Fornecer um sistema de alarme contra incêndios e contra intrusos para o edifício, com o objetivo 
de divulgar avisos internos e externos referentes a incêndios ou à entrada de pessoa não 
autorizada. 
Existem níveis de requisitos que devem ser respeitados para que se tenha uma boa definição de 
requisitos: 
- Requisitos dos usuários - para designar os requisitos abstratos de alto nível. São declarações, 
em linguagem natural e também em diagramas, sobre as funções que o sistema deve 
fornecer e as restrições sob as quais deve operar. 
Devem ser escritos para gerentes do clientes e dos fornecedores que não tenham um 
conhecimento detalhado do sistema. 
- Requisitos de sistema - para indicar a descrição detalhada que o sistema deverá fazer. 
Estabelecem detalhadamente as funções e as restrições de sistemas. O documento de 
requisitos de sistema, algumas vezes chamado de especificação funcional, deve ser preciso e 
pode servir como um contrato entre o comprador do sistema e o desenvolve-dor de software. 
Devem ter como alvo os profissionais técnicos de nível sênior e os gerentes de projeto. 
- Especificação de projeto de software– é uma descrição abstrata do projeto de software que é 
uma base para o projeto e a implementação mais detalhados. Essa especificação acrescenta 
detalhes à especificação de requisitos do sistema. 
É um documento orientado à implementação, deve ser escrito para os engenheiros de 
software que desenvolverão o sistema. 
 
Exemplos: 
Requisitos do usuário: 1. O software deve oferecer um meio de representar e acessar arquivos 
externos criados por outras ferramentas. 
 
Requisitos do sistema: 
1.1. O usuário deve dispor de recursos para definir o tipo dos arquivos externos. 
1.2. Cada tipo de arquivo externo pode ter uma feramenta asscoiada que pode ser aplicada a ele. 
1.3. Cada tipo de arquivo externo pode ser representado como um ícone especifico na tela do 
usuário. 
1.4. Devem ser fornecidos recursos para o ícone que representa um arquivo externo, a ser definido 
pelo usuário. 
1.5. Quando um usuário seleciona um ícone que representa um arquivo externo, o efeito dessa 
seleção é aplicar a ferramenta associada como tipo de arquivo externo representado pelo ícone 
selecionado. 
 
A Tabela 4 apresenta os diferentes leitores para os tipos de especificação de software. 
 
 9
Tabela 4 – Leitores para os diferentes tipos de especificação 
Requisitos dos usuários Gerentes de clientes, usuários finais de sistemas, engenheiros 
de clientes, gerentes do fornecedor, arquitetos de sistemas 
Requisitos de sistema Usuários finais de sistemas, engenheiros do cliente, arquitetos 
de sistemas, desenvolvedores de software. 
Especificação de projeto 
de software 
Engenheiros do cliente (talvez), arquitetos do sistema, 
desenvolvedores de software. 
 
 
Definindo Requisitos Funcionais e Não Funcionais 
 
Requisitos funcionais: São declarações de funções que o sistema deve fornecer, como o sistema 
deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em alguns 
casos, os requisitos funcionais, podem também explicitamente declarar o que o sistema não deve 
fazer. Especificação deve ser completa e consistente. 
Completa – que todas as funções requeridas pelo usuário devem estar definidas. 
Consistente – requisitos não devem ter informações contraditórias. 
 
A maioria dos problemas na especificação/desenvolvimento de sistemas ocorre devido ao não 
cuidado nessa fase. 
 
Requisitos não funcionais: São aqueles que não dizem respeito diretamente às funções específicas 
fornecidas pelo sistema. Eles podem estar relacionados a propriedades de sistemas como : 
confiabilidade, tempo de resposta e espaço em disco. Como alternativa, eles podem definir 
restrições para o sistema como a capacidade dos dispositivos de E/S e as representações de dados 
utilizadas nas interfaces de sistema. 
 
O não cumprimento de um requisito não funcional pode tornar o sistema inútil. 
Exemplo: Se um sistema de aviação não atender aos seus requisitos de confiabilidade, ele não será 
atestado como seguro para operação; se um sistema de tempo real falhar em cumprir com seus 
requisitos de desempenho, as funções de controle não operarão corretamente. 
 
Os requisitos não funcionais nem sempre dizem respeito ao sistema de software a ser desenvolvido. 
Alguns requisitos não funcionais podem restringir o processo que pode ser utilizado para 
desenvolver o sistema. 
Exemplos: Especificação de padrões de qualidade, que deve ser utilizada no processo, uma 
especificação de que o projeto deve ser produzido com um conjunto especificado de ferramentas 
CASE e uma descrição de processo a ser seguido. 
 
A Figura 4 exibe os tipos de requisitos não funcionais existentes. 
 
1. Requisitos de produtos: são os requisitos que especificam o comportamento do produto. 
Entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve 
operar e a quantidade de memória que ele requer, os requisitos de confiabilidade, que 
estabelecema taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de 
facilidade de uso. 
2. Requisitos de produtos: são os requisitos que especificam o comportamento do produto. 
Entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve 
operar e a quantidade de memória que ele requer, os requisitos de confiabilidade, que 
 10 
estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de 
facilidade de uso. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4 - Classificação dos Tipos de Requisitos Não Funcionais 
 
3. Requisitos organizacionais: são procedentes de políticas e procedimentos nas organizações 
do cliente e do desenvolvedor. Exemplos: padrões de processo que devem ser utilizados, os 
requisitos de implementação, como a linguagem de programação ou o método de projeto 
utilizado, e os requisitos de fornecimento, que especificam quando o produto e seus 
documentos devem ser entregues. 
4. Requisitos externos: abrange todos os requisitos procedentes de fatores externos ao sistema 
e a seu processo de desenvolvimento. Dentre eles destacam-se os requisitos de 
interoperabilidade, que definem como o sistema interage com outras organizações, os 
requisitos legais, que devem ser seguidos para assegurar que o sistema opera de acordo com 
a lei, e os requisitos éticos. Os requisitos éticos são definidos em um sistema para garantir 
que este será aceitável para seus usuários e o publico em geral. 
Requisitos não 
funcionais 
Requisitos 
organizacionais 
Requisitos 
externos 
Requisitos de 
confiabilidade 
Requisitos de 
eficiência 
Requisitos de 
portabilidade 
Requisitos de 
desempenho 
Requisitos de 
espaço 
Requisitos de 
entrega 
Requisitos de 
implementação 
Requisitos de 
padrões 
Requisitos de 
interoperabilidade
Requisitos de 
éticos 
Requisitos de 
legais 
Requisitos de 
privacidade 
Requisitos de 
segurança 
Requisitos do 
produto 
Requisitos de 
facilidade de 
uso 
 11
Exemplos de requisitos não funcionais 
Requisito de produto: Deve ser possível que toda a comunicação necessária entre o ambiente 
APSE e o usuário seja expressa no conjunto-padrão de caracteres Ada. 
 
Requisito organizacional: O processo de desenvolvimento de sistema e os documentos a serem 
entregues deverão estar de acordo com o processo e os produtos a serem entregues, definidos 
em XYZCo-SP-STAN-95. 
 
Requisito Externo: O sistema não deverá revelar aos operadores nenhuma informação pessoal 
sobre os clientes, além de seus nomes e o número de referencia. 
 
Tratamento dos Requisitos de usuário – Problemas e formas de Solução 
 
Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não funcionais 
de modo compressível pelos usuários do sistema que não têm conhecimentos técnicos detalhados. 
Eles devem especificar somente o comportamento externo do sistema, evitando tanto quanto 
possível as características de projeto de sistema. Conseqüentemente, não devem ser definidos 
utilizando-se um modelo de implementação. Eles podem ser descritos com o uso de linguagem 
natural, formulários e diagramas intuitivos simples. 
 
Problemas que normalmente ocorrem: 
1- Falta de clareza – é difícil utilizar a linguagem de maneira precisa e sem ambigüidade, sem 
produzir um documento de difícil leitura. 
2- Confusão de requisitos – quando os requisitos funcionais e não funcionais, os objetivos do 
sistema e as informações sobre o projeto não estão claramente definidos. 
3- Fusão de requisitos – quando vários requisitos diferentes são expressos junto como um 
único requisito. 
 
Diretrizes para redação de requisitos: 
1. Adote um formato-padrão e certifique-se de que todas as definições de requisitos 
estejam conforme esse formato. Padronizar o formato significa que as omissões 
podem ser menos freqüentes e faz com que os requisitos sejam verificados com mais 
facilidade. “O formato que utilizo inclui “reforçar”o requisito inicial, considerando 
uma declaração da lógica, com cada requisito de usuário e uma referencia à 
especificação mais detalhada de requisitos de sistema” 
2. Utilize a linguagem de modo consistente. Em particular, faça distinção entre os 
requisitos obrigatórios (utiliza-se o verbo deve) e os que são desejáveis (utiliza-se o 
verto deveria). 
3. Utilize destaques no texto (negrito ou itálico) para ressaltar partes importantes dos 
requisitos. 
4. Evite, tanto quanto possível, o uso de jargões de informática. Contudo, ocorrerá que 
termos técnicos detalhados, utilizados no domínio da aplicação do sistema, sejam 
incluídos nos requisitos dos usuários. 
 
Tratamento dos Requisitos de sistema 
 
São descrições mais detalhadas dos requisitos dos usuários. Eles podem servir de base para um 
contrato destinado à implementação do sistema e, portanto, devem ser uma especificação completa 
e consistente de todo o sistema. São utilizados pelos engenheiros de software como ponto de partida 
para o projeto de sistema. 
 12 
 
Os requisitos de sistema deveriam em principio definir o que o sistema deveria fazer, e não como 
ele teria de ser implementado. A linguagem natural por ser ambígua pode gerar problemas nesse 
documento. Dessa forma existem outras formas: linguagem natural estruturada, linguagem de 
descrição de projeto, notações gráficas, especificações matemáticas. 
 
Formalização: O documento de requisitos de software 
 
É a declaração oficial do que é exigido dos desenvolvedores de sistema. Ele deve incluir os 
requisitos de usuário para um sistema e uma especificação detalhada dos requisitos de sistema. 
Algumas vezes, esses dois tipos de requisitos podem ser integrados em uma única descrição. Em 
outros casos, os requisitos de usuários são definidos em uma introdução à especificação dos 
requisitos de sistema. Podem ser apresentados em documentos separados se possuírem um número 
grande de requisitos. 
Vários usuários utilizam o documento de requisitos: 
 
Conselhos de Heninger (1980) sobre seis requisitos aos quais um documento de requisitos de 
software deveria satisfazer: 
1. Especificar somente o comportamento externo do sistema. 
2. Especificar as restrições à implementação 
3. Ser fácil de ser modificado 
4. Servir como uma ferramenta de referencia para os responsáveis pela manutenção do sistema 
5. Registrar a estratégia sobre o ciclo de vida do sistema 
6. Caracterizar respostas aceitáveis para eventos indesejáveis. 
 
A Tabela 5 apresenta os diferentes usuários de um documento de requisitos e a forma como o 
utilizam. 
 
Tabela 5 – Usuários de um documento de requisitos 
Usuários Utilização 
Clientes de sistema Especificam os requisitos e os têm para verificar se eles 
atendem a suas necessidades. Especificam mudanças nos 
requisitos 
Gerentes Utilizam o documento para planejar um pedido de proposta 
para o sistema e para planejar o processo de 
desenvolvimento do sistema 
Engenheiros de sistema Utilizam os requisitos para compreender que sistema deve 
ser desenvolvido 
Engenheiros de teste de 
sistema 
Utilizam os requisitos para desenvolver testes de validação 
para o sistema. 
Engenheiros de manutenção 
de sistema 
Utilizam os requisitos para ajudar a compreender o sistema 
e as relações entre suas partes. 
 
 
Padrão do IEEE – IEEE/ANSI 830-1993 
 
Um padrão sugerido para o documento de requisitos tem a seguinte estrutura e foi proposta pelo 
IEEE. 
 
1. Introdução 
 13
1.1 Propósito 
Deve delinear o propósito do documento de requisitos. 
 
1.2 Escopo do produto 
Deve identificar, pelo nome, o software a ser produzido; deve explicar, o que o software 
fará e, se necessário, o que ele não fará. 
 
1.3 Definições, Acrônimose Abreviações 
Deve fornecer as definições de todos os termos, acrônimos e abreviações utilizados no 
documento, para que se possa interpreta-lo adequadamente. 
 
1.4 Visão Geral do restante do documento 
Deve descrever o restante do documento de requisitos e explicar como esse documento está 
organizado. 
2. Descrição Geral 
Descreve os fatores gerais que afetam o produto e seus requisitos. Essa seção não declara 
requisitos específicos. Ao invés disso, ela fornece um background para os requisitos 
específicos, os quais são definidos em detalhes na Seção 3. 
 
2.1 Perspectiva do produto 
Deve colocar o produto em perspectiva com outros produtos relacionados. Se o produto é 
independente e totalmente auto-contido, esse fato deve ser declarado aqui. Se o Documento 
de Requisitos define um produto que é um componente de um sistema maior, como 
freqüentemente ocorre, então essa subseção deve relatar os requisitos daquele sistema maior 
que têm alguma relação com a funcionalidade do software identificando as interfaces entre 
aquele sistema e o software em questão. 
 
2.2 Funções do Produto 
Deve fornecer um resumo das maiores funcionalidades que o software deve realizar. 
 
2.3 Características do Usuário 
Deve descrever as características gerais dos usuários do produto, incluindo nível de 
educação, experiência e conhecimento técnico. 
 
1.4 Restrições Gerais 
Deve descrever as restrições que o sistema tem. 
 
2.5 Suposições e Dependências 
Deve listar cada um dos fatores que afetam os requisitos declarados na Seção 3. 
 
3. Requisitos 
Deve conter todos os requisitos do software (funcionais, não funcionais e de interface) 
em um nível de detalhe suficiente para permitir que os projetistas possam elaborar um 
projeto que satisfaça esses requisitos. Os requisitos podem ser divididos em Requisitos 
Funcionais e Requisitos não funcionais. Cada requisito declarado deve possuir uma 
identificação única. 
3.1 Requisitos funcionais 
descrição 
entrada exigida 
processamento 
 14 
saída gerada 
3.2 Requisitos não funcionais 
do produto 
 organizacionais 
 externos 
3.3 Atributos 
Conter todos os atributos necessários para o software. Exs: de confiabilidade, segurança, 
portabilidade, manutenção. 
 
4. Apêndices 
5. Índice 
A estrutura de um documento de requisitos pode conter modificações, a partir da proposta do IEEE: 
 
Capítulo Descrição 
Prefácio Definir o público alvo a que se destina o documento e descrever 
seu histórico da versão, incluindo lógica para a criação de uma 
nova versão e um sumário das mudanças feitas em cada versão. 
Introdução Deve descrever: a necessidade do sistema, brevemente suas 
funções e explicar como ele deverá operar com outros sistemas; 
como o sistema se ajusta aos negócios em geral ou aos objetivos 
estratégicos da organização que está solicitando o software. 
Glossário Deve definir os termos técnicos utilizados no documento. Não 
deve fazer suposições sobre a experiência ou o conhecimento do 
leitor. 
Definição de 
requisitos de usuário 
Descrever os serviços fornecidos para o usuário e os requisitos não 
funcionais do sistema. Podem ser utilizadas: linguagem natural, 
diagramas ou outras notações que sejam compreensíveis pelo 
cliente. 
Arquitetura de 
sistemas 
Apresentar uma visão geral de alto nível da arquitetura prevista de 
sistema, mostrando a distribuição de funções por meio de módulos 
de sistemas. Se houver reuso, os componentes devem ser 
destacados. 
Especificação de 
requisitos do sistema 
Descrever requisitos funcionais e não funcionais com mais 
detalhes. 
Modelos de Sistema Devem mostrar o relacionamento entre os componentes de sistema 
e o sistema e seu ambiente. Podem ser modelos de fluxos de 
dados, de objetos, etc. 
Evolução do sistema Devem ser descritas as suposições fundamentais nas quais o 
sistema se baseia e as mudanças previstas, devidas à evolução do 
hardware, mudanças de usuário, etc. 
Apêndices Detalhes e informações específicas relacionadas à aplicação que 
está sendo desenvolvida (Exs: descrições de hardware, banco de 
dados) 
Índice Alfabético, índice de diagramas, de funções, etc.. 
 
 
Referencia Bibliográfica: Engenharia de Software – Ian Sommerville, 6a edição, Addison Wesley, 
2003. 
 
 15
Dicas Para a elaboração do Documento de Requisitos 
 
"Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de 
que aquilo que ouviu não é o que eu pretendia dizer". 
 
 
Possibilitando ao Engenheiro de Software: 
 
• especificar a função e o desempenho do software 
• indicar a interface do software com outros elementos do sistema 
• estabelecer quais são as restrições de projeto que o software deve enfrentar 
• construir modelos do processo, dos dados e dos domínios comportamentais. 
• traduzir em um projeto procedimental, arquitetônico e de dados a representação da 
informação e a função. 
 
Para se obter a declaração do escopo do sistema (1.2 IEEE) deve-se seguir os seguintes passos: 
 
1. entender as funções globais do sistema 
2. descrever a função principal do sistema 
3. identificar as principais entradas e saídas 
4. listar todas as restrições que afetam o sistema 
5. escrever um parágrafo claro 
 
1. - Entender as funções globais do sistema 
 
Antes que o processo de engenharia de software comece, deve-se entender as principais 
funções do sistema computacional e o papel do software dentro do sistema. Idealmente, uma 
descrição detalhada das funções do sistema seria fornecida pelo cliente. No entanto, na realidade, o 
analista deve formular uma série de questões para o cliente a fim de descrever suas necessidade de 
maneira concisa e não ambígua. 
 
O conjunto inicial de questões deve focalizar as saídas: 
 
• Que tipo de informação ou sinais de controle o sistema deve produzir? 
• Qual é o formato, o conteúdo e a estrutura de dados de saída? 
• Eles são produzidos na forma de relatório, necessita de periféricos gráficos ou em algum 
formato especial? 
• Quem faz uso dos dados de saída? 
• Outros sistemas fazem uso dos dados de saída? 
 
Respostas a tais questões auxiliam o analista a isolar os principais objetivos do sistema e 
fornecem indicações implícitas das funções do sistema. 
 
O segundo conjunto de questões deve focalizar as entradas: 
 
• Quais as informações ou sinais de controle o sistema deve aceitar como entrada? 
• Os dados de entrada são fornecidos através de um diálogo interativo homem-máquina? 
• Qual é o nível de validação de dados requerida? 
• Qual é o formato dos dados de entrada? 
 16 
• Quem fornece os dados? 
 
Respostas às questões de entrada e saída fornecerão informações substanciais sobre as 
funções do sistema. 
 
O terceiro conjunto de questões é formulado para melhor compreender as funções do 
sistema. São desenvolvidas questões para esclarecer cada função inferida. Essas respostas em 
conjunto com as anteriores permitem escrever a declaração do escopo do sistema. 
 
2. - Descrever a função principal do sistema 
 
Normalmente, essa função é expressa em um parágrafo que identifica o principal objetivo do 
sistema computacional. Utiliza uma linguagem clara para descrever: 
 
• Qual a função o sistema irá realizar 
• As informações necessárias 
• As informações produzidas 
 
Por exemplo, uma declaração do escopo para um programa de integração numérica pode ser: 
 
Será desenvolvido um sistema que utiliza técnicas numéricas para calcular 
a integral de uma função f(x) entre os valores a e b. Apenas funções da 
forma: f(x) = px3 + qx2 + rx + s serão consideradas. 
 
A declaração do escopo pode levar a muitas outras questões. O sistema é computadorizado 
ou manual? Qual o nível de precisão desejado? Como são fornecidas as funções f(x) e os valores 
limites a e b ? Com que velocidadea integração deve ser feita? 
 
Com o refinanciamento da declaração do escopo (após as respostas destas e outras questões), 
duas coisas acontecem: a função é identificada e analisada, e o papel de cada elemento é 
determinado. Por exemplo, se apenas uma aproximação é requerida, a velocidade não for 
importante, e o método de implementação não importa, a melhor alocação pode ser puramente 
manual – integração gráfica usando papel e caneta. Os elementos apropriados seriam pessoa, 
instruções (procedimentos) e uma representação gráfica de f(x) no papel (informação). Por outro 
lado, se for necessária uma alta precisão e milhões de integrações por minuto, uma solução baseada 
em computador é indicada. Nestes casos, os elementos apropriados do sistema seriam: hardware, 
software, pessoas, documentos, informação e procedimentos. 
 
Para começar uma abordagem mais sistemática, considere um problema mais complicado: 
um piloto automático. Uma declaração do escopo poderia ser descrita inicialmente como: 
 
O sistema Piloto- automático irá manter constante a velocidade do 
automóvel uma vez que ela tenha sido indicada pelo motorista. A velocidade 
irá ser mantida até que o sistema seja desligado ou até que o motorista 
pressione o freio. 
 
A declaração acima descreve tanto os objetivos do sistema como sua função principalmente. 
Indica também a informação requerida (uma velocidade indicada) e produzida (manter a velocidade 
 17
constante). Porém, muitos detalhes não foram tocados. A descrição dos objetivos e da principal 
função do sistema está em muito alto – nível. Isto é, detalhes funcionais não foram descritos, não 
foram identificadas as entradas e saídas específicas, e detalhes de implementação foram omitidos. É 
importante notar, no entanto, que estas omissões são completamente aceitáveis no inicio. O objetivo 
é desenvolver uma declaração inicial do escopo que descreve a função principal do sistema. 
 
Pode parecer desnecessário e redundante desenvolver uma declaração do escopo para o 
sistema Piloto – automático. Porém deve se ter em mente que: 
 
“Todos sabem o que o sistema deverá fazer até que alguém decida 
descreve-lo”. 
 
Uma declaração de escopo deve ser o mais simples possível no início. A primeira declaração 
os rascunho das principais funções do sistema devem ser sentenças simples (sujeito, verbo e objeto). 
Por exemplo, uma primeira declaração de um sistema de piloto automático poderia ser: 
 
O sistema piloto automático mantém constante a velocidade do automóvel. 
 
Interações subseqüentes dessa sentença pode refinar o sujeito, verbo e objeto, para fornecer 
maiores detalhes e menor ambigüidade. 
 
3. - Identificar as principais entradas e saídas 
 
Independente da área de aplicação, todo sistema computacional transforma informações. Isto 
é, dados fornecidos são transformados pelo sistema para produzir dados de saídas.O próximo passo 
na criação de uma declaração de escopo é uma descrição das principais entradas e saídas do sistema 
computacional. Durante os primeiros estágios do trabalho de análise, sempre é útil classificar os 
dados transformados pelo sistema em duas grandes categorias genéricas: itens de dados e itens de 
controle Um item de dados é qualquer entrada ou saída do sistema cujo conteúdo da 
informação é transformado (isto é, modificado, reorganizado, calculado, combinado) pelo 
elemento software. Em geral, algoritmos computacionais ou combinatoriais transformam itens de 
dados de uma forma ou de outra . Um item de controle geralmente implica na ocorrência de 
uma ação ou evento específico, ou requisito a inicialização de uma ação ou evento específico. 
Para ilustrar a diferença entre itens de dados e itens de controle, considere que o sistema 
Piloto automático permite ao motorista definir a velocidade desejada usando um teclado numérico 
do painel. A velocidade desejada é um item de dados – isto é, uma entrada do sistema que é 
processada pelo software e transformada em velocidade. Para desligar o sistema, o motorista deve 
pressionar o freio ou o botão de desliga. Ambas ações causam um pulso que é lido pelo software. 
Devido ao pulso não ser transformado (modificado, reorganizado, calculado, combinado) de alguma 
forma, mas representar um evento que provoca uma mudança imediata na função do sistema, ele 
será considerado um item de controle. 
 
4. - Listar todas as restrições que afetam o sistema 
 
A especificação e projeto de um sistema computacional são restringidos por muitas razões: 
 
• Considerações econômicas podem limitar tanto os recursos técnicos como humanos. 
• As características de um elemento do sistema podem restringir a maneira como um outro 
elemento do sistema é especificado e, conseqüente, projetado. 
 18 
• ambiente e que o sistema será desenvolvido poderá impor restrições quando as funções e 
desempenho do sistema. 
 
É importante reconhecer que atitudes fatalistas podem, muitas vezes, ser improdutivas. 
Embora o hardware tenha sido selecionado, pode não ser tão tarde efetuar mudanças, se as 
restrições impostas no software forem tão severas que: (1) uma quantidade exorbitante de tempo 
seja necessária para desenvolver o software, aumentando dramaticamente o custo de 
desenvolvimento; (2) a habilidade de alcançar o desempenho de controle esteja em risco ou (3) 
modificações no sistema operacional sejam possíveis. 
 
Por listar as restrições, está se conduzindo uma revisão implícita. Por exemplo, considere o 
desenvolvimento de uma rede de caixas eletrônicas para um grande banco. O sistema é composto de 
diferentes computadores e softwares, uma base de dados, operadores humanos, e substancial 
documentação e procedimentos. A capacidade de processamento do hardware, a organização da 
base de dados, os registros impostos para operadores humanos (clientes do banco), e muitos outros 
fatores irão criar um conjunto de restrições para o sistema. Além disso, a natureza da aplicação dita 
as suas próprias restrições implícitas: 
 
1. A necessidade da segurança apropriada para proteger os interesses do banco e de seus clientes 
2. A necessidade da disponibilidade de um caixa ao cliente 
3. A necessidade de expandir a rede de acordo com o crescimento do banco 
4. A necessidade de estender características e funções devido à pressões da concorrência. 
 
Cada uma dessas restrições implícitas deve ser listada nesta fase. Cada uma implica que 
certos elementos do sistema devem ter características especificas e, em muitos casos, especificas 
funções de desempenho. 
 
5. - Escrever um parágrafo claro 
 
Se tiver sido realizado cada um dos passos associados com o desenvolvimento de uma 
declaração de escopo, têm-se agora as seguintes informações: 
 
• Uma descrição da função principal do sistema. 
• Uma lista das principais entradas e saídas. 
• Uma lista de restrições que afetam o sistema. 
 
Estas informações são a base para um parágrafo claro que descreva todas as operações e 
características do sistema. O parágrafo deve descrever as funções importantes do sistema de forma 
objetiva, correta e simples. Deve conter referências á item de dados e de controle e, também, a 
maneira como eles interagem com as principais funções do sistema. Devido ao parágrafo ser a 
entrada essencial os próximos passos da análise de sistemas, ele deve ser desenvolvido com muito 
cuidado. De fato, é sempre vantajoso desenvolver o parágrafo interativamente. Isto é, começa-se a 
escrever um rascunho inicial, então se faz refinamentos, até a versão final. 
 
A cada elaboração da declaração do escopo as ambigüidades devem ser eliminadas e mais 
detalhes são fornecidos. Para ilustrar, considere o rascunho inicial da declaração de escopo do 
sistema Piloto-automático. 
 
O sistema "Piloto-automático" mantém constate a velocidade do automóvel. 
 
 19
Embora este rascunhodefina a principal função do sistema, fornece poucos detalhes e deve 
ser refinado. Após dialogar com o cliente, escreve-se: 
 
O sistema Piloto automático irá manter constante a velocidade do 
automóvel uma vez que ela tenha sido indicada pelo motorista. A velocidade 
irá ser mantida até que o sistema seja desligado ou até que o motorista 
pressione o freio. 
 
Melhor, mais ainda vago. Existe a necessidade de se conhecer qual é a variação da 
velocidade aceitável, qual o mecanismo que será usado para “indicar” a velocidade, qual o 
mecanismo será usado para desligar o sistema. Além disso, falta determinar alguns requisitos 
implícitos ou restrições (por exemplo: características de segurança). Note-se, no entanto, que não há 
necessidade de se determinar como o sistema irá realizar esta função. Isso será feito posteriormente. 
Neste ponto, o enfoque está sobre o problema e não sobre como resolve-lo. O terceiro rascunho 
pode ser: 
 
O sistema "Piloto Automático" mantém constate a velocidade do 
automóvel, podendo variar ±3 milhas por hora (mph) de um valor nominal 
especificado pelo motorista. O valor da velocidade nominal é indicado pelo 
motorista de duas formas: (1) ou pressionando-se um botão set speed 
enquanto o automóvel estiver andando com velocidade igual ou maior que 
45 mph, ou (2) teclando-se a velocidade desejada no painel do carro. O 
dado da potência será monitorado em intervalos de 0,1 segundo e a média 
calculada a cada segundo. O sistema irá ajustar a velocidade a cada 
segundo. O sistema é automaticamente desligado quando a velocidade 
nominal ficar abaixo de 45 mph. Além disso, o motorista pode desligar o 
sistema pressionando o freio ou pressionando o botão off. 
 
Em cada elaboração, maiores detalhes são fornecidos e futuras questões são levantadas e 
respondidas. O processo termina quando o analista der-se por satisfeito, ou seja, não tiver mais 
questões a levantar. 
 
Para execução desse processo de definição do escopo do sistema, várias técnicas podem ser 
utilizadas. A seguir, são apresentadas as principais técnicas para apoiar a etapa de levantamento de 
requisitos.