Requisitos de software

Requisitos - Definição
• Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema; • • Condição ou capacidade necessária que o software deve possuir:
– para que o usuário possa resolver um problema ou atingir um objetivo – para atender as necessidades ou restrições da organização ou de outros componentes

Requisitos - Definição
• Segundo a IEEE pode ser entendido como “Condição ou capacidade que deve ser alcançada ou possuída por um sistema, para satisfazer um padrão, contrato, especificação ou outro documento formal”; • • Segundo Sommerville “Descrições de como o sistema deve se comportar ou suas propriedades. Podem também ser restrições no processo de desenvolvimento”;

ele pode ser uma definição detalhada. um requisito é visto como uma declaração abstrata. de alto nível. no entanto sem estabelecer consistentemente sua definição: • – Em alguns casos.Requisitos . – – Em outro extremo.Definição • Às vezes o termo requisitos é empregado. matematicamente formal. de um função que o sistema deve fornecer ou de uma restrição do sistema. de uma .

Natureza dos Requisitos RASTREABILIDADE REQUISITOS DE SOFTWARE .

Classificação dos Requisitos Requisitos de usuário Requisitos de sistema Requisitos de desenho Quanto a visibilidade Quanto a natureza Funcionais Não funcionais Domínio .

Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento. indicando o que ele deve fazer (sem dizer como) que serve de base para o design e implementação. Escrito para os clientes.  – Requisitos do sistema: estabelecem detalhadamente as funções e restrições do sistema.• • Classificação dos Requisitos Quanto a Visibilidade – Requisitos do usuário: declarações. em linguagem natural e diagramas. sobre os serviços que o sistema oferece e as restrições para a sua operação. pode servir como um contrato entre cliente e desenvolvedor. . O documento de requisitos. chamado de especificação funcional.  – Requisitos de desenho(Especificação de software): especificação abstrata e precisa do software.

Classificação dos Envolvidos Requisitos .

• • Descrevem a funcionalidade ou serviços que um sistema oferece. • • Dependem do tipo de software. como o sistema deve reagir a entradas específicas e como deve se comportar em dada situações. • .Classificação dos Requisitos • Quanto a natureza • – Requisitos Funcionais:  • Declarações de funções que o sistema deve fornecer. usuários esperados e do tipo de sistema onde o software será usado. • • Requisitos funcionais de usuário podem ser declarações de alto nível do que o sistema deve fazer.

Classificação dos Requisitos • Quanto a natureza • – Requisitos Funcionais – Exemplo Sistema de biblioteca: – – O usuário 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 usuário ler documentos no repositório de documentos. .

ex. linguagem de programação ou processo de desenvolvimento. requisitos de armazenamento. confiabilidade. • • Também podem ser especificação de uma determinada ferramenta CASE. • • Definem propriedades e restrições do sistema.Classificação dos Requisitos • Quanto a natureza • – Requisitos Não-Funcionais:  • Restrições sobre as funções oferecidos pelo sistema. processo e padrão.: tempo de resposta. Destacam-se aqui as restrições de tempo. • • Podem ser mais críticos que os requisitos . capacidade dos dispositivos de I/O.

.Classificação dos Requisitos • Quanto a natureza – Requisitos Não-Funcionais . 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 .Classificação: E sp e ci ca m fi o co m p o rta m e n to do p ro d u to .

• • Requisitos externos: O sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes além de seus nomes e código. .Classificação dos Requisitos • Quanto a natureza  – Requisitos Não-Funcionais – Exemplos: – • Requisitos de produto: Deve ser possível que toda a comunicação necessária entre o software e o usuário seja expressa no conjunto padrão de caracteres ASCII.DOC. • • Requisitos de organização: O processo de desenvolvimento e os documentos entregues deverão estar de acordo com o processo e os produtos definidos em ABCD_ORG.

Classificação dos Requisitos • Quanto a natureza – Requisitos Não-Funcionais: Metas e requisitos  • Requisitos não-funcionais podem ser difíceis de estabelecer e requisitos imprecisos são difíceis para verificar. • • Meta: uma intenção do usuário como “fácil de usar”. . • • Requisito não funcional verificável: uma sentença que use alguma métrica que possa ser objetivamente testada.

