Exerccios resolvidos de Ian Sommerville, Software Engineering 8th Edition

indicados pelo Prof. Srgio Guerreiro, resolvidos por Carrajola e Zlia Regina.
Actualizaes a azul por Victor Freire.
Exerccios Pg.18
1.1 - Fazendo referncia aos custos do software indicados na seco 1.1.7,
explique porque apropriado considerar que o software mais que
programas que so executados por os usurios finais de um sistema.
Requisitos > Arquitectura > Desenvolvimento > Implementao > Testes >
Implantao > Manuteno/Evoluo O que se verifica que no processo de
distribuio do software, variando consoante o tipo de aplicao, que as
fases posteriores ao desenvolvimento, a validao (integrao e testes) e a
evoluo, tm por vezes um custo mais elevado do que a fase de
desenvolvimento. Quando o software desenvolvido integrado num sistema
j existente, a fase de integrao e testes extensa e dispendiosa,
atingindo cerca de 50% dos gastos totais do processo de criao do
software. Igualmente dispendioso o processo de evoluo depois do
software estar implementado e testado. Para uma aplicao com um longo
tempo de vida, como sistemas de comando e controle que sero usados
durante 10 anos ou mais, os custos de evoluo provavelmente chegaro a
3 ou 4 vezes o valor gasto para o desenvolvimento desse software. Sendo
assim correcto dizer-se que o processo de criao de software inclui toda a
actividade que o envolve, ou seja, a especificao, o desenvolvimento, a
validao e a evoluo, incluindo tambm toda a documentao associada a
cada uma dessas fases.
1.2 Quais so as diferenas entre o desenvolvimento de um produto de
software genrico e umdesenvolvimento de um produto de software
personalizado. Software genrico Quem produz o software controla a
especificao, feitos para o mercado geral. Software medida Quem
compra o software controla a especificao, feitos para um cliente
especfico.
1.7 - parte dos desafios de heterogeneidade, entrega rpida e confiana,
indique outros problemas e desafios que a engenharia de software
provavelmente enfrentar no sculo 21. Performance do software
(utilizao de ferramentas case cria cdigo no optimizado e menos
eficiente, novos algoritmos e linguagens mais eficazes para criao de
software) Escalabilidade modelos mais eficazes na escalabilidade e
manuteno de projectos de software cada vez mais complexos e melhor
reutilizao de cdigo. Evoluo dos mtodos de programao. Ex.:
programao estruturada, programao orientada a objectos, Segurana
Ergonomia do software software cada vez mais acessvel a todos os
utilizadores (Ex.: Utilizadores com deficincias) Produo de software com
linguagem natural acelera o processo de criao de software
possibilitando um nvel mximo de abstraco. Melhores e mais fiveis
agentes inteligentes para ajuda no processo de criao de software.
Software amigo do ambiente (performance e tica ambiental) Certificao
dos engenheiros de software. Custos mais baixos na produo de software,
conjunto das medidas acima indicadas


1.8 - Discuta se os engenheiros profissionais devem ser certificados do
mesmo modo que mdicos ou advogados
Abordagem concordante: Responsabilidade e certificao em reas de
conhecimento onde esto subjacentes riscos elevados, em vidas humanas e
em prejuzosmateriais, da mesma forma que as ordens regulam outras
reas (cdigo deontolgico) onde esse mesmo risco existe: medicina,
direito, farmcia, engenharia, etc. Abordagem discordante: invivel limitar
a criao de software. Custo mais elevado do software. Dificuldade a
especificar qual software de risco elevado e qual no , por exemplo,
software de uma empresa afecta os stakeholders mas no dependem
vidas deste directamente qual o grau de risco?, em comparao por
exemplo no caso relativamente s drogas farmacuticas existirem produtos
de livre utilizao. Onde se enquadra o software open source?
Exerccios Pg.41 2.4 - Explique por que importante produzir uma
descrio completa de uma arquitectura de sistema numa etapa inicial do
processo de especificao. Principalmente facilita o processo de gesto do
projecto nos seguintes pontos: Viabilidade do projecto e riscos em termos
financeiros, tecnolgicos, de tempo e de recursos humanos e materiais
Optimizaes na gesto do plano de distribuio de recursos humanos e
materiais no processo da criao do software Ajuda na gesto de
milestones e plano de trabalhos (tempo, recursos e custos) Sendo feito
ajuda a clarificar e avaliar o grau de importncia de cada requisito Melhor
documentao do projecto, vital para a continuao do trabalho em caso de
mudana de recursos humanos e testes Melhora da qualidade do software
em termos gerais Ajuda a especificar as condies do contrato com cliente

