expressando condicoes que osoftware deve atender ou qualidades especificas que o software deva ter(PRESSMAN, 2011; SOMMERVILLE, 2011). Estes requisitos sao muito importantespara a fase de projeto, servindo como base para tomada de decisao nesta fase. A origem dos requisitos nao funcionais esta em fatores como:nas necessidades dos usuarios; em restricoes de orcamentos; em politicasorganizacionais; necessidades de interoperabilidade com outros sistemas ouhardware; e, ate mesmo, fatores externos como regulamentos e legislacoes. Estesrequisitos podem ser mais criticos do que os requisitos funcionais, pois, casoo software nao venha a atender algum requisito nao funcional pode se tornarinutil (SOMMERVILLER, 2011). Logo, os requisitos nao funcionais podem serclassificados quanto a sua origem. SOMMERVILLE (2011) classifica-os em: Requisitos de produto: especificam ocomportamento do software. Referem-se a atributos de qualidade que o sistemadeve apresentar, tais como confiabilidade, usabilidade, eficiencia,portabilidade, manutenibilidade e seguranca; Requisitos organizacionais: sao derivados demetas, politicas e procedimentos das organizacoes do cliente e do desenvolvedor.Incluem requisitos de processo (padroes de processo e modelos de documentos quedevem ser usados), requisitos de implementacao (tal como a linguagem deprogramacao a ser adotada), restricoes de entrega (tempo para chegar aomercado, restricoes de cronograma etc.), restricoes orcamentarias (custo,custo-beneficio) etcRequisitos externos: referem-se a todos osrequisitos derivados de fatores externos ao sistema e seu processo dedesenvolvimento. Podem incluir requisitos de interoperabilidade com sistemas deoutras organizacoes, requisitos legais (tais como requisitos de seguranca eprivacidade) e requisitos eticos.E importante ressaltar que a identificacao de um requisitonao funcional deve ser realizada de forma que o mesmo possa ser validado. Logo,um requisito nao funcional deve ser mensuravel. Portanto, os requisitos naofuncionais devem ser elaborados ate que os mesmos se tornem verificaveis. 2.3 Requisitos de DominioAlem da classificacao de requisitos funcionais e naofuncionais, SOMMERVILLE (2011) considera tambem os requisitos de dominio e odefine como requisitos provenientes do dominio de aplicacao do sistema erefletem caracteristicas e restricoes desse dominio. Estes requisitos saoderivados do dominio da aplicacao e podem ser requisitos funcionais novos,restricoes sobre requisitos existentes ou computacoes especificas, refletindofundamentos do dominio da aplicacao. Para exemplificar, um requisito de dominiopode ser um calculo que deve ser realizado para uma determinada funcionalidade.Na literatura, encontramos autores quecompreendem requisitos de dominio como sendo regras de negocio e essas regrasde negocio, assim como os requisitos de dominio, incluem terminologiasespecificas do dominio da aplicacao e sao mais facilmente capturadas em umafase de modelagem conceitual. 2.4 Requisitos de Usuarios e Requisitos de SistemaConsiderando que os requisitos devem ser passiveis deentendimento a todos os envolvidos com o seu processo, como os stakeholders[1](cliente, usuarios, desenvolvedores) e que, cada envolvido possui expectativasdiferentes, SOMMERVILLE (2011) sugere mais dois niveis de classificacao pararequisitos, sendo os requisitos de sistema e requisitos de usuarios. Os requisitos de usuarios sao declaracoes em linguagemnatural acompanhadas de diagramas intuitivos de quais servicos sao esperados dosistema e das restricoes sob as quais ele deve operar. Devem estar em um nivelde abstracao mais alto, de modo que sejam compreensiveis pelos usuarios dosistema que nao possuem conhecimento tecnico.Os requisitos de sistema definem detalhadamente as funcoes,servicos e restricoes do sistema. Sao versoes expandidas dos requisitos deusuario usados pelos desenvolvedores para projetar, implementar e testar osistema. Como requisitos de sistema sao mais