Classificação dos requisitos • Métricas .

Classificação dos Requisitos • • Quanto a natureza • – Requisitos de Domínio:  • São derivados do domínio da aplicação do sistema. o desenvolvedor precisa de algum conhecimento da área de domínio. • • São descritos com terminologia específica do domínio e. • • Podem ser novos requisitos funcionais ou restrições em requisitos existentes. . • • Especialistas do domínio conhecem a área tão bem que não pensam em tornar os requisitos explícitos. em vez de serem obtidos a partir das necessidades específicas dos usuários do sistema. para os compreender.

”    .Exemplo: • “A desaceleração do trem de carga da linha férrea UNZX-CIA será computada como:     Dtrem = Dcontrole + Dgradiente onde: Dgradiente é 9.81ms2/alfa são conhecidos para diferentes tipos de trens.Classificação dos Requisitos • • Quanto a natureza •  – Requisitos de Domínio .81 ms2 * gradiente compensado/alfa. os valores de 9.

pessoas . • • Os requisitos são a descrição dos serviços de sistema e restrições que são geradosdurante o processo de engenharia de requisitos. • • Os processos usados dependem do domínio da aplicação.Engenharia de requisitos  • Processo de estabelecer os serviços que um cliente requer de um sistema e as restrições em que o mesmo é desenvolvido e será operado.

– Análise e negociação de requisitos.Engenharia de requisitos  Processos – Levantamento (elicitação) de requisitos. . – Gerenciamento de requisitos. – Validação e verificação de requisitos. – Especificação de requisitos. – Modelagem do sistema.

– – O que deve ser acompanhado.Engenharia de requisitos Levantamento  • Corresponde a identificar junto aos participantes:  – Quais são os objetivos do sistema ou produto. – – Como será a utilização do sistema ou produto no dia-a-dia. . – – Como o sistema ou produto se encaixa no contexto das necessidades do negócio.

Engenharia de requisitos Levantamento Trabalho do pessoal técnico com clientes para descobrir o domínio da aplicação. Devem incluir diversos envolvidos visando obter pontos de vista diferentes. . Identificar restrições que limitam a funcionalidade ou performance do sistema ou produto que será construído. • • • • • • • • • • • • • • • Definir um ou mais métodos de levantamento de requisitos. Avaliar a viabilidade técnica e de negócio para o sistema proposto. Definir o ambiente técnico no qual o sistema será instalado. Identificar claramente a justificativa de existência para cada requisito registrado. serviços providos e restrições. Identificar as pessoas que vão auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais.

Encontrar essas fontes qualificadas é uma tarefa importante e.Levantamento .  • As fontes primárias de requisitos são os futuros usuários do sistema e/ou os que entendem do processo de negócio. felizmente. então comece identificando-os a partir destes candidatos:  . necessita de poucos recursos.Fontes de requisitos  • Bons requisitos começam com boas fontes.

Levantamento - Fontes de requisitos
• Solicite a cada entrevistado que identifique outros interessados que possam contribuir com a coleta e análise dos requisitos. Ao "descascar a cebola" desta forma, você pode identificar rapidamente todos os envolvidos e assim não perder importantes perspectivas e requisitos associados. Isto irá ajudá-lo a identificar e resolver os requisitos conflitantes, o mais cedo possível.

• Estas são outras possíveis fontes de idéias para requisitos:
– Peritos do Domínio; Analistas da Indústria; Informações sobre competidores

• O último item muitas vezes inclui informações sobre o sistema atual que os concorrentes estão usando para

Requisitos de software – Técnicas de levantamento

Depois de você ter identificado as fontes, existem várias técnicas que você pode usar para obter os requisitos. Entretanto, é importante reconhecer que a obtenção de requisitos é um processo iterativo, e não existe uma técnica única que seja universalmente aplicável.

 

• • • • • •


Entrevistas Prototipação Questionários JAD Estudo de caso  Observação  Análise de interfaces  Brainstorming

Levantamentos - Dicas de sucesso

