Requisitos de software

Requisitos - Definio
Objetivos ou restries estabelecidas por clientes e usurios do sistema que definem as diversas propriedades do sistema; Condio ou capacidade necessria que o software deve possuir:
para que o usurio possa resolver um problema ou atingir um objetivo para atender as necessidades ou restries da organizao ou de outros componentes

Requisitos - Definio
Segundo a IEEE pode ser entendido como Condio ou capacidade que deve ser alcanada ou possuda por um sistema, para satisfazer um padro, contrato, especificao ou outro documento formal; Segundo Sommerville Descries de como o sistema deve se comportar ou suas propriedades. Podem tambm ser restries no processo de desenvolvimento;

Requisitos - Definio
s vezes o termo requisitos empregado, no entanto sem estabelecer consistentemente sua definio:

Em alguns casos, um requisito visto como uma declarao abstrata, de alto nvel, de um funo que o sistema deve fornecer ou de uma restrio do sistema.

Em outro extremo, ele pode ser uma definio detalhada, matematicamente formal, de uma

Natureza dos Requisitos

RASTREABILIDADE

REQUISITOS DE SOFTWARE

Classificao dos Requisitos Requisitos de usurio Requisitos de sistema

Requisitos de desenho Quanto a visibilidade

Quanto a natureza Funcionais No funcionais Domnio

Classificao dos Requisitos Quanto a Visibilidade

Requisitos do usurio: declaraes, em linguagem natural e diagramas, sobre os servios que o sistema oferece e as restries para a sua operao. Escrito para os clientes;

Requisitos do sistema: estabelecem detalhadamente as funes e restries do sistema. O documento de requisitos, chamado de especificao funcional, pode servir como um contrato entre cliente e desenvolvedor;

Requisitos de desenho(Especificao de software): especificao abstrata e precisa do software, indicando o que ele deve fazer (sem dizer como) que serve de base para o design e implementao. Acrescenta mais detalhes especificao funcional e escrito para a equipe de desenvolvimento;

Classificao dos Envolvidos Requisitos

Classificao dos Requisitos

Quanto a natureza
Requisitos Funcionais:

Declaraes de funes que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como deve se comportar em dada situaes; Descrevem a funcionalidade ou servios que um sistema oferece; Dependem do tipo de software, usurios esperados e do tipo de sistema onde o software ser usado; Requisitos funcionais de usurio podem ser declaraes de alto nvel do que o sistema deve fazer.

Classificao dos Requisitos

Quanto a natureza
Requisitos Funcionais Exemplo Sistema de biblioteca:
O usurio dever ser capaz de buscar todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele.

O sistema deve prover telas apropriadas para o usurio ler documentos no repositrio de documentos.

Classificao dos Requisitos

Quanto a natureza
Requisitos No-Funcionais:

Restries sobre as funes oferecidos pelo sistema. Destacam-se aqui as restries de tempo, processo e padro; Definem propriedades e restries do sistema, ex.: tempo de resposta, requisitos de armazenamento, confiabilidade, capacidade dos dispositivos de I/O. Tambm podem ser especificao de uma determinada ferramenta CASE, linguagem de programao ou processo de desenvolvimento; Podem ser mais crticos que os requisitos

Classificao dos Requisitos

Quanto a natureza
Requisitos No-Funcionais - Classificao:

E sp e ci ca m fi o co m p o rta m e n to do p ro d u to .

Pro ce d e n te s de p o l ti s e ca p ro ce d i e n to m s nas o rg a n i e s za d o cl e n te i e do d e se n vo l d o ve r

To d o s o s re q u i to s si p ro ce d e n te s de fa to re s exte rn o s a o si m a ste e a o se u p ro ce sso de d e se n vo l m e vi n to .

Classificao dos Requisitos

Quanto a natureza

Requisitos No-Funcionais Exemplos:

Requisitos de produto: Deve ser possvel que toda a comunicao necessria entre o software e o usurio seja expressa no conjunto padro de caracteres ASCII; Requisitos de organizao: O processo de desenvolvimento e os documentos entregues devero estar de acordo com o processo e os produtos definidos em ABCD_ORG.DOC; Requisitos externos: O sistema no dever revelar aos operadores nenhuma informao pessoal sobre os clientes alm de seus nomes e cdigo.