2.8 - Explique por que os sistemas de legado (legacy system) podem ser
crticos operao de um negcio. Sistema de legado: Sistema sciotcnico desenvolvido no passado, muitas vezes comtecnologia j obsoleta.
Gere habitualmente sistemas crticos para a actividade. Engloba o processo
de negcio, software aplicacional, software de apoio e hardware, portanto
muitas vezes a actividade de negcio no pode ser efectuada sem ele. Ex.:
Software de Secretaria Escolar Os sistemas Legacy proporcionam servios
essenciais ao negcio mas, porque incluem processos de negcio, software
aplicacional, software de apoio e sistemas de hardware, podem ser crticos
no funcionamento de um negcio por ser demasiado arriscado substitu-los,
visto que as polticas e procedimentos organizacionais dependem destes
sistemas.
2.9 Explique porque que os sistemas herdados (legacy systems) podem

causar dificuldades para as companhias que desejam reorganizar os seus

processos de negcio.

Custos de desenhar um novo sistema so proibitivos por causa do seu

tamanho, por ser monoltico ou demasiado complexo O sistema requere
uma disponibilidade de 100%, no pode ser retirado de servio, e o custo de
desenhar um novo sistema com uma taxa de disponibilidade elevado O
sistema funciona de forma pouco clara. Essa situao pode ocorrer quando
os arquitectos de sistema deixaram a organizao e o sistema no foi bem
documentado ou a documentao foi perdida Os dados do sistema so de
elevado grau de confidencialidade (Ex.: Dados Militares) O custo de
aprender a utilizar o novo software elevado em termos de tempo e custo
(Recursos Humanos) Riscos na migrao dos dados

2.10 Quais so os argumentos a favor e contra para considerar que a

Engenharia de Sistemas uma profisso no seu prprio direito como
engenharia elctrica ou engenharia de software. A favor:A Engenharia de
Sistemas envolve as seguintes disciplinas: engenharia de software;
engenharia electrnica; engenharia mecnica; arquitectura de interface do
utilizador; arquitectura de sistemas; engenharia elctrica; engenharia civil;
engenharia de estruturas. Assim, verifica-se que Engenharia de Sistemas
uma profisso que recorre a variados conhecimentos de outras engenharias.
Competncias diferentes, um engenheiro de software no tem todas as
competncias de um engenheiro de sistemas e vice-versa, porque apesar de
ser englobado, existem aspectos tcnicos especializados, seno
abstractamente sem especializao s haveria engenheiros em cincias
naturais. Contra: A engenharia de sistemas uma actividade interdisciplinar
que envolve equipas com diferentes formaes tcnicas, por causa do
amplo conhecimento exigido para considerar todas as implicaes das
decises referentes a projectos de sistemas. Os engenheiros de sistemas
no se ocupam apenas com o software, mas com as interaces de
software, hardware e sistema com os utlizadores e seu ambiente.
Eles devem pensar sobre os servios que o sistema fornece, as restries,
dentro dos quais o sistema deve ser construdo e operado e as interaces
do sistema com o seu ambiente. Os engenheiros de software necessitam de
uma compreenso sobre a engenharia de sistemas, porque os problemas de
ES, frequentemente so o resultado da engenharia de sistemas. 2.11
Suponha que um engenheiro relacionado com o desenvolvimento de um
sistema financeiro. Durante a instalao descobre que o sistema vai reduzir
um nmero significativo de pessoas. As pessoas envolvidas negam-lhe

acesso a informao essencial para completar ainstalao do sistema. At