Faça na hora, mantenha simples e itere. Capture os requisitos e então colabore com os interessados para corrigi-los e melhorá-los. O contato face-a-face com os usuários durante entrevistas é a principal fonte de requisitos e um meio importante para obter e validar os requisitos. Comece com entrevistas não estruturadas para obter uma compreensão do ambiente de trabalho. Pergunte aos entrevistados sobre os seus trabalhos e os problemas que eles enfrentam. Entrevistas estruturadas, que usam um conjunto de questões preparadas, podem ser feitas posteriormente para preencher as lacunas do seu conhecimento. Técnica sugerida: Entrevistas


Observar os usuários ajuda a entender os problemas que resistiram as soluções anteriores. quais são os problemas e o que eles gostariam de ter para deixar o trabalho mais fácil. Os usuários podem comentar sobre o que eles estão fazendo. ainda pode ser possível fazer um pouco mais do que simplesmente sentar e observar.Dicas de sucesso •  Observe o trabalho dos usuários Observe você mesmo o trabalho dos usuários. Quando o trabalho pode ser facilmente experimentado dessa forma. Técnica sugerida: Observação • • • • •  • • .Levantamentos .

produtos e sistemas comparáveis contêm versões funcionais de boas idéias para resolver os problemas dos usuários. Mesmo que eles resolvam problemas ligeiramente deferentes.  . Algumas vezes. normalmente eles fornecem pistas valiosas sobre o que você precisa fazer.• Estude sistemas semelhantes  Levantamentos . observando sistemas que já estão no mercado. • • Você pode economizar tempo e evitar a reinvenção da roda. ou produtos criados por organizações concorrentes. sejam sistemas instalados no ambiente do usuário.Dicas de sucesso • O ponto inicial para muitos projetos é normalmente um sistema semelhante ou já existente.

Faça perguntas aos usuários sobre essas áreas para esclarecer as reais necessidades deles. Os requisitos podem se originar de sugestões de mudanças e problemas de usuários. Muitas organizações possuem alguma forma de relatar problemas ou defeitos em sistemas. Se existir uma lista de itens de trabalho de uma versão anterior.•  Levantamentos . revise-a para encontrar potenciais requisitos que possam ser aplicados ao projeto de desenvolvimento atual.Dicas de sucesso Examine informes de problemas e sugestões. Organize-os em grupos para poder identificar as principais áreas que estão incomodando os usuários. Uma forma direta de encontrar requisitos é olhar as sugestões e problemas da forma que foram inicialmente descritos. ou mesmo de um projeto semelhante. Técnica sugerida: Estudo de caso • • •  •  • . Você pode pedir para olhar esses informes (e provavelmente haverá muitos). você poderá re-utilizar um pouco disso também. Se você tiver sorte.

e economizar tempo. Converse também com a equipe de treinamento e as equipes de instalação sobre o que os usuários acham mais problemático. 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.Dicas de sucesso • Converse com equipes de suporte   • A maioria das grandes organizações possui um help desk que mantém uma lista de problemas e soluções.  • Técnicas sugeridas: Entrevistas e Questionários .Levantamentos .

Dicas de sucesso • Estude melhorias feitas pelos usuários  • Esta é uma excelente fonte de requisitos.  • Técnica sugerida: Estudo de caso .Levantamentos . combinado planilhas diferentes ou desenhado gráficos que satisfaçam as suas necessidades. Em uma planilha padrão da companhia usuários podem ter adicionado alguns campos. Você só precisa perguntar: Por que você adicionou isso? As respostas lhe ajudarão a chegar ao coração do requisito real.

Produtos comerciais baratos já estão .• Procure por usos não intencionados  Levantamentos . • • Por exemplo. Essa é uma boa forma de obter novas idéias e pensar em inovações. um gerente de produto observador notou que um engenheiro ficava no escritório até mais tarde para usar um sistema de design auxiliado por computador para projetar uma nova cozinha para sua casa.Dicas de sucesso • As pessoas normalmente usam as coisas para propósitos que os projetistas não intencionaram.

