Você está na página 1de 106

'

Extracao de requisitos Requisito condio necessria para a obteno de certo objetivo ca a ca ou para o preenchimento de certo m. Requisitos de software requisitos que o produto a ser desenvolvido deve possuir.

&

'

Tipos de Requisitos

Requisitos funcionais: diretamente ligados ` a funcionalidade do software. Exemplo: O sistema deve prever um formulrio de a entrada dos resultados dos testes cl nicos do paciente. Requisitos no funcionais: expressam qualidades e a restrioes do software. Exemplos: c (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
2

&

'

Extrao de requisitos ca Processo de transformao das idias que esto na ca e a mente dos usurios (a entrada) em um documento a formal (sa da) atravs: e da determinao dos objetivos do produto; e ca das restrioes para a sua operacionalidade. c Envolve: anlise do problema; a documentao dos resultados; e ca vericao do entendimento do problema. ca
&

'

sa da: documento de especicao dos requisitos, que ca descreve o que o produto dever fazer, e no como deve a a ser feito. idealmente: completo e consistente; entretanto, a entrada para esse processo no tem nenhuma dessas a propriedades. conseqncia: o processo de extrao de requisitos no ue ca a pode ser totalmente formal e, portanto, totalmente automatizado.
&

'

foco: entendimento do produto a ser desenvolvido e de seus requisitos; quanto mais complexo for o produto, mais dif se torna o processo. cil princ da decomposio: ajuda a lidar com a pio ca complexidade.

&

'
Entendimento do domnio Extrao e anlise de requisitos Especificao

Validao

&

'

O processo de extrao de requisitos ca

entendimento do dom nio: documentos, livros, sistemas, pessoas; extrao e anlise de requisitos: descoberta, revelao e ca 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
7

'

especicao dos requisitos: armazenamento dos ca requisitos em uma ou mais formas, incluindo l ngua natural, linguagem semiformal ou formal, representaoes c simblicas ou grcas; o a validao dos requisitos: vericao dos requisitos, ca ca visando determinar se esto completos e condizentes a com as necessidades e desejos do usurio. a

&

'

o processo no uma seqncia linear dessas atividades a e ue elas no podem ser totalmente separadas e a executadas seqencialmente. u todas so intercaladas e executadas repetidamente. a no mundo real existe uma sobreposio e um feedback ca entre as atividades. algumas partes do produto podem ser analisadas e especicadas enquanto outras ainda esto sendo a analisadas.
&

'

a fase de validao pode revelar problemas com a ca especicao retorno ` fase de anlise e ca a a especicao. ca problemas com o entendimento do dom exigem um nio retorno a essa atividade. as necessidades do usurio mudam ` medida que o a a ambiente no qual o sistema funciona muda. o prprio documento de especicao de requisitos e o o ca processo de extrao do novas idias aos usurios sobre ca a e a as suas necessidades e sobre as funoes do sistema. c
&

10

'

portanto: mudanas nos requisitos acontecem na c maioria dos 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.
&
11

'

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 e formada por um computador 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.
12

'

Descrio de um sistema hospitalar (cont.) ca


Um aviso sonoro deve ser ativado nesse caso. A verificacao da pressao e 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.

13

'

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.
14

&

'

Dificuldades do processo de extracao 1. Falta de conhecimento usurio no conhece suas reais necessidades e o que a a o produto de software pode lhe oferecer. desenvolvedores no conhecem o dom do a nio problema. diferenas entre o que os usurios querem e o que c a precisam. escolhas quando dois requisitos no podem ser a totalmente satisfeitos.
&

15

'

2. Problemas de comportamento dom do processo de extrao de requisitos pelos nio ca desenvolvedores. conitos e ambigidades nos papis clima de u e insatisfao e participao menos efetiva. ca ca Resultado: custo maior, atraso no planejamento e projetos cancelados.

&

16

'

3. Problemas de comunicao ca usurios podem ser incapazes de expressar suas a necessidades apropriadamente. mal-entendidos entre usurios e desenvolvedores: a implementao a escrita do cdigo de programa ca o ou a colocao do produto em funcionamento? ca Se a temperatura ou presso do paciente lida a pelo terminal se tornarem cr ticas. ambigidade da l u ngua natural.
&

17

'

4. Problemas tcnicos e avano tecnolgico muito rpido problemas cada vez c o a mais complexos e conhecimentos cada vez mais detalhados; requisitos caros ou complexos podem se tornar viveis. a alterao nos requisitos. ca muitas fontes de requisitos.

&

18

'

Ambigidades no sistema hospitalar u Se a temperatura ou presso do paciente lida pelo a terminal se tornarem cr ticas, o computador principal dever mostrar uma tela de alerta com um a histrico das medidas realizadas para o paciente. o Um aviso sonoro deve ser ativado nesse caso. Duas interpretaoes: c 1. o terminal ativar um aviso sonoro; e/ou a 2. o computador principal ativar um aviso sonoro. a
&

19

'

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 m a nimo) a ser digitado pelo responsvel 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 m o a nimo so permitidos). a (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


20

'

Diculdade do usurio tomar decises a o quais as conseqncias das decises? ue o quais as alternativas poss veis? necessidades ou perspectivas diferentes: usurios se preocupam com usabilidade e a conana. c desenvolvedores com utilizao de recursos, ca algoritmos etc.
&

21

'

Caracter sticas dos requisitos a freqncia ue a previsibilidade da solicitao ca a atualizao da informao ca ca

&

22

'

Freqncia ue

Programada: Desejo receber diariamente uma lista dos pedidos feitos no dia anterior. O relatrio deve conter o os pedidos efetuados at as 16:30 horas e deve ser e entregue `s 9 horas da manh do dia seguinte. a a Disparada por evento: Todas as vezes que o n de vel estoque de um item car abaixo do n de segurana, vel c fornea um relatrio do status do item. O relatrio deve c o o ser gerado at a manh do dia seguinte. e a Eventual: Qual o valor do pedido de compra nmero e u 34923? O fornecedor precisa de conrmao agora. ca
23