Classificao dos Requisitos

Quanto a natureza
Requisitos No-Funcionais: Metas e requisitos

Requisitos no-funcionais podem ser difceis de estabelecer e requisitos imprecisos so difceis para verificar;

Meta: uma inteno do usurio como fcil de usar;

Requisito no funcional verificvel: uma sentena que use alguma mtrica que possa ser objetivamente testada;

Classificao dos requisitos

Mtricas

Classificao dos Requisitos

Quanto a natureza
Requisitos de Domnio:

So derivados do domnio da aplicao do sistema, em vez de serem obtidos a partir das necessidades especficas dos usurios do sistema; Podem ser novos requisitos funcionais ou restries em requisitos existentes; So descritos com terminologia especfica do domnio e, para os compreender, o desenvolvedor precisa de algum conhecimento da rea de domnio; Especialistas do domnio conhecem a rea to bem que no pensam em tornar os requisitos explcitos.

Classificao dos Requisitos

Quanto a natureza

Requisitos de Domnio - Exemplo:

A desacelerao do trem de carga da linha frrea UNZX-CIA ser computada como:

Dtrem = Dcontrole + Dgradiente onde: Dgradiente 9,81 ms2 * gradiente compensado/alfa; os valores de 9,81ms2/alfa so conhecidos para diferentes tipos de trens.

Engenharia de requisitos

Processo de estabelecer os servios que um cliente requer de um sistema e as restries em que o mesmo desenvolvido e ser operado.

Os requisitos so a descrio dos servios de sistema e restries que so geradosdurante o processo de engenharia de requisitos.

Os processos usados dependem do domnio da aplicao, pessoas

Engenharia de requisitos

Processos
Levantamento (elicitao) de requisitos. Anlise e negociao de requisitos. Especificao de requisitos. Modelagem do sistema. Validao e verificao de requisitos. Gerenciamento de requisitos.

Engenharia de requisitos Levantamento

Corresponde a identificar junto aos participantes:

Quais so os objetivos do sistema ou produto; O que deve ser acompanhado; Como o sistema ou produto se encaixa no contexto das necessidades do negcio; Como ser a utilizao do sistema ou produto no dia-a-dia;

Definir um ou mais mtodos de levantamento de requisitos;

Engenharia de requisitos Levantamento

Trabalho do pessoal tcnico com clientes para descobrir o domnio da aplicao, servios providos e restries; Devem incluir diversos envolvidos visando obter pontos de vista diferentes; Identificar claramente a justificativa de existncia para cada requisito registrado; Avaliar a viabilidade tcnica e de negcio para o sistema proposto; Identificar as pessoas que vo auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais; Definir o ambiente tcnico no qual o sistema ser instalado; Identificar restries que limitam a funcionalidade ou performance do sistema ou produto que ser construdo;

Levantamento - Fontes de requisitos

Bons requisitos comeam com boas fontes. Encontrar essas fontes qualificadas uma tarefa importante e, felizmente, necessita de poucos recursos.

As fontes primrias de requisitos so os futuros usurios do sistema e/ou os que entendem do processo de negcio, ento comece identificando-os a partir destes candidatos:

Levantamento - Fontes de requisitos

Solicite a cada entrevistado que identifique outros interessados que possam contribuir com a coleta e anlise dos requisitos. Ao "descascar a cebola" desta forma, voc pode identificar rapidamente todos os envolvidos e assim no perder importantes perspectivas e requisitos associados. Isto ir ajud-lo a identificar e resolver os requisitos conflitantes, o mais cedo possvel.

Estas so outras possveis fontes de idias para requisitos:

Peritos do Domnio; Analistas da Indstria; Informaes sobre competidores

O ltimo item muitas vezes inclui informaes sobre o sistema atual que os concorrentes esto usando para

Requisitos de software Tcnicas de levantamento

Depois de voc ter identificado as fontes, existem vrias tcnicas que voc pode usar para obter os requisitos. Entretanto, importante reconhecer que a obteno de requisitos um processo iterativo, e no existe uma tcnica nica que seja universalmente aplicvel.

Entrevistas Prototipao Questionrios JAD Estudo de caso Observao Anlise de interfaces Brainstorming