O workshop tem que ser completamente organizado para tirar vantagem do tempo das pessoas. Se todos no workshop tentarem estimar o custo e valor de cada requisito. Entre dois e cinco dias. tais como entrevistas pessoais. você pode criar um conjunto de requisitos. e então revisá-los e melhorálos. a economia pode ser enorme. Você está reunindo o grupo certo de pessoas e fazendo com que elas corrijam. porem organize o recebimento de mensagens.Dicas de sucesso •  Conduza workshops colaborativos Os Workshops colaborativos podem agregar um bom conjunto de requisitos rapidamente. Desencoraje os telefones celulares. Tire vantagem das interações informais escolhendo um local onde as pessoas não tenham que sair separadamente ou ir para casa a noite. Os Workshops colaborativos são melhores e mais rápidos para a descoberta de requisitos do que quaisquer outras técnicas. de forma que as pessoas não sejam perturbadas pelos problemas do dia-a-dia. mas ele economiza uma quantidade de tempo significante. Técnica sugerida: JAD •  •  •  •  • • . Um workshop é inerentemente caro por causa da quantidade de pessoas envolvidas. Se você puder definir o produto logo na primeira vez e cortar três meses para obtenção de requisitos. Escolha um local tranqüilo para o workshop. o documento se torna muito mais útil e com custos efetivos.Levantamentos . melhorem e cheguem a um consenso a respeito dos seus requisitos.

uma impressão de um artista ou mesmo uma animação para dar aos usuários uma visão das possibilidades. faça uma maquete das telas da interface com o usuário enfatizando que não existe código e que o sistema não foi projetado nem especificado ainda. Ao invés. Isso é excelente porque cada problema leva a um novo requisito. Mostrar aos usuários um protótipo simples pode estimulá-los a fornecer boas informações sobre requisitos ou mudar de idéia sobre os requisitos existentes. Os protótipos podem ilustrar como uma abordagem pode funcionar. você está descobrindo o que eles querem realmente. Esta prototipagem objetiva fazer com que os usuários mencionem o que pode se transformar em requisitos faltantes. Uma apresentação pode usar uma seqüência de slides. um quadro de história. Quando da prototipagem de software. Cuidado: Uma maquete pode gerar expectativas difíceis de serem atendidas. Técnicas sugeridas: Entrevistas com Prototipação •  •  •  • • . Você não está tentando vender aos usuários uma idéia ou produto. ou dar aos usuários uma visão do que eles podem ser capazes de fazer.Levantamento .Dicas de sucesso •  Mostre protótipos aos envolvidos Os protótipos e os modelos são excelentes formas de apresentar idéias aos usuários. Mais requisitos podem emergir quando os usuários vêem o que você está sugerindo. Eles podem apontar vários problemas com o protótipo. Ver um protótipo. porque eles permitem as pessoas verem imediatamente alguns aspectos do sistema. que invariavelmente está errado em alguns aspectos e correto em outros. é um poderoso estímulo para os usuários começarem a dizer o que eles querem.

Um conjunto de cenários de uso capazes de prover uma idéia do uso do sistema ou produto sob diferentes condições de operação. Uma lista de envolvidos que participaram da atividade de levantamento de requisitos. Qualquer protótipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos.Engenharia de requisitos – Resultado do levantamento • • • • • • • • • • • • • As necessidades e viabilidade estruturadas. Uma descrição do ambiente técnico do sistema. O limite de escopo do sistema ou produtos. . Uma lista de requisitos e as regras de negócio aplicáveis a cada um.

examina consistência.Engenharia de requisitos – Análise e negociação  • Com os requisitos obtidos. os produtos de trabalho citados anteriormente formam a base para a análise de requisitos. explora o relacionamento de cada requisito com todos os demais. omissão e ambigüidade dos requisitos . • • Esta análise categoriza e organiza os requisitos em subconjuntos relacionados.

Engenharia de requisitos – Análise e negociação   Problemas • Envolvidos (clientes) não sabem o que querem. • • Envolvidos (clientes) expressam requisitos em seus termos próprios. . • • Os requisitos mudam durante o processo de análise. • • Diferentes envolvidos (clientes) podem ter conflitos de requisitos. • • Fatores organizacionais e políticos podem influenciar nos requisitos.

