Vol Ere

Modelo para Especificaes de Requisitos
Edio 14Agosto 2009

por James & Suzanne Robertson diretores da Associao Atlntica de Sistemas
Volere, Modelo para Especificaes de Requisitos, pretende ser utilizado como base para suas especificaes de requisitos. Ele fornece sees para cada um dos tipos de requisitos, adequados aos atuais sistemas aplicativos de computadores. Voc pode adaptar este Modelo ao seu processo, como uma ferramenta de coleta de requisitos. Ele pode ser usado como o DOORS (Dynamic Object-Oriented Requirements System Sistema Dinmico de Requisitos Orientados ao Objeto), Caliber RM, IRqA ou qualquer outra ferramenta popular aplicativa da Engenharia de Requisitos. Este Modelo no pode ser vendido ou utilizado para ganhos comerciais ou, propsitos que no tenham como base a especificao de requisitos, sem permisso prvia por escrito. O Modelo pode ser modificado ou copiado e usado em seu trabalho de requisitos, anexo a ele, inclua o seguinte aviso de direitos autorais, ou em qualquer outro documento que utilize qualquer parte deste Modelo: Reconhecemos que este documento utiliza material do Modelo de Especificaes de Requisitos Volere, copyright 1995 2009 the Atlantic Systems Guild Limited.
Contedo
Diretivas do Projeto 1. O Propsito do Projeto 2. Os Interessados Restries do Projeto 3. Restries Obrigatrias 4. Nomeando Convenes e Definies 5. Fatos e Suposies Relevantes Requisitos Funcionais 6. O Escopo do Trabalho 7. Modelos de Dados do Negcio 8. O Escopo do Produto 9. Requisitos Funcionais e dos Dados Requisitos No Funcionais 10. Requisitos de Aparncia e Sensaes 11. Requisitos de Usabilidade e Humanidade 12. Requisitos de Desempenho 13. Requisitos Operacionais e Ambientais 14. Requisitos de Mantenabilidade e Suporte 15. Requisitos de Segurana 16. Requisitos Culturais e Polticos 17. Requisitos Legais Temas do Projeto 18. Temas Abertos 19. Solues Disponveis 20. Problemas Novos 21. Tarefas 22. Migrao para o Novo Produto 23. Riscos 24. Custos 25. Documentao e Treinamento de Usurios 26. Sala de Espera 27. Ideias para Solues
Copyright the Atlantic Systems Guild Limited
Volere Template V14 /2
Volere
Volere o resultado de muitos anos de prtica, consultas e pesquisas em Engenharia de Requisitos. Reunimos nossa experincia na forma de um processo genrico de requisitos, celebrando treinamentos, consultorias, auditorias, uma variedade de diretivas disponveis para download, e este Modelo para elas. Por favor, visite nosso portal digital para maiores informaes. Seminrios pblicos sobre o Volere ocorrem frequentemente na Europa, EUA, Austrlia e Nova Zelndia. Para informaes adicionais e agenda de cursos, visite-nos em www.volere.co.uk ou www.systemsguild.com.
Tipos de Requisitos
Para facilitar o uso, achamos conveniente imaginar que todo requisito pertence a algum tipo especfico. H duas razes para isto: como uma forma de auxlio para encontrar os requisitos; e tornar possvel agrupar os requisitos que sejam relevantes a uma especfica habilidade ou especialidade. Requisitos Funcionais so assuntos de importncia fundamental ou essencial ao produto. Eles descrevem o que o produto tem de fazer ou que aes processuais deve tomar. Requisitos No Funcionais so as propriedades que as funes devem ter, tais como desempenho e usabilidade. No se detenha ao seu nome pouco apropriado (ns o usamos porque a maneira mais comum de se referir a estes tipos de requisitos)estes requisitos so to importantes quanto as exigncias funcionais, para o sucesso do produto. Restries do Projeto so as limitaes no produto devido ao oramento ou ao tempo disponvel para constru-lo. Restries de Desenho impem limitaes de como o produto deve ser desenhado. Por exemplo, pode ser implementado em dispositivos portteis atingindo a maioria dos clientes ou, pode ser utilizado em servidores e computadores de mesa, ou qualquer outra mquina, programa aplicativo, ou prtica de negcio. Diretivas do Projeto so as foras relacionadas ao negcio. Por exemplo, o propsito do projeto uma diretiva prpria, bem como so todas as intenes dos interessadoscada uma, por diferentes razes. Temas do Projeto definem as condies nas quais o projeto ser realizado. Nossa razo para inclu-las, como parte dos requisitos, apresentar uma imagem coerente de todos os fatores que contribuem para o sucesso ou falha do projeto, e ilustrar como gestores podem usar os requisitos como entradas,
Copyright the Atlantic Systems Guild Limited Volere Template V14 /3
quando gerenciando um projeto.
Testando Requisitos
Os requisitos so passveis de testes pela adio de um critrio de ajuste. Este critrio de ajuste uma medida do requisito, na qual torna-se possvel determinar se uma dada soluo se ajusta exigncia. Se um critrio de ajuste no pode ser encontrado para um requisito, ento ele ambguo ou mal compreendido. Todas os requisitos podem ser medidos, e todos devem carregar um critrio de ajuste. H exemplos de critrios de ajuste ao longo deste Modelo.
Formulrio de Requisitos
O formulrio de requisitos um guia para descrever cada mnima exigncia. Os componentes do formulrio (tambm chamado de carto de neve) so discutidos a seguir. Este formulrio pode, e deve, ser automatizado.
1. O Propsito do Projeto
1a. O Negcio do Usurio ou o Conhecimento do Esforo do Projeto Contedo Uma descrio breve da atividade realizada, seu contexto, e o evento que disparou o esforo de desenvolvimento. Deve descrever, tambm, o trabalho que o usurio pretende realizar com o produto pronto. Motivao Sem esta declarao, o projeto falha em justificativa e direo. Consideraes Voc deve considerar se o problema do usurio srio, se e, porqu necessita ser resolvido. 1b. Metas do Projeto Contedo Remete a uma sentena ou, na maioria, a pouqussimas sentenas, que dizem por que queremos este produto. onde voc estabelece a razo real para o produto ser desenvolvido. Motivao Existe o risco de que o propsito possa se perder ao longo do caminho. medida que os esforos no desenvolvimento so aquecidos e, tanto clientes como desenvolvimentistas, descobrem mais sobre o que seja possvel, o sistema pode, potencialmente, afastar-se de suas metas originais, medida que declina sua construo. Isto indesejado a menos que, exista alguma ao deliberada do cliente para mudar as metas. Pode ser necessrio apontar uma pessoa para custdia das metas, provavelmente seja suficiente tornar as metas pblicas e, periodicamente, lembrar os desenvolvimentistas delas. Deve ser obrigatrio tornar claras as metas a cada sesso de reviso. Exemplos Desejamos dar resposta imediata e completa aos clientes que encomendarem nossos bens por telefone. Queremos ser capazes de fazer a previso do tempo. Medida Qualquer meta razovel deve ser medida. Isto necessrio se voc estiver preparado para testar se atingiu o sucesso com o projeto. A medida deve quantificar a vantagem obtida pelo negcio ao longo da execuo do projeto. Se o projeto for valioso, deve haver uma razo slida do negcio para execut-lo. Por exemplo, se o objetivo do projeto for:
Desejamos dar resposta imediata e completa aos clientes que encomendarem nossos bens por telefone, voc deve perguntar qual vantagem esta meta traz organizao. Se a resposta imediata resultar em clientes mais satisfeitos, ento a medida deve quantificar esta satisfao. Por exemplo, voc pode medir o aumento na repetio de um negcio (tendo como base que um cliente satisfeito sempre retornar), o aumento nas taxas de aprovao dos clientes atravs de pesquisas, o aumento do lucro pelos clientes que retornam, e assim por diante. crucial ao restante do esforo de desenvolvimento que a meta esteja estabelecida firmemente, seja razovel, e seja medida. Usualmente, a segunda afirmao que torna a primeira possvel.
2. Os Interessados
2a. O Cliente Contedo Este item nos d o nome do cliente. permissvel ter diversos nomes, mas, havendo mais de trs, invalida esta questo. Motivao O cliente tem a palavra final na aceitao do produto e, desta forma, deve estar satisfeito com o produto entregue. Voc pode imaginar o cliente como sendo a pessoa responsvel pelo investimento no produto. Se o produto estiver sendo desenvolvido para consumo domstico, os papeis de cliente e consumidor so, frequentemente, preenchidos pela mesma pessoa. Se voc no conseguir encontrar um nome para seu cliente, ento talvez voc no deva fabricar o produto. Consideraes s vezes, quando construindo uma soluo ou um produto para usurios externos, o cliente o prprio departamento comercial. Neste caso, uma pessoa deste departamento deve ser nomeada como cliente. 2b. O Consumidor Contedo A pessoa interessada em comprar o produto. No caso de desenvolvimento de produtos para uso domstico, cliente e consumidor so, frequentemente, a mesma pessoa. No caso de produtos desenvolvidos para atacado, esta seo contm uma descrio do tipo de pessoa mais adequada para adquirir o produto.
Motivao O consumidor , eventualmente, o responsvel por decidir se ir comprar o produto do cliente. Os requisitos corretos podem ser reunidos apenas se voc compreender o consumidor e suas aspiraes ao usar seu produto. 2c. Outros Interessados Contedo Os papis e (se possvel) nomes de outras pessoas e organizaes que so afetadas pelo produto, ou as quais a introduo seja necessria para a construo do produto. Exemplos de interessados: Patrocinadores Testadores Analistas de negcios Especialistas em tecnologia Desenhistas de sistemas Especialistas em Mercado Juristas Especialistas de domnio Especialistas em usabilidade Representantes de associaes externas
Para uma lista completa, baixe o modelo de anlise de interessados de www.volere.co.uk. Para cada tipo de interessado, fornea as seguintes informaes: Identificao do interessado (algumas combinaes papeis/ttulo do cargo, nome da pessoa, e nome organizao) Conhecimento necessrio para o projeto Grau de envolvimento necessrio entre interessado/combinao de conhecimentos Grau de influncia conhecimentos entre interessado/combinao de de da
Acordo sobre como enderear conflitos entre interessados que queiram a mesma informao.
Motivao Falhas em considerar todos os interessados resultam em ausncia de requisitos importantes.