onde deveria, como engenheiro de sistemas, ficar envolvido nisto?
responsabilidade profissional sua completar a instalao como estipula o
contrato? Devia simplesmente abandonar o trabalho at que a organizao
tenha resolvido/classificado o problema?
Deveria manter como objectivo a concluso do trabalho contratado,
respeitando todos os mbitos legais e ticos no seu desenvolvimento e
utilizando os canais prprios e bom senso para arbitrar cada situao.
Exerccios Pg.91
4.2 Explique porque que programas que foram desenvolvidos usando
desenvolvimento evolucionrio tendem a ser difceis de manter.
Requerem constantes mudanas aos requisitos, actualizaes ao design,
contnuos processos de desenvolvimento e testes, o que leva a custos
elevados na sua manuteno. Alm disso a evoluo pode ser complicada
de acompanhar para os gestores e utilizadores do software da organizao.
4.5 - Explique porque importante fazer a distino do desenvolvimento
dos requisitos do usurio e o desenvolvimento dos requisitos do sistema no
processo de engenharia de requisitos. Os requisitos de usurio para um
sistema devem descrever os requisitos funcionais e no funcionais de modo
compreensvel pelos usurios do sistema que no tem conhecimentos
tcnicos detalhados. Eles devem especificar somente o comportamento
externo do sistema. Evitando tanto quanto possvel as caractersticas de
sistema.
Os requisitos de sistema so as descries mais detalhadas dos requisitos
do usurio. Eles podem servir como base para um contrato destinado
implementao do sistema e portanto devem ser uma especificao
completa e consistente de todo o sistema.Eles so utilizados pelos
engenheiros de software como ponto de partida para o projecto do sistema.
4.6 Descreva as principais actividades no processo de design de software
e os outputs destas actividades. Usando um diagrama, mostre as relaes
entre os outputs destas actividades As principais actividades no processo de
desenho de software so: 1. Projecto de arquitectura Os subsistemas que
constituem o sistema e suas relaes so identificadas e documentadas; 2.
Especificao abstracta Para cada subsistema, produzida uma
especificao abstracta das suas funes e das restries dentro das quais
devem operar; 3. Projecto de interface Para cada subsistema, projectada
e documentada uma interface com outros subsistemas. Essa especificao
de interface no pode apresentar ambiguidade, uma vez que ela permite
que o subsistema seja utilizado sem conhecimentos de operao do
subsistema. Os mtodos de especificao formal, podem ser utilizados
neste estgio; 4. Projecto de componentes As funes so alocadas a
diferentes componentes e as interfaces desses componentes so
projectadas; 5. Projecto de estrutura de dados As estruturas de dados
utilizadas na implementao de sistemas so projectadas em detalhe e

especificadas. 6. Projecto de algoritmos Os algoritmos utilizados para

proporcionarem servios so projectados detalhadamente e especificados.
Exerccios Pg.112
5.1 Explique porque que a intangibilidade dos sistemas de software traz
problemas para a gesto de projectos de software. Uma boa gesto do
projecto de software essencial para que os projectos de software sejam
desenvolvidos dentro do prazo e do oramento. Os gestores deprojecto de
software no podem quantificar o progresso, eles dependem de outras
pessoas para produzir a documentao necessria, a fim de saberem o
estado de desenvolvimento. Se essa documentao insuficiente ou
inexistente o gestor no tem elementos para decidir.
5.2 Explique porque que os melhores programadores no fazem sempre
os melhores gestores de software. Voc pode ter como base til a lista de
actividades de gesto dadas na seco 5.1. Elaborao de propostas
descreve os objectivos do projecto e como ele ser realizado Planeamento e programao de projectos se preocupam em identificar as
actividades, os marcos, e os documentos a serem produzidos em um
projecto. - Custo do projecto.custos requeridos para realizar um projecto Monitorizao e revises de projectos.o monitoriamento de projecto uma
actividade continua. o gestor deve manter o acompanhamento do
andamento do projecto e comparar os progressos e custos reais com os que
foram planeados. - Seleco e avaliao do pessoalo ideal que uma
equipa hbil e com experincia adequada esteja disponvelmas isso nem
sempre possvel porque: 1. O oramento pode no chegar para contratar
uma equipa bem paga 2. A equipa apropriada pode no estar disponvel por
exemplo por estar alocada a outro projecto 3. A organizao pode querer
desenvolver as habilidades de seus funcionrios. - Elaborao de relatrios
e apresentaes.tanto para a organizao do cliente como para as
organizaes dos fornecedores
5.3 Explique porque que o processo de planeamento do projecto
iterativo e porque que um plano deve ser continuamente revisto durante
um projecto de software.

