'

Requisitos de Software

Requisito condio necessria para a obteno de certo objetivo ca a ca ou para o preenchimento de certo m. Requisitos para um sistema de software descrio das funes e restries que o produto a ser ca co co desenvolvido deve possuir. Engenharia de Requisitos processo de descobrir, analisar, documentar e vericar essas funes e restries. co co
1

&

'

Tipos de Requisitos 1. Do usurio: declaraes, em l a co ngua natural e/ou diagramas, sobre as funes que o sistema deve fornecer co e restries sob as quais deve operar. So requisitos co a abstratos de alto n vel. 2. Do sistema: funes e restries do sistema, de uma co co forma mais detalhada. Normalmente classicados como funcionais e no funcionais. a
&

'

Requisitos funcionais Diretamente ligados ` funcionalidade do software, como a o sistema deve reagir ` entradas espec a cas, como deve se comportar em determinadas situaes. co Em alguns casos podem declarar o que o sistema no a deve fazer. Dependem do tipo de sistema a ser desenvolvido e dos usurios. a
&

'

Exemplo: Sistema de biblioteca de universidade permite pedir livros e documentos a outras universidades. (a) buscar todo o conjunto inicial no banco de dados ou selecionar um subconjunto; (b) fornecer telas apropriadas para ler documentos no repositrio de documentos; o (c) alocar um unico identicador a cada pedido.
&

'

Requisitos funcionais (cont.) (a) descritos em diferentes n veis de detalhes (telas apropriadas = diferentes formatos); (b) documento completo e consistente, mas na prtica a e quase imposs atingir essa meta. vel (c) ` medida que os problemas so descobertos, o a a documento de especicao deve ser corrigido. ca

&

'

Requisitos no funcionais a No dizem respeito diretamente `s funes espec a a co cas do sistema. Podem estar relacionados `s propriedades do sistema a como conabilidade, tempo de resposta, restries sobre co o processo, padres, etc. o

&

'

&

Exemplos: (a) dependendo do resultado do teste, somente o supervisor pode efetuar a entrada do resultado do teste de um paciente. (b) o sistema deve emitir um recibo para o cliente at e oito segundos aps a transao. o ca (c) um sistema de aviao deve atender ao requisito de ca conabilidade. (d) um sistema de tempo real deve atender ao requisito de desempenho; do contrrio as funes de controle no a co a operaro corretamente. a (e) tipos de ferramentas CASE e descrio do processo ca a ser seguido.
7

'

Requisitos no funcionais (cont.) a

1. Requisitos do produto: comportamento do produto desempenho, memria, conabilidade (taxa aceitvel de o a falha), portabilidade e facilidade de uso; 2. Requisistos organizacionais: pol ticas e procedimentos nas organizaes do cliente e do desenvolvedor co padres de processo, requisitos de implementao o ca (linguagem ou mtodo de projeto) e requisitos de e entrega (do produto e documentos associados); 3. Requisitos externos: fatores externos ao sistema e ao processo de desenvolvimento - interoperabilidade (com outros sistemas), requisitos legais, requisitos ticos. e
8

&

'

Objetivo do sistema versus requisitos vericveis a Objetivo: O sistema deve ser fcil de utilizar por a controladores experientes e deve ser organizado de modo que os erros dos usurios sejam minimizados; a Requisito vericvel: Controladores experientes devem a ser capazes de utilizar todas as funes do sistema co depois de duas horas de treinamento. O nmero mdio u e de erros cometidos por usurios experientes no deve a a exceder a dois por dia.
&

'

Requisitos de dom nio Tem origem no dom de aplicao e reetem nio ca caracter sticas desse dom nio; Podem ser novos requisitos funcionais, podem restringir requisitos funcionais existentes, ou ainda estabeler como realizar clculos espec a cos.

&

10

'

Exemplo para o sistema de biblioteca: 1. Deve haver uma interface padro com o usurio para a a todos os bancos de dados, que ter como base o a padro X. a 2. Em razo das restries referentes a direitos autorais, a co alguns documentos devem ser imediatamente exclu dos aps serem fornecidos. o 3. Alguns documentos sero impressos localmente no a servidor do sistema para serem encaminhados ao usurio ou direcionados para uma impressora de rede. a
&

11

'

Requisitos do usurio a Devem descrever os requisitos funcionais e no a funcionais de modo compreens pelos usurios sem vel a conhecimento tcnico detalhado. e Devem especicar o comportamento externo do sistema, evitando caracter sticas de projeto. Podem ser escritos em l ngua natural, formulrios e a diagramas intuitivos simples.
&

12

'

Problemas com uso de l ngua natural 1. Falta de clareza: ambigidade e falta de preciso, dando u a origem a um documento de dif leitura; cil 2. Confuso: os requisitos funcionais e no funcionais, os a a objetivos do sistema e as informaes sobre o projeto co podem no estar claramente denidos; a 3. Fuso de requisitos: vrios requisitos diferentes podem a a ser expressos juntos, como um unico requisito.
&

13

'

Documento de Especicao de Requisitos ca Declarao ocial do que exigido dos desenvolvedores ca e do sistema. Inclui os requisitos do usurio para um sistema e uma a especicao detalhada dos requisito do sistema. ca O documento tem um nmero diversicado de usurios: u a

&

14

'

Doc. de Requisitos de Software (cont.)

(a) Clientes do sistema: especicam e vericam se os requisitos atendem as suas necessidades; tambm e especicam mudanas; c (b) Gerentes: usam o documento para planejar o processo de desenvolvimento; (c) Engenheiros de software: compreender que sistema dever ser desenvolvido; a (d) Engenheiros de teste: desenvolver testes de validao do sistema; ca (e) Engenheiros de manuteno: compreender o sistema ca e as relaes entre suas partes. co
15

&

'

Documento de Especicao de Requisitos de ca Software 1. Introduo: Descreve os objetivos do sistema, suas ca funes e explica como ele deve operar com outros co sistemas. Descreve tambm como o sistema se ajusta e aos objetivos estratgicos da organizao que est e ca a encomendando o software. 2. Glossrio: Dene os termos tcnicos utilizados no a e documento. No se deve fazer suposies sobre a a co experincia ou conhecimento do leitor. e
&

16

'

Documento de Especicao de Requisitos ca (cont.) 3. Denio dos requisitos do usurio: Descreve os ca a servios fornecidos para o usurio e os requisitos no c a a funcionais do sistema. Pode-se utilizar l ngua natural, diagramas ou outras notaes que sejam compreendidas co pelos clientes.

&

17

'

4. Especicao dos requisitos do sistema: ca Descreve os requisitos funcionais e no funcionais com a mais detalhes. Podem ser denidas interfaces, isto , e como o software interage com as pessoas, com o hardware do sistema, com outros sistemas e com outros produtos. As restries impostas pela aplicao, tais co ca como padres, linguagem de implementao, ambientes o ca operacionais e limites de recursos tambm so descritas. e a

&

18

'

5. Evoluo do sistema: Descreve as suposies ca co fundamentais nas quais o sistema se baseia e as mudanas previstas devido ` evoluo do hardware, c a ca mudanas nas necessidades do usurio, etc. c a 6. Anlise de risco: Dene os pontos de risco e as a aes a serem contempladas para evitar ou minimizar co impacto dos riscos. 7. Anexo: Descreve todos os recursos e tcnicas e utilizados para a o levantamento de requisitos, assim como as questes feitas e o nome das pessoas o envolvidas.
&
19