2d. Mos Obra no Produto Contedo Uma lista de tipos especiais de interessadosusurios potenciais do produto. Para cada categoria de usurio, fornea as seguintes informaes: Nome do usurio/categoria: Mais apropriadamente o nome do grupo de usurios, tais como crianas em idade escolar, engenheiros de rodovias, ou gerentes de projetos. Papel do usurio: Sumarize as responsabilidades dos usurios. Considere a importncia de sua experincia: Resuma o conhecimento prvio do usurio sobre o negcio. Classifique como iniciante, experiente, ou mestre. Experincia tecnolgica: Descreva a experincia do usurio na tecnologia em questo. Classifique-os da mesma forma anterior. Demais caractersticas do usurio: Descreva quaisquer caractersticas dos usurios que tenham efeito nas exigncias e eventuais desenhos do produto. Por exemplo: Capacidades/incapacidades fsicas Capacidades/incapacidades Intelectuais Postura frente ao uso Postura frente tecnologia Educao Proficincia lingustica Grupo etrio Gnero Motivao Usurios so seres humanos que interferem no produto de alguma maneira. Use as caractersticas dos usurios para definir os requisitos de usabilidade do produto. Os usurios so tambm conhecidos como atuadores. Exemplos Os usurios podem surgir de uma grande variedade de origens (s vezes inesperadas). Considere a possibilidade de seus usurios serem um grupo clrigo, funcionrios de lojas, gerentes, operadores altamente treinados, o pblico em geral, usurios causais, transeuntes, pessoas iletradas, operrios, estudantes, engenheiros de testes, estrangeiros, crianas, advogados, usurios remotos, pessoas usando o sistema ao telefone ou atravs de uma conexo Internet, socorristas, e assim por diante.
2e. Personagens Contedo Uma estria sobre uma pessoa imaginria que inclui: Nome da personagem, idade, ocupao, famlia, lazer, onde vive, refeio predileta, msica favorita, gostos, desgostos, aonde costuma estar nos feriados, postura frente tecnologia, postura com dinheiro, fotografia ou desenho da pessoa imaginada. Motivao Havendo uma ou mais (limitadas a 3) pessoas reais, voc pode fazer requisitos especficos para elas, na inteno de satisfaz-las. Esta uma tcnica particularmente efetiva se voc estiver especificando os requisitos para os consumidores deste produto. 2f. Prioridades Atribudas aos Usurios Contedo Associe uma prioridade para cada categoria de usurio. Isto identifica a importncia e a excelncia do usurio. Priorize os usurios da seguinte forma: Usurios chave: Eles so crticos ao sucesso continuado do produto. D maior importncia aos requisitos gerados por este tipo de usurio. Usurios secundrios: Eles usaro o produto mas, sua opinio sobre ele, no tem efeito no sucesso dele a longo termo. Onde houver conflito entre requisitos de usurios secundrios e, aqueles que so chaves, estes ltimos tem preferncia. Usurios triviais: Para esta categoria de usurio dada a menor prioridade. Isto inclui usurios espordicos, no autorizados, e usurios desabilitados, bem como pessoas que pratiquem uso incorreto ou ilegal.
A porcentagem do tipo de usurios tem como objetivo criar uma taxa para o montante de consideraes atribudas a cada categoria. Motivao Se alguns usurios so mais importantes ao produto ou organizao, ento esta preferncia deve ser declarada, porque deve afetar o desenho final do produto. Por exemplo, voc precisa saber se existe um grupo grande de clientes que tem perguntado especificamente sobre o produto, e por esta razo, se eles no obtiverem o que desejam, os resultados podem ter uma perda significante do negcio. Alguns usurios podem ser listados como no tendo qualquer impacto sobre o produto. Estes usurios faro uso do produto, mas no tem interesse absoluto nele. Em outras palavras, estes usurios no iro
reclamar, nem contribuir. Qualquer exigncia especial partindo destes usurios ter prioridade inferior no desenho. 2g. Participao do Usurio Contedo Onde apropriado, vincule s categorias de usurios uma declarao de sua participao que voc acredite ser necessria para eles, a fim de fornecer os requisitos. Descreva a contribuio que espera que estes usurios forneampor exemplo, conhecimento do negcio, prottipo da interface, ou exigncias de usabilidade. Se possvel, crie um indicador do montante mnimo de tempo que estes usurios devem despender para voc ser capaz de determinar os requisitos completamente. Motivao Muitos projetos falham pela falta de participao do usurio, s vezes porque o grau requerido de participao no foi feito claro. Quando as pessoas tem que fazer uma escolha entre realizar seu trabalho dirio e trabalhar em um novo projeto, o trabalho dirio, usualmente, tem prioridade. Esta exigncia torna claro, desde o princpio, que recursos especficos do usurio devem ser alocados no projeto. 2h. Usurios de Manuteno e Tcnicos de Servio. Contedo Usurios de manuteno so um tipo de mo de obra especializada que tem exigncias especficas para manter e modificar o produto. Motivao Muitos dos requisitos sero descobertos considerando-se os vrios tipos de exigncias de manuteno, detalhadas na seo 14. Entretanto, se definirmos as caractersticas das pessoas que mantm o produto, ajudar a disparar exigncias que podiam, de alguma forma, serem esquecidas.
3. Restries Obrigatrias
Esta seo descreve restries nos eventuais desenhos do produto. Elas so as mesmas que outras exigncias exceto aquelas limitaes que so obrigatrias, usualmente, no incio do projeto. Restries tem descrio, razes, critrios de ajuste e, geralmente, so escritas no mesmo formato para as exigncias funcionais tanto quanto no funcionais.
3a. Restries de Solues Contedo Especifica as restries na maneira de abordar o problema a ser solucionado. Descreve a tecnologia ou a soluo obrigatria. Atribua nmeros de verso apropriados. Voc tambm pode explicar a razo para usar determinada tecnologia. Motivao Identificar limites que direcionem o produto final. Seu, cliente, consumidor, ou usurio podem ter preferncias no desenho, ou apenas certas solues podem ser aceitas. Se estes limites no so encontrados, sua soluo no aceitvel. Exemplos Os limites so escritos usando a mesma forma como quaisquer outras mnimas exigncias (recorra ao formulrio de requisitos para localizar os atributos). importante que para cada limite exista uma razo e um critrio de ajuste, de maneira que eles auxiliem a expor limites falsos (solues mascaradas como limites). Voc tambm perceber que, usualmente, limites afetam o produto como um todo, em mais de um caso de uso dele. Descrio: O produto deve utilizar comunicao comum bidirecional via rdio para contatar os motoristas em seus caminhes. Razo: O cliente no pagar pelo novo sistema de rdio, nem mesmo se estejam quaisquer outros meios de comunicao disponveis aos motoristas. Critrio de ajuste: Todos os sinais gerados pelo produto devem ser audveis e compreensveis pelos motoristas atravs do sistema de rdio bidirecional. Descrio: O produto deve operar utilizando Windows XP. Razo: O cliente usa XP e no pretende mudar. Critrio de ajuste: O produto deve ser aprovado como adequado ao XP, em acordo com o grupo de testes da MS. Descrio: O produto deve ser um dispositivo porttil. Razo: O produto deve ser direcionado ao mercado de pessoas que gostam de caminhar e escalar montanhas. Critrio de ajuste: O produto no deve pesar mais que 300 g, no ser maior que 15 cm, e no devem ter fonte de alimentao externa.
Consideraes Queremos definir as fronteiras dentro das quais podemos solucionar o problema. Seja cauteloso, porque qualquer um que tenha experimentado ou sido exposto a uma parcela da tecnologia, tende a visualizar exigncias em termos daquela tecnologia. Esta tendncia guia as pessoas a impor limites soluo por razes equivocadas, tornando-a, com muita facilidade, em especificaes distorcidas. Os limites da soluo devem ser apenas aqueles que so absolutamente no negociveis. Em outras palavras, apesar de voc ter solucionado o problema, deve usar esta tecnologia em particular. Qualquer outra soluo poderia ser inaceitvel. 3b. Ambiente de Implementao do Sistema Atual Contedo Descreve o ambiente tecnolgico e fsico no qual o produto ser instalado. Isto inclui dispositivos automatizados, mecnicos, organizacionais, e quaisquer outros, ao longo de sistemas adjacentes no humanos. Motivao Descreve o ambiente tecnolgico dentro do qual o produto deve se ajustar. Os locais ambientes desenham limitaes no produto. Esta parte das especificaes fornece informaes suficientes sobre o ambiente, para os projetistas fazerem o produto interagir com sucesso s tecnologias em derredor dele. Exigncias operacionais so derivadas desta descrio. Exemplos Exemplos podem ser mostrados como um diagrama, com algum tipo de cone para representar em separado cada dispositivo ou pessoa (processador). Desenhe setas para identificar as interfaces entre os processadores, e anote-os com sua forma e contedo. Consideraes Todas as partes do componente do sistema corrente, com exceo de seus tipos, devem ser includas na descrio do ambiente de implementao. Se o produto afeta ou importante organizao atual, ento inclua um grfico dela. 3c. Aplicaes Cooperativas ou Parceiras Contedo Descreve as aplicaes que no so parte do produto, mas com as quais ele ir colaborar. As aplicaes podem ser externas, conjuntos comerciais, ou aplicaes internas pr existentes.
Motivao Fornecer informaes sobre restries do desenho causadas pelo uso de aplicaes parceiras. Pela descrio ou modelagem destas aplicaes parceiras, voc descobre e releva problemas potenciais de integrao. Exemplos Esta seo pode ser completada pela incluso de descries, modelos, ou referncias para outras especificaes. As descries devem incluir uma especificao completa de todas as interfaces que tenham efeito sobre o produto. Consideraes Examine o contexto do trabalho para determinar se qualquer um dos sistemas adjacentes deve ser tratado como aplicao parceira. Pode ser tambm necessrio, examinar alguns dos detalhes do trabalho para descobrir aplicaes parceiras relevantes. 3d. Programa Aplicativo Comum Contedo Descreve programas aplicativos de cdigo aberto, ou quaisquer outros comuns (OTS Off-The-Shelf; Fora da Prateleira) que devem ser usados para implementar algum dos requisitos do produto. possvel tambm serem aplicados aos componentes feitos sob medida tais como maquinrios ou, qualquer outro produto comercial que seja utilizado como parte da soluo. Motivao Identificar e descrever produtos comerciais, grtis, de cdigo aberto ou quaisquer outros j existentes a serem, eventualmente, incorporados no produto. As caractersticas, comportamento, e interfaces do conjunto so requisitos do desenho. Exemplos Esta seo pode ser completada pela incluso de descries, modelos, ou referncias s especificaes de fornecedores. Consideraes Quando reunindo requisitos, voc pode descobrir exigncias que conflitem com o comportamento e caractersticas dos programas aplicativos OTS. Tenha em mente que o uso de OTS's j era obrigatrio antes que a abrangncia completa dos requisitos se tornasse conhecida. Na luz de suas descobertas, voc deve considerar se o produto OTS uma escolha vivel. Se o uso de programas aplicativos OTS no for negocivel, ento os requisitos conflitantes devem ser descartados. Note que, sua estratgia para descobrir requisitos, afetada pela
deciso pelo uso de programas aplicativos OTS. Nesta situao, voc investiga o contexto do trabalho em paralelo, fazendo comparaes com as capacidades do produto OTS. Dependendo da compreenso do programa OTS, voc pode ser capaz de descobrir ajustes ou desajustes sem ter de descrever cada um dos requisitos do negcio, nos mnimos detalhes. As discordncias so requisitos que voc precisar especificar de maneira a decidir em satisfaz-las, pela modificao do programa OTS ou pela modificao dos requisitos do negcio. Dado o volume de questes jurdicas que envolvem o cenrio dos programas aplicativos, voc deve considerar se qualquer implicao legal pode ser levantada em consequncia do uso do OTS. Voc pode cobrir esta suposio na seo 17, Requisitos Legais. 3e. Ambiente do Local de Trabalho Antecipado Contedo Descreve o local de trabalho no qual os usurios iro utilizar o produto. Devem ser descritas quaisquer caractersticas do local de trabalho que podem afetar no desenho do produto, bem como aspectos sociais e culturais deste ambiente. Motivao Identificar as caractersticas do local de trabalho de maneira que o produto seja desenhado para compensar quaisquer dificuldades. Exemplos A impressora est a uma distncia considervel da mesa do usurio. Esta limitao sugere que o trmino da impresso deve ser sinalizado. O local de trabalho tem muito rudo ento, sinais audveis podem no funcionar. O local de trabalho externo, ento o produto deve ser resistente ao tempo, possuir mostradores visveis luz do sol, e prevenir o efeito do vento sobre a bandeja dos papis. O produto ser utilizado na biblioteca; ele deve ser extremamente silencioso. O produto uma fotocopiadora a ser utilizado por uma organizao de conscientizao ambiental; ele deve aceitar papel reciclado. O usurio permanecer em p ou trabalhar em posies onde ser necessrio segurar o produto. Isto sugere um produto porttil, mas apenas um estudo cuidadoso do trabalho do usurio e de seu local, fornecer a ideia necessria para identificar os requisitos operacionais. Consideraes Limites do ambiente fsico que proporcionem a realizao do trabalho. O produto deve superar quaisquer dificuldades existentes; entretanto,
voc poder considerar redesenhar o local de trabalho como uma alternativa para ter um produto que o atenda. 3f. Limites de Agenda Contedo Quaisquer prazos conhecidos, ou janelas de oportunidades devem ser estabelecidos aqui. Motivao Identificar os tempos e datas crticas que tenham efeito nos requisitos do produto. Se o prazo curto, ento os requisitos devem ser mantidos de maneira que a construo ocorra dentro do prazo permitido. Exemplos Definir o lanamento do programa aplicativo. Poder haver outras partes do negcio ou outros derivados do aplicativo que dependam deste produto. Janelas de oportunidades de mercado. Mudanas na agenda do negcio que ir utilizar seu produto. Por exemplo, a organizao pode estar iniciando uma nova unidade fabril e seu produto ser necessrio antes que a produo se inicie. Consideraes Estabelea prazos limites pela adio da data e descrevendo por que ela crtica. Identifique, tambm, datas prvias onde partes do produto precisam estar disponveis para testes. Voc tambm deve questionar o impacto de no cumprir os prazos: O que acontece se no fizermos o produto at o final do ano calendrio? Qual o impacto financeiro de no ter o produto no incio da temporada de compras natalinas?
3g. Limites Oramentrios Contedo O oramento do projeto, expresso em moeda ou recursos disponveis. Motivao Os requisitos no devem exceder o oramento. Esta limitao pode conter o nmero de requisitos que podem ser includos no produto. A inteno desta questo determinar se o produto realmente desejado. Consideraes realstico criar um produto dentro deste oramento? Se a resposta a
esta questo for no, ento, ou o cliente no est realmente comprometido criao dele ou, ele no atribui valor suficiente ao produto. Em ambos os casos voc deve considerar se vale pena continuar.
4. Nomeando Convenes e Definies