Nova informaofica disponvel O objectivo do software (negcio) pode

alterar-se O projecto pode sofrer atrasos Pode haver recursos que deixam de
estar disponveis Custos mais elevados que o previsto
5.4 Resumidamente explique o propsito/objectivo de cada uma das
seces num plano de projecto de software.
O plano do projecto define os recursos disponveis para o projecto, a
estrutura analtica do trabalho e uma programao (calendrio) para
realizar o trabalho. Contudo, a maioria dos planos deve incluir as seguintes
seces:

Introduo - descreve com brevidade os objectivos do projecto e define as

restries ( oramento , prazo) que afectam a gesto do projecto.
Organizao do projecto descreve o modo como a equipe organizada, as
pessoas envolvidas e os seus papeis na equipe. Anlise de riscos descreve
possveis riscos do projecto, a probabilidade de surgir esses riscos e as
estratgias propostas para a reduo deles. Requisitos necessrios de
hardware e de software descreve o hardware e o software de apoio
exigidos para realizar o desenvolvimento. Se o hardware tiver de ser
comprado devero ser includos os prazos de entra e as estimativas de
preo. Diviso do trabalho descreve a diviso do trabalho em actividades e
identifica os marcos (milestones) e os produtos a serem entregues com cada
actividade (deliverables). Calendarizao de projecto descreve as
dependncias entre actividades, o tempo estimado requerido para cada
marco e a alocao de pessoas nas actividades. Mecanismos de
monitoramento e de elaborao de relatrios Descreve os relatrios de
gesto que devem ser produzidos, quando eles devem ser produzidos e
quais os mecanismos de monitorizaoque so utilizados.
5.5 Qual a diferena fundamental entre um milestone e um
deliverable?

Milestone Um milestone interno e s entregue ao gestor do projecto.

Milestone para o gestor acompanhar o projecto.

Deliverable Um deliverable um milestone de uma fase importante no

desenvolvimento do projecto que entregue ao cliente. Deriverable
para o cliente acompanhar o projecto.
5.6 A figura 5.15 mostra um conjunto de actividades, duraes e
dependncias. Desenha uma rede de actividades e um grfico de barras que
mostre a programao do projecto.
5.7 A figura 5.5 assinala a durao das tarefas para as actividades do
projecto de software. Suponha que h uma contrariedade imprevista em
lugar de requerer 10 dias, a tarefa T5 requer 40 dias. Fazer uma reviso da
rede de actividades resultante, destacando o novo caminho critico. Desenhe
um novo grfico de barras que mostre como se poderia reorganizar o
projecto.
5.9 Para alm dos riscos que se mostram na figura 5.11, indique outros
seis possveis riscos nos projectos de software. No livro: Tecnologia Riscos
que derivam do software ou hardware usados no desenvolvimento do
sistema. Ex.: Defeitos no hardware, insuficincias do software, recursos
indisponveis. Pessoas Riscos associados s pessoas na equipa de
desenvolvimento. Ex.: Doenas, Inexistncia de especialistas disponveis.
Organizacionais Riscos que derivam do ambiente da organizao onde o
software est a ser desenvolvido. Ex.: Reestruturaes, falta de fundos.

Ferramentas Riscos que derivam de ferramentas CASE e de outro software

usado no desenvolvimento do software. Ex.: Cdigo gerado
ineficiente,impossibilidade de integrao das ferramentas. Requisitos Riscos
que derivam de mudanas dos requisitos por parte do cliente e no processo
de gesto dessa mudana de requisitos. Ex.: As modificaes inseridas pelo
cliente geram um trabalho avultado, os clientes no compreendem o
impacto das mudanas de requisitos, o cliente no deu os requisitos certos.