'

Processos da Engenharia de Requisitos 1. Estudo de viabilidade 2. Levantamento e anlise dos requisitos a 3. Validao dos requisitos ca 4. Gerenciamento dos requisitos

&

20

'

Estudo de viabilidade O estudo de viabilidade permite que se decida se vale a pena desenvolver o sistema proposto. O sistema contribui para os objetivos da organizao? ca Pode ser implementado com a tecnologia atual e dentro do oramento? c Pode ser integrado com outros sistemas em operao? ca
&

21

'

Estudo de viabilidade (cont.) O que aconteceria se o sistema no fosse a implementado? Quais os problemas com os processos atuais? Como o sistema proposto ir ajudar? a Pode haver troca de informaes entre outros sistemas co e o sistema proposto?
&

22

'

Levantamento e anlise dos requisitos a

Desenvolvedores trabalham com o cliente e usurios a nais para descobrir mais informaes sobre o dom co nio da aplicao, servios, desempenho, restries de ca c co hardware, etc. Envolve diferentes tipos de pessoas. Stakeholder: qualquer pessoa com alguma inuncia, e direta ou indireta, sobre os requisitos. Exemplo: usurios nais, todo pessoal afetado pelo a sistema; desenvolvedores, mantenedores de sistemas relacionados, gerente de negcios, especialistas no o dom nio, etc.
23

&

'

Problemas com o levantamento 1. Os usurios muitas vezes no sabem o que querem, a a a no ser em termos muito gerais: podem achar dif a cil articular o que desejam do sistema, fazer pedidos no a realistas. 2. Os usurios expressam os requisitos em seus prprios a o termos e com conhecimento impl cito de sua rea de a atuao. Engenheiros de requisitos devem entender ca esses requisitos.
&

24

'

Problemas com o levantamento (cont.) 3. Diferentes usurios tem em mente diferentes requisitos a e podem express-los de maneira distinta. Os a engenheiros de requisitos devem descobrir todas as fontes poss veis e encontrar pontos comuns e conitos. 4. O ambiente econmico e de negcios dinmico e se o o e a modica durante o processo de anlise a importncia a a dos requisitos pode mudar, novos requisitos podem surgir.
&

25

'

O processo de levantamento de requisitos

1. Compreenso do domnio: documentos, livros, a sistemas, pessoas. Exemplo: sistema de biblioteca entender com funcionam as bibliotecas. 2. Coleta e anlise de requisitos: descoberta, revelao e a ca entendimento dos requisitos, atravs de interao entre e ca clientes, usurio(s) e desenvolvedores envolvendo: a a descoberta, classicao e organizao dos ca ca requisitos; a determinao de suas prioridades; ca resoluo de inconsistncias e conitos; e ca e
&

descoberta de omisses. o
26

'

O processo de levantamento de requisitos (cont.) 3. Especicao dos requisitos: armazenamento dos ca requisitos em uma ou mais formas, incluindo l ngua natural, linguagem semiformal ou formal, representaes co simblicas ou grcas (casos de uso, por exemplo); o a 4. Validao dos requisitos: vericao dos requisitos, ca ca visando determinar se esto completos e condizentes a com as necessidades e desejos do usurio. a
&

27

'

Definicao e especificacao
Validacao

Compreensao Entrada do Dominio Coleta de Requisitos Classificacao

&

Prioridades

Resolucao Conflitos

28

'
Especificacao de requisitos de sistema e modelagem Especificacao de requisitos de usuario Especificacao de requisitos de negocio Elicitacao de requsitos de usuario Especificacao de requisitos

Elicitacao de requisitos de sistema

Estudo de viabilidade Prototipacao

Revisoes

&

Elicitacao de requisitos

Validacao de requisitos

Documento de requisitos do sistema

29

'

Descrio de um sistema hospitalar ca