4a. Definies de Todos os Termos, Incluindo Acrnimos, Usados no Projeto. Contedo Um glossrio contendo os significados de todos os nomes, acrnimos, e abreviaes usadas nas especificaes de requisitos. Selecione os nomes cuidadosamente para evitar dar um significado diferente, no intencionado. Este glossrio reflete a terminologia de uso corrente na rea de trabalho. Voc pode tambm criar nomes padres utilizados em sua indstria. Para cada termo, descreva uma definio sucinta. Os interessados apropriados devem concordar com estas definies. Evite abreviaes que possam introduzir ambiguidades, requeiram traduo adicional, e possam potencialmente direcionar a uma m interpretao de quem esteja tentando compreender seus requisitos. Pea aos seus analistas de requisitos substiturem todas as abreviaes pelos termos corretos. Isto facilmente feito com editores eletrnicos de texto. Acrnimos so aceitos se estiverem completamente explicados por uma definio. Motivao Os nomes so muito importantes. Eles invocam os significados que, se definidos cuidadosamente, podem poupar horas de explicaes. Ateno aos nomes nesta fase do projeto auxilia a evitar erros. O glossrio produzido durante os requisitos usado e estendido ao longo do projeto. Exemplos Caminho: Um veculo usado para espalhar material de degelo sobre as estradas. Caminho no ir se referir a veculo para transporte de mercadorias. SIN: Servio de Inteligncia do Negcio. Departamento liderado por Antnio Francisco, responsvel pelo fornecimento de inteligncia do negcio ao restante da organizao.
Consideraes Faa uso de referncias existentes, tambm em dicionrios de dados. Obviamente, melhor evitar renomear itens existentes, a menos que sejam to ambguos que causem confuso. Desde o princpio do projeto, enfatize a necessidade de evitar homnimos e sinnimos. Explique como eles elevam o custo do projeto.
5. Fatos e Suposies Relevantes

5a. Fatos Relevantes Contedo Fatores que tem efeitos sobre o produto, mas no so limites de requisitos obrigatrios. Fatos fornecem ao leitor das especificaes, maior conhecimento prvio para compreender os problemas do negcio. Motivao Fatos relevantes fornecem informao prvia aos leitores das especificaes e, podem contribuir com os requisitos. Eles tero um efeito sobre o eventual desenho do produto. Exemplos Uma tonelada de material para degelo ir cobrir quase 5 Km de uma pista de uma rodovia. A aplicao existente representa 10.000 linhas do cdigo C. 5b. Regras do Negcio Contedo Estas so regras do negcio que podem ter um impacto sobre o trabalho/negcio/domnio, que sero fonte de requisitos. Regras relevantes ao negcio sero o gatilho para os requisitos. Motivao Regras do negcio so mencionadas em todos os estgios do processo de descoberta dos requisitos. frequentemente difcil acertar de imediato se uma regra do negcio relevante ou no. Esta seo fornece um local para captura das regras do negcio e, conforme a compreenso do trabalho aumenta, voc deve revisit-lo e us-lo como gatilho para a descoberta de requisitos relevantes. Exemplos A durao mxima do turno de um motorista de caminho de 7 horas.
Os engenheiros daro manuteno s estaes climticas uma vez por semana. 5c. Suposies Contedo Uma lista de suposies que os desenvolvimentistas estejam imaginando. Estas suposies podem tratar do ambiente operacional pretendido, mas podem ser sobre qualquer aspecto que tenha um efeito sobre o produto. Como parte das expectativas gerenciais, as suposies tambm contm declaraes sobre o que o produto no realizar. Motivao Fazer as pessoas declararem as suposies que estejam abordando. Fazer tambm com que todos no projeto estejam cientes das suposies que j tenham sido abordadas. Exemplos Suposies sobre novas leis ou decises polticas. Suposies que abordem as expectativas de seus desenvolvimentistas quanto ao produto estar pronto a tempo de ser utilizadopor exemplo, outras partes de seus produtos, trmino de outros projetos, ferramentas de programas aplicativos ou seus componentes. Suposies sobre o ambiente tecnolgico no qual o produto ir operar. Elas devem sinalizar as reas de equilbrio esperado. Os componentes dos programas aplicativos que estaro disponveis aos desenvolvimentistas. Outros produtos sendo desenvolvidos ao mesmo tempo deste. A disponibilidade e a capacidade dos componentes adquiridos. Subordinao a sistemas de computador ou pessoas externas deste projeto. Os requisitos que, especificamente, no estaro dispostos no produto. Consideraes Ns, frequentemente, criamos suposies inconscientes. necessrio conversar com os membros do time de projeto para descobrir quaisquer suposies inconscientes que eles tenham criado. Pergunte aos interessados (tcnicos e comerciais) questes tais como estas: Que ferramentas aplicativas voc espera estarem disponveis? Haver qualquer novo produto de programa aplicativo? Voc espera usar o produto atual de uma nova maneira? Haver quaisquer mudanas no negcio que voc admita sermos capazes de administrar?
importante estabelecer estas suposies logo no incio. Voc tambm pode considerar a probabilidade de que, se a suposio estiver correta e, onde relevante, fazer uma lista de alternativas para que, se algo suposto, no ocorra. Suposies devem ser transitrias. Significa que todas devem ser esclarecidas junto publicao das especificaesa suposio deve tornar-se um requisito ou uma restrio. Por exemplo, se uma suposio relacionada capacidade do produto, tenha a inteno de ser um produto parceiro ao seu, ento a capacidade deve ter sido provada satisfatria, e torna-se uma limitao ao us-la. Ao contrrio, se o produto adquirido no adequado, ento ele se torna um requisito para o time de projeto criar a capacidade necessria.
6. O Escopo do Trabalho
6a. A Situao Atual Contedo Esta uma anlise dos processos existentes no negcio, incluindo os processos manuais e automatizados que possam ser substitudos ou modificados pelo novo produto. Analistas comerciais podem j terem feito esta investigao, como parte da anlise de casos do negcio para o projeto. Aqui onde pode ser apropriado construir alguns modelos de processos do negcio. Estes so modelos de processos que o negcio utiliza para apresentar o trabalho da organizao. Os modelos incluem papeis, indivduos, departamentos, tecnologia e procedimentos. Eles ilustram o fluxo de trabalho e as dependncias entre os componentes do processo. Motivao Se o projeto pretende realizar modificaes em um sistema manual ou automatizado, voc precisa entender o efeito das mudanas propostas. O estudo da situao atual fornece a base para compreenso dos efeitos das modificaes propostas e a escolha das melhores alternativas. A modelagem dos processos do negcio nem sempre direciona para a construo de um programa aplicativo. Ao invs, algumas mudanas nos procedimentos e na maneira em que os papis so alocados, podem ser a melhor maneira de fazer a melhoria necessria. Exemplos H diversas notaes adequadas e diferentes para construir modelos de processos do negcio, por exemplo: diagramas de atividades, diagramas de processos do negcio, diagramas tipo swimlane, diagramas de fluxo de dados.
6b. O Contexto do Trabalho Contedo O diagrama de contexto do trabalho identifica suas fronteiras, as quais voc precisa investigar, para ser capaz de construir o produto. Note que ele inclui mais que apenas o produto desejado. A menos que compreendamos o trabalho que o produto ir realizar, temos pouca chance de construir um que se encaixe perfeitamente em seu ambiente. Os sistemas adjacentes no diagrama de contexto (Servio de Previso do Tempo, por exemplo) indicam outros domnios de sujeitos importantes (sistemas, pessoas e organizaes), que precisam ser compreendidos. As interfaces entre os sistemas adjacentes e o contexto do trabalho indicam por que elas so interessantes neles. No caso do Servio de Previso do Tempo, podemos dizer que estamos interessados nos detalhes tais como quando, como, onde, o que, e por que produzir a informao da Previso do Tempo em dada Regio. Motivao Definir com clareza a fronteira para o estudo do trabalho e aumentar o empenho dos requisitos. Sem esta definio, temos pouca chance de construir um produto que ir se encaixar consistentemente em seu ambiente.
Exemplo:
Consideraes Os nomes utilizados no diagrama de contexto devem ser consistentes com as convenes das nomenclaturas (seo 4), e dicionrio de dados de definies (seo 7). Sem estas definies, os modelos de contexto falham no rigor exigido, e podem serem mal compreendidos. Os principais interessados devem concordar com as definies das interfaces mostradas no modelo de contexto.
6c. Diviso do Trabalho Contedo Uma lista exibindo todos os eventos do negcio ao quais o trabalho corresponde. Eventos do negcio so acontecimentos no mundo real que afetam o trabalho. Eles tambm ocorrem porque hora da tarefa ser executadapor exemplo, produzir relatrios semanais, lembrar clientes inadimplentes, verificar o estado de uso de um dispositivo, e assim por diante. A resposta a cada evento chamada caso de uso do negcio (conhecida como BUC); ela representa uma diviso discreta do trabalho que contribui com a funcionalidade total dele. A lista de eventos inclui os seguintes elementos: Nome do evento Entradas feitas por sistemas adjacentes (idntica ao nome no diagrama de contexto) Sadas dos sistemas adjacentes (idntica ao nome no diagrama de contexto) Resumo do caso de uso do negcio (Isto opcional, mas descobrimos ser um primeiro passo muito til na definio de requisitos para os casos de uso do negciovoc pode imaginar este fato como um sendo mini cenrio)
Motivao Identificar aglomerados lgicos do sistema que possam ser utilizados como base para descobrir requisitos detalhados. Estes eventos do negcio tambm fornecem os subsistemas que podem ser utilizados como base para o gerenciamento de anlises detalhadas e de desenho. Cada evento do negcio tem um BUC no qual os detalhes podem ser estudados independentemente. Entretanto, todos os BUCs se conectam uns aos outros atravs de dados armazenados do negcio (veja seo 7). Exemplo Nome do Evento Lista de Eventos do Negcio Entradas e Sadas Resumo do BUC
Registre as leituras pertencentes estao climtica.
1. Estao Climtica transmite Leituras da Estao a leitura Climtica (E)
2. Servio do Tempo previses Previso do Tempo para a Registre a previso. do tempo Regio (E) Registre a nova ou a rodovia 3. Engenheiros de Estradas Rodovia Modificada (E) modificada. Verifique se todas as notificam rodovias modificadas estaes climticas apropriadas esto anexas. 4. Engenheiro de Estrada Nova Estao Climtica instala nova Estao Climtica (E)
Registre a estao climtica e anexe-a as rodovias apropriadas.

5. Engenheiro de Estrada modifica a Estao Climtica 6. Hora de testar a Estao Climtica
Estao Climtica Modificada (E)
Registre as modificaes da estao climtica.
Alerta de Falha da Estao Investigue se alguma estao Climtica (S) climtica no transmitiu por duas horas, e informe a Engenharia de Estradas quaisquer falhas. Registre as trocas de caminhes. Preveja a situao de gelo para as prximas duas horas. Designe caminhes para as rodovias que iro congelar. Publique a agenda. Registre a rodovia como estando em condies seguras pelas prximas trs horas.
7. Ptio substitui um caminho Troca de Caminho (E) 8. Hora de investigar estradas Agenda de Degelo da Rodovia (S) congeladas
9. Caminho beneficia uma estrada
Rodovia Beneficiada (E)
10. Ptio relata problema com Quebra do Caminho (E) Envie os caminhes disponveis, Agenda de Cascalho um caminho atribudos previamente s Alterada (S) rodovias. 11. Hora de monitorar o beneficiamento das estradas Lembrete para as Rodovias No Beneficiadas (S) Verifique se todas as rodovias agendadas foram beneficiadas no tempo determinado, e publique lembrete para aquelas no beneficiadas.
Consideraes Listar os eventos do negcio e fazer um resumo para cada um dos BUCs uma maneira de testar o contexto do trabalho. Esta atividade no cobre incertezas e enganos sobre o projeto e facilita comunicaes precisas. Quando realizar a anlise de um evento, isto ir despert-lo a fazer mudanas no seu diagrama de contexto. Sugerimos reunir requisitos para as sees distintas do trabalho. Isto exige particion-lo e, descobrimos que os eventos do negcio ficam mais convenientes, consistentes, e uma maneira natural de fracionlo em unidades gerenciveis, capazes de levar os detalhes de volta ao seu escopo. 6d. Especificando um BUC Contedo Uma especificao dos detalhes de como um Caso de Uso do Negcio corresponde a um de seus Eventos. Motivao Entender os detalhes da resposta do negcio que devem ser praticados quando um evento dele toma lugar e, fornecer uma base
para encontrar requisitos detalhados. A compreenso do BUC tambm fornece a base para discutir quais partes dele devem ser praticadas pelo produto que ser construdo. Exemplo Um BUC pode ser especificado usando qualquer combinao de modelos que sejam adequadas ao analista. As aproximaes mais comuns so: diagramas de atividade, cenrios do BUC, diagramas de fluxo de processo, diagramas de sequncia, mapas mentais, notas de entrevistas... Consideraes Seja qual for a aproximao que voc utilize para especificar os detalhes de um BUC, voc deve permanecer dentro de limites das entradas e sadas para aquele evento do negcio. Se voc encontrar dados de entrada e sada adicionais, ento uma indicao de que necessita fazer mudanas neles sobre a lista de eventos e, tambm no diagrama de contexto do trabalho.
7. Modelo dos Dados do Negcio