Estimativas Riscos que derivam das estimativas feitas pela gesto quanto
s caractersticas do sistema e dos recursos necessrios para o construir.
Ex.: Estimativas erradas quanto ao tempo de desenvolvimento, extenso
de defeitos, ao tamanho do software.
Adicionais: Acidentes Riscos que derivam de um evento acidental, interno
ou externo. Ex.: Perda de trabalho acidentalmente, incndios, roubos.
Comunicao Riscos que derivam de transmisso de informao no clara,
errada ou em falta entre a equipa de desenvolvimento. Ex.: Equipa de vrias
nacionalidades, canais de comunicao deficientes, equipas de em locais
diferentes. Motivao Riscos que derivam da motivao da equipa ou do
cliente para a realizao do projecto Ex.: Indisponibilidade para reunies,
local de trabalho desconfortvel, salrios baixos. Expectativas Riscos que
derivam de uma expectativa frustrada dos utilizadores do software. Ex.:
Interface no user friendly, tarefas dificultadas no software, ergonomia.
Conflitos Riscos que derivam de conflitos entre os membros da equipa e/ou
com o cliente. Ex.: Segurana Riscos que derivam de falhas de segurana no
sistema. Ex.: Intruses, vrus.

5.11 Seu chefe solicitou que entregue um software num tempo que s
pode ser possvel cumprir perguntando equipa do projecto se deseja
trabalhar horas extras no pagas. Todos os membros da equipa tm filhos
pequenos. Comente se deveria aceitar esta exigncia do seu chefe ou se

voc deveria persuadir a equipa para dar o seu tempo organizao mais
que as suas famlias. Que factores poderiam ser significativos na deciso?

Importncia na data de entrega do software Perda do contracto se o

software no for entregue ou um simples milestone. Consequncias para
os trabalhadores Perda de emprego, prmios. Motivao Nvel de motivao
da equipa para terminar o projecto.

5.12 Como programador, se lhe oferecessem uma promoo como gestor

de projecto, mas voc sente que pode ter uma contribuio melhor num
papel tcnico do que num papel administrativo. Comente se deveria aceitar
esta promoo. Factores de deciso: Competncias Desafio
Vantagens para a organizao Ordenado
Exerccios Pg.141
6.1 Identifique resumidamente e descreva 4 tipos de requisitos que se
podem definir para um sistema informtico.

Funcionais Declaraes de funes que o sistema deve fornecer, como o

sistema deve reagir a entradas especficas e como se deve comportar em
determinadas situaes. Em alguns casos os requisitos funcionais podem
tambm explicitamente dizer o que o sistema no deve fazer. Ex.: Consulta
de dados de histrico, diferentes graus de privilgios de administrador. No
funcionais Restries sobre os servios ou as funes oferecidas pelo
sistema. Entre eles destacam-se restries de tempo, processo de
desenvolvimento (produto, organizacionais, externos).

Ex.: Tempo de resposta de acesso aos dados inferior a 5 segundos,

disponibilidade a100%. Requisitos dos utilizadores Declaraes em
linguagem natural e tambm em diagramas sobre as funes que o sistema
deve fornecer e as restries sob as quais deve operar. Ex.: Interface
simplificada com uma curva de aprendizagem rpida, linguagem do
programa em portugus e ingls. Requisitos do sistema Descries mais
detalhadas dos requisitos de usurio. Eles podem servir de base a um
contrato destinado implementao do sistema e, portanto deve ser uma
especificao completa e consistente do sistema. Ex.: Sistemas redundantes
com tolerncia a falhas em RAID 5, utilizao de cdigo aberto grtis PHP e
MySQL em ambiente Linux.

6.2 Discuta o problema de usar linguagem natural para definir os

requisitos do usurio e do sistema e mostre, usando pequenos exemplos,
porque que a estruturao da linguagem natural em formulrios pode
ajudar a evitar algumas destas dificuldades.
Tipos de Notaes para especificao requisitos: Linguagem natural
estruturada Definio de formulrios standard ou templates para exprimir a
especificao dos requisitos. Linguagens de descrio de design Utiliza uma
espcie de linguagem de programao mas com conceitos abstractos. No
muito utilizada, a no ser para especificar interfaces. Notaes grficas Uma
linguagem grfica com anotaes em texto. utilizada para definir
requisitos funcionais para o sistema. So exemplos comuns as descries
use-case e diagramas de sequncia. Especificaes matemticas Notaes
baseadas em conceitos matemticos como mquinas de estado finitas. Esta
especificao reduz os argumentos com o cliente sobre a funcionalidade de
sistema. Dificulta no entanto a compreenso por parte docliente, podendo
este recusar-se a aceitar essa especificao como contracto do sistema.

Dificuldades: Ambiguidade da linguagem natural A interpretao da