Gostaria que fosse constru do um sistema para monitorar a temperatura e a pressao de pacientes da UTI, que deverao ficar ` ligados on-line a rede de computadores do hospital, que formada por um computador e principal e varios terminais que monitoram os pacientes. Se a temperatura ou pressao do paciente lida pelo terminal se tornarem cr ticas, o computador principal devera mostrar uma tela de alerta com um historico das medidas realizadas para o
&

paciente.
30

'

Descrio de um sistema hospitalar (cont.) ca

Um aviso sonoro deve ser ativado nesse e caso. A verificacao da pressao feita comparando-se a pressao do paciente com um valor padrao de pressao (maximo e m nimo) a ser digitado pelo responsavel e verificando-se se a pressao medida esta dentro dos parametros considerados normais para o paciente (valores proximos ao maximo e m nimo sao permitidos). Temos varios sistemas on-line no computador e
&

todos devem rodar ao mesmo tempo.

31

'

Funoes: c monitorar temperatura e presso; e a apresentar uma tela de alerta com o histrico de o medidas. Restrioes: c o sistema deve ser on-line; deve rodar ao mesmo tempo que outros controle de concorrncia; e e o aviso de temperatura e presso cr a ticas deve ser sonoro.
32

&

'

Ambigidades no sistema hospitalar u

Se a temperatura ou presso do paciente lida pelo a terminal se tornarem crticas, o computador principal dever mostrar uma tela de alerta com a um histrico das medidas realizadas para o o paciente. Um aviso sonoro deve ser ativado nesse caso. Duas interpretaes: co 1. o terminal ativar um aviso sonoro e/ou a 2. o computador principal ativar um aviso sonoro? a
&

3. Pode ser integrado com outros sistemas em operao? ca

33

'

Omisses do sistema hospitalar o A vericao da presso feita comparando-se a ca a e presso do paciente com um valor padro de presso a a a (mximo e mnimo) a ser digitado pelo responsvel a a e vericando-se se a presso medida est dentro dos a a parmetros considerados normais para o paciente a (valores prximos ao mximo e mnimo so o a a permitidos). (a) valores poss veis para mximo e m a nimo? (b) mximo < m a nimo? (c) intervalo fora de um valor normal?
&

(d) o que signica valores prximos? o

34

'

Mudanas nos requisitos acontecem na maioria dos c sistemas complexos. embora muitas delas sejam devidas a mudanas das c necessidades dos usurios, outras advm da a e interpretao incorreta dos requisitos do produto a ser ca desenvolvido. requisitos incompletos, incorretos ou mal entendidos sao as causas mais frequentes da baixa qualidade, ultrapassagem dos custos previstos e atraso na entrega do produto de software.
&
35

'

Brainstorming Tcnica bsica para gerao de idias. e a ca e Uma ou vrias reunies que permitem que as a o pessoas sugiram e explorem idias sem que sejam e criticadas ou julgadas. Existe um lder cujo papel fazer com que a sesso e a comece, sem restringi-la.

&

36

'

Especialmente util no comeo do processo de extrao c ca de requisitos pois: ausncia de cr e tica e julgamento ajuda a eliminar algumas das diculdades inerentes ao processo. evita a tendncia a limitar o problema muito cedo. e fornece uma interao social mais confortvel do que ca a algumas tcnicas de grupo mais estruturadas. e pode ser aprendida, com muito pouco investimento. Desvantagem: por ser um processo relativamente no a estruturado, pode no produzir a mesma qualidade ou a n de detalhe de outros processos. vel
37

&

'

1. Gerao de idias ca e

Participantes fornecem idias, sem discusso sobre o e a mrito delas. e Util na gerao de vrias vises do problema e na sua ca a o formulao de diferentes maneiras. ca Atividades dessa fase: identicao dos participantes (normalmente ca usurios e desenvolvedores); a designao do l ca der; agendamento da sesso com todos os participantes; a e
&

preparao da sala. ca
38

'

Gerao de idias (cont.) ca e Sa da: depende das idias geradas (pessoas com e conhecimento e especialidades apropriados). L abre a sesso falando sobre o problema de um der a modo geral, e os participantes podem gerar novas idias e para expressar o problema. Continua enquanto novas idias estiverem sendo e geradas.
&

39

'

Gerao de idias (cont.) ca e Quatro regras: 1. terminantemente proibido criticar as idias; e e 2. idias no convencionais ou estranhas so e a a encorajadas; 3. o nmero de idias geradas deve ser bem grande; e u e 4. os participantes devem ser encorajados a combinar ou enriquecer as idias de outros (idias vis e e veis).
&

40

'

Gerao de idias (cont.) ca e A fase de gerao pode terminar de duas maneiras: ca 1. se o l acreditar que no esto sendo geradas der a a idias sucientes. e 2. se tiverem sido geradas e registradas idias e sucientes.

&

41

'

2. Consolidao das idias ca e Idias so discutidas, revisadas, organizadas e avaliadas. e a Algumas idias so refraseadas. e a Quando duas ou mais idias so consideradas iguais, so e a a combinadas e reescritas para capturar a sua essncia. e Os participantes podem concordar em que algumas das idias so muito esquisitas e descart-las. e a a
&

42

'

Consolidao das idias (cont.) ca e

Idias remanescentes so discutidas e classicadas em e a ordem de prioridade. Freqentemente necessrio identicar: u e a requisitos absolutamente essenciais; aqueles que so bons, mas no essenciais; e a a aqueles que seriam apropriados para uma verso a subseqente do software. u O l ou outra pessoa designada produz um registro der das idias remanescentes, juntamente com suas e prioridades ou outros comentrios relevantes. a
43

&

'

Levantamento orientado a pontos de vista H diferentes tipos de usurio nal, com diferentes a a interesses. Exemplo: Sistema de caixa automtico de um banco a (ATM): 1. Clientes do banco: recebem servios do sistema; c 2. Representantes de outros bancos: acordos de reciprocidade que permitem utilizar ATMs uns dos outros;
&

44

'

3. Gerentes de agncias bancrias: obtm informaes do e a e co sistema; 4. Equipes de atendimento de balco: envolvidas nas a operaes dirias do sistema, reclamaes de clientes co a co etc; 5. Administradores de bancos de dados: responsveis pela a integrao do sistema com o banco de dados do cliente ca do banco;
&

45

'

6. Gerentes de segurana bancria: que devem garantir que c a o sistema no apresente nenhuma falha de segurana; a c 7. Departamento de marketing: interessado em utilizar o sistema como instrumento de marketing do banco; 8. Engenheiros de manuteno de hardware e software: ca fazer a manuteno do hardware e do software. ca

&

46

'

Pontos de vista - Vantagens

1. Como os pontos de vista so externos ao sistema, so a a uma maneira natural de estruturar o processo de levantamento de requisitos. 2. E relativamente fcil decidir se alguma coisa um a e ponto de vista vlido. Os pontos de vista devem a interagir com o sistema de alguma maneira. 3. Os pontos de vista e os servios so um meio util de c a estruturar os requisitos no funcionais. Cada servio a c pode ter requisitos no funcionais associados. Os a pontos de vista permitem que o mesmo servio tenha c diferentes requisitos no funcionais. a
47

&

'

Denio de requisitos orientada a ponto de vista ca 1. Identicao dos pontos de vista: descobrir os pontos ca de vista que utilizam quais servios espec c cos. 2. Estruturao dos pontos de vista: agrupar pontos de ca vista relacionados, segundo uma hierarquia. Servios c comuns localizados no n mais alto e herdados por vel pontos de vista de n inferior. vel

&

48

'

3. Documentao do ponto de vista: renar a descrio ca ca dos pontos de vista e servios identicados. c 4. Mapeamento do sistema conforme pontos de vista (identicar objetos, utilizando informaes de servio co c encapsuladas nos pontos de vista).

Identificacao

Estruturacao

Documentacao

Mapeamento

&

49

'

Usa formulrios-padro para pontos de vista e servios. a a c Exemplo: ATM - sistema de software embutido, destinado a dirigir o hardware e se comunicar com a central de dados do banco.

&

50

'

Aceita solicitaes do cliente e fornece dinheiro, co informaes sobre conta, atualizao de informaes, co ca co etc. Clientes podem fazer retiradas, pagamentos, conferir saldos transferir dinheiro de uma conta para outra, pedir extrato, talo, etc. a Mquinas de um banco podem permitir que clientes de a outros bancos utilizem um subconjunto de seus recursos (retirada em dinheiro e consulta a saldo).
&

51

'

Templates
Template de servico Referencia: Nome do servico Razao: razao pela qual o servico e oferecido Especificacao: lista de especificao de servicos Pontos de vista: que recebem o servico Requisitos nao funcionais: restricoes ao servico Provedores: objetos que fornecem o servico

Template de ponto de vista Referencia: Nome do ponto de vista Atributos: Informacoes sobre o ponto de vista Eventos: Estimulos externos gerados pelo ponto de vista Servicos: O que o sistema oferece Subpontos de vista: Nomes dos pontos de vista associados

&

52

'
Consulta de saldo Banco de dados do cliente Retirada de Dinheiro Caixa de banco

Obtencao transacoes

Confiabilidade

Gerente Nao titular da conta

Transferir fundos

Titular da conta Manutencao de hardware

Seguranca

Pedido de cheques

&

53

'

Informacoes de servicos para os pontos de vista

TITULAR DA CONTA Lista de Servicos NAOTITULAR DA CONTA Lista de Servicos Retirar dinheiro Consultar saldo

Retirar dinheiro Consultar saldo Pedir cheques Pedir extrato Transferir fundos

&

54

'

Dados de ponto de vista e informacoes de controle

TITULAR DA CONTA Entrada de controle Iniciar transacao Cancelar transacao Encerrar transacao Selecionar servico Entrada de dados Detalhes do cartao PIN Quantia solicitada Mensagem

&

55

'
Todos os pontos de vista Servicos Consultar saldo Retirar dinheiro Cliente Pessoal do banco

Titular Servicos Pedir cheque Pedir extrato Transferir fundo

Naotitular

Caixa

Gerente

Eng.

&

56

'

Ponto de vista cliente e retirada de dinheiro

Referencia: Cliente Atributos: n. conta PIN inicio da transacao Eventos: selecionar servico cancelar transacao encerrar transacao Servicos: retirar dinheiro consultar saldo Subpontos : titular nao titular de vista Referencia: retirar dinheiro Razao: melhorar o servico Especificacoes: pressionar botao de retirada; em seguida informar quantia solicitada; operacao con firmada se houver saldo Ponto de vista: cliente Req. n. funcional: entregar o dinheiro um minuto apos confirmada quantia Provedor: preenchido posteri ormente

&

57

'

Cenrios a Mostram como as pessoas interagiriam com o sistema. Adicionam detalhes a uma descrio de requisitos. ca Descries de exemplos de sesses de interao. co o ca Cada cenrio: uma ou mais interaes. a co Diferentes cenrios: diferentes tipos de informao a ca sobre o sistema, em diferentes n veis de detalhe.
&

58

'

Cenrios (cont.) a Um cenrio deve incluir: a * uma descrio do estado do sistema no in do ca cio cenrio. a * o uxo normal de eventos no cenrio. a * o que pode dar errado e como isso tratado. e * outras atividades que podem ocorrer simultaneamente. * o estado do sistema no m do cenrio. a Podem ser descritos na forma de texto, diagramas, imagens de computador etc.
&

59

'

Cenrio do evento: iniciar transao a ca Quando o carto inserido, o nmero de identicao a e u ca pessoal (PIN) solicitado. e O cliente insere o carto e seu PIN. a Se o carto for vlido, ele poder ser processado pela a a a mquina e o controle poder passar para o prximo a a o estgio. a

&

60

'

Cenrio do evento: trs exceoes a e c 1. Tempo esgotado: o cliente pode no fornecer o PIN a dentro do limite de tempo permitido e o carto a e devolvido. 2. Carto invlido: o carto no reconhecido e a a a a e e devolvido. 3. Carto roubado: o carto reconhecido como roubado a a e e retido pela mquina. a
&

61

'
Cartao

Cartao presente Solicitar PIN

Cartao valido

Usuario OK PIN Numero da conta PIN Validar usuario Tempo esgotado Devolver cartao Cartao invalido Devolver cartao Cartao roubado Reter cartao Novamente PIN incorreto Devolver cartao PIN incorreto Informar PIN

Numero da conta Selecionar servico

&

62

'

Cenrio do evento: Imprimir cpia de artigo a o

Cpias gratuitas para assinantes e pagas para no o a assinantes. T tulo e data de publicao conhecidos. ca Hiptese inicial: Usurio se conectou ao sistema e o a localizou a revista que contm artigo. e Normal: Usurio seleciona artigo. a Sistema solicita informaes sobre assinatura, ou forma co de pagamento (carto de crdito ou depsito em conta). a e o
&

Usurio deve preencher formulrio de direitos autorais e a a envi-lo ao sistema de biblioteca. a

63

'

O formulrio vericado e, se aprovado, a verso pdf a e a do artigo baixada na rea de trabalho do usurio, que e a a avisado. e Usurio deve selecionar uma impressora e a cpia do a o artigo impressa. e Se o artigo estiver marcado como apenas impresso, a ele ser apagado do sistema do usurio aps o trmino a a o e da impresso. a
&

64

'

O que pode dar errado: O usurio pode no a a preencher o formulrio de direitos autorais corretamente a e o formulrio deve ser apresentado ao usurio para a a correo. ca Se ainda estiver incorreto, a solicitao do usurio ser ca a a rejeitada. O pagamento pode ser rejeitado; nesse caso, a solicitao tambm ser rejeitada. ca e a
&

65

'

O download pode falhar; nesse caso o sistema tenta novamente at conseguir, ou at que o usurio termine e e a a sesso. a Pode no ser poss imprimir. Se o artigo no estiver a vel a marcado apenas para impresso, ele ser mantido na a a rea de trabalho; caso contrrio, ele ser apagado e o a a a custo debitado da conta do usurio. a

&

66

'

Outras atividades: Downloads simultneos de a outros artigos. Estado do sistema aps o trmino: o e Usurio conectado; o artigo baixado teria sido apagado, a caso estivesse marcado como apenas para impresso. a

&

67

'

Entrevistas

Srie de encontros com os usurios que explicam: e a o seu trabalho; o ambiente no qual atuam; as suas necessidades etc. Tcnica estruturada, que pode ser aprendida e na qual e os desenvolvedores podem ganhar procincia. e Requer o desenvolvimento de algumas habilidades sociais gerais: habilidade de ouvir; e
&

conhecimento de uma variedade de tticas de a entrevista.

68

'

Fases da Entrevista 1. Planejamento da entrevista; 2. Conduo da entrevista; e ca 3. Finalizao. ca

&

69

'

Planejamento da entrevista Ler material dispon vel Estabelecer objetivo da entrevista: freqncia dos servios do novo sistema ue c previsibilidade dos servios c atualidade dos dados Decidir quem ser entrevistado a incluir uma pessoa-chave de cada n afetado vel pedir ajuda na empresa para a escolha de pessoas
&

70

'

Planejamento da entrevista (cont.) Preparar os entrevistados avisar a data e durao ca comunicar o assunto Preparar lista de questes o direcionadas para o objetivo da entrevista informaes obtidas novas questes co o
&

71

'

Tipos de questes o

abertas-dirigidas: Explique como esse relatrio o e produzido Vantagem descobre-se detalhes e vocabulrio a Desvantagem perde-se a objetividade e gasta-se tempo fechadas: Quantos relatrios desse tipo so gerados por o a mes? Vantagem: facilidade na compilao dos resultados ca Desvantagem: falta de detalhes e monotonia seqncia: d continuidade a uma questo. Por que? D ue a a e um exemplo.
72

&

'

Estrutura da entrevista Pirmide a comea com questes fechadas obtm respostas c o e diretas expande os tpicos com questes abertas dirigidas o o
Qual o n. de vezes que esse relatrio solicitado? til quando o entrevistado parece relutante em falar do assunto Seqncia pode ser utilizada para expandir os tpicos

Qual o principal problema com esse relatrio?

Perguntas fechadas desarmam o entrevistado Voc acredita que esse problema pode ser resolvido?

&

73

'

Funil comea obtendo detalhes questes abertas dirigidas c o d continuidade obtendo respostas diretas questes a o fechadas
Qual a sua expectativa com o desenvolvimento do novo sistema? Muitas quetes fechadas e seqncias tornam-se necessrias Quanto tempo voc gasta fazendo esse relatrio?

&

74

'

Diamante combina as duas estruturas anteriores

Qual a sua expectativa com o desenvolvimento do novo sistema?

A entrevista fica menos cansativa pois varia o tipo de questo

Qual o n. de vezes que esse relatrio solicitado?

Voc acredita que esse problema pode ser resolvido?

&

75

'

Finalizao da entrevista ca Quando todas as questes tiverem sido feitas e o respondidas; Quando o tempo alocado tiver se esgotado; ou Quando o entrevistador sentir que o entrevistado est exausto. a

&

76

'

Finalizao da entrevista (cont.) ca Reservar cinco ou dez minutos para sumarizar e consolidar a informao recebida (principais tpicos ca o explorados e aqueles que necessitam de informao ca adicional). Explicar as prximas aes a ser tomadas, incluindo o co a oportunidade para o entrevistado revisar e corrigir um resumo escrito da entrevista. Agradecer o entrevistado pelo tempo e esforo c dedicados.
&

77

'

Atividades aps a entrevista o

Enviar ao entrevistado um agradecimento por escrito. Produo de um resumo escrito reconhecer ou ca reordenar os tpicos discutidos e consolidar a o informao obtida: ca descobrir ambigidades; e u informao conitante ou ausente. ca Informaes estat co sticas ou baseadas em fatos relatados de memria conrmar com fontes conveis. o a Revisar procedimentos utilizados para preparar e conduzir a entrevista melhorar o processo.
78

&

'

Habilidades e estratgias para comunicao oral e ca A primeira resposta para a pergunta pode no estar a necessariamente completa e correta. Pode ser expressa numa linguagem desconhecida para o entrevistador (resumir, refrasear e mostrar as implicaes do que o entrevistador est ouvindo). co a A sumarizao util durante a entrevista toda e no s ca e a o no nal (conrma o entendimento, generalizaes uteis co e abstraes de alto n co vel).
&

79

'

Habilidades e estratgias (cont.) e

Questes espec o cas: no induzir respostas como a O relatrio de vendas deveria ser produzido o semanalmente?. Perguntas com respostas do tipo sim ou no a permitem que o entrevistado responda sem que precise de muito tempo para pensar. Uma unica pergunta sobre um determinado tpico pode o no produzir uma resposta completa ou signicativa. a Explorar os tpicos com questes que os abordem em o o diferentes n veis de abstrao. ca
80

&

'

Erros mais comuns

Erros de observao: pessoas diferentes se ca concentram em diferentes aspectos e podem ver coisas diferentes. Erros de memria: o entrevistado pode estar o conando demais na lembrana de informaes c co espec cas, e a memria humana pode falhar. o Erros de interpretao: o entrevistador e o ca entrevistado podem estar interpretando palavras comuns de maneira diferente, tais como pequena quantidade de dados ou caracteres especiais.
81

&

'

Erros mais comuns (cont.) Erros de foco: o entrevistador pode estar pensando de maneira ampla, e o entrevistado pode estar pensando de maneira restrita (ou vice-versa), o que afeta o n de abstrao na discusso vel ca a daquele tpico. o Ambigidades: h ambigidades inerentes ` u a u a maioria das formas de comunicao, especialmente ca a l ngua natural.
&