um protótipo. A especificação limita cada elemento alocado ao sistema e também descreve a informação (dados e controle) que são entrada e saída do • • . software e banco de dados. uma coleção de cenários de uso.• • • • • • • • • • Engenharia de requisitos Especificação gráfico. pois descreve funções e performance requeridas de um sistema baseado em computação e as regras que irão guiar seu desenvolvimento. Para grandes sistemas. A especificação do sistema é o produto final produzido pelos engenheiros de requisitos. um modelo Pode ser um documento escrito. um documento escrito contendo linguagem natural combinada a modelos gráficos pode ser a melhor abordagem. um modelo matemático formal. ou qualquer combinação dos itens citados. Ela é usada como a base para as engenharias de hardware. Para sistemas pequenos desenvolvidos em ambiente técnico conhecido pode ser suficiente a utilização de cenários de uso.

Engenharia de requisitos Especificação • Descreva os requisitos usando uma linguagem natural de forma que todas as partes envolvidas entendam os requisitos. • • . • • Considere o público para certificar-se de que possam ser transmitidos com eficácia.

Engenharia de requisitos Especificação • Para escrever um bom requisito.  • Assim. muitas vezes incluindo as condições e os critérios de desempenho.  • O sujeito é um ator. o sistema em desenvolvimento ou uma entidade de design que está relacionado ao requisito. Por exemplo: . O predicado especifica uma ação ou um resultado desejado que é feito para. você deve escrevê-lo como uma sentença completa. por. com um sujeito e um predicado. com ou ao sujeito. você pode analisar o requisito de um ponto de vista gramatical.

a forma verbal "é <ação>" deixa claro que o sistema deve executar esta ação sob as condições determinadas. as listas numeradas podem tornar a escrita mais clara. mas cada item da lista deve ser um requisito completo para maximizar o benefício de qualquer informação de rastreabilidade. Você terá certeza que levou em conta todos os casos? Qual proporção do todo o alguns . mas não é (necessariamente) forçado a fazer. • • Palavras como todos.• Engenharia de requisitos Especificaçãoforma verbal Nos requisitos dos envolvidos. Nos requisitos de sistema. o uso da "deve ser capaz de" deixa claro que o requisito especifica algo que o envolvido deve ser capaz de fazer. • • Em alguns casos. cada e alguns podem levar a ambigüidade.

Especificação de requisitos – diretrizes básicas  • Defina um requisito por vez. com uma mão.  – O piloto deve ser capaz de controlar o ângulo de subida da aeronave. Por exemplo. – – O piloto deve ser capaz de sentir o ângulo de subida a partir do .

Especificação de requisitos – diretrizes básicas • Evite as conjunções (e. – O navegador deve ser capaz de visualizar a posição da aeronave pela estimativa da orientação inercial. use:  – O navegador deve ser capaz de visualizar a posição da aeronave em relação às balizas da rota. ou) que criam múltiplos requisitos. Por exemplo. – – Em vez de: – O navegador deve ser capaz de ver a posição da aeronave em relação às .

