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
REQUISITOS DE SOFTWARE
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;
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.
O sistema deve prover telas apropriadas para o usurio ler documentos no repositrio de documentos.
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
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
Requisitos no-funcionais podem ser difceis de estabelecer e requisitos imprecisos so difceis para verificar;
Requisito no funcional verificvel: uma sentena que use alguma mtrica que possa ser objetivamente testada;
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.
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.
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.
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;
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;
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:
O ltimo item muitas vezes inclui informaes sobre o sistema atual que os concorrentes esto usando para
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
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
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
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.
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.
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
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
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
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
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
Considere o pblico para certificar-se de que possam ser transmitidos com eficcia.
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:
"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
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
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
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
Foque na declarao de que resultado voc fornecer para esse tipo de usurio.
...ver nuvens de tempestade atravs do radar...
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).
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
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.
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".
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
"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.
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.
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
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.
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.
Termos e fatos.
Exemplo: Um gerente definido como uma pessoa a quem duas ou mais pessoas reportam diretamente.
Alguns fatos denotam regras de negcio. Deve-se atentar para os fatos do tipo: Restries, clculos, habilitadores de ao, inferncia.
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.
Exemplo: O valor de venda calculado como o valor lquido mais a alquota de 18% do imposto sobre circulao de mercadorias do estado.
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
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