82

'

Erros mais comuns (cont.) Conitos: entrevistador e entrevistado podem ter opinies conitantes sobre um determinado o problema, e a tendncia registrar o ponto de vista do e e entrevistador. Fatos que simplesmente no so verdadeiros: a a o entrevistado pode dar informaes que ele assume co como fatos verdadeiros, mas que, na verdade, so s a o a sua opinio. a
&

83

'

PIECES

Desenvolvedores inexperientes dicilmente sabem como comear. c Que perguntas fazer para extrair os requisitos. Seis categorias de problemas que podem ajudar o analista a estruturar o processo: 1. desempenho (ou performance); 2. informao e dados; ca 3. economia; 4. controle; 5. ecincia; e e
&

6. servios. c
84

'

Pode ser adaptada para incluir questes iniciais ou o bsicas que sejam especialmente relevantes para o tipo a de software. Ajuda a lidar com diculdades de articulao dos ca problemas e comunicao. ca Mais proveitosa na anlise de produtos j existentes a a (manuais ou automatizados). Pode ser adaptada para dom nios de aplicao ca espec cos. Com a experincia: um conjunto de questes detalhadas e o pode ser elaborado (produtos novos e produtos a ser melhorados).
85

&

'

1. Desempenho

Medido de duas maneiras: 1. pelo nmero de tarefas completadas em uma u unidade de tempo (throughput), tal como o nmero u de pedidos processados no dia; e 2. pelo tempo de resposta, ou seja, a quantidade de tempo necessria para executar uma unica tarefa. a Perguntas que ajudem a identicar as tarefas e o tempo de resposta para cada tipo de tarefa. Quando o produto j existe: descobrir se os usurios a a experientes j sabem onde existem problemas de a desempenho.
86