7a. Modelo dos Dados Contedo Uma especificao de temas importantes, objetos do negcio, entidades, e membros que sejam relevantes ao produto. Pode transformar-se em um modelo de primeira classe, de relacionamento de entidades, ou qualquer outra espcie de base de dados. Motivao Esclarecer a importncia do elemento principal do sistema, consequentemente, incitando o reconhecimento dos requisitos ainda no considerados. Para encontrar requisitos perdidos voc pode cruzar o modelo de dados e os eventos usando uma tabela CRUD (Create, Retrieve, Update, Delete). Para detalhes veja Masterizando o Processo de Requisitos, Editora Addison Wesley 2006. Agir como uma especificao para todos os dados do negcio que sejam relevantes ao escopo do trabalho. Exemplo Este um modelo do elemento principal do sistema do negcio, utilizando notao de classes da Linguagem de Modelagem Unificada (UML). Estes so todos os dados Criados, Referenciados, Atualizados e Apagados (CRUD) pelos processos, dentro do escopo do trabalho em estudo. Veja seo 6 para mais informaes sobre o escopo do trabalho.
Voc pode usar quaisquer tipos de dados ou modelos de classes para obter esta informao. A ideia encontrar o significado da importncia do elemento principal do negcio e as conexes entre as partes individuais e, mostrar a consistncia de seu projeto. Se voc tiver uma anotao padro estabelecida pela companhia, use-a, de maneira a auxiliar a reutilizao de informaes de outros projetos. Consideraes Existem quaisquer dados ou modelos de objeto para sistemas comuns ou, similares que possam ser um ponto de partida til? Existe um modelo de domnio para o elemento de maior importncia, compartilhado por este sistema? 7b. Dicionrio dos Dados Contedo O dicionrio dos dados especifica o contedo de: Classes no modelo dos dados Atributos das classes Relaes entre as classes Entradas e Sadas em todos os modelos Elementos dos dados dentro das Entradas e Sadas
Quando as decises da implementao so feitas, as especificaes tcnicas para as interfaces devem ser adicionadas ao dicionrio.
Motivao O diagrama de contexto fornece uma definio precisa do escopo do trabalho em estudo ou do produto a ser construdo. Esta definio ser completa apenas se a informao acompanhar as determinaes dos atributos. Exemplos O dicionrio de dados a seguir apenas parcial para o projeto de degelo de rodovias, exemplo utilizado neste Modelo. Note que esta verso do dicionrio distribuda de acordo com o Tipo. Nome Regio Suposio Rodovia Trecho da Rodovia Contedo Nome + Tamanho Temperatura + Tempo Nome + Nmero Identificador do Trecho + Coordenadas Identificador do Caminho Identificador do Ptio Tipo Classe Classe Classe Classe Classe Classe Classe Atributo/Elemento Atributo/Elemento Atributo/Elemento Atributo/Elemento Atributo/Elemento Atributo/Elemento Atributo/Elemento Atributo/Elemento Atributo/Elemento Atributo/Elemento Atributo/Elemento {Identificador do Trecho da Rodovia + Data Agendada do Beneficiamento + Hora Agenda Fluxo dos Dados
Leitura da Temperatura Hora da Leitura + Medida Caminho Ptio Nome da Regio Tamanho da Regio Suposio da Temperatura Hora da Suposio Hora da Leitura Nome da Rodovia Nmero da Rodovia Coordenadas do Trecho da Rodovia Identificador do Trecho da Rodovia Medida da Temperatura Identificador do Caminho Agenda de Degelo da Rodovia
de Incio do Beneficiamento + Hora do Incio Crtica + Identificador do Caminho} Hora de Incio Crtica *Beneficiamento no iniciado Elemento antes desta hora no garantia de ser efetivo * DD/MM/AA Elemento Elemento
Data Agendada do Beneficiamento
Hora Agendada de Incio HH/MM/SS do Beneficiamento Relgio de 24 horas Consideraes
O dicionrio fornece um elo entre os analistas de requisitos/negcio e os desenhistas/desenvolvimentistas/provedores. Os provedores adicionam detalhes de implementao aos termos no dicionrio, definindo como os dados so inseridos. Da mesma forma, eles adicionam termos que estejam presentes na tecnologia escolhida e que so independentes dos requisitos do negcio. medida que voc estuda o trabalho, frequentemente, descobre que uma entrada feita nas convenes de nomes (seo 5), se transforma num fluxo especfico de dados ou num atributo deles. Quando isto acontece, voc deve transferir a entrada ao dicionrio de dados.
8. O Escopo do Produto
8a. Fronteiras do Produto Um diagrama de caso de uso identifica as fronteiras entre os usurios (atuadores) e o produto. Voc chega fronteira do produto atravs da inspeo de cada caso de uso do negcio e, determinando em conjunto com os interessados apropriados, qual parte do caso de uso deve ser automatizada (ou satisfeita por alguma caracterstica do produto), e qual parte deve ser realizada pelo usurio. Esta tarefa deve levar em conta as habilidades dos atuadores (seo 2), as limitaes (seo 3), as metas do projeto (seo 1), e seu conhecimento, tanto do trabalho como da tecnologia que poder fazer a melhor contribuio a ele. O diagrama de caso de uso exibe os atuadores/usurios fora da fronteira do produto (o retngulo). O casos de uso do produto (PUCs) so as elipses dentro da fronteira. Os nmeros ligam cada PUC de volta ao BUC, de onde ele parte (veja seo 6). As linhas indicam a utilizao. Note que os atuadores podem ser automatizados ou humanos.
Exemplo
Derive os PUCs decidindo onde a fronteira do produto deve estar para cada para cada caso de uso do negcio (BUC). Estas decises so baseadas em seu conhecimento do trabalho e nas limitaes dos requisitos. Note que os PUCs abordados devem ser rastreveis de volta aos BUCs. Os nmeros sobre o diagrama de PUC correspondem aos nmeros de BUC na Lista de Eventos no Negcio (veja seo 6). 8b. Lista de Casos de Uso do Produto O diagrama de uso uma maneira grfica de resumir os PUCs relevantes ao produto. Se existir um nmero grande de PUCs (achamos que 1520 um bom limite), ento melhor fazer a lista dos PUCs e dos modelos, ou descrever cada um individualmente. 8c. Casos de Uso de Produtos Individuais onde voc mantm detalhes sobre os casos individuais de uso do produto PUCs na sua lista. Voc pode incluir um cenrio ou modelo, para cada caso de uso do produto nela. Representaes tpicas so cenrios PUC (informais ou formais) ou diagramas de sequncia.
9. Requisitos Funcionais e dos Dados

9a. Requisitos Funcionais Contedo Uma especificao para cada requisito funcional. Como feito com todos os seus tipos, utilize a ficha de requisitos. Uma explicao completa est includa no material introdutrio deste Modelo. Motivao Apresentar os requisitos funcionais, detalhados, oferecidos pelo produto. Exemplo:
Critrio de Ajuste Cada requisito funcional deve ter um critrio de ajuste ou um caso para teste. Em qualquer evento, o critrio de ajuste o modelo que permite, a quem testa, determinar se o produto implementado atingiu o requisito. Consideraes Se voc criou uma lista de casos de eventos/uso (veja sees 6c e 8 a/b), voc pode us-la como auxlio para descobrir requisitos funcionais para cada caso de evento/uso. Se voc no criou esta lista, d a cada requisito funcional um nmero exclusivo e, para auxiliar na rastreabilidade no desenvolvimento do processo, divida mais tarde estes requisitos em casos relacionados entre os casos de eventos/uso. Note que, se voc no tiver identificado a fronteira do produto e no estiver em posio determinante quanto aos casos de uso dele
(PUCs), ento descreva os requisitos funcionais e no funcionais para os casos de uso do negcio (BUCs). uma boa estratgia, especialmente, se estiver descrevendo requisitos do negcio e questionando os fornecedores sobre quais deles podem ser satisfeitos por seus produtos.
10. Requisitos de Aparncia e Sensaes

10a. Requisitos de Aparncia Contedo Esta seo contm requisitos relacionados ao esprito do produto. Seu cliente pode ter feito exigncias particulares para o produto, tais como marcas corporativas, cores utilizadas, e assim por diante. Os requisitos abordados aqui so os da aparncia. No tente desenh-lo at que os requisitos de aparncia sejam mostrados. Motivao Assegurar que a aparncia do produto esteja de acordo s expectativas da organizao. Exemplos O produto deve ser atrativo ao pblico adolescente. O produto deve estar de acordo com os padres de marcas da companhia. Critrio de Ajuste Uma amostra de adolescentes alvo deve, sem qualquer estmulo propositado, iniciar o uso do produto dentro de quatro minutos de seu primeiro contato com ele. O escritrio de marcas deve certificar-se de que o produto atende padres correntes. Consideraes Mesmo se voc estiver utilizando prottipos, importante compreender os requisitos de aparncia. O prottipo utilizado para auxiliar na provocao de requisitos; ele no deve ser considerado como um substituto dos requisitos. 10b. Requisitos de Estilo Contedo Requisitos que especifiquem a impresso emocional, estilo, ou sensaes ao produto, os quais influenciam na maneira potencial de como o consumidor ir perceb-lo. Da mesma forma, as intenes dos interessados ao montante de interaes que o usurio ter com o produto.
Nesta seo ser descrita tambm a aparncia da embalagem, se tratar de um produto manufaturado. A embalagem precisa ter os requisitos tais como seu tamanho, estilo, consistentes com outras embalagens consideradas por sua organizao. Tenha em mente que leis nacionais que fazem referncia s embalagens, requerem que as mesmas no sejam significantemente maiores que o produto a ser acondicionado. Os requisitos de estilo aqui registrados vo direcionar os desenhistas na criao do produto imaginado por seu cliente. Motivao Dado o estado dos mercados atuais e das expectativas das pessoas, no podemos arcar com custos de produtos que tenham um estilo equivocado. Uma vez que as exigncias funcionais estejam satisfeitas , frequentemente, a aparncia e o estilo dos produtos que determinam se eles tero sucesso. Sua tarefa nesta seo determinar, precisamente, como o produto deve mostrar-se ao cliente alvo. Exemplo O produto deve parecer confivel. Critrio de Ajuste Depois de seu primeiro contato com o produto, 70 por cento dos clientes potenciais devem concordar que eles sentem confiana no produto. Consideraes Os requisitos visuais e de sensaes especificam a percepo de seu cliente sobre a aparncia do produto. Os requisitos podem, a princpio, parecerem vagos (por exemplo, aparncia conservadora e formal), mas estes sero quantificados atravs de seus critrios de ajuste. Os critrios de ajuste oferecem a oportunidade de extrair de seu cliente, precisamente, o que ele tem em mente, e proporcionar ao desenhista instrues acuradas sobre o que ele quer atingir.
11. Requisitos de Usabilidade e Humanidade