Levantamentos - Dicas de sucesso

Faa na hora, mantenha simples e itere. Capture os requisitos e ento colabore com os interessados para corrigi-los e melhor-los. O contato face-a-face com os usurios durante entrevistas a principal fonte de requisitos e um meio importante para obter e validar os requisitos. Comece com entrevistas no estruturadas para obter uma compreenso do ambiente de trabalho. Pergunte aos entrevistados sobre os seus trabalhos e os problemas que eles enfrentam. Entrevistas estruturadas, que usam um conjunto de questes preparadas, podem ser feitas posteriormente para preencher as lacunas do seu conhecimento. Tcnica sugerida: Entrevistas

Levantamentos - Dicas de sucesso

Observe o trabalho dos usurios Observe voc mesmo o trabalho dos usurios. Observar os usurios ajuda a entender os problemas que resistiram as solues anteriores. Quando o trabalho pode ser facilmente experimentado dessa forma, ainda pode ser possvel fazer um pouco mais do que simplesmente sentar e observar. Os usurios podem comentar sobre o que eles esto fazendo, quais so os problemas e o que eles gostariam de ter para deixar o trabalho mais fcil. Tcnica sugerida: Observao

 Estude sistemas semelhantes

Levantamentos - Dicas de sucesso

O ponto inicial para muitos projetos normalmente um sistema semelhante ou j existente. Algumas vezes, produtos e sistemas comparveis contm verses funcionais de boas idias para resolver os problemas dos usurios. Voc pode economizar tempo e evitar a reinveno da roda, observando sistemas que j esto no mercado, sejam sistemas instalados no ambiente do usurio, ou produtos criados por organizaes concorrentes. Mesmo que eles resolvam problemas ligeiramente deferentes, normalmente eles fornecem pistas valiosas sobre o que voc precisa fazer.

Levantamentos - Dicas de sucesso Examine informes de problemas e sugestes.

Os requisitos podem se originar de sugestes de mudanas e problemas de usurios. Uma forma direta de encontrar requisitos olhar as sugestes e problemas da forma que foram inicialmente descritos. Muitas organizaes possuem alguma forma de relatar problemas ou defeitos em sistemas. Voc pode pedir para olhar esses informes (e provavelmente haver muitos). Organize-os em grupos para poder identificar as principais reas que esto incomodando os usurios. Faa perguntas aos usurios sobre essas reas para esclarecer as reais necessidades deles. Se existir uma lista de itens de trabalho de uma verso anterior, ou mesmo de um projeto semelhante, revise-a para encontrar potenciais requisitos que possam ser aplicados ao projeto de desenvolvimento atual. Se voc tiver sorte, voc poder re-utilizar um pouco disso tambm. Tcnica sugerida: Estudo de caso

Levantamentos - Dicas de sucesso

Converse com equipes de suporte A maioria das grandes organizaes possui um help desk que mantm uma lista de problemas e solues, e engenheiros de suporte que solucionam os problemas. Conversar com o pessoal de help desk e com os engenheiros de suporte pode lhe dar um bom direcionamento para os requisitos, e economizar tempo. Converse tambm com a equipe de treinamento e as equipes de instalao sobre o que os usurios acham mais problemtico.

Tcnicas sugeridas: Entrevistas e Questionrios

Levantamentos - Dicas de sucesso

Estude melhorias feitas pelos usurios

Esta uma excelente fonte de requisitos. Em uma planilha padro da companhia usurios podem ter adicionado alguns campos, combinado planilhas diferentes ou desenhado grficos que satisfaam as suas necessidades. Voc s precisa perguntar: Por que voc adicionou isso? As respostas lhe ajudaro a chegar ao corao do requisito real.

Tcnica sugerida: Estudo de caso

 Procure por usos no intencionados

Levantamentos - Dicas de sucesso

As pessoas normalmente usam as coisas para propsitos que os projetistas no intencionaram. Essa uma boa forma de obter novas idias e pensar em inovaes.

Por exemplo, um gerente de produto observador notou que um engenheiro ficava no escritrio at mais tarde para usar um sistema de design auxiliado por computador para projetar uma nova cozinha para sua casa. Produtos comerciais baratos j esto