&

'

2. Informao e dados ca

Produtos de software fornecem dados ou informaes co uteis para a tomada de deciso. a O software deve fornecer acesso: ao tipo certo de informao (nem de mais nem de ca menos); no tempo certo; e em forma utilizvel. a Se os usurios tendem a no utilizar o produto a a sintoma de que informaes erradas esto sendo co a fornecidas.
87

&

'

Se eles o utilizam, mas expressam frustrao o ca sistema apresenta muita informao, ou o faz de uma ca forma diferente daquela que o usurio necessita. a Exemplo: (1) relatrio dirio que seria necessrio somente o a a mensalmente, ou mensal que seria necessrio a diariamente. (2) o relatrio pode conter informao relevante, mas o ca e preciso consultar um relatrio de cem pginas vrias o a a vezes ao dia (acesso on-line).
&

88

'

3. Economia

Custo de usar um produto de software sempre e importante. Dois fatores de custo inter-relacionados: 1. n de servio: medida do desempenho do sistema vel c (throughput, tempo de resposta, ou ambos). 2. capacidade de lidar com alta demanda: em alguns sistemas varia consideravelmente de minuto a minuto, ou de hora em hora. Usurios gostariam de ter um n de servio ou a vel c desempenho relativamente estveis. a
89

&

'