Esta seo preocupa-se com os requisitos que tornam o produto til e ergonomicamente aceitvel aos usurios efetivos. 11a. Requisitos de Uso Confortvel Contedo Esta seo descreve os desejos de seus clientes e usurios alvos quanto facilidade de operao do produto. A usabilidade do produto derivada das habilidades do usurio no manuseio dele bem como da complexidade de sua funcionalidade.
Os requisitos de usabilidade devem cobrir propriedades tais como estas: Eficincia do uso: Com que rapidez ou preciso o usurio pode utilizar o produto. Memria de uso: Quanto esperado do usurio casual lembrarse sobre o manuseio do produto. Proporo de erros: Para alguns produtos crucial que o usurio cometa poucos erros ou, nenhum. Satisfao geral com o uso do produto: especialmente importante para produtos comerciais e interativos que enfrentem muitos competidores. Portais digitais de Internet so um timo exemplo. Retorno: Quanto de retorno os usurios precisam para sentirem-se confiantes de que o produto esteja, atualmente, realizando com preciso o que eles esperam. O grau necessrio de retorno ser maior para alguns produtos (por exemplo, produtos de segurana crtica), em relao aos demais.
Motivao Conduzir os desenhistas do produto na direo de constru-lo, de maneira a atingir as expectativas de seus usurios eventuais. Exemplos O produto deve ser fcil de usar por uma criana de 11 anos. O produto deve ajudar ao usurio evitar cometer erros. O produto deve fazer o usurio querer utiliz-lo. O produto deve ser utilizado por pessoas sem treinamento e, possivelmente, sem compreenso do idioma utilizado no equipamento. Critrio de Ajuste Estes podem ser exemplos simples, mas expressam a inteno do cliente. Para especificar completamente o que significante para um requisito, voc deve adicionar uma medida pela qual ele possa ser testadoo prprio critrio de ajuste. Aqui esto alguns critrios de ajuste para exemplos que os precedem: Oitenta por cento de um painel de testes com crianas devem ser capazes de completar, com sucesso, a [lista de tarefas] dentro do [tempo especificado]. Um ms de utilizao do produto deve resultar numa razo de erro total de menos de 1 por cento. Uma pesquisa annima deve demonstrar que, os usurios alvo, esto utilizando regularmente o produto aps um perodo de trs semanas de familiarizao.
Consideraes Utilize a seo 3, Usurios do Produto, para assegurar que voc tenha considerado os requisitos de usabilidade a partir da perspectiva de cada tipo deles. Pode ser necessrio ocorrerem sesses de consultas especiais com os usurios e seu cliente, para determinar se quaisquer consideraes de usabilidade especiais devem ser adicionadas ao produto. Voc tambm pode considerar consultar um laboratrio de ensaios experiente para testar a utilizao dos produtos que estejam na situao de projeto (sees 17 deste modelo) similares sua. 11b. Personalizao e Internacionalizao de Requisitos Contedo Esta seo descreve a maneira na qual o produto pode ser alterado ou configurado, para levar em conta as preferncias pessoais dos usurios ou a escolha do idioma. Os requisitos de personalizao devem abordar temas tais como os seguintes: Idiomas, preferncias fonticas, e expresses idiomticas Moeda, incluindo os smbolos e convenes decimais Configuraes de opes pessoais
Motivao Assegurar que os usurios do produto no precisem competir com ele, ou aceitar com submisso, as convenes culturais dos construtores. Exemplos O produto deve manter as preferncias de aquisio do comprador. Consideraes Considere o pas e a cultura dos potenciais consumidores e usurios de seu produto. Quaisquer usurios estrangeiros daro boas vindas oportunidade de converter sua fontica e s expresses nativas. Permitindo aos usurios realizar adaptaes sob medida na maneira de utilizar o produto, voc proporciona a oportunidade de participar com maior proximidade sua organizao bem como o usurio poder desfrutar de sua experincia pessoal. Voc tambm pode considerar a configurabilidade do produto. Ela permite a usurios distintos realizarem diferentes variaes funcionais no produto.
11c. Requisitos de Aprendizagem Contedo Especificar os requisitos da maneira mais simples possvel para tornar fcil a utilizao do produto. Esta curva de aprendizado se estende desde o tempo zero, para produtos dirigidos ao mercado de domnio pblico (por exemplo, um parqumetro ou um portal digital), a um montante bastante considervel para produtos de altssima complexidade tcnica. (Conhecemos um produto onde foi necessrio, mesmo para engenheiros graduados, despender 18 meses em um programa de treinamento, antes de estarem qualificados para utilizlo). Motivao Quantificar o tempo que seu cliente define ser adequado at que o usurio possa utilizar o produto com sucesso. Este requisito direciona os desenhistas compreenso da maneira com que os usurios vo aprender sobre o produto. Por exemplo, os desenhistas podem criar dispositivos de auxlio interativos bem elaborados no produto, ou ele pode ser embalado junto a instrues especficas. Alternativamente, o produto pode ser construdo de maneira que todas as suas funcionalidades sejam aparentes ao primeiro contato com ele. Exemplos O produto deve ser fcil de um engenheiro aprender. Um assistente deve ser capaz de estar produtivo em pouqussimo tempo. O produto deve ser capaz de ser utilizado por integrantes do pblico que no recebero treinamento antes de manuse-lo. O produto deve ser usado por engenheiros que participaro de cinco semanas de treinamento antes de utiliz-lo. Critrio de Ajuste Um engenheiro deve produzir um [resultado especfico] dentro [do prazo especificado] do incio do uso do produto, sem a necessidade de consulta ao manual. Aps receber [o nmero de horas] treinando um auxiliar que deve ser capaz de produzir [quantidade de sadas especificadas] por [unidade de tempo]. [A porcentagem compatvel] para o teste de um painel deve ser completada com sucesso [tarefa especfica] dentro [do tempo limite especificado]. Os engenheiros devem atingir [a porcentagem compatvel] dentro do tempo delimitado para as avaliaes do treinamento. Consideraes Verifique a seo 3, Usurios do Produto, para assegurar que voc
tenha considerado a facilidade de aprendizado a partir da perspectiva de todos os diferentes tipos de usurios. 11d. Requisitos de Expectativas e Elegncia Esta seo preocupa-se em encontrar requisitos relacionados aos conceitos e metforas que sejam familiares aos usurios alvo. Contedo Especificar requisitos do produto que sejam compreendidos por seus usurios. Enquanto usabilidade diz respeito facilidade de manuseio, eficincia, e caractersticas similares, expectativas determinam se os usurios sabem instintivamente o que o produto ir realizar por eles e como ele se adapta s suas vises do mundo. Voc pode pensar sobre as expectativas do produto como ele sendo elegante aos seus usurios e no esperando que eles saibam ou aprendam coisas que no tenham nada a ver com o problema de seu negcio. Motivao Evitar que os usurios sejam forados a aprender termos e conceitos que faam parte da construo interna do produto e no sejam relevantes ao mundo deles. Tornar o produto mais compreensvel e, desta forma, mais atraente a seus usurios alvo. Exemplos O produto deve usar smbolos e palavras que sejam compreendidas naturalmente pela comunidade usuria. O produto deve ocultar do usurio seus detalhes construtivos. Consideraes Verifique a seo 3, Usurios do Produto, e considere o mundo do ponto de vista de cada um dos diferentes tipos de usurio. 11e. Requisitos de Acessibilidade Contedo Requisitos que definem o quanto deve ser fcil acessar o produto por pessoas com deficincias comuns. Estas deficincias podem estar relacionadas a incapacidades fsicas, visuais, auditivas, cognitivas ou outras. Motivao Em muitos pases exigido que alguns produtos comutem de disponveis para indisponveis. Em qualquer evento, trata-se de um caso de auto proteo, excluir esta comunidade mensurvel de clientes potenciais. Exemplos O produto deve ser utilizvel por usurios com viso parcial.
O produto deve estar de acordo com a lei Americanos com Aes Incapazes (ADA 26/07/1990). Consideraes Alguns usurios tem outras incapacidades que as comumente descritas. Da mesma forma, algumas incapacidades so bastante corriqueiras. Um exemplo simples, e de pequenas consequncias, que, 20 por cento dos homens so daltnicos.
12. Requisitos de Desempenho

12a. Requisitos de Velocidade e Latncia Contedo Determina a quantidade de tempo disponvel para completar tarefas especficas. Estes requisitos, frequentemente, referem-se aos tempos de resposta. Eles tambm podem estar relacionados capacidade do produto em operar a uma velocidade adequada ao seu ambiente. Motivao Alguns produtosusualmente de tempo realdevem ser capazes de desempenhar algumas de suas funcionalidades em um dado tempo de comutao. Erros ao realiz-las podem significar falhas catastrficas (por exemplo, radar de um avio falha em detectar uma montanha que se aproxima) ou o produto no atende o volume de uso exigido (por exemplo, uma mquina automatizada de venda de bilhetes). Exemplos Qualquer interface entre um usurio e o sistema automatizado deve ter um tempo mximo de resposta de 2 segundos. A resposta deve ser rpida suficiente para evitar interrupo no fluxo de pensamento do usurio. O produto deve verificar os sensores a cada 10 segundos. O produto deve buscar os novos parmetros de operao em 5 minutos antes da mudana de estado. Critrio de Ajuste Critrios de Ajuste so necessrios quando a descrio do requisito no est quantificada. Portanto, descobrimos que a maioria dos requisitos de desempenho est situada em termos de quantificao. A exceo o segundo requisito mostrado acima, para a qual se sugere que o critrio de ajuste seja: O produto deve responder em menos de 1 segundo para 90 por cento das solicitaes. Nenhuma resposta deve levar mais que 2,5 segundos.
Consideraes H uma larga variao na importncia dos diferentes tipos de requisitos de velocidade. Se voc estiver trabalhando em sistema de direcionamento de msseis, ento a velocidade extremamente importante. Em contraste, um relatrio de controle de inventrio que executado uma vez a cada seis meses tem pouqussima necessidade de tempo de resposta imediata. Adapte esta seo do Modelo aos exemplos de requisitos de velocidade dados, que sejam importantes dentro do seu ambiente. 12b. Requisitos Segurana Crtica Contedo Quantificao dos riscos reconhecidos de danos s pessoas, propriedade e ambiente. Pases diferentes tem padres distintos, ento o critrio de ajuste deve especificar precisamente quais deles o produto deve atingir. Motivao Entender e sinalizar danos potenciais que possam ocorrer enquanto usando o produto, dentro do ambiente operacional esperado. Exemplos O produto no deve emitir gases nocivos sade. O trocador de calor deve ser protegido do contato humano. Critrio de Ajuste O produto deve ser certificado para cumprir o modelo E110-98 do Departamento de Sade. Certificao realizada por engenheiros de testes qualificados. Nenhum elemento do painel de testes de [tamanho especificado] pode ser capaz de tocar o trocador de calor. O trocador de calor tambm deve cumprir os padres de segurana [especifique cada um]. Consideraes Os requisitos aqui exemplificados aplicam-se a alguns, mas no a todos os produtos. No possvel dar exemplos para cada variao da segurana crtica. Para fazer o modelo funcionar em seu ambiente, voc deve adapt-lo atravs da adio de exemplos que sejam especficos aos seus produtos. Esteja ciente, tambm, de que pases diferentes tem normas de segurana e leis relacionadas distintas. Se voc planeja vender seu produto internacionalmente, voc deve conhecer tais leis. Se voc pretende, por exemplo, comercializar produtos eltricos, sugerimos seguir as normas Alems pois, desta forma, um maior nmero de pases os validar.
Se voc estiver construindo sistemas de segurana crtica, provavelmente, os padres relevantes para ela j estaro bem especificados. muito importante ter especialistas em segurana em sua equipe. So as melhores fontes de requisitos de segurana crtica para seu produto. Eles iro, quase que certamente, ter informaes em abundncia que voc possa utilizar. Consulte seu departamento jurdico. Membros deste departamento estaro cientes dos tipos de casos precedentes de falha de segurana de produto. Este , provavelmente, o melhor lugar para comear a gerar requisitos relevantes de segurana. 12c. Requisitos de Preciso ou Exatido Contedo Quantificao da exatido desejada dos resultados atingidos pelo produto. Motivao Alcanar as expectativas dos clientes e usurios quanto preciso do produto. Exemplos Toda quantia monetria deve ser exata em duas posies decimais. Preciso das leituras de temperatura da rodovia deve estar entre 2C. Consideraes Se voc realizou um trabalho bem detalhado nas definies, ento alguns requisitos de preciso podem estar adequadamente dispostos na seo 5. Voc pode pensar cuidadosamente com quais unidades de medida o produto vai operar. Leitores vo se lembrar da nave espacial que colidiu com Marte, ocasio na qual as coordenadas foram enviadas em dados mtricos, em vez de dados imperiais. O produto pode tambm necessitar manter a hora exata, estar sincronizado com um servidor de hora, ou trabalhar no sistema UTC (Tempo Universal Coordenado). Da mesma forma, estar ciente de que algumas moedas no possuem ponto decimal, tais como o Yen Japons. 12d. Requisitos de Confiabilidade e Disponibilidade. Contedo Esta seo quantifica a confiabilidade necessria do produto. A confiabilidade usualmente expressa como o tempo permissvel entre falhas, ou a taxa permitida total delas.
Esta seo tambm quantifica a disponibilidade esperada do produto. Motivao crtico para alguns produtos no falharem com muita frequncia. Esta seo permite a voc explorar a possibilidade da falha e especificar nveis realsticos de servio. Oferece tambm, a oportunidade de determinar as expectativas dos clientes e usurios quanto quantidade de tempo que o produto estar disponvel para utilizao. Exemplos O produto deve estar disponvel para uso 24 horas por dia, 365 dias por ano. O produto deve estar disponvel para uso entre 8h00m e 17h30m. A escada rolante deve funcionar de 6h00m s 22h00m, ou at que o ltimo avio pouse. O produto deve estar disponvel 99 por cento do tempo. Consideraes Pense, cuidadosamente, se o requisito real para seu produto aquele que o torne disponvel para uso incessante ou que ele jamais falhe. Considere tambm o custo da confiabilidade e disponibilidade, e se justificado para seu produto. 12e. Requisitos de Robustez ou Tolerncia a Falhas Contedo A robustez especifica a habilidade do produto continuar a funcionar sob circunstncias anormais. Motivao Garantir que o produto seja capaz de fornecer alguns ou todos seus servios, depois ou durante algum acontecimento anormal em seu ambiente. Exemplos O produto deve permanecer operando em modo local mesmo quando perdida a conexo com o servidor central. O produto deve prover 10 minutos de operao de emergncia se desconectado da fonte de energia eltrica. Consideraes Eventos anormais podem ser considerados quase normais. Os produtos atuais so to extensos e complexos que existe uma boa chance que, num dado momento, um componente venha a funcionar incorretamente. Requisitos de robustez tem a inteno de prevenir a falha total do produto.
Voc tambm pode considerar a recuperao de uma falha nesta seo. Este plano descreve a habilidade do produto em restabelecer desempenho aceitvel aps falhas ou eventos anormais. 12f. Requisitos de Capacidade Contedo Esta seo especifica os volumes que o produto deve ser capaz de administrar e a quantidade de dados armazenados por ele. Motivao Garantir que o produto capaz de processar os volumes esperados. Exemplos O produto deve atender 300 usurios simultneos de 09h00m s 11h00m. Carga mxima, em outros perodos, ser de 150 usurios simultneos. Durante a hora do almoo, o produto deve atender, no mximo, 20 pessoas no interior da sala. Critrio de Ajuste Neste caso, a descrio do requisito quantificada e, portanto, pode ser testada. 12g. Requisitos de Escala ou Extenso Contedo Especifica o aumento esperado no tamanho que o produto deve ser capaz de segurar. medida que um negcio cresce (ou se espera que cresa), nossos programas de computadores devem aumentar suas capacidades de atender os novos volumes. Motivao Garantir que os desenhistas possam prever capacidades futuras. Exemplos O produto deve ser capaz de processar os 100.000 clientes existentes. Espera-se que este nmero aumente para 500.000 clientes dentro de trs anos. O produto deve ser capaz de processar 50.000 transaes por hora dentro de dois anos de seu lanamento. 12h. Requisitos de Longevidade Contedo Especifica o tempo de vida esperado do produto.
Motivao Garantir que o produto seja construdo com base no entendimento do retorno esperado sobre o investimento. Exemplos Deve-se se esperar que o produto opere dentro de um oramento mximo de manuteno, por no mnimo cinco anos.
13. Requisitos Operacionais e Ambientais