linguagem natural depende de quem a l ou a escreve, o que pode levar a
mal entendidos no significado dos requisitos. Excesso de flexibilidade Um
mesmo requisito pode ser identificado de diversas maneiras diferentes,
levando a confuso se os requisitos so os mesmos ou diferentes.
Dificuldade a modular Sendo a linguagem difcil de modular, difcil
relacionar os requisitos entre si de forma a verificar as consequncias de
uma mudana.

Ex.: Dicionrio de requisitos, em todos os stios na documentao e no

programa determinado requisito referenciado da mesma forma. Template
ou formulrio para preenchimento de cada requisito (Descrio da funo,
inputs/outpus, origem/destino, pr/ps condies).

6.3 - Descubra ambiguidades ou omisses na seguinte afirmao de

requisitos de uma parte de um sistema de emisso de bilhetes. Um sistema
automtico de emisso de bilhetes vende bilhetes de comboio. Os usurios
seleccionam o seu destino e introduzem um carto de crdito e um nmero
de identificao pessoal. O bilhete de comboio emitido e a conta deles de
carto de crdito cobrada. Quando o usurio pressiona o boto de incio,

mostrado um menu que mostra os possveis destinos, junto com uma

mensagem para o usurio que lhe indica para seleccionar um destino. Uma
vez que se seleccionou um destino, pede aos usurios que introduzam o
carto de crdito. A sua validade verificada e pedido ao usurio para
introduzir um identificador pessoal. Quando a transaco de crdito
forvalidada, o bilhete emitido.
Ambiguidades S cartes de crdito ou tambm de dbito? Bancrio
ou interno? N de identificao pessoal = identificador pessoal? (Conta de
carto de crdito cobrada = transaco de crdito validada?) O que faz 1?
Depois da transaco que emite o bilhete, no antes!
Omisses Tipos de bilhetes? Tipos de comboios? Quais os destinos?
Nmero de identificao pessoal de qu? Do carto? Ecr inicial (Incio)
aparece por defeito a escolha de destino? Onde fica o boto de incio?
Validar antes de inserir um identificador pessoal? No descreve quando e
como solicitado o cdigo pessoal ao utilizador. No descreve como o
sistema deve reagir a um carto ou cdigo pessoal no vlido. No define
como devolvido o carto ao utilizador.

6.4 Volte a escrever a descrio anterior utilizando a aproximao

estruturada descrita neste captulo. Resolva de forma apropriada as
ambiguidades identificadas. Pretende-se o desenvolvimento de um sistema
automtico de venda de bilhetes de comboio. Para iniciar a utilizao do
sistema o utilizador dever premir o boto incio, activando o menu de
destinos possveis associado a uma mensagem que lhe indicar que deve
seleccionar o destino pretendido. Aps a seleco do destino pretendido, o
sistema pede ao utilizador para inserir o carto de crdito na ranhura
existente para o efeito mediante a apresentao de uma mensagem no
ecr. De seguida, o sistema solicitar a introduo do cdigo pessoal
mediante a apresentao de uma mensagem. Aps a introduo do cdigo
pessoal pelo utilizador, recorrendo ao teclado existente no dispositivo, o
sistema comprovar a validade docarto. Se o carto ou cdigo pessoal no
for vlido, o sistema apresentar a mensagem de Carto no vlidoe
expelir o carto. Se o carto e cdigo pessoal estiverem correctos, o
sistema iniciar a transaco. Terminada a transaco, o sistema devolver
o carto ao utilizador apresentando a seguinte mensagem: Retire o carto
por favor. Aps o utilizador retirar o carto do sistema, ser impresso o
bilhete e expedido pela respectiva ranhura, apresentando uma mensagem
de convite ao utilizador para retirar o bilhete. Retirado o bilhete, termina a
operao e o sistema volta ao estado de incio, aguardando que novo
utilizador pressione no respectivo boto.
6.7 Descreva 4 tipos de requerimentos no funcionais que podem existir
em um sistema. De exemplos de cada um destes tipos de requerimentos.
Requisitos de produtos Requisitos que especificam o comportamento do
produto. Ex.: Os requisitos de desempenho sobre com que rapidez o sistema

deve operar e quanta memria ele requer, os requisitos de confiabilidade,