Pode-se embutir no produto a capacidade de lidar com a alta demanda necessria nas horas de pico: a Processadores adicionais, unidades de disco ou conexes de rede, projeto de estruturas de dados o internas para armazenar informaes de tamanho ou co complexidade no previs a veis de tempos em tempos. Pode ser caro, e, portanto, essas questes devem ser o discutidas com os usurios. a Um completo entendimento da carga esperada e do n de servio necessrio ao produto ajudar os vel c a a desenvolvedores a tomar decises. o
90

&

'

4. Controle

Sistemas so normalmente projetados para ter a desempenho e sa das previs veis. Quando o sistema se desvia do desempenho esperado algum controle deve ser ativado para tomar aes corretivas. co Em sistemas de tempo real o controle exercido e diretamente pelo software. Segurana controle importante para alguns produtos c (acesso restrito a certos usurios ou a certas horas do a dia).
91

&

'

Tipo de acesso restrito (somente leitura ou leitura e escrita). Auditoria habilidade de ver, monitorar ou reconstruir o comportamento do sistema, durante ou depois da execuo do processo. ca Questes de controle so importantes para no o a a construir: um sistema que fornece pouco controle (processo pode fugir de controle); ou Controle em excesso (impedir que o trabalho seja executado).
92

&

'

5. Ecincia e

No sempre que a energia e os recursos aplicados a a e uma tarefa produzem trabalho util. Algumas vezes h uma perda. a Ecincia medida dessa perda (relao entre os e ca recursos que resultam em trabalho util e o total dos recursos gastos). Ecincia versus economia: e para melhorar a economia do processo, a quantidade de recursos deve ser reduzida;
&

para melhorar a ecincia, a perda no uso desses e recursos deve ser reduzida.
93

'

Algumas inecincias podem ser caracterizadas como e redundncias desnecessrias: a a Coletar o mesmo dado mais de uma vez, armazen-lo em espaos mltiplos ou computar um a c u determinado valor mais de uma vez, uso de algoritmos e estruturas de dados pobres. Interface pobre pode ocasionar perda de tempo do usurio. a

&

94

'

6. Servios c Produtos de software fornecem servios aos usurios. c a Pode ser util pensar em termos de servios durante o c processo de extrao de requisitos. ca Usurios respondem perguntas sobre que tipos de a servios eles precisam que o produto realize e como c esses servios devem ser fornecidos. c O produto pode tambm prestar servios a outros e c produtos de software que interfaces sero necessrias a a entre esses dois produtos.
&

95

'

Questionario Forma rpida de se obter dados de uma grande a amostra de usurios a Tipos de dados que podem ser coletados: a utilizao do sistema atual ca problemas que os usurios enfrentam em seu a trabalho expectativas dos usurios em relao ao novo a ca sistema
&

96

'

E apropriado quando: as pessoas envolvidas esto dispersas a (exemplo: liais) o nmero de pessoas envolvidas muito grande u e deseja-se explorar vrias opinies a o deseja-se conhecer melhor o sistema para organizar melhor as entrevistas

&

97

'

Questionrio a As questes devem ser claras no poss o a e vel explic-las a As poss veis respostas devem ser antecipadas A aplicao e compilao dos resultados devem ser ca ca planejadas antecipadamente

&

98

'

Tipos de questes o Questes abertas-dirigidas: Por que voc acha que o e os manuais do usurio para o sistema de contabilidade a no funcionam? a antecipar o tipo de resposta (enumer-las) a deve ser poss interpretar corretamente as vel respostas utilizadas quando no poss listar todas as a e vel alternativas
&

99

'

Questes fechadas: Os dados sobre vendas so o a normalmente entregues com atraso? utilizada quando poss listar todas as e vel alternativas as respostas devem ser mutuamente exclusivas

&

100

'
Abertas Lenta
Velocidade de Trmino

Fechadas Rpida

Alta

Natureza Exploratria

Baixa

Alta

Largura e Profundidade

Baixa

Fcil

Facilidade de Preparao

Difcil

Difcil

Facilidade de Anlise

Fcil

&

101

'

Linguagem empregada nos questionrios a Usar a linguagem de quem vai responder o questionrio a sempre que poss vel, mantendo as perguntas simples, claras e curtas. Ser espec co, mas no exageradamente. a Fazer a pergunta certa para a pessoa certa. Ter certeza de que as questes esto tecnicamente o a corretas antes inclu -las no questionrio. a
&

102

'

Elaborao do Questionrio ca a Ordem em que as perguntas devem aparecer. Questes mais importantes devem vir primeiro. o As questes de contedo semelhante e relacionado o u devem estar prximas. o As associaes provveis devem ser antecipadas pelo co a elaborador do questionrio. a As questes que podem gerar controvrsias devem ser o e deixadas para depois.
&

103

'