13a. Ambiente Fsico Esperado Contedo Esta seo especifica o ambiente fsico no qual o produto ir operar. Motivao Sinalizar condies que possam necessitar de requisitos especiais, preparaes, ou treinamentos. Estes requisitos garantem que o produto esteja ajustado para ser utilizado no ambiente previsto. Exemplos O produto deve ser utilizado por um trabalhador, em p, em ambiente externo frio, em condies de chuva. O produto deve ser utilizado em condies de rudo e muita poeira. O produto deve ser capaz de caber na bolsa ou no bolso. O produto deve ser utilizado com iluminao reduzida. O produto no deve ter volume sonoro mais alto que o nvel de rudo existente no ambiente. Consideraes O ambiente de trabalho: O produto vai operar em algum ambiente no usual? Esta condio necessita requisitos especiais? Veja tambm a seo 11, Recursos de Usabilidade e Humanidade. 13b. Requisitos para as Interfaces com os Sistemas Adjacentes Contedo Esta seo descreve os requisitos para a interface entre a aplicao e/ou dispositivos parceiros que o produto necessita, para operar com sucesso. Motivao Requisitos para interfaces com outras aplicaes, normalmente, permanecem ocultas at o tempo de implementao. Evite um alto grau de retrabalho atravs da descoberta prvia destes requisitos.
Exemplos Os produtos devem funcionar nas ltimas quatro edies dos cinco navegadores mais populares. A nova verso da tabela deve ser capaz de acessar os dados das duas verses anteriores. Nosso produto deve fazer interface com as aplicaes que atuam nas estaes climticas. Critrio de Ajuste Para cada interface de aplicao, especifique os seguintes elementos: O contedo dos dados O contedo do material fsico O meio que carrega a interface A frequncia O volume
13c. Requisitos de Produo Contedo Quaisquer requisitos que sejam necessrios para fazer o produto um item distribuvel ou vendvel. apropriado descrever aqui tambm as operaes necessrias para instalar um programa aplicativo com sucesso. Motivao Garantir que, se um trabalho deve ser realizado para fazer o produto ter sucesso, ento ele se torna parte dos requisitos. Da mesma forma, quantificar as expectativas dos clientes e usurios sobre o tempo, dinheiro e recursos que eles precisaro para alocar e instalar o produto. Exemplos O produto deve ser distribudo em arquivo ZIP. O produto deve ser capaz de ser instalado por usurio no treinado, sem recorrer s instrues impressas. O produto deve caber em um CD. Consideraes Alguns produtos tem necessidades especiais para tornarem-se vendveis ou utilizveis. Voc pode considerar que o produto tem que ser protegido de maneira que, apenas clientes pagantes possam acess-lo. Faa perguntas ao seu departamento comercial para encontrar suposies no concludas, que tenham sido feitas sobre o ambiente
especificado e as expectativas dos clientes, de quanto tempo a instalao ir levar e quanto ir custar. A maioria dos produtos comerciais tem necessidades neste aspecto. 13d. Requisitos de Lanamento Contedo Especificao do ciclo de lanamento pretendido para o produto e a forma que sua liberao deve tomar. Motivao Fazer todos cientes de, com que frequncia voc pretende produzir novos lanamentos do produto. Exemplos Os lanamentos de manuteno sero oferecidos aos usurios finais uma vez ao ano. Cada lanamento no deve produzir falhas em recursos anteriores. Critrio de Ajuste Descrio do tipo de manuteno, mais o oramento empenhado a ela. Consideraes H algum compromisso contratual ou acordos de manuteno que possam ser afetados pelo novo produto?
14. Requisitos de Mantenabilidade e Suporte

14a. Requisitos de Manuteno Contedo Uma quantificao do tempo necessrio para realizar mudanas especficas no produto. Motivao Fazer todos cientes da necessidade de manuteno do produto. Exemplos Novos relatrios MIS (Sistema de Gerenciamento de Informaes) devem estar disponveis dentro de uma semana, a partir da data em que os requisitos estiverem estabelecidos. Uma nova estao climtica deve poder ser adicionada ao sistema durante a noite. Consideraes Pode haver requisitos especiais para a mantenabilidade, tais como o
produto ter sua manuteno realizada por usurios finais ou pelos seus desenvolvimentistas que, no sejam os originais. Estes requisitos tem efeito sobre a maneira na qual o produto desenvolvido. Em adio, pode haver requisitos para documentao ou treinamento. Voc pode considerar, tambm, escrever requisitos de testabilidade nesta seo. 14b. Requisitos de Suportabilidade Contedo Especifica o nvel de suporte que o produto requer. O suporte frequentemente oferecido atravs de teleatendimento. Se pessoas vo fornecer suporte para o produto, quais servios so considerados parte dele? Existem requisitos para este suporte? Voc pode tambm construir suporte no prprio produto, neste caso, esta seo o lugar para descrever estes requisitos. Motivao Garantir que o aspecto de suporte do produto esteja especificado adequadamente. Consideraes Considere o nvel de suporte antecipado e que forma ele pode tomar. Por exemplo, uma limitao, pode estabelecer que no exista manual impresso. Alternativamente, o produto pode precisar ser inteiramente auto suportado. 14c. Requisitos de Adaptabilidade Contedo Descrio de outras plataformas ou ambientes nos quais o produto deva operar. Motivao Quantificar as expectativas de clientes e usurios sobre a plataforma na qual o produto ser capaz de operar. Exemplos O produto esperado funcionar em Windows XP e Linux. O produto deve, eventualmente, ser vendido no mercado Japons. O produto desenhado para operar em escritrios mas, h a inteno de existir uma verso operando em cozinhas. Critrio de Ajuste Especificao do sistema operacional no qual o produto deve executar. Especificao dos ambientes futuros no qual o produto esperado operar.
Tempo permitido para fazer a transio. Consideraes Questione seu departamento comercial para encontrar suposies no concludas que tenham sido feitas sobre a portabilidade do produto.
15. Requisitos de Segurana

15a. Requisitos de Acesso Contedo Especificao de quem tem acesso autorizado ao produto (funcionalidade e dados), sob que circunstncias ele concedido, e em quais partes do produto o acesso permitido. Motivao Entender quais as expectativas confidencialidade do sistema. Exemplos Apenas gerentes diretos podem ver os registros pessoais de sua equipe. Apenas detentores oficiais do sistema de segurana podem adentrar o prdio. Critrio de Ajuste Nome da funo ou dos dados do sistema. Papeis dos usurios e/ou nomes das pessoas que tenham permisso. Consideraes Existe algum dado que a gerncia considere ser sensvel? Existe algum dado que a gerncia no deseje que os usurios de nvel inferior acessem? Existem processos que possam causar danos ou serem usados para ganho pessoal? Existem pessoas que no devem ter acesso ao sistema? Evite estabelecer como voc vai desenvolver os requisitos de segurana. Por exemplo, no desenvolva uma senha do sistema. Sua meta aqui identificar o requisito de segurana; o desenvolvimento vir, ento, desta descrio. Considere pedir ajuda. Segurana de computadores um campo altamente especializado, rea onde somente pessoas bem qualificadas atuam. Se seu produto tem necessidade de mais que apenas segurana mdia, recomendamos utilizar uma consultoria de segurana. Tais consultorias no so baratas, mas os resultados de uma segurana inadequada podem ser bem mais caros.
quanto
aos
aspectos
de
15b. Requisitos de Integridade Contedo Especificao da integridade exigida dos bancos de dados ou arquivos, e do prprio produto. Motivao Entender as expectativas da integridade dos dados do produto. Especificar o que o produto ir fazer para garantir sua integridade no caso de um acontecimento indesejado, tal como uma ameaa externa ou uso incorreto acidental, por usurio no autorizado. Exemplos O produto deve impedir que dados incorretos sejam introduzidos. O produto deve proteger-se de abuso intencional. Consideraes As organizaes esto confiando mais e mais em seus dados armazenados. Se estes dados se tornarem corrompidos ou incorretosou desaparecerempoder ocorrer uma ruptura fatal organizao. Por exemplo, quase metade dos pequenos negcios vai quebrar financeiramente depois de um incndio destruir seus sistemas de computadores. Requisitos de integridade tem como meta prevenir perdas totais, bem como evitar corrompimento dos dados e processos. 15c. Requisitos de Privacidade Contedo Especificao do que o produto tem que fazer para garantir a privacidade dos indivduos sobre os quais armazena informaes. O produto deve tambm garantir que todas as leis relacionadas privacidade dos dados de um indivduo sejam observadas. Motivao Garantir que o produto esteja de acordo com a lei e proteja a privacidade individual de seus clientes. Poucas pessoas, atualmente, olham com apreo, organizaes que no observam a privacidade. Exemplos O produto deve tornar seus usurios cientes de suas prticas de informaes antes de coletar seus dados. O produto deve notificar seus clientes sobre as mudanas em sua poltica de informaes. O produto deve revelar informaes particulares apenas se estiverem de acordo com as polticas da organizao. O produto deve proteger informaes particulares em concordncia com leis de privacidade relevantes e, poltica de informaes da
organizao. Consideraes Os temas da privacidade podem ter implicaes legais importantes, recomendamos consultar o departamento jurdico da organizao sobre os requisitos a serem descritos nesta seo. Considere que voc deve notificar seus clientes antes de coletar suas informaes pessoais. A notificao deve alcanar seus clientes, onde estiverem, afim de faz-los cientes da sua inteno de colocar um cookie em seu computador. Da mesma forma, voc no acha que deve fazer o possvel para manter seus clientes informados de que possui suas informaes pessoais? Os clientes devem sempre estar em posio de dar ou consentir permisso quando seus dados particulares so coletados ou armazenados. Igualmente, os clientes devem ser capazes de visualizar quaisquer dados particulares e, onde apropriado, pedir a correo deles. Considere tambm a integridade e segurana dos dados particulares por exemplo, quando voc estiver armazenando informaes do carto de crdito. 15d. Requisitos de Auditoria Contedo Especificao do que o produto tem que fazer (usualmente reter registros) para permitir a verificao requerida pela auditoria. Motivao Construir um sistema que esteja de acordo com regras de auditoria apropriadas. Consideraes Esta seo pode ter implicaes jurdicas. Recomendamos procurar a aprovao dos auditores de sua organizao com respeito ao que voc descreve aqui. Voc tambm deve considerar se o produto possui informaes sobre quem o tem utilizado. A inteno fornecer segurana de forma que o usurio no possa negar mais tarde ter utilizado o produto ou participado, de alguma maneira, da transao realizada nele. 15e. Requisitos de Imunidade Contedo Os requisitos para o quais o produto seja protegido de ser infectado por programas no autorizados ou indesejados, tais como vrus, Cavalos de Tria, entre outros.
Motivao Construir um produto que seja to protegido quanto possvel das interferncias mal intencionadas. Consideraes A cada dia surgem mais violaes do ambiente exterior. Pessoas que compram programa de computadores, ou qualquer outro tipo de produto, esperam que o mesmo seja capaz da auto proteo s interferncias externas.
16. Requisitos Culturais e Polticos