que estabelecem a taxa aceitvel de falhas, os requisitos de portabilidade e
os requisitos de facilidade de uso. Requisitos organizacionais procedentes
de polticas e procedimentos nas organizaes do cliente e do
desenvolvedor. Ex.: Os padres de processo que devem ser utilizados, os
requisitos de implementao, como a linguagem de programao ou o
mtodo de projecto utilizado, e os requisitos de fornecimento, que
especificam quando o produto e seus documentos devem ser entregues.
Requisitos externos Abrange todos os requisitos procedentes de factores
externos ao sistema e a seu processo de desenvolvimento. Ex.: Os
requisitos de interoperabilidade, que definemcomo o sistema interage com
sistemas noutras organizaes, 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 so definidos num sistema para garantir que este
ser aceitvel para os seus utilizadores e o pblico em geral).

6.10 Voc aceitou um trabalho com um utilizador de software que

contratou anteriormente o seu antigo empregador para desenvolver um
sistema. Voc descobre que a interpretao de sua empresa dos requisitos
diferente da interpretao feita pelo seu antigo empregador. Discuta o que
deve fazer nesta situao. Voc sabe que os custos para o seu actual
empregador vo aumentar se as ambiguidades no forem resolvidas. Tem
tambm uma responsabilidade de confidencialidade para com seu
empregador anterior.
Tentava resolver as ambiguidades sem revelar informao confidencial.
Exerccios Pg.167
7.1 Sugira quem podem ser os stakeholders num sistema de registo de
estudantes numa universidade. Explique por que quase sempre inevitvel
que os requisitos de diferentes stakeholders sejam, de alguma maneira,
conflituosos. Os stakeholders no sabem o que querem do sistema a
no ser num carcter geral. Podem ter dificuldades a verbalizar o que
querem ou fazem exigncias irrealistas pois no tm noo dos custos.
Cada stakeholder expressa requisitos baseados no seu conhecimento
especfico do negcio, tendo estes que ser integrados no todo.
Stakeholders diferentes tm requisitos diferentes que expressam de
maneira diferente. Factores polticos influenciam o design do sistema, por
exemplo, gestores que requerem algo especfico paraaumentar a sua
influncia na organizao. O ambiente onde o sistema se integra
dinmico, os requisitos podem variar durante a sua avaliao e entrada de
novos stakeholders que no foram consultados.

7.6 Discuta o exemplo de um tipo de sistema em que os factores sociais e

polticos podem influenciar fortemente os requisitos do sistema. Explique
porque que esses factores so importantes no seu exemplo. Mudanas
legislativas originam requisitos novos. Ex: mudana do IVA Escutas
autorizadas na Internet. Projectos internacionais questes lingusticas,
dicionrios e adaptar a cada pas.
Polticas da empresa barrar sites, acessos, ver produes dos empregados.
7.7 Quem deve estar envolvido em uma reviso de requisitos? Desenhe
um modelo de processo mostrando como uma reviso de requisitos pode
ser organizada. Os requisitos devem ser analisados sistematicamente pela
equipa de revisores.
um processo manual, que envolve muitos leitores, tanto do pessoal do
cliente como do fornecedor, que verifica o documento de requisitos a fim de
detectar anomalias ou omisses. (pode e deve envolver todos os
stakeholders do sistema)
Como alternativa, esse processo pode ser organizado em maior escala, com
muitos participantes envolvidos na verificao de diferentes partes do
documento.
As revises de requisitos podem ser formais ou informais.
As informais simplesmente envolvem os fornecedores/desenvolvedores que
discutem os requisitos com tantos stakeholders qt possvel .
Na formal a equipe de desenvolvimento deve conduzir o cliente pelos
requisitos do sistema. Explicando as implicaes de cada um.
7.8 Porque que as matrizes defacilidade de rastreio se tornam difceis de
gerir quando existem muitos requisitos de sistema? Projecte um mecanismo
de estruturao de requisitos, com base em pontos de vista, que possa
ajudar a reduzir a escala desse problema. Existem muitas relaes entre
requisitos e outros requisitos e entre os requisitos e o design Quando so
propostas modificaes preciso verificar o impacto dessas mudanas
sobre outros requisitos e o design do projecto.
A facilidade de rastreio uma propriedade geral de uma especificao de
requisito e reflecte a facilidade de se encontrar requisitos relacionados.
Existem 3 tipos de informaes sobre a facilidade de rastreio , que podem
ser mantidas.
1- Informaes sobre a facilidade de rastreio da origem vinculam os
requisitos aos stakeholders que propuseram esses requisitos. 2- Informaes