Levantamentos - Dicas de sucesso

Conduza workshops colaborativos Os Workshops colaborativos podem agregar um bom conjunto de requisitos rapidamente. Entre dois e cinco dias, voc pode criar um conjunto de requisitos, e ento revis-los e melhorlos. Se todos no workshop tentarem estimar o custo e valor de cada requisito, o documento se torna muito mais til e com custos efetivos. Os Workshops colaborativos so melhores e mais rpidos para a descoberta de requisitos do que quaisquer outras tcnicas, tais como entrevistas pessoais. Voc est reunindo o grupo certo de pessoas e fazendo com que elas corrijam, melhorem e cheguem a um consenso a respeito dos seus requisitos. Um workshop inerentemente caro por causa da quantidade de pessoas envolvidas, mas ele economiza uma quantidade de tempo significante. Se voc puder definir o produto logo na primeira vez e cortar trs meses para obteno de requisitos, a economia pode ser enorme. O workshop tem que ser completamente organizado para tirar vantagem do tempo das pessoas. Escolha um local tranqilo para o workshop, de forma que as pessoas no sejam perturbadas pelos problemas do dia-a-dia. Desencoraje os telefones celulares; porem organize o recebimento de mensagens. Tire vantagem das interaes informais escolhendo um local onde as pessoas no tenham que sair separadamente ou ir para casa a noite. Tcnica sugerida: JAD

Levantamento - Dicas de sucesso

Mostre prottipos aos envolvidos Os prottipos e os modelos so excelentes formas de apresentar idias aos usurios, porque eles permitem as pessoas verem imediatamente alguns aspectos do sistema. Mostrar aos usurios um prottipo simples pode estimul-los a fornecer boas informaes sobre requisitos ou mudar de idia sobre os requisitos existentes. Os prottipos podem ilustrar como uma abordagem pode funcionar, ou dar aos usurios uma viso do que eles podem ser capazes de fazer. Mais requisitos podem emergir quando os usurios vem o que voc est sugerindo. Uma apresentao pode usar uma seqncia de slides, um quadro de histria, uma impresso de um artista ou mesmo uma animao para dar aos usurios uma viso das possibilidades. Quando da prototipagem de software, faa uma maquete das telas da interface com o usurio enfatizando que no existe cdigo e que o sistema no foi projetado nem especificado ainda. Cuidado: Uma maquete pode gerar expectativas difceis de serem atendidas. Esta prototipagem objetiva fazer com que os usurios mencionem o que pode se transformar em requisitos faltantes. Voc no est tentando vender aos usurios uma idia ou produto. Ao invs, voc est descobrindo o que eles querem realmente. Ver um prottipo, que invariavelmente est errado em alguns aspectos e correto em outros, um poderoso estmulo para os usurios comearem a dizer o que eles querem. Eles podem apontar vrios problemas com o prottipo. Isso excelente porque cada problema leva a um novo requisito. Tcnicas sugeridas: Entrevistas com Prototipao

Engenharia de requisitos Resultado do levantamento

As necessidades e viabilidade estruturadas; O limite de escopo do sistema ou produtos; Uma lista de envolvidos que participaram da atividade de levantamento de requisitos; Uma descrio do ambiente tcnico do sistema; Uma lista de requisitos e as regras de negcio aplicveis a cada um; Um conjunto de cenrios de uso capazes de prover uma idia do uso do sistema ou produto sob diferentes condies de operao; Qualquer prottipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos.

Engenharia de requisitos Anlise e negociao

Com os requisitos obtidos, os produtos de trabalho citados anteriormente formam a base para a anlise de requisitos.

Esta anlise categoriza e organiza os requisitos em subconjuntos relacionados, explora o relacionamento de cada requisito com todos os demais, examina consistncia, omisso e ambigidade dos requisitos

Engenharia de requisitos Anlise e negociao

Problemas

Envolvidos (clientes) no sabem o que querem; Envolvidos (clientes) expressam requisitos em seus termos prprios; Diferentes envolvidos (clientes) podem ter conflitos de requisitos; Fatores organizacionais e polticos podem influenciar nos requisitos; Os requisitos mudam durante o processo de anlise.

