{"id":195,"date":"2011-06-15T21:23:21","date_gmt":"2011-06-16T00:23:21","guid":{"rendered":"https:\/\/www.semeru.com.br\/blog\/?p=195"},"modified":"2022-12-20T17:59:51","modified_gmt":"2022-12-20T20:59:51","slug":"engenharia-de-requisitos","status":"publish","type":"post","link":"https:\/\/www.semeru.com.br\/blog\/engenharia-de-requisitos\/","title":{"rendered":"Engenharia de Requisitos"},"content":{"rendered":"<p>Os problemas que os engenheiros de software precisam solucionar, muitas vezes, podem ser muito complexos. Compreender corretamente o problema se torna muito dif\u00edcil, especialmente se o sistema for novo. E claro, fica dif\u00edcil definir com clareza o que o sistema deve fazer. A descri\u00e7\u00e3o das fun\u00e7\u00f5es e das restri\u00e7\u00f5es s\u00e3o os requisitos do sistema. O processo de descobrir, analisar, documentar e verificar os requisitos recebe ent\u00e3o o nome de Engenharia de Requisitos (SOMMERVILLE, 2008).<\/p>\n<h3>1.1 Caracter\u00edsticas da Engenharia de Requisitos<\/h3>\n<p>O termo requisito n\u00e3o se aplica de forma consistente a ind\u00fastria de software. Isso se deve ao fato de em alguns casos os requisitos serem encarados como uma declara\u00e7\u00e3o abstrata de uma fun\u00e7\u00e3o que o sistema deve fornecer ou uma restri\u00e7\u00e3o do sistema. Em outros casos ele \u00e9 uma descri\u00e7\u00e3o detalhada de uma fun\u00e7\u00e3o do sistema (SOMMERVILLE, 2008). Em todo caso deve-se levar em conta que uma boa Engenharia de Requisitos \u00e9 um passo fundamental para o desenvolvimento de um bom produto (PAULA FILHO, 2000).<\/p>\n<p>Se uma empresa deseja estabelecer um contrato de desenvolvimento de um grande projeto a princ\u00edpio ela deve fazer defini\u00e7\u00e3o de requisitos relativamente abstrata (PAULA FILHO, 2000). Isso possibilita que os diferentes fornecedores apresentem propostas sugerindo diferentes maneiras de atender as necessidades organizacionais do cliente. Evitando ainda, que solu\u00e7\u00f5es predefinidas sejam adotadas em detrimento das particularidades organizacionais. Uma vez que o contrato esteja firmado o fornecedor deve ent\u00e3o preparar uma defini\u00e7\u00e3o de sistema bem detalhada. O que facilita a compreens\u00e3o por parte do cliente e possibilita tamb\u00e9m validar o que o software far\u00e1 (SOMMERVILLE, 2008).<\/p>\n<p>Durante a Engenharia de Requisitos podem aparecer alguns problemas decorrentes da falta de uma separa\u00e7\u00e3o n\u00edtida entre os dois diferentes n\u00edveis de descri\u00e7\u00e3o. Esses n\u00edveis podem ser distinguidos utilizando-se os termos <em>requisitos de usu\u00e1rio<\/em> para os requisitos abstratos de alto n\u00edvel e <em>requisitos de sistema<\/em> para indicar a descri\u00e7\u00e3o detalhada das funcionalidades do sistema. Pode ser produzida ainda uma descri\u00e7\u00e3o mais detalhada associando a Engenharia de Requisitos \u00e0s atividades de projeto. Para Sommerville (2008) esses dois n\u00edveis de requisitos e a especifica\u00e7\u00e3o de projeto de software podem ser definidos do seguinte modo:<\/p>\n<ul>\n<li><em>Requisitos de usu\u00e1rio <\/em>s\u00e3o declara\u00e7\u00f5es em linguagem natural e diagramas contendo as funcionalidades e as restri\u00e7\u00f5es sob as quais o sistema deve operar. Esse documento \u00e9 escrito para gerentes do cliente e dos fornecedores que n\u00e3o tenham conhecimento t\u00e9cnico detalhado do sistema.<\/li>\n<li><em>Requisitos de sistema<\/em> detalham funcionalidades e restri\u00e7\u00f5es. Esse documento pode inclusive servir como um contrato entre as partes envolvidas no projeto. Ele \u00e9 escrito para os profissionais t\u00e9cnicos de n\u00edvel s\u00eanior e para gerentes de projeto<\/li>\n<li><em>Especifica\u00e7\u00e3o de projeto de software<\/em> \u00e9 uma descri\u00e7\u00e3o abstrata do projeto de software na qual se acrescenta mais detalhes aos requisitos do sistema. Esse documento \u00e9 escrito para os engenheiros de software que desenvolver\u00e3o o sistema.<\/li>\n<\/ul>\n<h3>1.2 Requisitos Funcionais e N\u00e3o Funcionais<\/h3>\n<p>Sommerville (2008) classifica os requisitos de sistema de software como funcionais, n\u00e3o funcionais e como requisitos de dom\u00ednio:<\/p>\n<ul>\n<li><em>Requisitos funcionais<\/em> definem as funcionalidades do sistema como deve reagir em condi\u00e7\u00f5es espec\u00edficas e como se comportar em determinadas situa\u00e7\u00f5es. Podem ainda declarar o que o sistema n\u00e3o deve fazer.<\/li>\n<li><em>Requisitos n\u00e3o funcionais<\/em> s\u00e3o restri\u00e7\u00f5es sobre servi\u00e7os ou fun\u00e7\u00f5es oferecidas pelo sistema. Dentre elas destacam-se restri\u00e7\u00f5es de tempo, sobre o processo de desenvolvimento e de padr\u00f5es. A descri\u00e7\u00e3o das restri\u00e7\u00f5es complementa a defini\u00e7\u00e3o de requisitos (PAULA FILHO, 2000).<\/li>\n<li><em>Requisitos de dom\u00ednio<\/em> s\u00e3o restri\u00e7\u00f5es origin\u00e1rias do dom\u00ednio da aplica\u00e7\u00e3o do sistema e refletem caracter\u00edsticas do mesmo. Podem ser requisitos funcionais ou n\u00e3o funcionais.<\/li>\n<\/ul>\n<p>A distin\u00e7\u00e3o entre esses diferentes tipos de requisitos n\u00e3o \u00e9 t\u00e3o clara como sugere essas defini\u00e7\u00f5es. Um requisito pode parecer-se inicialmente n\u00e3o funcional, mas que quando desenvolvido com mais detalhes pode dar origem a uma s\u00e9rie de novos requisitos funcionais. Ao discutirmos sobre requisitos devemos levar em conta que na realidade a distin\u00e7\u00e3o entre eles \u00e9 artificial (SOMMERVILLE, 2008).<\/p>\n<h4>1.2.1 Requisitos funcionais<\/h4>\n<p>Os requisitos funcionais descrevem a funcionalidade ou os servi\u00e7os que se espera que o sistema realize em benef\u00edcio dos usu\u00e1rios (PAULA FILHO, 2000). Eles variam de acordo com o tipo de software em desenvolvimento, com usu\u00e1rios e com o tipo de sistema que est\u00e1 sendo desenvolvido. Requisitos funcionais podem ser expressos de diversas maneiras e, como j\u00e1 foi dito acima, em diferentes n\u00edveis de detalhamento. Os requisitos funcionais de usu\u00e1rios definem recursos espec\u00edficos que devem ser fornecidos pelo sistema (SOMMERVILLE, 2008).<\/p>\n<p>\u00c9 natural para um desenvolvedor de sistemas interpretar um requisito amb\u00edguo para simplificar sua implementa\u00e7\u00e3o. Entretanto isso pode n\u00e3o ser necessariamente o que o cliente necessita. Surgem ent\u00e3o novos requisitos e \u00e9 necess\u00e1rio realizar altera\u00e7\u00f5es no sistema, o que afetar\u00e1 diretamente o tempo e o custo do projeto.<\/p>\n<p>Inicialmente a especifica\u00e7\u00e3o de requisitos funcionais deve ser completa \u2013 deve definir todos os requisitos de usu\u00e1rio e refletir as decis\u00f5es de especifica\u00e7\u00e3o tomadas \u2013 e consistente \u2013 os requisitos n\u00e3o devem ter defini\u00e7\u00f5es contradit\u00f3rias (PAULA FILHO, 2000). Entretanto, na realidade, em sistemas complexos e grandes, \u00e9 quase imposs\u00edvel atingir a consist\u00eancia e a completeza dos requisitos. Isso ocorre, principalmente, em fun\u00e7\u00e3o da complexidade inerente ao sistema e porque as pessoas possuem diferentes pontos de vistas em rela\u00e7\u00e3o a um problema. Esses problemas somente emergem ap\u00f3s uma an\u00e1lise mais aprofundada. \u00c0 medida que os problemas v\u00e3o sendo descobertos, deve se ir atualizando o documento de requisitos (SOMMERVILLE, 2008).<\/p>\n<h4>1.2.2 Requisitos n\u00e3o funcionais<\/h4>\n<p>Os requisitos n\u00e3o funcionais s\u00e3o aqueles que n\u00e3o dizem respeito diretamente \u00e0s funcionalidades fornecidas pelo sistema. Podem estar relacionados a propriedades de sistemas emergentes, como confiabilidade, tempo de resposta, espa\u00e7o em disco, desempenho e outros atributos de qualidade do produto (PAULA FILHO, 2000). \u00c0s vezes podem dizer respeito ao sistema como um todo. Isso significa que na maioria das vezes eles s\u00e3o mais importantes que os requisitos funcionais individuais. Se uma falha em cumprir um requisito funcional pode comprometer parte do sistema, uma falha em cumprir um requisito n\u00e3o funcional pode tornar todo o sistema in\u00fatil (SOMMERVILLE, 2008).<\/p>\n<p>Nem sempre os requisitos n\u00e3o funcionais dizem respeito ao sistema de software a ser desenvolvido. Muitas vezes requisitos n\u00e3o funcionais podem restringir o processo utilizado para desenvolver o sistema. Requisitos de processo podem abranger desde uma especifica\u00e7\u00e3o de padr\u00f5es de qualidade a ser utilizada no processo at\u00e9 uma especifica\u00e7\u00e3o de ferramentas as serem utilizadas.<\/p>\n<p>Os requisitos n\u00e3o funcionais surgem de acordo com as necessidades dos usu\u00e1rios, em raz\u00e3o de restri\u00e7\u00f5es or\u00e7ament\u00e1rias, de politicas organizacionais, pela necessidade de interoperabilidade com outros sistemas de software ou hardware e at\u00e9 mesmo em fun\u00e7\u00e3o de fatores externos. Esses \u00faltimos podem ser por exemplo de natureza legal ou de seguran\u00e7a.<\/p>\n<p>Sommerville (2008) classifica os requisitos n\u00e3o funcionais em:<\/p>\n<ul>\n<li><em>Requisitos de produto<\/em> que especificam o comportamento do produto. Podem restringir, por exemplo, a liberdade dos projetistas a utilizar uma determinada linguagem.<\/li>\n<li><em>Requisitos organizacionais <\/em>que s\u00e3o procedentes de pol\u00edticas e procedimentos adotados nas organiza\u00e7\u00f5es do cliente e do desenvolvedor. Especifica que o sistema deve ser de acordo com um processo-padr\u00e3o da empresa.<\/li>\n<li><em>Requisitos externos<\/em> que abrange t\u00f3picos advindos de fatores externos ao sistema. Dentre eles destacam-se os requisitos de interoperabilidade, os requisitos \u00e9ticos e os requisitos legais que devem ser observados a fim de garantir que o sistema opera de acordo com a lei.<\/li>\n<\/ul>\n<p>Um problema dos requisitos n\u00e3o funcionais \u00e9 que geralmente eles s\u00e3o de dif\u00edcil verifica\u00e7\u00e3o e quantifica\u00e7\u00e3o em uma primeira vers\u00e3o do produto (PAULA FILHO, 2000). Podem ser escritos para refletir os objetivos gerais do cliente como usabilidade, recupera\u00e7\u00e3o \u00e0 falhas ou rapidez de resposta ao usu\u00e1rio. Esses requisitos s\u00e3o problem\u00e1ticos na medida em que abrem a possibilidade e m\u00faltiplas interpreta\u00e7\u00f5es e claro discuss\u00f5es quando o sistema \u00e9 entregue (SOMMERVILLE, 2008).<\/p>\n<p>O ideal \u00e9 que os requisitos n\u00e3o funcionais sejam expressos de forma quantitativa utilizando-se m\u00e9tricas que possam ser testadas. Algumas das principais m\u00e9tricas para testar os requisitos n\u00e3o funcionais s\u00e3o, a velocidade, o tamanho, a usabilidade, a confiabilidade, a robustez e a portabilidade.<\/p>\n<p>Todavia a especifica\u00e7\u00e3o quantitativa de requisitos tamb\u00e9m se mostra problem\u00e1tica uma vez que os clientes podem n\u00e3o conseguir traduzir suas metas em requisitos quantitativos. N\u00e3o h\u00e1, por exemplo, uma m\u00e9trica capaz de mensurar a facilidade de manuten\u00e7\u00e3o. Por esse motivo, os documentos de requisitos podem incluir declara\u00e7\u00f5es de metas junto aos requisitos. Elas s\u00e3o \u00fateis, pois fornecem pistas quanto as prioridades dos clientes. Entretanto essas metas podem ser mal entendidas e n\u00e3o serem objetivamente verificadas.<\/p>\n<p>Requisitos n\u00e3o funcionais podem entrar em conflito e interagir com outros requisitos funcionais do sistema. Muitas vezes pode ser imposs\u00edvel equilibrar diferentes requisitos n\u00e3o funcionais sendo necess\u00e1rio sacrificar um em detrimento de outro de maior import\u00e2ncia para a aplica\u00e7\u00e3o. \u00c9 o que Sommerville (2008) chama de encontrar uma \u201ccompensa\u00e7\u00e3o\u201d para minimizar o impacto no sistema como um todo de uma escolha por atender um determinado requisito n\u00e3o funcional em detrimento de outro. De forma similar o PMBOK (2008) afirma que com frequ\u00eancia s\u00e3o necess\u00e1rias compensa\u00e7\u00f5es entre os requisitos e os objetivos do projeto. Destaca ainda que essas compensa\u00e7\u00f5es ir\u00e3o variar de projeto para projeto.<\/p>\n<p>\u00c9 recomend\u00e1vel que requisitos funcionais e n\u00e3o funcionais sejam diferenciados em um documento de requisitos; embora isso n\u00e3o seja f\u00e1cil. Se os requisitos n\u00e3o funcionais forem definidos separadamente dos requisitos funcionais ser\u00e1 dif\u00edcil relacion\u00e1-los. Por outro lado se forem definidos juntos, ser\u00e1 dif\u00edcil separar considera\u00e7\u00f5es funcionais de n\u00e3o funcionais e delinear requisitos que dizem respeito ao sistema como um todo. Sendo assim \u00e9 preciso encontrar um equil\u00edbrio adequado que ir\u00e1 depender do tipo de sistema. O ideal \u00e9 que seja criada uma se\u00e7\u00e3o separada no documento de requisitos listando aqueles que claramente se relacionam (SOMMERVILLE, 2008).<\/p>\n<h3>1.3 Requisitos de Dom\u00ednio<\/h3>\n<p>Os requisitos de dom\u00ednio s\u00e3o derivados do dom\u00ednio da aplica\u00e7\u00e3o do sistema que podem ser novos requisitos funcionais em si, podem restringir os requisitos funcionais existentes ou estabelecer como devem ser executados c\u00e1lculos espec\u00edficos. Muitas vezes esses requisitos refletem fundamentos do dom\u00ednio da aplica\u00e7\u00e3o (SOMMERVILLE, 2008). Sem uma compreens\u00e3o satisfat\u00f3ria desses requisitos pode ser imposs\u00edvel fazer o sistema operar de forma satisfat\u00f3ria (PRESSMAN, 2006).<\/p>\n<p>Esses requisitos s\u00e3o expressos com o uso de uma linguagem espec\u00edfica do dom\u00ednio da aplica\u00e7\u00e3o e, geralmente, de dif\u00edcil compreens\u00e3o para os engenheiros de software. Os especialistas do dom\u00ednio podem, por julgarem \u00f3bvio, deixarem de fornecer informa\u00e7\u00f5es importantes e como resultado o requisito pode n\u00e3o ser implementado de forma satisfat\u00f3ria (SOMMERVILLE, 2008).<\/p>\n<h3>1.4 Requisitos de Usu\u00e1rio<\/h3>\n<p>Os requisitos de usu\u00e1rios descrevem os requisitos funcionais e n\u00e3o funcionais de forma compreens\u00edvel pelos usu\u00e1rios do sistema que n\u00e3o t\u00eam conhecimentos t\u00e9cnicos detalhados. Devem especificar somente o comportamento externo do sistema evitando o quanto for poss\u00edvel das caracter\u00edsticas do projeto de sistema. Podem ser escritos em linguagem natural, formul\u00e1rios e diagramas simples e intuitivos. Entretanto de acordo com Sommerville (2008) podem surgir alguns problemas quando os requisitos s\u00e3o escritos em linguagem natural:<\/p>\n<ul>\n<li><em>Falta de clareza <\/em>n\u00e3o \u00e9 f\u00e1cil utilizar a linguagem natural de forma precisa e sem ambiguidades sem acarretar em um documento de dif\u00edcil leitura.<\/li>\n<li><em>Confus\u00e3o de requisitos <\/em>os requisitos funcionais e n\u00e3o funcionais, os objetivos do sistema e informa\u00e7\u00f5es do projeto podem estar definidos de forma obscura.<\/li>\n<li><em>Fus\u00e3o de requisitos<\/em> v\u00e1rios requisitos distintos podem ser unificados em um \u00fanico requisito.<\/li>\n<\/ul>\n<p>Uma boa pratica \u00e9 isolar requisitos de usu\u00e1rio de requisitos de sistema caso contr\u00e1rio os leitores podem ser sobrecarregados por detalhes t\u00e9cnicos que n\u00e3o lhes s\u00e3o relevantes. A fim de minimizar diverg\u00eancias na elabora\u00e7\u00e3o requisitos de usu\u00e1rio Sommerville (2008) \u00a0recomenda que:<\/p>\n<ul>\n<li>Se crie um formato-padr\u00e3o e certifique que todas as defini\u00e7\u00f5es de requisitos estejam de acordo com ele.<\/li>\n<li>Utilize a linguagem de forma consistente, distinguindo requisitos obrigat\u00f3rios dos desej\u00e1veis.<\/li>\n<li>Ressalte partes importantes dos requisitos.<\/li>\n<li>Evite o uso de jarg\u00f5es t\u00e9cnicos.<\/li>\n<\/ul>\n<h3>1.5 Requisitos de Sistema<\/h3>\n<p>Requisitos de sistema s\u00e3o descri\u00e7\u00f5es mais detalhadas dos requisitos de usu\u00e1rio. Podem servir de base para um contrato de implementa\u00e7\u00e3o e devem especificar completa e consistentemente todo o sistema. S\u00e3o utilizados como ponto de partida para o projeto do sistema. Inicialmente eles deveriam definir o que o sistema deveria fazer e n\u00e3o como ele teria de ser implementado. Entretanto de acordo com Sommerville (2008) isso \u00e9 quase imposs\u00edvel por diferentes motivos:<\/p>\n<ul>\n<li>A defini\u00e7\u00e3o de uma arquitetura inicial do sistema pode ser definida para auxiliar a estruturar a especifica\u00e7\u00e3o de requisitos.<\/li>\n<li>Frequentemente os sistemas devem interagir com outros sistemas restringindo o sistema e consequentemente gerando novos requisitos.<\/li>\n<li>O uso de um projeto espec\u00edfico pode ser um requisito externo de sistema.<\/li>\n<\/ul>\n<p>A linguagem natural \u00e9 frequentemente usada para escrever especifica\u00e7\u00f5es de requisitos de sistema. Todavia, de acordo com Sommerville (2008) quando ela \u00e9 usada para especificar requisitos de forma detalhada isso pode provocar problemas:<\/p>\n<ul>\n<li>A linguagem natural est\u00e1 sujeita a ambiguidades<\/li>\n<li>Uma especifica\u00e7\u00e3o de requisitos em linguagem natural \u00e9 muito flex\u00edvel permitindo dizer a mesma coisa de diferentes formas.<\/li>\n<li>N\u00e3o existe nenhum meio f\u00e1cil de padronizar especifica\u00e7\u00f5es de requisitos escritos em linguagem natural.<\/li>\n<\/ul>\n<p>As especifica\u00e7\u00f5es de requisitos escritas em linguagem natural est\u00e3o sujeitas a diverg\u00eancias. Frequentemente, elas s\u00f3 s\u00e3o descobertas em fases posteriores do processo de software. As solu\u00e7\u00f5es, quase sempre, levam a um aumento no custo e no tempo do projeto.<\/p>\n<p>Enfim, as informa\u00e7\u00f5es dos documentos de softwares ir\u00e3o variar de acordo com o tipo de software em desenvolvimento e da abordagem adotada para faz\u00ea-lo. E nada mais s\u00e3o que esbo\u00e7os (PRESSMAN, 2008) que podem ser usados para descrever as funcionalidades de um sistema. Dependendo da abordagem escolhida o documento de requisitos ir\u00e1 variar no enfoque e no tamanho. O documento poder\u00e1 ter desde uma simples defini\u00e7\u00e3o geral do escopo para um dado processo at\u00e9 um documento extremamente detalhado para outro processo. A decis\u00e3o de qual adotar caber\u00e1 aos engenheiros de software e sua decis\u00e3o frente \u00e0s caracter\u00edsticas do sistema.<\/p>\n<h2>Treinamentos relacionados com essa postagem<\/h2>\n<p><a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_agile\" target=\"_blank\" rel=\"noopener\"><br \/>\n<img decoding=\"async\" style=\"max-width: 107%;\" title=\"Agile desmistificado com Scrum, XP, Kanban, Spotify e Trello\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/05-agile.png\" \/><br \/>\n<\/a><\/p>\n<p><a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_trello\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" style=\"max-width: 107%;\" title=\"Trello 2023: Gest\u00e3o Otimizada de Equipes e Projetos Pessoais\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/04-trello.png\" \/><br \/>\n<\/a><\/p>\n<p><a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_spotify\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" style=\"max-width: 107%;\" title=\"Spotify Engineering Culture Desmistificado\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/06-spotify.png\" \/><br \/>\n<\/a><\/p>\n<p><a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_scrum_remote\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" style=\"max-width: 107%;\" title=\"Agile e Scrum para Times em Home Office com Trello\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/23-scrum-remote.png\" \/><br \/>\n<\/a><\/p>\n<p><a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_kanban_remote\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" style=\"max-width: 107%;\" title=\"Agile e Kanban para Times em Home Office com Trello\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/21-kanban-remote.png\" \/><br \/>\n<\/a><\/p>\n<h2>Refer\u00eancias:<\/h2>\n<p>SOMMERVILLE, Ian. <strong>Engenharia de Software <\/strong>: 8 ed. Rio de Janeiro: Prentice-Hall, 2008.<\/p>\n<p>PRESSMAN, Roger S. <strong>Engenharia de Software <\/strong>: 6 ed. S\u00e3o Paulo: McGraw Hill\/Nacional, 2006.<\/p>\n<p>PMBOK. <strong>Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK)<\/strong>. 4 ed. Pennsylvania: Project Management Institute, Inc., 2008.<\/p>\n<p>PAULA FILHO, Wilson de P\u00e1dua. <strong>Engenharia de Software:<\/strong> fundamentos, m\u00e9todos e padr\u00f5es. S\u00e3o Paulo: LTC Editora, 2000.<\/p>\n<div align=\"right\"><div class=\"sharexyWidgetNoindexUniqueClassName\"><div id=\"shr_42821628\"><\/div><\/div><\/div>","protected":false},"excerpt":{"rendered":"<p>Os problemas que os engenheiros de software precisam solucionar, muitas vezes, podem ser muito complexos. Compreender corretamente o problema se torna muito dif\u00edcil, especialmente se o sistema for novo. E claro, fica dif\u00edcil definir com clareza o que o sistema deve fazer. A descri\u00e7\u00e3o das fun\u00e7\u00f5es e das restri\u00e7\u00f5es s\u00e3o os requisitos do sistema. O [&#8230;]<\/p>\n<div align=\"right\">\n<div class=\"sharexyWidgetNoindexUniqueClassName\">\n<div id=\"shr_42821628\"><\/div>\n<\/div>\n<\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[45,67,44,70,72,71,68,69],"tags":[147,166,164,165],"_links":{"self":[{"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/posts\/195"}],"collection":[{"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/comments?post=195"}],"version-history":[{"count":6,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/posts\/195\/revisions"}],"predecessor-version":[{"id":1357,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/posts\/195\/revisions\/1357"}],"wp:attachment":[{"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/media?parent=195"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/categories?post=195"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/tags?post=195"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}