sobre a facilidade de rastreio de requisitos vinculam requisitos dependentes

dentro de seu respectivo documento. 3- Informaes sobre a facilidade de
rastreio de design vinculam os requisitos aos mdulos de design em que
esses requisitos so implementados.
As informaes sobre a facilidade de rastreio so, frequentemente
representadas com o uso de matrizes de facilidade de rastreio. Estas
relacionam os requisitos aos stackeholders , os requisitos entre si ou aos
mdulos de design .
As matrizes de facilidade de rastreio podem ser utilizadas quando um
pequeno numero de requisitos precisa de ser gerido, mas elas tornam-se
muito difceis de serem manuseadas e so de manuteno dispendiosa em
grandes sistemas com muitos requisitos.
Para esses sistemas temos de obter as informaes da facilidade de rastreio
em base de dados de requisitos ,em que cada requisito explicita/
vinculado a requisitos relacionados. O impacto das mudanas pode ser
avaliado pelo uso dos recursos de visualizao das bases de dados. Como
alternativa, pode ser possvel gerar as matrizes de facilidade de rastreio
automtica/.
A gesto de requisitos precisa de algum apoio automatizado e as
ferramentas CASE devem ser usadas em :
1- armazenaneto de requisitos 2- gesto de mudanas 3- gesto de
facilidade de rastreio
mecanismo de estruturao de requisitos, com base em pontos de vista
mesmo para um sistema relativa/ simples existem muitos pontos de vista
diferentes que devem ser considerados. Os diferentes pontos de vista a
respeito de um problema vem o problema de modos diferentes. Contudo,
suas perspectivas no so inteiramente independentes, tem alguma
duplicidade, e apresentam requisitos comuns. A abordagem orientada aos
pontos de vista e usada para estruturar e organizar o processo de
levantamento de requisitos.
Os estgios do VORD (viewpoint oriented requiremens definition )
1- Identificao dos pontos de vista- descobrir os pontos de vista e
respectivos servios 2- Estruturao de pontos de vista- agrupar pontos de
vista relacionados segundo uma hierarquia 3- Documentao de ponto de
vista refinar a descrio 4- Maneamentos de sistema de ponto de vista
envolve identificar objectos em um design orientado a objectos, utilizando
informaes de servio que esto encapsuladas nos pontos de vista
Exerccios Pg.214
9.2 Num sistema de bomba de insulina, o usurio tem de modificar a
agulha e a proviso de insulina regularmente e tambm pode modificar a

dose nica mxima e o mximo dirio que pode seradministrado. Sugira

trs erros de usurios que poderiam ocorrer e propor exigncias de
segurana que evitariam esses erros que resultam em um acidente
9.3- Um sistema de software seguro e crtico para o tratamento de doentes
com cancro tem dois componentes principais:
A mquina de radioterapia que administra doses controladas de radiao
aos stios do tumor. Esta mquina controlada por um sistema de software
embebido.
Uma base de dados de tratamentos que inclui os detalhes do tratamento
dado a cada paciente. Os requerimentos do tratamento so introduzidos
nesta base de dados e automaticamente se descarregam na mquina de
radioterapia.
Identifique trs contingncias que podem surgir neste sistema. Para cada
contingncia sugira um requerimento defensivo que reduza a probabilidade
de que estas contingncias provoquem um acidente. Explique porque que
a defesa sugerida por voc provvel que reduza o risco associado a
contingncia.
Anexo:
Software development process
Activities and steps Requirements | Architecture | Design | Implementation |
Testing | Deployment Models Agile | Cleanroom | Iterative | RAD | RUP |
Spiral | Waterfall | XP | Scrum Supporting disciplines Configuration
management | Documentation | Software quality assurance (SQA) | Project
management | User experience design
Some software development methods: Waterfall model Spiral model
Model driven development User experience Top-down and bottom-up design
Chaos model Evolutionary prototyping Prototyping ICONIX Process (UMLbased object modeling with use cases) Unified Process V-model Extreme
Programming Software Development Rhythms Incremental funding
methodology