Engenharia de requisitos Especificao grfico, um modelo Pode ser um documento escrito, um modelo
matemtico formal, uma coleo de cenrios de uso, um prottipo, ou qualquer combinao dos itens citados. Para grandes sistemas, um documento escrito contendo linguagem natural combinada a modelos grficos pode ser a melhor abordagem. Para sistemas pequenos desenvolvidos em ambiente tcnico conhecido pode ser suficiente a utilizao de cenrios de uso. A especificao do sistema o produto final produzido pelos engenheiros de requisitos. Ela usada como a base para as engenharias de hardware, software e banco de dados, pois descreve funes e performance requeridas de um sistema baseado em computao e as regras que iro guiar seu desenvolvimento. A especificao limita cada elemento alocado ao sistema e tambm descreve a informao (dados e controle) que so entrada e sada do

Engenharia de requisitos Especificao

Descreva os requisitosusando uma linguagem natural de forma que todas as partes envolvidas entendam os requisitos.

Considere o pblico para certificar-se de que possam ser transmitidos com eficcia.

Engenharia de requisitos Especificao

Para escrever um bom requisito, voc deve escrev-lo como uma sentena completa, com um sujeito e um predicado.

O sujeito um ator,o sistema em desenvolvimento ou uma entidade de design que est relacionado ao requisito. O predicado especifica uma ao ou um resultado desejado que feito para, por, com ou ao sujeito, muitas vezes incluindo as condies e os critrios de desempenho.

Assim, voc pode analisar o requisito de um ponto de vista gramatical. Por exemplo:

Engenharia de requisitos Especificaoforma verbal Nos requisitos dos envolvidos, o uso da

"deve ser capaz de" deixa claro que o requisito especifica algo que o envolvido deve ser capaz de fazer, mas no (necessariamente) forado a fazer. Nos requisitos de sistema, a forma verbal " <ao>" deixa claro que o sistema deve executar esta ao sob as condies determinadas.

Em alguns casos, as listas numeradas podem tornar a escrita mais clara, mas cada item da lista deve ser um requisito completo para maximizar o benefcio de qualquer informao de rastreabilidade. Palavras como todos, cada e alguns podem levar a ambigidade. Voc ter certeza que levou em conta todos os casos? Qual proporo do todo o alguns

Especificao de requisitos diretrizes bsicas

Defina um requisito por vez. Por exemplo,

O piloto deve ser capaz de controlar o ngulo de subida da aeronave, com uma mo. O piloto deve ser capaz de sentir o ngulo de subida a partir do

Especificao de requisitos diretrizes bsicas

Evite as conjunes (e, ou) que criam mltiplos requisitos. Por exemplo, use:

O navegador deve ser capaz de visualizar a posio da aeronave em relao s balizas da rota. O navegador deve ser capaz de visualizar a posio da aeronave pela estimativa da orientao inercial.

Em vez de: O navegador deve ser capaz de ver a posio da aeronave em relao s

Especificao de requisitos diretrizes bsicas

Evite clusulas ou palavras que implicam opes ou excees (salvo, exceto, se necessrio, mas). Elas so perigosas uma vez que fica difcil determinar quando o requisito aplicvel. melhor escrever requisitos separados, tratando cada condio especfica, ou estado do sistema. Por exemplo, use:
O sistema deve fornecer 100% de classificao em condies normais. O sistema deve ser capaz de fornecer at 125% de classificao para os primeiros 15 minutos em uma condio de emergncia. O sistema deve fornecer um mnimo de 90% de classificao em no menos de 15 minutos aps os primeiros 15 minutos em uma condio de emergncia. O sistema deve ativar uma exceo de classificao reduzida se o mnimo de 95% de classificao no for mantido em uma condio de emergncia. Em vez de: O sistema deve executar a classificao mxima em todas as ocasies exceto, que em situaes de emergncia deve ser capaz de fornecer at 125% da classificao salvo se a condio de emergncia continuar por mais de 15 minutos, que neste caso a classificao deve ser reduzida para 105% mas no caso de apenas 95% poder ser alcanado, ento o sistema deve ativar uma exceo de classificao reduzida e deve manter a classificao em 10% dos valores declarados por no mnimo 30 minutos.

Especificao de requisitos diretrizes bsicas

Use sentenas simples e diretas.