&

'

Previsibilidade Previs veis Programada Desejo receber diariamente uma lista dos pedidos feitos no dia anterior. O relatrio deve o conter os pedidos efetuados at as 16:30 horas e deve e ser entregue `s 9 horas da manh do dia seguinte. a a Eventual Qual o valor do pedido de compra nmero e u 34923? O fornecedor precisa de conrmao agora. ca
&

24

'

Imprevis veis Qual o montante de negcios gerados pelo cliente o 34923 nos ultimos trs meses, at sexta-feira passada? e e Terei uma reunio com ele depois de amanh. a a

&

25

'

Atualidade dos dados Imediata: Dados atualizados a cada transao. ca Qual o saldo devedor do cliente da conta nmero e u 34923? Adiada: Dados atualizados ao nal do per odo. Todas as vezes que o n de estoque de um item car vel abaixo do n de segurana, fornea um relatrio do vel c c o status do item. O relatrio deve ser gerado at a manh o e a do dia seguinte.
&

26

'

Complexidade versus custo de processamento quando a solicitao imprevis e o resultado da ca e vel informao precisa ser imediato custo de ca processamento maior. quando a solicitao previs e o resultado no ca e vel a precisa ser imediato custo de processamento menor.

&

27

'

Tcnicas de extrao de requisitos e ca

depende da complexidade e dos objetivos do produto de software a ser desenvolvido. o desenvolvedor (ou engenheiro de requisitos) responsvel pela produo dos requisitos e lidera o a ca processo. conhecimento imprescind habilidade de empregar vel um processo sistemtico na extrao de requisitos. a ca freqentemente auxiliado por outros desenvolvedores de u software, especialistas em documentao e pessoal de ca apoio.
&

os usurios potenciais do produto fazem parte do a


28

'

processo. Exemplos: 1. um novo e melhor processador de textos. 2. produto sem precedentes (pesquisa de mercado, prottipos, testes e avaliaoes com os usurios). o c a Entretanto: nenhuma tcnica por si s suciente e oe para projetos reais.

&

29

'

Procedimentos Perguntar: identicar a pessoa apropriada e perguntar. Observar e inferir: observar o comportamento dos usurios e inferir suas necessidades. a Discutir e formular: discutir com os usurios suas a necessidades e, juntamente com eles, formular um entendimento comum dos requisitos.

&

30

'

Negociar: comear com um conjunto-padro e negociar c a quais desses requisitos sero inclu a dos, exclu dos ou modicados. Estudar e identicar problemas: identicar os requisitos que podem melhorar o produto Supor: quando no existe usurio, ou na criao de um a a ca produto existente preciso usar intuio. e ca

&

31

'

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.


32

'

Fases da Entrevista 1. planejamento da entrevista; 2. conduo da entrevista; e ca 3. nalizao. ca

&

33

'

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
&

34

'

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 informaoes obtidas novas questes c o
&

35

'

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.
36

&

'

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?

&

37

'

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 quetoes fechadas e seqncias tornam-se necessrias Quanto tempo voc gasta fazendo esse relatrio?

&

38

'

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?

&

39

'

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

&

40

'

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

41

'

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 informaoes estat c 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.
42

&

'

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 implicaoes do que o entrevistador est ouvindo). c a a sumarizao util durante a entrevista toda e no s ca e a o no nal (conrma o entendimento, generalizaoes uteis c e abstraoes de alto n c vel).
&

43

'

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
44

&

'

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 informaoes c c 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.
45

&

'

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.
&

46

'

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 informaoes que ele assume c como fatos verdadeiros, mas que, na verdade, so s a o a sua opinio. a
&

47

'

Questionario Forma rpida de se obter dados de uma grande amostra a 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
&

48

'

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

&

49

'

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

&

50

'

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
&

51

'

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

&

52

'
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

&

53

'

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
&

54

'

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 associaoes provveis devem ser antecipadas pelo c a elaborador do questionrio. a As questes que podem gerar controvrsias devem ser o e deixadas para depois.
&

55

'

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 instruoes de retorno). c 5. Entregue pelo engenheiro de requisitos.
&

56

'

Uso de escalas no quetionrio 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
&

57

'

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 do e pessoal de manuteno (1 para ruim e 5 para excelente) ca
&

58

'

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 atributo. e Exemplo: Qual o tempo aproximado que voc trabalha e no computador diariamente. a) o% b) 25% c) 50% d) 75% e) 100%

&

59

'

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 l cujo papel fazer com que a sesso der e a comece, sem restringi-la.

&

60

'

especialmente util no comeo do processo de extrao c ca de requisitos pois: a 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
61

&

'

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
62

'

Gerao de idias (cont.) ca e sa da: depende das idias geradas (pessoas com e conhecimento e especialidades apropriados). o 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.
&

63

'

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).
&

64

'

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.

&

65

'

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
&

66

'

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
67

&

'

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
68

'

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).
69

&

'

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.
70

&

'

2. Informao e dados ca

os produtos de software fornecem dados ou informaoes c 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 informaoes erradas esto sendo c a fornecidas.
71

&

'

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).
&

72

'

3. Economia

custo de usar um produto de software so sempre a importantes. 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
&

pode-se embutir no produto a capacidade de lidar com


73

'

a alta demanda necessria nas horas de pico: a processadores adicionais, unidades de disco ou conexes de rede, ou o projeto de estruturas de o dados internas para armazenar informaoes de c tamanho ou 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
74

&

'

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 aoes corretivas. c 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).
75

&

'

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 construir: o a a um sistema que fornece pouco controle (processo pode fugir de controle); ou controle em excesso (impedir que o trabalho seja executado).
&

76

'

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.
77

'

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

&

78

'

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.
&

79

'

JAD tcnica para promover cooperao, entendimento e e ca trabalho em grupo entre usurios e desenvolvedores. a facilita a criao de uma viso compartilhada do que o ca a produto de software deve ser. desenvolvedores ajudam usurios a formular problemas e a explorar soluoes. c usurios ganham um sentimento de envolvimento, posse a e responsabilidade para com o sucesso do produto.
&

80

'

quatro princ pios: 1. dinmica de grupo, com a utilizao de sesses de grupo a ca o facilitadas para aumentar a capacidade dos indiv duos; 2. uso de tcnicas visuais para aumentar a e comunicao e o entendimento; ca 3. manuteno do processo organizado e racional; ca 4. utilizao de documentao-padro, preenchida e ca ca a assinada por todos os participantes.
&

81

'

duas etapas principais: 1. planejamento: extrao e especicao de requisitos. ca ca 2. projeto de software. cada etapa consiste de trs fases: e 1. adaptao; ca 2. sesso; e a 3. nalizao. ca

&

82

'

Adaptao: preparao para a sesso: ca ca a organizar a equipe; adaptar o processo JAD ao produto a ser constru do; preparar o material. Sesso: um ou mais encontros estruturados, a envolvendo desenvolvedores e usurios: a requisitos so desenvolvidos e documentados. a Finalizao: converter a informao da fase de sesso ca ca a em sua forma nal, em um documento de especicao ca de requisitos.
&

83

'

Seis componentes: 1. l da sesso; der a 2. engenheiro de requisitos; 3. executor; 4. representantes dos usurios; a 5. representantes de produtos de software; e 6. especialista

&

84

'

L der da sesso a responsvel pelo sucesso do esforo e facilitador dos a c encontros: familiaridade com todos os aspectos do JAD; habilidade para gerenciar encontros; experincia na rea da aplicao (planejar e entender e a ca as vrias tarefas da tcnica e sa a e das);

&

85

'

bom relacionamento pessoal e qualidades de liderana c para: entender e facilitar a dinmica de grupo; a iniciar e manter o foco das discusses; o reconhecer quando os encontros esto saindo da a meta e traz-los de volta para o objetivo; e lidar ecientemente com personalidades e comportamentos diferentes dos participantes; e permanecer entusiasmado ao longo de encontros demorados e dif ceis.
&

86

'

Engenheiro de requisitos participante diretamente responsvel pela produo dos a ca documentos de sa das sesses JAD: da o desenvolvedor experiente para entender questes o tcnicas e detalhes discutidos durante as sesses. e o habilidade de organizar idias e express-las com e a clareza. saber usar as ferramentas de software necessrias a (produo de documentos ou ferramentas de ca prototipagem).
&

87

'

Executor responsvel pelo produto sendo constru com duas a do, principais responsabilidades: 1. dar aos outros participantes uma viso dos pontos a estratgicos do produto a ser constru (o porqu e do e de ele estar sendo constru e como a empresa do espera melhorar com a utilizao do novo produto). ca 2. tomar decises executivas (alocao de recursos, que o ca podem afetar os requisitos e o projeto do novo produto).
&

88

'

Representantes dos usurios a pessoas na empresa que iro utilizar o produto de a software: gerentes ou pessoas-chave dentro da empresa (melhor viso do sistema todo e de como ele ser a a usado), selecionados de acordo: com o conhecimento de suas prprias necessidades o dentro da empresa; o entendimento de como seu departamento interage com outros departamentos; e algum conhecimento de produtos de software.
&

89

'

Representantes de produtos de software pessoas bastante familiarizadas com as capacidades dos produtos de software, cujo papel : e ajudar os usurios a entender o que razovel ou a e a poss que o novo produto faa. vel c esclarecer o usurio sobre as tecnologias existentes. a entender as conseqncias de escolher um ou outro ue caminho para resoluo do problema. ca
&

90

'

Especialista pode fornecer informaoes detalhadas sobre um tpico c o espec co: especialista da comunidade de usurios usa um a determinado tipo de relatrio, ou responsvel pela o e a execuo de um determinado tipo de pedido. ca especialista da comunidade de desenvolvedores conhecesse os detalhes da rede interna da empresa (protocolos de comunicao). ca
&

91

'

A fase de adaptao ca deve ser adaptada a cada produto de software a ser desenvolvido. responsabilidade do l da sesso, com a ajuda de um der a ou dois desenvolvedores.

&

92

'

1. Preparao: o l da sesso e desenvolvedores devem ca der a se inteirar do que foi conseguido, tipo de produto sendo discutido e decises tomadas. o pequenos encontros com um ou mais usurios e a talvez um encontro com o executor. o l da sesso e o engenheiro de requisitos podem der a necessitar de familiarizao com a empresa ou ca departamento para o qual o produto ser constru a do. organograma da companhia ajuda na identicao ca das pessoas-chave que realmente iro contribuir. a
&

93

'

2. Organizar o grupo: l seleciona os participantes; der executor tambm pode ter identicado alguns. e l prepara os participantes para a sesso (data, hora e der a lugar, uma lista de perguntas). requisitos de alto n vel: objetivos, benef cios esperados, restrioes, adaptados ao produto a ser desenvolvido. c os participantes abordam as questes de acordo com as o suas perspectivas (usurios ponto de vista comercial, a representantes de produtos de software ponto de vista tecnolgico). o
&

94

'

3. Ajustar o processo: l usa sua experincia e der e julgamento para adaptar o processo ao produto a ser constru (tempo e quantos encontros necessrios, do a formato geral dos documentos). 4. Preparar material: l faz arranjos log der sticos necessrios (reserva e organizao da sala do encontro). a ca recursos visuais (transparncias, canetas de e marcao, lousa de papel, computador etc.) ca mensagem de boas-vindas, agenda, reviso do a processo e categorias de requisitos de alto n vel, questes o sobre escopo do produto e os formulrios JAD. a
&

95

'

A fase de sesso a um ou mais encontros do grupo para denir os requisitos de alto n para o novo sistema, assim como vel seu escopo. participantes trazem idias e vises diferentes do e o produto para a sesso. a atravs de discusses cuidadosas e facilitadas, essas e o idias e vises so apresentadas, analisadas e renadas. e o a
&

96

'

1. Preparao: sesso comea com o l e o executor ca a c der dando boas-vindas aos participantes. todos os participantes so apresentados. a executor faz um breve resumo do esforo feito at o c e momento e descreve as expectativas dos participantes em relao ` sesso. ca a a o l d uma viso geral do processo, incluindo o der a a tempo a ser gasto em cada tarefa. ` medida que uma nova tarefa comea, o l a c der fornece informaoes mais detalhadas sobre ela c (motivo da tarefa, os papis dos participantes, como e a tarefa executada e como as sa e das so a registradas e formatadas).
97

&

'

2. Denir requisitos de alto n vel. Cinco tpicos: o 1) Objetivos: nalidade da construo desse produto ca 2) Benef cios esperados: quanticveis ou no, a a tang veis ou intang veis 3) Estratgias e consideraoes futuras: como esse e c produto pode ajudar na organizao, avano ca c estratgico ou competitivo? e 4) Restrioes e suposioes: recursos, estrutura c c organizacional, padres, leis? o 5) Segurana, auditoria e controle: requisitos de c segurana internos ou externos, auditorias ou c controles?
98

&

'

3. Delimitar o escopo do sistema quem realmente vai usar o produto. quais as principais funoes que o produto ajudar a c a executar. funcionalidades que esto fora do escopo do sistema a (delimitar o escopo). 4. Documentar questes e consideraoes: algumas afetam o c o processo JAD, outras no, mas podem afetar a a maneira como o produto ser constru ou utilizado. a do
&

99

'

5. Concluir a fase de sesso: reviso da informao a a ca coletada e das decises tomadas. o cada participante tem a oportunidade de expressar preocupaoes sobre os requisitos remanescentes. c todos adquirem um senso de posse e de responsabilidade para com os requisitos documentados. a concluso da sesso de forma positiva garante a a contribuioes futuras de todos os participantes. c
&

100

'

A fase de nalizao ca transformar as transparncias, anotaoes da lousa de e c papel e outros documentos em documentos de especicao dos requisitos de software. ca desenvolvedores trabalham em tempo integral durante essa fase, auxiliados pelo l da sesso. der a

&

101

'

Trs etapas distintas: e 1. Completar o documento: formato xo para o documento, mas pode ser adaptado. 2. Revisar o documento: participantes revisam e fazem comentrios substanciais um novo encontro pode ser a marcado. 3. Obter a aprovao do executor: todos os participantes ca recebem uma cpia do documento nal. o
&

102

'

Prototipagem comparao com um produto de software que sirva de ca referncia. e criar um produto que ilustre as caracter sticas relevantes. os usurios podem descobrir quais so as suas reais a a necessidades.

&

103

'

processo: um estudo preliminar dos requisitos do usurio; e a um processo iterativo de construo do prottipo e ca o avaliao junto dos usurios. ca a cada repetio permite que o usurio entenda melhor ca a seus requisitos, inclusive as implicaoes dos requisitos c articulados nas iteraoes anteriores. c um conjunto nal de requisitos pode ser formulado, e o prottipo descartado. o
&

104

'

benca somente se o prottipo puder ser constru e o do substancialmente mais rpido que o sistema real. a usada para extrair e entender requisitos. seguida pelo processo estruturado e gerenciado de construo do sistema propriamente dito. ca pode ser muito util para superar vrias diculdades de a comunicao e de articulao do usurio. ca ca a

&

105

'

Comentrios nais a ferramentas para auxiliar na extrao de requisitos. ca propiciam condioes para que as pessoas possam c trabalhar juntas, sem que necessariamente estejam na mesma sala ou prdio (videoconferncia). e e ferramentas para prototipagem e para produo de ca documentos. ferramentas podem ser uteis na fase de consolidao ca (edio e a reordenao das idias). ca ca e
&

106