2
Introdução aos Sistemas de Informação
Aula 2 - Processo de Software
Material elaborado pelas Profas. Junia e Rosângela
0
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.
Existem também os custos de evolução (manutenção), alteração do software depois que foi
colocado em uso.
0
25
50
100
Especificação
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
25
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.
Desenvolvimento
50
desenvolvimento cíclico e iterativo
75
100
Teste de sistema
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.
4
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?
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.
Cidade
Rua
Edifício
Sistema de
Sistema de
Aquecimento energia
Sistema de
água
Sistema de
Segurança
Sistema de
esgoto
Sistema de
iluminação
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.
5
6
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
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.
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).
Sensores de
movimento
Sensores de
porta
Considerando esses componentes para o exemplo anterior tem-se a Tabela 3.
Controlador
de alarme
Sirene
Sintetizador
de voz
Discador
de telefone
Centro de controle
externo
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
Tabela 3 Componentes de sistemas e suas funções
Tipos de componentes
Componentes
Função
Sensor
Sensor de movimento, Detecta movimento nos cômodos
sensor de porta
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:
8
Especificação
de requisitos
Desativação
do sistema
Projeto do
sistema
Evolução do
sistema
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.
Desenvolvimento
de subsistema
Instalação do
sistema
Integração do
sistema
Figura 3 – Processo de engenharia de sistemas
Especificação de Requisitos
Um 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.
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 Engenheiros do cliente (talvez), arquitetos do sistema,
de software
desenvolvedores de software.
10
estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de
facilidade de uso.
Requisitos do
produto
Requisitos de
confiabilidade
Definindo Requisitos Funcionais e Não Funcionais
Requisitos de
eficiência
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.
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
estabelecem a 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
Requisitos de
desempenho
Requisitos de
espaço
Requisitos de
portabilidade
Requisitos não
funcionais
Requisitos
organizacionais
Requisitos de
entrega
Requisitos de
implementação
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.
Requisitos de
facilidade de
uso
Requisitos de
padrões
Requisitos
externos
Requisitos de
interoperabilidade
Requisitos de
éticos
Requisitos de
legais
Requisitos de
privacidade
Requisitos de
segurança
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.
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.
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.
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.
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 Utilizam os requisitos para desenvolver testes de validação
sistema
para o sistema.
Engenheiros de manutenção Utilizam os requisitos para ajudar a compreender o sistema
de sistema
e as relações entre suas partes.
Tratamento dos Requisitos de sistema
Padrão do IEEE – IEEE/ANSI 830-1993
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.
Um padrão sugerido para o documento de requisitos tem a seguinte estrutura e foi proposta pelo
IEEE.
1. Introdução
14
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ônimos e 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
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
Prefácio
Descrição
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.
Deve descrever: a necessidade do sistema, brevemente suas
Introdução
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.
Deve definir os termos técnicos utilizados no documento. Não
Glossário
deve fazer suposições sobre a experiência ou o conhecimento do
leitor.
Definição
de Descrever os serviços fornecidos para o usuário e os requisitos não
requisitos de usuário funcionais do sistema. Podem ser utilizadas: linguagem natural,
diagramas ou outras notações que sejam compreensíveis pelo
cliente.
Arquitetura
de 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
sistemas
de sistemas. Se houver reuso, os componentes devem ser
destacados.
Especificação
de Descrever requisitos funcionais e não funcionais com mais
requisitos do sistema detalhes.
Devem mostrar o relacionamento entre os componentes de sistema
Modelos 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.
Detalhes e informações específicas relacionadas à aplicação que
Apêndices
está sendo desenvolvida (Exs: descrições de hardware, banco de
dados)
Alfabético, índice de diagramas, de funções, etc..
Índice
Referencia Bibliográfica: Engenharia de Software – Ian Sommerville, 6a edição, Addison Wesley,
2003.
16
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.
2.
3.
4.
5.
entender as funções globais do sistema
descrever a função principal do sistema
identificar as principais entradas e saídas
listar todas as restrições que afetam o sistema
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?
•
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 velocidade a 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.
2.
3.
4.
A necessidade da segurança apropriada para proteger os interesses do banco e de seus clientes
A necessidade da disponibilidade de um caixa ao cliente
A necessidade de expandir a rede de acordo com o crescimento do banco
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 rascunho defina 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.