O piloto deve ser capaz de ver o indicador de velocidade do ar.

Use palavras simples, tanto quanto possvel, especialmente se o seu pblico alvo for internacional, o que torna a traduo precisa uma preocupao.

A companhia area deve ser capaz de converter as aeronaves de vos empresariais para festivos em menos de 12

Especificao de requisitos diretrizes bsicas

Identifique o tipo de usurio que precisa de cada requisito.
O navegador deve ser capaz de...

Foque na declarao de que resultado voc fornecer para esse tipo de usurio.
...ver nuvens de tempestade atravs do radar...

Defina critrios verificveis

...pelo menos 100 milhas frente.

Especificao de requisitos diretrizes bsicas

Use A ser confirmado (confirmar) para sinalizar que um requisito poder ser alterado ou que ainda no definitivo. Isto ajuda a identificar trabalho excedente. Por exemplo:

A aeronave deve ser capaz de aterrizar de forma segura em uma pista de aterrizagem com comprimento mnimo de 1000 metros (confirmar).

Especificao de requisitos diretrizes bsicas

Use A ser determinado (definir) onde se saiba que um requisito especfico ser necessrio, mas os detalhes ainda no so conhecidos. Tambm ajuda a identificar trabalho excedente. Por exemplo:

A aeronave deve ser capaz de aterrizar, de forma segura, em pistas de aterrizagem com comprimento mnimo

O que deve ser evitado ao escrever requisitos

Embora no exista uma forma certa de eliminar os erros nos requisitos em geral, existem armadilhas comuns na escrita de requisitos que so relativamente fceis de evitar.

Ambiguidade
Evitar a ambigidade um dos mais difceis mandatos na escrita dos requisitos. Tente escrever o mais claro e explcito possvel. Seja especfico. Se voc tiver que usar termos vagos ou ambguos, tenha certeza de t-los definido no glossrio. Solicite a vrios colegas e envolvidos que revisem os seus requisitos para garantir a coerncia e a compreenso comum. Embora no exista nenhum teste definitivo para a ambigidade, que no seja o consenso, algumas ambigidades perigosas podem ser causadas pelo uso das palavras para, ou e a menos que. Exemplo
"O mesmo subsistema deve tambm ser capaz de gerar um sinal de cuidado/alerta visvel ou audvel para chamar a ateno do co-piloto ou navegador". Qual subsistema? O sinal deve ser visvel, audvel ou ambos? Deve ser cuidado e alerta, somente cuidado ou somente alerta? Deve ser para o co-piloto e o navegador ou somente um deles? Se somente um deles, quem e em que condies?

Requisitos mltiplos
Requisitos que possuem conjunes (palavras que ligam clusulas independentes) so perigosos. Problemas surgem quando os leitores tentam entender que parte se aplica, especialmente se as clusulas diferentes parecem conflitar ou se as partes individuais se aplicam separadamente. Mltiplos requisitos tambm fazem a verificao ficar mais complexa. Conjunes perigosas incluem: e, ou, mas

Exemplo
"A lmpada de alerta de bateria fraca deve acender quando a voltagem cair abaixo de 3.6 Volts, e a rea de trabalho corrente ou os dados de entrada devem ser salvos". A lmpada de alerta de bateria fraca deve acender quando a voltagem cair e a rea de trabalho for salva? A lmpada de alerta de bateria fraca deve acender e a rea de trabalho deve ser salva quando a voltagem cair?

Clusulas evasivas
Os requisitos que incluem opes ou excees so perigosos. Eles parecem pedir algo definitivo, mas no ltimo momento eles desistem e permitem outras opes. Os problemas surgem quando os requisitos so testados e algum tem que decidir o que (se houver) provaria que o requisito foi satisfeito. Palavras perigosas que implicam excees incluem: se, quando, mas, exceto, a menos que, embora.

Exemplos
"A porta posterior de passageiros deve abrir automaticamente quando a aeronave parar, exceto quando a rampa traseira estiver aberta". "O alarme de incndio deve sempre ser tocado quando a fumaa for detectada, a menos que o alarme esteja sendo testado ou o engenheiro tenha suprimido o alarme". A ltima sentena realmente um requisito perigoso!

Incoerncias