Aplicao do Questionrio ca a Quem responder o questionrio? depende dos a a objetivos. 1. Todos respondem ao mesmo tempo no mesmo lugar. 2. Entregues pessoalmente e depois recolhidos. 3. Colocados a disposio e depois devolvidos. ca 4. Enviados por correio eletrnico ou correio normal o (prazo e instrues de retorno). co 5. Entregue pelo engenheiro de requisitos.
&

104

'

Uso de escalas no questionrio a Atribuio de nmeros ou outros s ca u mbolos Escala Nominal: usada para classicar atributos ou caracter sticas. Exemplo: Que tipo de programa voc e mais usa? 1. processador de textos 2. planilha eletrnica o 3. gerenciador de banco de dados 4. programas grcos a
&

105

'

Ordinal: classica atributos ou caracter sticas em uma determinada ordem. Exemplo: A pessoa de suporte na empresa : e 1. muito util 2. moderadamente util 3. intil u Intervalo o intervalo entre as alternativas de resposta igual e Exemplo: D uma nota de 1 a 5 para o atendimento e do pessoal de manuteno (1 para ruim e 5 para ca excelente)
106

&

'

Proporo ca alternativas em termos de proporo ou % ca o intervalo entre as alternativas igual e existe o valor zero que representa a ausncia do e atributo. Exemplo: Qual o tempo aproximado que voc trabalha e no computador diariamente. a) o% b) 25% c) 50% d) 75% e) 100%
&

107

'

Validao dos requisitos ca 1. Vericao de validade: identicar funes adicionais ou ca co diferentes. 2. Vericao de consistncia: no devem existir requisitos ca e a conitantes, restries contraditrias ou diferentes para co o uma mesma funo. ca 3. Vericao de completude: todas as funes e restries ca co co exigidas pelo usurio. a
&

108

'

Validao dos requisitos (cont.) ca 4. Vericao de realismo: com conhecimento da ca tecnologia existente, vericar se os requisitos realmente podem ser implementados (oramento e prazos). c 5. Facilidade de vericao: requisitos escritos de modo a ca serem vericados; conjunto de testes para demonstrar que o sistema a ser entregue satisfaz cada requisito especicado.
&

109

'

Tcnicas de validao e ca

1. Revises: Requisitos analisados sistematicamente por o um time de revisores. 2. Prototipao: um modelo executvel do sistema ca a e mostrado para os usurios, que podem experimentar e a avaliar se o sistema atende suas reaisnecessidades. 3. Gerao de casos de teste: requisitos devem ser ca testveis. a Quando os testes so criados como parte do processo a de validao podem revelar problemas. ca
&

Se um teste dif ou imposs de ser projetado e cil vel requisitos de dif implementao. cil ca
110

'

Revises dos Requisitos o Reviso informal: envolve os desenvolvedores e tantos a stakeholders quantos poss para discutir os requisitos. vel Reviso formal: a equipe de desenvolvimento deve: a conduzir o cliente, mostrando implicaes de cada co requisito. revisores vericam cada um em termos de consistncia, e os requisitos como um todo, em e termos de completude.
&

111

'