16a. Requisitos Culturais Contedo Esta seo contm requisitos que so especficos aos fatores sociolgicos que afetam a aceitabilidade do produto. Se voc estiver desenvolvendo um produto para mercados externos, ento estes requisitos so particularmente relevantes. Motivao Encontrar estes requisitos, particularmente difceis de elaborar, por estarem alm da experincia cultural dos desenvolvimentistas. Exemplos O produto no pode ser ofensivo a religiosos ou grupos tnicos. O produto deve ser capaz de distinguir entre os sistemas de numerao de rodovias Francs, Italiano e Britnico. O produto deve manter um registro de feriados pblicos para todos os pases da Unio Europeia e para todos os Estados nos EUA. Consideraes Pergunte se o produto dirigido a uma cultura diferente daquela que lhe seja familiar. Questione se as pessoas em outros pases ou em outros tipos de organizao vo utilizar o produto. Estas pessoas tem hbitos diferentes, feriados, supersties, ou normas culturais que no se aplicam sua prpria cultura? Existem cores, cones, ou palavras que tenham significados diferentes em outro ambiente cultural? 16b. Requisitos Polticos Contedo Esta seo contm requisitos que so especficos aos fatores polticos que afetam a aceitabilidade do produto.
Motivao Entender os requisitos que, s vezes, parecem irracionais. Exemplos O produto deve ser instalado utilizando apenas componentes feitos nos EUA. O produto deve tornar todas suas funcionalidades disponveis, apenas ao presidente da empresa. Consideraes Voc tinha a inteno de desenvolver o produto para Macintosh, quando o escritrio da gerncia decretou que apenas mquinas com Windows seriam permitidas? Um dos diretores est, tambm, no comando de uma companhia que fabrica produtos similares ao que voc deseja construir? Se a respostas para estes requisitos polticos for sim, voc tem poucas chances de obter resultados. A realidade que o sistema deve estar de acordo com os requisitos polticos, mesmo se voc puder encontrar uma soluo melhor, mais eficiente ou mais econmica. Umas poucas perguntas de teste nesta etapa, podem poupar dissabores posteriormente. Os requisitos polticos podem estar, unicamente, preocupados com as polticas internas de sua organizao. Entretanto, em outras situaes, voc pode precisar considerar a poltica interna da organizao de seu cliente ou da poltica nacional de um pas.
17. Requisitos Legais

17a. Requisitos Obrigatrios Contedo Uma declarao especificando os requisitos legais do sistema. Motivao Obedecer lei de maneira a evitar atrasos, precedentes legais e encargos jurdicos. Exemplos Informaes pessoais devem ser implementadas de forma a estarem de acordo com o Ato de Proteo de Dados (Reino Unido). Critrio de Ajuste A opinio de juristas de que o produto no desobedece a nenhuma lei.
Consideraes Considerar consultar juristas para auxiliar na identificao de requisitos legais. Existem quaisquer direitos de reproduo ou outros de propriedade intelectual que devem ser protegidos? Igualmente, algum concorrente tem direitos de reproduo nos quais voc possa estar em perigo de infrao? Trata-se de um requisito, que os desenvolvimentistas no tenham visto os cdigos dos concorrentes ou mesmo tenham trabalhado para eles? O Ato Sarbanes-Oxley (SOX), a Portabilidade dos Planos de Sade (HIP), o Ato de Portabilidade e Contabilidade dos Planos de Sade (HIPAA) e o Ato Gramm-Leach-Bliley, podem ter implicaes para voc. Verifique isto com o departamento jurdico de sua empresa. Pode qualquer legislao pendente afetar o desenvolvimento deste sistema? Existem quaisquer aspectos das leis criminais que voc deva considerar? Voc considerou as taxas legais que afetam seu produto? Existem quaisquer leis trabalhistas (por exemplo, horas trabalhadas) relevantes ao seu produto? 17b. Requisitos Padres Contedo Uma declarao especificando padres aplicveis e descries detalhadas referente a eles. Isto no se refere s leis do paspense sobre uma lei interna imposta por sua companhia. Motivao Estar de acordo com os padres, de maneira a evitar atrasos posteriores. Exemplo O produto deve obedecer aos padres MilSpec (Padres Militares EUA). O produto deve obedecer aos padres das empresas seguradoras. O produto deve ser desenvolvido de acordo com os passos de desenvolvimento SSADM (Anlise de Sistemas Estruturados & Metodologia de Desenho). Critrio de Ajuste O padronizador apropriado certifica que o modelo foi aderido a ele. Consideraes Nem sempre aparente existirem padres aplicveis, porque sua
existncia frequentemente tomada por prerrogativa. Considere o seguinte: Alguma indstria tem padres aplicveis? A indstria tem um cdigo de boas prticas, guardio ou responsvel por reclamaes? Existem quaisquer passos especiais de desenvolvimento para este tipo de produto?
18. Temas Abertos

Os temas que foram levantados e no tem ainda uma concluso. Contedo Uma declarao dos fatores que sejam incertos e possam acarretar uma diferena significante no produto. Motivao Abordar incertezas e fornecer sugestes objetivas anlise dos riscos. Exemplos Nossa investigao sobre a verso de processador que atender nossa aplicao ainda est incompleta. O governo planeja modificar as regras sobre quem responsvel por beneficiar as rodovias, mas no sabemos quais mudanas podem ocorrer. Consideraes Existem quaisquer temas que foram levantados a partir da reunio dos requisitos que ainda no foram resolvidos? Voc ouviu algo a respeito de quaisquer mudanas que possam ocorrer em outras organizaes, ou sistemas no seu diagrama de contexto? Existem quaisquer mudanas na legislao que possam afetar seu sistema? Existem rumores sobre seu fornecedor de equipamentos, ou de programas de computador, que possam ter um impacto?
19. Solues Disponveis

19a. Produtos Prontos Contedo Lista dos produtos existentes que devem ser investigados como solues potenciais. Utilize quaisquer pesquisas j realizadas a respeito deles.
Motivao Considerar se a soluo pode ser adquirida. Consideraes Voc pode comprar algo que j existe ou, est para tornar-se disponvel? Pode no ser possvel, neste estgio, fazer esta determinao com muita confiana, mas quaisquer produtos satisfatrios devem ser listados aqui. Considere, tambm, se alguns produtos no devem ser utilizados. 19b. Componentes Reutilizveis Contedo Descrio dos componentes candidatos, comprados ou construdos por sua empresa, que possam ser utilizados neste projeto. Elenque bibliotecas que possam ser fonte de componentes. Motivao Reutilizar, mais que reinventar. 19c. Produtos Que Podem Ser Copiados Contedo Lista de outros produtos similares ou partes de produtos que possam ser copiados legalmente ou facilmente modificados. Motivao Reutilizar, mais que reinventar. Exemplos Uma outra empresa de eletricidade construiu um sistema de servio ao cliente. Seu equipamento diferente do nosso, mas podemos comprar sua especificao e reduzir nosso esforo de anlise em aproximadamente 60 por cento. Consideraes Enquanto uma soluo pronta pode no existir, talvez algo, em sua essncia, seja similar o suficiente para que voc possa copiar e, possivelmente modificar, obtendo melhor efeito que partir do rascunho. Esta aproximao potencialmente perigosa porque confia, com base em um sistema ser de boa qualidade. Esta pergunta deve ser respondida sempre. O ato de respond-la vai proporcionar buscar outras solues existentes para problemas similares.
20. Novos Problemas

20a. Efeitos Sobre o Ambiente Atual Contedo Uma descrio de como o novo produto afetar o ambiente atual de implementao. Esta seo deve cobrir tambm tarefas que o novo produto no deve realizar. Motivao Descobrir, previamente, qualquer conflito potencial que possa, de alguma maneira, no ser percebido dentro do tempo de implementao. Exemplos Qualquer mudana no sistema de agendamento afetar o trabalho dos engenheiros na diviso de tarefas e, dos motoristas dos caminhes. Consideraes possvel que o novo sistema possa danificar algum outro existente? As pessoas podem ser deslocadas ou, de alguma forma, afetadas pelo novo sistema? Estes temas requerem um estudo do ambiente atual. Um modelo enfatizando os efeitos da mudana uma boa maneira de fazer esta informao amplamente compreendida. 20b. Efeitos Sobre os Sistemas Instalados Contedo Especificao das interfaces entre os novos e os sistemas existentes. Motivao Muito raramente, um novo desenvolvimento pretende trabalhar completamente sozinho. Usualmente, o novo sistema deve coexistir com algum mais antigo. Esta questo fora voc a olhar cuidadosamente para o sistema existente, examin-lo para conflitos potenciais com o novo desenvolvimento. 20c. Problema Potenciais do Usurio Contedo Detalhes de qualquer reao adversa que possa ser sofrida pelos usurios. Motivao Algumas vezes, usurios esto utilizando um produto de tal maneira que ir faz-los sofrer efeitos indesejados do novo sistema ou de seus elementos. Identifique quaisquer reaes adversas dos usurios e
determine se elas requerem cuidados e, que precaues devem ser tomadas. 20d. Limitaes no Ambiente de Implementao Antecipado Que Possam Inibir o Novo Produto Contedo Uma declarao de quaisquer problemas potenciais com a nova tecnologia automatizada ou, novas maneiras de estruturar a organizao. Motivao A inteno fazer descoberta antecipada de quaisquer conflitos potenciais que possam, de alguma forma, no serem percebidos at o tempo de implementao. Exemplos O novo servidor planejado no robusto o suficiente para alcanar o padro crescente de nosso projeto. Tamanho e peso do novo produto no se encaixam no ambiente fsico. A potncia disponvel no ir satisfazer o consumo projetado para o produto. Consideraes Isto requer um estudo do ambiente de implementao desejado. 20e. Problemas de Acompanhamento Contedo Identificao de situaes que possam no ser capazes de super-los. Motivao Preservar-se das situaes em que o produto possa falhar. Consideraes Criaremos uma demanda para o nosso produto na qual no somos capazes de prestar servio? O novo sistema ir nos causar coliso com leis que no se aplicam atualmente? O equipamento existente suportar? Existem centenas de efeitos potenciais indesejados. Esteja atento a estas questes, cuidadosamente.
21. Tarefas
21a. Planejamento do Projeto Contedo Detalhes do ciclo de vida e da aproximao que ser utilizada para entregar o produto. Um diagrama de processo de alto nvel exibindo as tarefas e as interfaces entre elas, uma boa maneira de comunicar esta informao. Motivao Especificar a aproximao que ser tomada para entregar o produto, de maneira que todos tenham as mesmas expectativas. Consideraes Dependendo do nvel de maturidade de seu processo, o novo produto ser desenvolvido utilizando sua aproximao padro. Entretanto, algumas circunstncias so nicas para um produto em particular, e necessitaro de mudanas em seu ciclo de vida. Enquanto estas consideraes no representam requisitos do produto, elas so necessrias para que ele seja desenvolvido com sucesso. Se possvel, agregue um tempo estimado e os recursos necessrios para cada tarefa, baseado nos requisitos que voc especificou. Anexe suas estimativas aos eventos, utilize casos e/ou funes que voc especificou nas sees 8 e 9. Lembre-se dos temas relacionados s converses de dados, treinamento de usurios e cortes. Estas necessidades so usualmente ignoradas quando o projeto determina as datas da implementao. 21b. Planejamento das Fases de Desenvolvimento Contedo Especificao de cada fase de desenvolvimento e os componentes no ambiente operacional. Motivao Identificar as fases necessrias para implementar o ambiente operacional para o novo sistema, de maneira que a implementao possa ser gerenciada. Critrio de Ajuste Nome da fase. Data operacional requerida. Ambiente operacional e componentes includos. Requisitos funcionais includos. Requisitos no funcionais includos.
Consideraes Identifique quais equipamentos e outros dispositivos so necessrios para cada fase do novo sistema. Esta lista pode estar indisponvel na poca do processo de requisitos, medida que eles vo sendo descobertos na ocasio do desenvolvimento.
22. Migrao do Novo Produto