Longas sentenas Incoerentes, especialmente quando combinadas com linguagem rebuscada ou referncias a documentos de difcil acesso, levam rapidamente confuso e erros.

Exemplo
"Dado que os sinais de entrada designados dos dispositivos especificados sejam recebidos na ordem correta onde o sistema seja capaz de

Design prematuro
Os requisitos devem especificar as possibilidades de design sem restries desnecessrias de um design especfico. Se detalharmos demais, comearemos a projetar o sistema. Ir muito longe tentador para os designers, especialmente quando eles chegam s suas partes favoritas.

Sinais de perigo incluem nomes de componentes, materiais, objetos de software ou procedures e campos de bancos de dados.

Exemplo
"A antena deve ser capaz de receber sinais FM usando um miolo de cobre protegido por nylon e uma capa de borracha endurecida prova d'gua". Especificar design em vez das reais necessidades aumenta o custo dos sistemas por colocar restries desnecessrias no desenvolvimento e na manufatura. Freqentemente,

Misturar diferentes tipos de requisitos completo do que Os requisitos de usurio formam um modelo

os usurios querem. Eles precisam ser organizados coerentemente para exibirem falhas e sobreposies. O mesmo se aplica aos requisitos de sistema, que formam um modelo funcional completo do sistema proposto. Uma forma rpida de conseguir confuso misturar requisitos de usurios, sistemas e como o sistema deveria ser projetado, testado ou instalado.

Sinais de perigo so qualquer referncia sistema, design, teste ou instalao.

Exemplo
"O usurio deve ser capaz de ver o nmero do canal corrente que deve ser exibido com fonte Swiss tamanho 14 em um painel LCD em conformidade com o padro regulamentar federal 567-89 e montado com arruelas de borracha prova de choque".

Especulao
Os requisitos so parte de um contrato entre o cliente e o desenvolvedor. No h espao para listas de desejos, termos de significado geral sobre coisas que algum provavelmente quer.

Sinais de perigo incluem idias vagas sobre que tipo de usurio est falando e generalizaes tais como: usualmente, geralmente, freqentemente, normalmente e tipicamente.

Exemplo
"Os usurios normalmente necessitam de rpida indicao de incluso no sistema".

Termos vagos e indefinidos

Muitas palavras usadas informalmente para indicar a qualidade do sistema so muito vagas para uso em requisitos. Termos vagos incluem, entre outros: amigvel, verstil, flexvel, aproximadamente, possvel. Os requisitos que usam esses termos no so verificveis porque no h teste definitivo para mostrar se o sistema tem a propriedade indicada.

Exemplos
"A caixa de dilogo de impresso deve ser verstil e amigvel". "A lmpada indicadora de status OK deve ser acesa o mais rpido possvel depois do auto-teste do

Expressando meras possibilidades

Sugestes que no so explicitamente declaradas como requisitos so invariavelmente ignoradas pelos desenvolvedores.

"Opes possveis" so indicadas com termos tais como: pode, deveria, desejvel, poderia, talvez, provavelmente.

Exemplo
"O subsistema de recepo provavelmente dever ser forte o suficiente para receber um sinal de dentro de uma construo de placas de ao".

Pensamentos desejosos
Os pensamentos desejosos significam pedir o impossvel. A engenharia uma atividade do mundo real e nenhum sistema ou componente perfeito.

Termos de pensamentos desejosos incluem: confivel, seguro, trata todas as falhas inesperadas, agrada a todos os usurios, roda em todas as plataformas, nunca falha, atualizvel a todas as situaes futuras.

Exemplos
"A caixa de cmbio deve ser 100% segura

Regras de negcio

As regras de negcio so declaraes sobre polticas ou condies que devem ser satisfeitas.

Uma regra de negcio uma sentena que define ou qualifica algum aspecto do negcio, representando o conhecimento dos especialistas do negcio (BRG, 2000). Atravs das regras de negcio possvel garantir a estrutura do negcio ou influenciar o

Regras de negcio
Algumas regras de negcios so impostas com base em leis e regulamentos; outras podem ser padres da empresa. H outras ainda que expressam as metas a serem atingidas pelo esforo de modelagem de negcios.