Revises dos Requisitos (cont.) o Facilidade de vericao: pode ser testado? ca Facilidade de compreenso: pelos usurios e/ou a a compradores. Facilidade de rastreamento: a origem do requisito e claramente denida? (pode ser preciso retornar ` origem a do requisito para avaliar o impacto de uma mudana) c Adaptabilidade: o requisito adaptvel? (isto , e a e modicvel sem provocar efeitos em larga escala em a outros requisitos)
&

112

'

Revises (cont.) o Conitos, contradies, erros e omisses devem ser co o detectados e descartados durante a reviso e a formalmente registrados. Os usurios, compradores e desenvolvedores devem a negociar a soluo para esses problemas. ca

&

113

'

Gerenciamento de requisitos Requisitos esto sempre sendo modicados, a especialmente para sistemas complexos. Como o problema no pode ser inteiramente denido, a requisitos so necessariamente incompletos. a Durante o processo de desenvolvimento, a compreenso a dos desenvolvedores est em constante modicao, a ca que tambm se reete nos requisitos. e
&

114

'

Gerenciamento de requisitos (cont.) Com sistemas existentes: dif prever que efeitos o cil sistema atualizado ter sobre a organizao. a ca Com sistemas novos: depois que os usurios nais se a familiarizam com o sistema, novos requisitos surgem porque:

&

115

'

Gerenciamento de requisitos (cont.)

1. Comunidade de usurios diversicada, diferentes a prioridades e requisitos, muitas vezes conitantes ou contraditrios. Requisitos nais conciliao entre o ca eles. 2. Pessoas que pagam pelo sistema so diferentes das que a usam. Restries organizacionais e oramentrias, co c a conitantes com os requisitos dos usurios. a 3. A empresa e o ambiente tcnico do sistema se e modicam reetido no sistema (novo hardware, novas interfaces com outros sistemas, prioridades da empresa mudam, novas legislaes). co
116

&

'

Gerncia de requisitos (cont.) e E o processo de compreender e controlar as mudanas c nos requisitos do sistema. E realizado em conjunto com outros processos da engenharia de requisitos. O planejamento se inicia junto com o levantamento inicial de requisitos. O gerenciamento deve comear assim que uma verso c a inicial do documento de requisitos estiver dispon vel.
&

117

'

Requisitos permanentes e volteis a

1. Requisitos permanentes: relativamente estveis, a derivam da atividade principal da organizao e se ca relacionam diretamente com o dom nio. Exemplo: Em um hospital, sempre haver requisitos a relativos aos pacientes, mdicos, enfermeiras e aos e tratamentos. 2. Requisitos volteis: requisitos que provavelmente vo se a a modicar durante o desenvolvimento ou depois que o sistema estiver em operao. ca Exemplo: Requisitos resultantes de pol ticas governamentais sobre assistncia mdica. e e
118

&

'

Classicao dos requisitos volteis ca a 1. Requisitos mutveis: que se modicam devido ` a a mudanas no ambiente no qual a organizao opera. c ca Exemplo: Em sistemas hospitalares, o nanciamento do tratamento de pacientes pode se modicar e, assim, exigir que diferentes informaes sobre o tratamento co sejam coletadas. 2. Requisitos emergentes: que surgem ` medida que a a compreenso do cliente e dos desenvolvedores cresce a durante o desenvolvimento.
&

119

'

Classicao dos requisitos volteis (cont.) ca a 3. Requisitos consequentes: que resultam da introduo do ca sistema nas organizao. Pode modicar os processos e ca criar novos meios de trabalho, que geram novos requisitos de sistema. 4. Requisitos de compatibilidade: que dependem de sistemas ou processos de negcio espec o cos dentro da organizao. A medida que eles se modicam, os ca ` requisitos de compatibilidade nos sistema encomendado ou entregue tambm podem ter que evoluir. e
&

120

'

Planejamento do gerenciamento de requisitos 1. Identicao dos requisitos: identicado de modo unico, ca para referncia cruzada entre ele e os outros requisitos e e para que possa ser usado na avaliao de facilidade de ca rastreabilidade. 2. Processo de gerenciamento de mudanas: conjunto de c atividades que avalia o impacto e o custo de mudanas. c 3. Pol ticas de rastreabilidade: denem as relaes entre os co requisitos que devem ser registrados e como esses registros devem ser mantidos.
&

121

'

4. Apoio de ferramentas CASE: vo desde sistemas a especializados de gerenciamento de requisitos ` a planilhas de clculo e sistemas simples de bancos de a dados. Apoio necessrio para: a (a) armazenamento de requisitos; (b) gerenciamento de mudanas; c (c) gerenciamento de facilidade de rastreabilidade. Para sistemas pequenos processadores de textos, planilhas de clculos e bancos de dados. a
&

122

'

Informaoes de rastreabilidade c (a) Informaes de rastreabilidade de origem: vinculam co requisitos aos stakeholders que propuseram esses requisitos e aos motivos desses requisitos (quando uma mudana proposta, fcil descobrir os stakeholders e c e a consult-los). a (b) Informaes de ratreabilidade de requisitos: ligam co requisitos dependentes dentro do documento de requisitos (avaliam quantos requisitos sero afetados a pela mudana proposta e a extenso das mudanas de c a c requisitos consequentes).
&

123

'

(c) Informaes de rastreabilidade de projeto: ligam os co requisitos aos mdulos de projeto em que esses o requisitos so implementados (avaliam impacto das a mudanas no projeto e implementao). c ca Matrizes de rastreabilidade relacionam os requisitos aos stakeholders, aos outros requisitos ou aos mdulos de projeto. o

&

124

'

Informaoes de rastreabilidade (cont.) c Cada requisito introduzido em uma linha e uma e coluna da matriz. As dependncias entre diferentes requisitos so e a registradas na clula correspondente ` interseco de e a ca linha/coluna. Podem ser usadas quando um pequeno nmero de u requisitos deve ser gerenciado.
&

125

'

Matriz de Rastreabilidade

ID de requisito 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 R R D R R R D R D R D D D R D D= Requisito da linha depende do da coluna R= Relacionamento mais fraco (ex: ambos definem requsitos para partes do mesmo sistema)

&

126

'

Para sistemas de grande porte, com muitos requisitos, tornam-se dif ceis de serem gerenciadas. Nesses casos, informaes de rastreabilidade devem ser co armazenadas em um banco de dados de requisitos, onde cada requisito explicitamente ligado a requisitos e relacionados. O impacto das mudanas avaliado usando o banco de c e dados. Ferramentas CASE devem ser selecionadas durante a fase de planejamento do gerenciamento de requisitos para: armazenamento, gerenciamento das mudanas e c gerenciamento de rastreabilidade.
127

&

'

Gerenciamento de mudanas nos requisitos c

1. Anlise do problema e especicao da mudana: a ca c comea com a identicao do problema com os c ca requisitos ou com uma proposta espec ca de mudana. c Anlise do problema para vericar validade. Proposta a mais espec ca de mudana pode ser feita. c 2. Anlise e custo da mudana: o efeito avaliado, com a c e informaes sobre facilidade de rastreamento e co conhecimento geral dos requisitos. Custo em termos de modicaes no documento de requisitos e, quando co apropriado, no projeto e implementao. Deciso sobre ca a prosseguir com a alterao ou no. ca a
128

&

'

3. Implementao de mudanas: documento de requisito ca c e, quando apropriado, projeto e implementao. ca Documento deve acomodar mudanas sem muito c esforo (minimizar referncias externas e sees do c e co documento modulares). Mudanas urgentes: tentao de fazer a mudana c ca c primeiro no sistema e depois no documento de requisitos. Conseqncia: especicao de requisitos e ue ca implementao no compat ca a veis.
&

129

'

Resumo

Processo de engenharia de requisitos: estudo de viabilidade, elicitao, anlise, especicao, validao e ca a ca ca gerenciamento de requisitos. Elicitao e anlise dos requisitos: processo iterativo, ca a que pode ser representado como uma espiral de atividades - obteno, classicao, organizao, ca ca ca negociao e documentao de requisitos. ca ca Sistemas devem ser analisados sob diferentes pontos de vista (pessoas ou sistemas que interagem com o sistema tratado, stakeholders afetados pelo sistema ou pontos de vista do dom nio).
130

&

'

Fatores sociais e organizacionais inuenciam os requisitos do sistema e podem determinar se o sistema ser usado ou no. a a Validao de requisitos: vericar validade, consistncia, ca e completude, realismo e facilidade de vericao. ca Gerenciamento de requisitos: controle de mudanas nos c negcios, na organizao e nas tcnicas. o ca e Gerenciamento: inclui planejamento (pol ticas e procedimentos) e gerenciamento de mudanas (avaliar c impacto).
&

131

'

Exerc cios 1. A Editora ABC trabalha com diversos autores que escrevem livros que ela publica. Alguns autores escrevem apenas um livro, enquanto outros escrevem muitos; alm disso, alguns livros so escritos em e a conjunto por diversos autores. Mensalmente enviado e `s livrarias um catlogo com o nome dos livros lanados a a c e seus respectivos autores. Esse catlogo organizado a e por assunto para facilitar a divulgao. Informaes ca co sobre a cota de cada livraria so modicadas a cada trs a e meses, de acordo com a mdia de compra no trimestre. e
&

132

'

Uma carta enviada ` livraria anunciando a nova cota e a em cada assunto e os descontos especiais que lhe sero a concedidos para compras em quantidades maiores. Aos autores dos dez livros mais vendidos no ano, a Editora ABC oferece prmios. A festa de premiao anunciada e ca e com dez dias de antecedncia, atravs de publicao em e e ca jornal dos dez livros mais vendidos, com seus respectivos autores.

(a) Indique ambigidades, omisses e jarges (se houver). u o o (b) Elabore um questionrio baseado nos problemas a encontrados no item a.
&

(c) Apresente uma lista de funes e restries. co co

133

'

2. Sugira quem podem ser os stakeholders em um sistema de registro de estudantes de uma universidade. Explique por que quase inevitvel que os requisitos de diferentes e a stakeholders sejam conitantes de alguma forma.

&

134