22a. Requisitos de Migrao para Novo Produto Contedo Uma lista de atividades de converso. Tabela dos tempos de implementao. Motivao Identificar as tarefas de converso medida que vo sendo inseridas ao processo de planejamento do projeto. Consideraes Utilizaremos uma implementao fsica para instalar o novo sistema? Se sim, descreva quais requisitos sero implementados por cada uma das fases majoritrias. Que tipo de converso de dados necessria? Programas especiais devem ser escritos para transportar dados de um sistema existente para o novo? Se sim, descreva, nesta seo, os requisitos para estes programas. Que tipo de cpia de segurana manual necessria enquanto o sistema instalado? Quando componentes majoritrios estaro prontos para serem colocados no lugar? Quando as fases de implementao sero liberadas? Existe a necessidade de executar o novo produto em paralelo com o existente? Necessitaremos de uma equipe diferente ou suplementar? necessrio algum esforo adicional para desativar o produto antigo? Esta seo a tabela temporal para a implementao do novo sistema. 22b. Dados que Devem Ser Modificados ou Traduzidos para o Novo Sistema Contedo Lista de tarefas da traduo dos dados.
Motivao Encontrar tarefas esquecidas que afetaro o tamanho e as fronteiras do projeto. Critrio de Ajuste Descrio da tecnologia atual que sustenta os dados. Descrio da nova tecnologia que sustentar os dados. Descrio de tarefas da traduo dos dados. Problemas previsveis. Consideraes Toda vez que realizar uma adio ao seu dicionrio (veja seo 5), faa esta pergunta: Onde esto estes dados atualmente armazenados e, o novo sistema afetar esta implementao?
23. Riscos
Todos os projetos envolvem riscosespecificamente, o risco de que algo errado acontea. O risco no , necessariamente, algo ruim. Nenhum progresso feito sem que exista algum risco. Entretanto, h uma diferena entre risco no gerenciadocomo jogar dadose risco gerenciado, onde as probabilidades so bem entendidas e planos de contingncia so feitos. Riscos apenas so algo ruim se ignorados e se tornam problemas. Gerenciamento de riscos obriga determinar aqueles mais evidentes que se apliquem ao projeto, decidindo um curso de ao se eles se tornarem problemas e, monitorar projetos para dar alertas antecipados de sua ocorrncia. Esta seo de suas especificaes deve conter uma lista dos riscos mais evidentes e daqueles mais srios para o seu projeto. Para cada risco, inclua a probabilidade dele se tornar um problema. O livro Determinao e Controle de Riscos em Programas de Computadores (Prentice-Hall, Englewood Cliffs, N.J., 1994), d uma lista compreensiva e suas probabilidades; voc pode utilizar esta lista como um ponto de partida. Por exemplo, Jones cita os seguintes riscos como sendo os mais srios: Mtrica imprecisa Medio inadequada Presso excessiva da agenda Ms prticas de gerenciamento
Estimativa de custos imprecisa Sndrome da bala de prata Exigncias de usurios pessimistas Baixa qualidade Baixa produtividade Projetos cancelados Utilize seu conhecimento de requisitos como um estmulo para descobrir quais riscos so mais relevantes ao seu projeto. Tambm, uma adio til ao gerenciamento do projeto, incluir o impacto na agenda, ou o custo, se o risco se tornar um problema.
24. Custos
Para detalhes sobre como estimar esforos e custos de requisitos, verifique em Contagem do Ponto Funcional, Apndice C: Uma Introduo Simplificada. O outro custo dos requisitos o investimento financeiro ou esforo que voc teve que despender, os inserindo no produto. Uma vez que as especificaes de requisitos esteja completa, voc pode utilizar um dos mtodos estimativos para determinar o custo, expressando os resultados como um investimento ou o tempo para construir. No h mtodo melhor que outro a ser utilizado, quando estimando. Tenha em mente, entretanto, que suas estimativas devem ser baseadas em algum aspecto contvel e tangvel. Se voc estiver utilizando este Modelo, como resultado da realizao do trabalho de especificaes, ento voc est produzindo muitos resultados mensurveis. Por exemplo: Nmero de fluxos de entrada e sada no contexto de trabalho Nmero de eventos do negcio Nmero de casos de uso do produto Nmero de requisitos funcionais Nmero de requisitos no funcionais Nmero de restries dos requisitos Nmero de pontos de funo
Quanto mais detalhado o trabalho realizado nos requisitos mais precisos sero seus resultados. Sua estimativa de custos a quantidade de recursos estimada para cada resultado alcanado em
seu ambiente prprio. Voc pode criar algumas estimativas prvias de custos, baseado no contexto do trabalho. Neste estgio, seu conhecimento do trabalho ser generalizado, e voc deve refletir sobre esta falta, fazendo do custo estimado um escopo mais preciso que apenas uma imagem simplificada. medida que voc aumenta seu conhecimento dos requisitos, sugerimos que voc tente utilizar a contagem de ponto de funono porque seja um mtodo superior intrnseco, mas devido ser amplamente aceito. Tanto se conhece da contagem de ponto de funo que, possvel realizar comparaes simples com outros produtos e outras instalaes de produtividade. importante que seu cliente seja avisado, neste estgio, que o produto adequado ao custo. Usualmente, esta quantidade expressa como custo total para completar o produto, mas possvel tambm encontrar vantagens em apontar o custo do empenho nos requisitos, ou os custos de requisitos individuais. No importa o que seja feito, no deixe que os custos caiam nos devaneios do otimismo. Tenha certeza de que esta seo inclui nmeros significativos baseados em resultados tangveis.
25. Documentao de Usurio e Treinamento

25a. Requisitos de Documentao de Usurio Contedo Lista da documentao de usurio a ser fornecida como parte do produto. Motivao Determinar as expectativas para a documentao e identificar quem ser responsvel por cri-la. Exemplos Especificaes tcnicas que acompanhem o produto. Manuais de usurio. Manuais de servio (se no abordado nas especificaes tcnicas). Manuais de procedimento de emergncia (por exemplo, os cartes encontrados em avies). Manuais de instalao. Consideraes Quais documentos voc precisa entregar e, a quem? Tenha em mente que a resposta a esta pergunta depende dos procedimentos em sua organizao e de seus papeis.
Para cada documento, considere estes assuntos: O propsito do documentos As pessoas que iro utilizar o documento Manuteno do documento
Que nvel de documentao esperado? Os usurios estaro envolvidos na produo da documentao? Quem ser responsvel em manter a documentao atualizada? Que forma a documentao tomar? 25b. Requisitos de treinamento Contedo Uma descrio do treinamento necessrio para os usurios do produto. Motivao Determinar as expectativas para o treinamento. Identificar quem o responsvel por criar e fornecer o treinamento. Consideraes Que treinamentos sero necessrios? Quem treinamento? Quem vai fornecer o treinamento? vai elaborar o
26. Sala de Espera

Requisitos que no faro parte do prximo lanamento. Estes requisitos podem ser includos em lanamentos futuros do produto. Contedo Qualquer tipo de exigncia. Motivao Permitir que os requisitos sejam reunidos, mesmo se no puderem fazer parte do desenvolvimento atual. Garantir que boas ideias no sejam perdidas. Consideraes O processo de reunio dos requisitos, frequentemente, apresenta aqueles que esto alm da sofisticao ou, do tempo permitido para o lanamento do produto. Esta seo coloca os requisitos na espera. A inteno evitar a supresso da criatividade dos usurios e clientes, utilizando uma espcie de armazm para guardar requisitos futuros. Voc gerencia tambm expectativas, tornando claro que leva estes requisitos seriamente, apesar deles no fazerem parte do produto final, neste momento. Muitas pessoas utilizam a sala de espera como uma maneira de planejar verses futuras do produto. Cada requisito na sala de espera
etiquetado com o nmero da verso pretendida. medida que um requerimento progride, mais prximo implementao, voc pode despender mais tempo sobre ele e adicionar detalhes, tais como o custo benefcio agregado. Voc tambm pode priorizar os contedos da sala de espera. Ao alcance de suas mosrequisitos que fornecem um alto benefcio a baixo custo de implementaoso os candidatos mais cotados para o prximo lanamento. Voc pode tambm dar um alto valor sala de espera dos requisitos, para os quais exista uma demanda reprimida.
27. Ideias para Solues

Quando voc rene requisitos, voc focaliza em descobrir quais deles so reais e tenta evit-los com solues futuras. Entretanto, quando pessoas criativas comeam a pensar no problema, elas sempre geram ideias sobre solues potenciais. Esta seo do Modelo apresentada para colocar estas ideias de maneira a serem lembradas e de que possam serem separadas dos requisitos reais do negcio. Contedo Qualquer ideia para uma soluo, que pense valer a pena manter para futuras consideraes. Isto pode levar a formar anotaes primrias, rascunhos, apontar outros documentos, apontar pessoas, ndices para produtos existentes e assim por diante. A meta capturar, com um mnimo de esforo, uma ideia que possa retornar mais tarde. Motivao Garantir que boas ideias no sejam perdidas. Auxiliar na separao dos requisitos das solues. Consideraes Enquanto voc rene os requisitos, inevitavelmente, ter ideias para solues; esta seo oferece uma maneira de captur-las. Tenha em mente que esta seo no ser, necessariamente, includa em todo documento publicado.

Vol Ere

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Vol Ere

Enviado por

Direitos autorais:

Formatos disponíveis

Modelo para Especificaes de Requisitos

Edio 14Agosto 2009

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /2

quando gerenciando um projeto.

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /4

Motivao Falhas em considerar todos os interessados resultam em ausncia de requisitos importantes.

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /10

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /11

4. Nomeando Convenes e Definies

5. Fatos e Suposies Relevantes

Copyright the Atlantic Systems Guild Limited

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /19

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /20

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /21

1. Estao Climtica transmite Leituras da Estao a leitura Climtica (E)

Registre a estao climtica e anexe-a as rodovias apropriadas.

5. Engenheiro de Estrada modifica a Estao Climtica 6. Hora de testar a Estao Climtica

Estao Climtica Modificada (E)

Registre as modificaes da estao climtica.

9. Caminho beneficia uma estrada

Rodovia Beneficiada (E)

7. Modelo dos Dados do Negcio

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /25

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /26

Data Agendada do Beneficiamento

Hora Agendada de Incio HH/MM/SS do Beneficiamento Relgio de 24 horas Consideraes

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /27

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /28

9. Requisitos Funcionais e dos Dados

10. Requisitos de Aparncia e Sensaes

11. Requisitos de Usabilidade e Humanidade

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /33

12. Requisitos de Desempenho

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /40

13. Requisitos Operacionais e Ambientais

14. Requisitos de Mantenabilidade e Suporte

15. Requisitos de Segurana

16. Requisitos Culturais e Polticos

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /48

17. Requisitos Legais

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /49

18. Temas Abertos

19. Solues Disponveis

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /52

20. Novos Problemas

Copyright the Atlantic Systems Guild Limited

Volere Template V14 /54

22. Migrao do Novo Produto