mas). O sistema deve fornecer um mínimo de 90% de classificação em não menos de 15 minutos após os primeiros 15 minutos em uma condição de emergência. tratando cada condição específica. Elas são perigosas uma vez que fica difícil determinar quando o requisito é aplicável. que neste caso a classificação deve ser reduzida para 105% mas no caso de apenas 95% poder ser alcançado.Especificação de requisitos – diretrizes básicas • Evite cláusulas ou palavras que implicam opções ou exceções (salvo. . que em situações de emergência deve ser capaz de fornecer até 125% da classificação salvo se a condição de emergência continuar por mais de 15 minutos. se necessário. ou estado do sistema. então o sistema deve ativar uma exceção de classificação reduzida e deve manter a classificação em 10% dos valores declarados por no mínimo 30 minutos. use: – – – – – – O sistema deve fornecer 100% de classificação em condições normais. O sistema deve ativar uma exceção de classificação reduzida se o mínimo de 95% de classificação não for mantido em uma condição de emergência. O sistema deve ser capaz de fornecer até 125% de classificação para os primeiros 15 minutos em uma condição de emergência. Por exemplo. É melhor escrever requisitos separados. exceto. Em vez de: O sistema deve executar a classificação máxima em todas as ocasiões exceto.

tanto quanto possível. o que torna a tradução precisa uma preocupação.  – O piloto deve ser capaz de ver o indicador de velocidade do ar. especialmente se o seu público alvo for internacional.Especificação de requisitos – diretrizes básicas • Use sentenças simples e diretas.  – A companhia aérea deve ser capaz de converter as aeronaves de vôos empresariais para festivos em menos de 12 . – • Use palavras simples.

ver nuvens de tempestade através do radar.pelo menos 100 milhas à frente.....  • Foque na declaração de que resultado você fornecerá para esse tipo de usuário.  • Defina critérios verificáveis – .. – . – O navegador deve ser capaz de..Especificação de requisitos – diretrizes básicas • Identifique o tipo de usuário que precisa de cada requisito. ...

– .Especificação de requisitos – diretrizes básicas  • Use A ser confirmado (confirmar) para sinalizar que um requisito poderá ser alterado ou que ainda não é 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 mínimo de 1000 metros (confirmar).

em pistas de aterrizagem com comprimento mínimo . Por exemplo:  – A aeronave deve ser capaz de aterrizar. mas os detalhes ainda não são conhecidos. Também ajuda a identificar trabalho excedente. de forma segura.Especificação de requisitos – diretrizes básicas  • Use A ser determinado (definir) onde se saiba que um requisito específico será necessário.

. existem armadilhas comuns na escrita de requisitos que são relativamente fáceis de evitar.O que deve ser evitado ao escrever requisitos • • Embora não exista uma forma certa de eliminar os erros nos requisitos em geral.

– Qual subsistema? O sinal deve ser visível. Se você tiver que usar termos vagos ou ambíguos. Exemplo – "O mesmo subsistema deve também ser capaz de gerar um sinal de cuidado/alerta visível ou audível para chamar a atenção do co-piloto ou navegador".Ambiguidade • Evitar a ambigüidade é um dos mais difíceis mandatos na escrita dos requisitos. quem e em que condições?  •  • . audível ou ambos? Deve ser cuidado e alerta. algumas ambigüidades perigosas podem ser causadas pelo uso das palavras para. que não seja o consenso. Embora não exista nenhum teste definitivo para a ambigüidade. Solicite a vários colegas e envolvidos que revisem os seus requisitos para garantir a coerência e a compreensão comum. Tente escrever o mais claro e explícito possível. tenha certeza de tê-los definido no glossário. Seja específico. somente cuidado ou somente alerta? Deve ser para o co-piloto e o navegador ou somente um deles? Se somente um deles. ou e a menos que.

.

Múltiplos requisitos também fazem a verificação ficar mais complexa. • Conjunções perigosas incluem: e. mas  • Exemplo – "A lâmpada de alerta de bateria fraca deve acender quando a voltagem cair abaixo de 3. especialmente se as cláusulas diferentes parecem conflitar ou se as partes individuais se aplicam separadamente.Requisitos múltiplos • Requisitos que possuem conjunções (palavras que ligam cláusulas independentes) são perigosos.6 Volts. ou. – A lâmpada de alerta de bateria fraca deve acender quando a voltagem cair e a área de trabalho for salva? A lâmpada de alerta de bateria fraca deve acender e a área de trabalho deve ser salva quando a voltagem cair? . e a área de trabalho corrente ou os dados de entrada devem ser salvos". Problemas surgem quando os leitores tentam entender que parte se aplica.

• Palavras perigosas que implicam exceções incluem: se. embora. mas no último momento eles desistem e permitem outras opções. mas. exceto.  • Exemplos – "A porta posterior de passageiros deve abrir automaticamente quando a aeronave parar.Cláusulas evasivas • Os requisitos que incluem opções ou exceções são perigosos. – A última sentença é realmente um requisito perigoso! . quando. a menos que. exceto quando a rampa traseira estiver aberta". a menos que o alarme esteja sendo testado ou o engenheiro tenha suprimido o alarme". Os problemas surgem quando os requisitos são testados e alguém tem que decidir o que (se houver) provaria que o requisito foi satisfeito. – "O alarme de incêndio deve sempre ser tocado quando a fumaça for detectada. Eles parecem pedir algo definitivo.

levam rapidamente à confusão e erros. especialmente quando combinadas com linguagem rebuscada ou referências a documentos de difícil acesso.  • Exemplo – "Dado que os sinais de entrada designados dos dispositivos especificados sejam recebidos na ordem correta onde o sistema seja capaz de .Incoerências  • Longas sentenças Incoerentes.

.

– Especificar design em vez das reais necessidades aumenta o custo dos sistemas por colocar restrições desnecessárias no desenvolvimento e na manufatura.  • 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". Se detalharmos demais. Freqüentemente. começaremos a projetar o sistema.  • Sinais de perigo incluem nomes de componentes. Ir muito longe é tentador para os designers. objetos de software ou procedures e campos de bancos de dados. especialmente quando eles chegam às suas partes favoritas. . materiais.Design prematuro • Os requisitos devem especificar as possibilidades de design sem restrições desnecessárias de um design específico.

sistemas e como o sistema deveria ser projetado. Uma forma rápida de conseguir confusão é misturar requisitos de usuários.  • Exemplo – "O usuário deve ser capaz de ver o número do canal corrente que deve ser exibido com fonte Swiss tamanho 14 em um painel LCD em conformidade com o padrão regulamentar federal 567-89 e montado com arruelas de borracha à prova de choque".• Misturar diferentes tipos de requisitos completo do que Os requisitos de usuário formam um modelo os usuários querem. que formam um modelo funcional completo do sistema proposto. teste ou instalação. design.  • Sinais de perigo são qualquer referência à sistema. testado ou instalado. O mesmo se aplica aos requisitos de sistema.  . Eles precisam ser organizados coerentemente para exibirem falhas e sobreposições.

Especulação • Os requisitos são parte de um contrato entre o cliente e o desenvolvedor. termos de significado geral sobre coisas que alguém provavelmente quer. normalmente e tipicamente.  .  • Sinais de perigo incluem idéias vagas sobre que tipo de usuário está falando e generalizações tais como: usualmente. geralmente. Não há espaço para listas de desejos.  • Exemplo – "Os usuários normalmente necessitam de rápida indicação de inclusão no sistema". freqüentemente.

.

Termos vagos incluem.Termos vagos e indefinidos • Muitas palavras usadas informalmente para indicar a qualidade do sistema são muito vagas para uso em requisitos. flexível.  • Exemplos – "A caixa de diálogo de impressão deve ser versátil e amigável". versátil.   • Os requisitos que usam esses termos não são verificáveis porque não há teste definitivo para mostrar se o sistema tem a propriedade indicada. aproximadamente. – "A lâmpada indicadora de status OK deve ser acesa o mais rápido possível depois do auto-teste do . possível. entre outros: amigável.

provavelmente. poderia. deveria. . desejável.Expressando meras possibilidades • Sugestões que não são explicitamente declaradas como requisitos são invariavelmente ignoradas pelos desenvolvedores. talvez.  • Exemplo – "O subsistema de recepção provavelmente deverá ser forte o suficiente para receber um sinal de dentro de uma construção de placas de aço".  • "Opções possíveis" são indicadas com termos tais como: pode.

agrada a todos os usuários. trata todas as falhas inesperadas. nunca falha. A engenharia é uma atividade do mundo real e nenhum sistema ou componente é perfeito. roda em todas as plataformas.Pensamentos desejosos • Os pensamentos desejosos significam pedir o impossível. seguro. atualizável a todas as situações futuras.  • Termos de pensamentos desejosos incluem: confiável.  • Exemplos – "A caixa de câmbio deve ser 100% segura .

2000).Regras de negócio • • As regras de negócio são declarações sobre políticas ou condições que devem ser satisfeitas. • • Uma regra de negócio é uma sentença que define ou qualifica algum aspecto do negócio. representando o conhecimento dos especialistas do negócio (BRG. Através das regras de negócio é possível garantir a estrutura do negócio ou influenciar o .

.

Regras de negócio • Algumas regras de negócios são impostas com base em leis e regulamentos. outras podem ser padrões da empresa. Há outras ainda que expressam as metas a serem atingidas pelo esforço de modelagem de negócios. Considere o público para certificar-se de que possam ser transmitidas com eficácia. • • Analise os resultados para verificar se você seguiu um estilo consistente ao definir as . • • Descreva as regras de negócios usando uma linguagem rigorosa e formal.

decisões estratégicas. obrigações contratuais. As regras podem depois ser combinadas em comportamentos mais complexos. de modo que somente uma regra seja necessária para executar uma ação definida. As regras de negócio definem como o negócio funciona e ditam o seu funcionamento. leis e regulamentações entre outros. objetivos. compromissos éticos e sociais. Regras de negócio abrangem diversos assuntos como políticas. Devem ser criadas regras que sejam executadas da forma mais independente possível. Essa técnica permite o teste e validação independentes para cada regra separadamente. •  • .Regras de negócio Estruturação •  Deve-se capturar e estruturar todas as regras de negócio que governam o universo de discussão. interesses. suas restrições e validações.

Nesses casos. tais construções levam a regras que são difíceis de entender e testar. Embora alguns mecanismos de regras permitam usar a construção ou em uma condição.Regras de negócio Estruturação • • As regras são tipicamente estruturadas como um par de instruções de condição e ação bem definidos. ao invés de criar uma . Geralmente. é melhor criar múltiplas regras para cobrir cada situação de ou. é uma melhor prática escrever as condições da regra como um conjunto em que todas as condições devem ser atendidas para acionar a regra. na prática.

status de emprego. com ações baseadas nas alterações de valores para essas condições. onde as decisões sobre a concessão de um empréstimo são baseadas no histórico de crédito. que é apenas uma maneira de resumir várias regras que compartilham um conjunto de condições. do solicitante. . Essa situação é comum em instituições financeiras.Regras de negócio Estruturação • • Algumas regras são representadas melhor em uma tabela de decisões. ativos possuídos. etc.

. por exemplo).  • Ao usar grupos e fluxos de regras. é útil agrupar essas regras para limitar as regras consideradas na validação. é possível modelar claramente o comportamento geral do mecanismo de regras e validar as regras isoladamente.Regras de negócio Estruturação • Regras podem ser estreitamente relacionadas na medida em que atendem aos mesmos dados de entrada ou executam um conjunto de ações semelhante (regras de validação. Muitas vezes.  • Grupos de regras são usados para organizar conjuntos de regras em categorias bem definidas para permitir a criação de um fluxo de regras.

Regras de negócio Estruturação  • As regras devem ser atômicas e escritas completamente na ótica de negócio.  • Procure estruturar as regras da seguinte forma:  – Termos e fatos.  .

Estruturação de regras Termos • • Defina os termos que pertencem ao negócio e são utilizados nas regras.  • Exemplo: Um gerente é definido como uma pessoa a quem duas ou mais pessoas reportam diretamente.  • Sugestão: Criação de um glossário corporativo com a coleção de termos usados no negócio. .

Estruturação de regras Fatos • • Descreva os fatos a partir dos termos.  • Exemplo: Um item de pedido deve conter um código. • • Alguns fatos denotam regras de negócio. inferência. Deve-se atentar para os fatos do tipo: Restrições. o preço e a descrição do produto. habilitadores de ação. cálculos. .

 • Exemplo: O valor da diária para um locatário da categoria ABC não deve exceder 1000 reais. • .Estruturação de regras Restrições • • Fatos que denotam restrições do processo de negócio podem ser considerados regras do negócio.

Estruturação de regras Cálculos • • Fatos que determinam cálculos dentro do processo de negócio.  .  • Exemplo: O valor de venda é calculado como o valor líquido mais a alíquota de 18% do imposto sobre circulação de mercadorias do estado.

um alarme será emitido para o setor de anti-fraude • .  • Exemplo: Quando o mesmo cartão for usado em duas lojas separadas por mais de 100 KM em menos que uma hora.Estruturação de regras – Habilitadores de ação • • Fatos que representam eventos dentro do processo de negócio.

000KM.Estruturação de regras Inferência • • Fatos expressos como inferências. então um desconto de 10% sobre o total do . senão (caso contrário). alguma outra ação pode ser executada.  • Esse tipo de regra geralmente é descrito por uma lógica do tipo "se-então-senão".  • Exemplo: Se o plano do cliente é VIP e a milhagem utilizada ultrapassou 10. então uma determinada ação é executada. onde se um conjunto específico de regras de negócios é atendido.