Descreva as regras de negcios usando uma linguagem rigorosa e formal. Considere o pblico para certificar-se de que possam ser transmitidas com eficcia.

Analise os resultados para verificar se voc seguiu um estilo consistente ao definir as

Regras de negcio Estruturao

Deve-se capturar e estruturar todas as regras de negcio que governam o universo de discusso. As regras de negcio definem como o negcio funciona e ditam o seu funcionamento, suas restries e validaes. Regras de negcio abrangem diversos assuntos como polticas, interesses, objetivos, compromissos ticos e sociais, obrigaes contratuais, decises estratgicas, leis e regulamentaes entre outros. Devem ser criadas regras que sejam executadas da forma mais independente possvel, de modo que somente uma regra seja necessria para executar uma ao definida. Essa tcnica permite o teste e validao independentes para cada regra separadamente. As regras podem depois ser combinadas em comportamentos mais complexos.

Regras de negcio Estruturao

As regras so tipicamente estruturadas como um par de instrues de condio e ao bem definidos. Geralmente, uma melhor prtica escrever as condies da regra como um conjunto em que todas as condies devem ser atendidas para acionar a regra. Embora alguns mecanismos de regras permitam usar a construo ou em uma condio, na prtica, tais construes levam a regras que so difceis de entender e testar. Nesses casos, melhor criar mltiplas regras para cobrir cada situao de ou, ao invs de criar uma

Regras de negcio Estruturao

Algumas regras so representadas melhor em uma tabela de decises, que apenas uma maneira de resumir vrias regras que compartilham um conjunto de condies, com aes baseadas nas alteraes de valores para essas condies. Essa situao comum em instituies financeiras, onde as decises sobre a concesso de um emprstimo so baseadas no histrico de crdito, status de emprego, ativos possudos, etc. do solicitante.

Regras de negcio Estruturao

Regras podem ser estreitamente relacionadas na medida em que atendem aos mesmos dados de entrada ou executam um conjunto de aes semelhante (regras de validao, por exemplo). Muitas vezes, til agrupar essas regras para limitar as regras consideradas na validao.

Grupos de regras so usados para organizar conjuntos de regras em categorias bem definidas para permitir a criao de um fluxo de regras.

Ao usar grupos e fluxos de regras, possvel modelar claramente o comportamento geral do mecanismo de regras e validar as regras isoladamente.

Regras de negcio Estruturao

As regras devem ser atmicas e escritas completamente na tica de negcio.

Procure estruturar as regras da seguinte forma:

Termos e fatos.

Estruturao de regras Termos

Defina os termos que pertencem ao negcio e so utilizados nas regras.

Sugesto: Criao de um glossrio corporativo com a coleo de termos usados no negcio.

Exemplo: Um gerente definido como uma pessoa a quem duas ou mais pessoas reportam diretamente.

Estruturao de regras Fatos

Descreva os fatos a partir dos termos.

Exemplo: Um item de pedido deve conter um cdigo, o preo e a descrio do produto.

Alguns fatos denotam regras de negcio. Deve-se atentar para os fatos do tipo: Restries, clculos, habilitadores de ao, inferncia.

Estruturao de regras Restries

Fatos que denotam restries do processo de negcio podem ser considerados regras do negcio.

Exemplo: O valor da diria para um locatrio da categoria ABC no deve exceder 1000 reais.

Estruturao de regras Clculos

Fatos que determinam clculos dentro do processo de negcio.

Exemplo: O valor de venda calculado como o valor lquido mais a alquota de 18% do imposto sobre circulao de mercadorias do estado.

Estruturao de regras Habilitadores de ao

Fatos que representam eventos dentro do processo de negcio.

Exemplo: Quando o mesmo carto for usado em duas lojas separadas por mais de 100 KM em menos que uma hora, um alarme ser emitido para o setor de anti-fraude

Estruturao de regras Inferncia

Fatos expressos como inferncias.

Esse tipo de regra geralmente descrito por uma lgica do tipo "se-ento-seno", onde se um conjunto especfico de regras de negcios atendido, ento uma determinada ao executada; seno (caso contrrio), alguma outra ao pode ser executada.

Exemplo: Se o plano do cliente VIP e a milhagem utilizada ultrapassou 10.000KM, ento um desconto de 10% sobre o total do