Modelagem de requisitos de clientes de empreendimentos habitacionais de interesse social com o uso de BIM

Modeling client requirements for low-income housing with the use of BIM

ARTIGOS

Modelagem de requisitos de clientes de empreendimentos habitacionais de interesse social com o uso de BIM

Modeling client requirements for low-income housing with the use of BIM

Juliana Parise Baldauf^I; Carlos Torres Formoso^II; Luciana Inês Gomes Miron^III

^IUniversidade Federal do Rio Grande do Sul Porto Alegre - RS - Brasil

^IIUniversidade Federal do Rio Grande do Sul Porto Alegre - RS - Brasil

^IIIUniversidade Federal do Rio Grande do Sul Porto Alegre - RS - Brasil

^{Endereço para correspondência}

RESUMO

O gerenciamento de requisitos do cliente visa a melhorar a geração de valor em empreendimentos de construção através de um processo sistemático de captura de requisitos, processamento desta informação, tornando-as explícitas para a equipe de desenvolvimento do produto, bem como controlar se os requisitos de diferentes clientes são atendidos de forma equilibrada. Isto é particularmente importante quando os recursos são limitados, como em empreendimentos habitacionais de interesse social (EHIS). A modelagem dos requisitos dos clientes é complexa, à medida que existe uma grande quantidade de informações qualitativas e é preciso considerar a diversidade de requisitos que normalmente existem entre os diferentes envolvidos no processo. O objetivo deste artigo é propor um método para modelar requisitos de clientes de EHIS com suporte de Building Information Modeling (BIM). Este método foi concebido para apoiar os processos de tomada de decisão durante as fases de desenvolvimento de projeto bem como a avaliação de projetos que já foram entregues. Este artigo está focado nas principais atividades envolvidas na aplicação do método: explorar diferentes abordagens de modelagem de requisitos, estruturar requisitos e utilizar o software dRofus para gerenciar requisitos em distintas etapas de projeto. Uma das principais contribuições do estudo refere-se à estruturação de requisitos genéricos que podem servir de base para o desenvolvimento de novos empreendimentos de habitação de interesse social.

Palavras-chave: Gerenciamento de requisitos do cliente. Modelagem de requisitos. BIM. Habitação de interesse social. Geração de valor.

ABSTRACT

Client requirements management aims to improve value generation in construction projects through a systematic process of capturing requirements, processing this information, and making them explicit to the product development team, as well as controlling whether the requirements from different clients are properly balanced. This is particular important when resources are limited, such as in low-income housing projects. Modeling requirements is a complex task due to the large amount of qualitative information involved, and the need to consider the diversity of requirements that usually exist among different stakeholders. This paper aims to propose a method to model client requirements in social housing projects with the support of Building Information Modeling (BIM). This method was devised to support both the decision-making processes during design stages, and also the evaluation of projects that have already been delivered. This article is focused on main activities involved in the application of the method: exploring different ways of modeling client requirements, structuring client requirements, and using dRofus to requirements management on different design stages. One of the main contributions of this article is concerned with the structuring of generic requirements that can be used as a starting point for developing new low-income housing projects.

Keywords: Client requirements management. Modeling client requirements. BIM. Low-income housing. Value generation.

Introdução

O governo brasileiro, visando à redução do déficit habitacional estimado em 5,546 milhões de domicílios (MINISTÉRIO..., 2011), criou em 2009 o Programa Minha Casa Minha Vida (PMCMV), gerenciado pelo Ministério das Cidades e operado pela Caixa Econômica Federal (CAIXA). A meta inicial deste programa foi a construção de um milhão de moradias para famílias com renda de até 10 salários mínimos, em parceria com estados, municípios e iniciativa privada (INSTITUTO..., 2011). A segunda etapa do PMCMV tem como meta a produção de mais de dois milhões de moradias até 2014.

Além da necessidade de reduzir o déficit habitacional no país, é importante agregar valor ao ambiente construído através da melhoria da qualidade do projeto para que efetivamente sejam proporcionados benefícios aos usuários de empreendimentos habitacionais de interesse social (EHIS). As soluções adotadas na fase de projeto geram amplas repercussões em todo o processo da construção assim como na qualidade do produto final a ser entregue ao cliente (SOUZA; ABIKO, 1997). Para que o produto final atenda às necessidades dos clientes, é preciso gerenciar os requisitos dos clientes envolvidos. O gerenciamento de requisitos do cliente consiste na identificação, análise, priorização e disponibilização de informações sobre as necessidades e preferências do cliente (KAMARA; ANUMBA; EVBUOMWAN, 1999). Assim, tornando esses requisitos explicitamente disponíveis e mantendo o controle da evolução dessas informações é possível apoiar o processo de tomada de decisão bem como verificar se esses requisitos foram devidamente atendidos na solução de projeto (KAMARA; ANUMBA; EVBUOMWAN, 2002). Essa etapa de verificação está vinculada à exposição de problemas com os requisitos e suas soluções de projeto, possibilitando realizar as correções destes problemas antes da produção do produto e assim evitar prejuízos e retrabalhos (SOMMERVILLE, 2007).

Devido à grande quantidade de informações qualitativas envolvidas nos requisitos do cliente, Kiviniemi (2005) aponta para a necessidade de desenvolver métodos de gestão de requisitos que se apóiem em ferramentas de tecnologia de informação (TI) para permitir certo grau de automação para este processo. De fato, Kamara e Anumba (2001) sugerem que a TI pode apoiar a criação, comunicação, documentação e gestão da informação do programa de necessidades. No entanto, existem alguns desafios no uso de TI para gestão de requisitos, tais como a dificuldade de capturar os requisitos implícitos e explícitos, manter essas informações atualizadas e armazenar diferentes requisitos das distintas partes interessadas ao longo do processo de desenvolvimento de produto (LEINONEN; HUOVILA, 2001).

O uso de Building Information Modeling¹ (BIM) apresenta um bom potencial para apoiar o gerenciamento de requisitos de clientes, uma vez que pode conectar diferentes tipos de informação com modelos do produto. BIM, entre outras coisas, tem como objetivo agilizar os processos, apresentar informações da construção de uma forma acessível e um formato comum (HOOPER; EKHOLM, 2010), reduzir a possibilidade de falta ou confronto de informações (HOOPER; EKHOLM, 2010; EASTMAN et al., 2008), permitir a coordenação do trabalho de diferentes intervenientes do empreendimento (HOOPER; EKHOLM, 2010) e facilitar o trabalho simultâneo de vários profissionais envolvidos na concepção e produção do empreendimento (EASTMAN et al., 2008).

No entanto, tem havido poucas aplicações de BIM na modelagem de requisitos de cliente, especialmente nos estágios iniciais de desenvolvimento de projeto (KOPPINEN et al., 2008). O presente trabalho também explora o potencial da tecnologia BIM para a modelagem de requisitos de empreendimentos habitacionais de interesse social, em contraste com outros estudos que tem como foco obras emblemáticas ou de grande complexidade, tais como museus, edifícios de alta tecnologia, ou prédios industriais.

Este artigo tem como objetivo propor um método para modelar os requisitos dos clientes de empreendimento habitacionais de interesse social, com o uso de BIM. Pretende-se com este tipo de modelagem apoiar a tomada de decisão no processo de desenvolvimento de produto para os profissionais envolvidos tanto no processo de projeto quanto na avaliação de propostas de projetos, a partir da perspectiva da agência de financiamento. Neste sentido, a modelagem de requisitos com apoio de BIM é importante no contexto de habitação de interesse social por possibilitar:

(a) a organização de grande quantidade de informações qualitativas e resultantes da diversidade de requisitos que normalmente existe entre os diferentes envolvidos;

(b) a visualização e disponibilização dessas informações para as partes interessadas;

(c) o controle dos requisitos ao longo do processo de desenvolvimento de EHIS.

Assim, o uso de ferramenta BIM pode facilitar o acesso a informações sobre requisitos, por auxiliar na organização ou estruturação da grande quantidade de informações, além de possibilitar a conexão entre requisitos e o modelo do produto, facilitando a visualização, disponibilização e controle dessas informações.

Modelagem de requisitos

Algumas abordagens para modelar requisitos são sugeridas na literatura, embora nenhuma delas tenha sido amplamente utilizada na indústria da construção. Quatro destas abordagens foram utilizadas como ponto de partida para esta pesquisa:

(a) desdobramento da função qualidade (QFD²);

(b) diagrama em árvore;

(c) modelo de processamento de requisitos do cliente (CRPM³), proposto por Kamara, Anumba e Evbuomwan (2002); e

(d) modelo de requisitos, proposto por Kiviniemi (2005).

Todas possuem em comum o foco na etapa de estruturação dos requisitos, percebida como importante na modelagem de requisitos desenvolvida nesta pesquisa.

Desdobramento da função qualidade

O desdobramento da função qualidade é uma ferramenta amplamente conhecida para processar os requisitos dos clientes. São utilizadas matrizes para representar e monitorar o atendimento aos requisitos, assim como melhorar a comunicação e integração horizontal entre os membros da equipe de desenvolvimento do produto (KAMARA; ANUMBA; EVBUOMWAN, 1999). No entanto, a aplicação de QFD na construção tem sido muito modesta e existe apenas um número limitado de exemplos na literatura de gestão da construção (DIKMEN; BIRGONUL; KIZILTAS, 2005).

No contexto da habitação de interesse social no Brasil, Lima, Formoso e Echeveste (2011) apontou algumas dificuldades e limitações da aplicação do QFD:

(a) o processamento dessas informações é complexo e demanda muito tempo, principalmente se a matriz atingir tamanhos muito grandes; e

(b) é difícil envolver membros do desenvolvimento do produto que desconhecem a ferramenta, no processamento das informações, necessárias para produzir a matriz, particularmente se este processo é fragmentado.

Embora existam limitações e dificuldades na aplicação do QFD no contexto da habitação social, é importante salientar que esta ferramenta tem desempenhado um papel importante neste estudo, uma vez que influenciou fortemente o desenvolvimento de algumas ferramentas de TI, tais como ClientPro, que tem como base o CRPM e o EcoProP⁴.

Diagrama em árvore

O diagrama em árvore é uma ferramenta que permite o mapeamento sistemático em detalhes ampliados de toda a gama de caminhos e tarefas que precisam ser realizadas a fim de alcançar um objetivo principal e cada subobjetivo relacionado (ANJARD, 1995). Este diagrama é usado de uma forma descendente para desmembrar os objetivos e necessidades dos clientes em requisitos até se alcançar níveis mais detalhados como os atributos que podem ser utilizados para a aplicação (KWONG; BAI, 2002). O diagrama em árvore é uma ferramenta que pode ser utilizada para representar graficamente os requisitos permitindo melhorar a visualização e estruturação desses requisitos.

Modelo de processamento de requisitos do cliente (CRPM)

O CRPM é a representação de uma estrutura proposta para estabelecer os requisitos do cliente em projetos da construção. Esse modelo descreve as funções ou atividades que necessitam ser realizadas, assim como, ferramentas e técnicas requeridas para efetivamente definir, analisar e traduzir os requisitos do cliente dentro de uma solução neutra de especificações do projeto (KAMARA; ANUMBA; EVBUOMWAN, 2002). Os resultados das atividades de processamento dos requisitos dos clientes podem facilitar o trabalho colaborativo da equipe de projeto multidisciplinar.

O CRPM utiliza ferramentas como o QFD, através matriz da qualidade para implementar a "voz do consumidor", além de outras técnicas como a modelagem IDEF-0 (KAMARA; ANUMBA; EVBUOMWAN, 2002). Segundo os referidos autores, o CRPM foi desenvolvido para assegurar o foco adequado no cliente, e a partir desse modelo foi gerada uma versão de software, o ClientPro, criado para automatizar o processamento de requisitos.

Modelo de requisitos (KIVINIEMI, 2005)

Kiviniemi (2005) desenvolveu um modelo para estabelecer conexões entre os requisitos e modelos de produtos da construção, que visa a apoiar a gestão de requisitos do cliente no processo de projeto. Este modelo é baseado na ideia de que é necessário estruturar (ou modelar) requisitos a fim de conectá-los ao modelo do produto. Através da modelagem de requisitos desenvolvida por Kiviniemi (2005), é possível, entre outras coisas, visualizar as relações entre os requisitos do empreendimento e objetos de projeto por meio de conexões diretas e indiretas bem como disponibilizar essas informações às partes interessadas. Além disso, Kiviniemi (2005) salienta que os modelos oferecem a oportunidade de gerenciar e conectar a informação de modo que não seja necessário dispor de um ambiente com base em diferentes documentos, já que em um único modelo é possível armazenar todas as informações necessárias para o desenvolvimento de um produto da construção civil.

Kiviniemi (2005) enfatiza a necessidade de registrar e estruturar requisitos para que estes possam ser comparados com as soluções de projeto. Quando os conflitos entre requisitos e soluções surgem, deveria ser fácil para a equipe de projeto visualizar e gerenciar esses problemas (KIVINIEMI, 2005).

O mesmo autor sugere alguns potenciais benefícios de implementar o modelo de requisitos em ferramentas de gestão de requisitos, o que permitiria, por exemplo:

(a) o desenvolvimento de templates

⁵ de requisitos para diferentes tipos de edificação; e

(b) armazenamento de informações que poderiam ser comparadas, não somente com as soluções de projeto, mas também com informações de manutenção através do ciclo de vida da edificação (KIVINIEMI, 2005).

Os templates de requisitos podem permitir o gerenciamento de um grande conjunto de requisitos, onde os usuários definiriam um significativo subconjunto de requisitos para diferentes tipos de projetos (KIVINIEMI, 2005). Da mesma forma, o desenvolvimento de um método sistemático para acompanhar a evolução dos requisitos poderia fornecer informações para definir requisitos aos novos empreendimentos (KIVINIEMI, 2005).

Estruturação dos requisitos

A estruturação e decomposição de requisitos em uma hierarquia, que inicia em um nível mais geral (requisitos primários) e se desdobra em níveis mais detalhados (requisitos secundários e terciários), pode facilitar a compreensão e acompanhamento das informações à medida que são geradas (KOTT; PEASANT, 1995; ULRICH; EPPINGER, 2008). Kiviniemi (2005) acrescenta que somente com uma estrutura ampla de um conjunto de requisitos predefinidos pode-se estabelecer uma conexão eficaz entre requisitos e modelos do produto.

Contudo, Kiviniemi (2005) argumenta que não é possível padronizar os diferentes tipos de requisitos devido à existência de diversos tipos de edificações, as quais possuem alguns requisitos em comum, mas também uma grande quantidade de requisitos específicos. Kiviniemi (2005) identificou um conjunto de requisitos e criou uma estrutura, o Modelo de especificação de requisitos, que possibilita a adição de requisitos específicos para se adequar a um determinado empreendimento (KIVINIEMI, 2005). Neste modelo, a estruturação de requisitos é baseada em cinco programas de construção, duas hierarquias de requisitos amplamente usadas (WBFS⁶ e EcoProp) e requisitos espaciais das especificações IFC⁷.

Segundo Kiviniemi (2005), uma hierarquia de requisitos pode ser organizada de duas formas:

(a) categorias funcionais, tais como, requisitos de segurança, iluminação e requisitos acústicos; e

(b) níveis de detalhe do produto da construção, tais como, projeto, terreno, requisitos dos espaços.

Essas duas formas permitem diferentes modos de visualizar a organização dos requisitos e isso fornece uma base para interfaces com os usuários para gerenciamento de requisitos.

A hierarquia de Kiviniemi (2005) é formada por 300 requisitos, divididos em 13 principais categorias, tais como localização e serviço, e 35 subcategorias, tais como terreno e infraestrutura, ambas pertencentes à categoria de requisitos de localização. Esta hierarquia possui uma grande quantidade de requisitos, tornando possível adaptá-la a vários tipos de empreendimentos da construção. Esta estrutura foi utilizada como ponto de partida para a estruturação dos requisitos de empreendimento habitacionais de interesse social.

Ferramentas para a gestão de requisitos

A partir da revisão de literatura, foram investigadas algumas ferramentas computacionais que podem apoiar a gestão de requisitos: ClientPro, DOORS⁸, RequisitePro⁹, EcoProP e dois software BIM, o dRofus¹⁰ e Solibri Model Checker¹¹. O software ClientPro, que possui como base o CRPM, foi excluído da análise por não ser um software comercial. As ferramentas DOORS e RequisitePro não foram analisadas pois são ferramentas de gestão de requisitos na área de engenharia de software. As demais ferramentas possuem potencial de serem utilizadas para a modelagem de requisitos, a partir da opinião de especialistas e de citações na literatura (EASTMAN et al., 2009; EASTMAN et al., 2008; HUOVILA; PORKKA, 2005; HÄKKINEN et al., 2007; KIVINIEMI, 2005).

O EcoProP é uma ferramenta para gestão sistemática de requisitos de empreendimentos da construção (HUOVILA; PORKKA, 2005). Esse software facilita a captura dos requisitos (KIVINIEMI, 2005) já que utiliza como base a ferramenta QFD para documentar requisitos de desempenho para todo o ciclo de vida do produto edifício (LEINONEN; HUOVILA, 2000). O EcoProP também permite a visualização de um grande conjunto de requisitos, os quais estão estruturados em uma hierarquia de requisitos com base nos requisitos de desempenho (HUOVILA; PORKKA, 2005). Adicionalmente, este software também auxilia na disponibilização dos requisitos aos clientes através da interface com o usuário. Entretanto, existe a necessidade de ferramentas que permitam auxiliar, além da disponibilização de informações, na organização, controle e verificação dos requisitos, em função da importância dessas etapas para o efetivo gerenciamento dos mesmos.

O dRofus, por sua vez, é um software que permite que os requisitos sejam armazenados em uma estrutura hierárquica, a qual facilita a visualização e organização dos requisitos dentro do software. Além disso, auxilia na disponibilização e controle dos requisitos bem como na realização de alguns tipos de verificações, tais como verificações de áreas, equipamentos e mobiliários, com a finalidade de garantir que os requisitos planejados estão sendo atendidos na solução de projeto adotada. Por ser um software BIM, o dRofus, possibilita a visualização do modelo do produto, o qual pode ser desenvolvido em um software de modelagem BIM, como, por exemplo, o Autodesk Revit¹². Isto é feito através da importação de dados do modelo via formato IFC (NOSYKO AS, 2013). Adicionalmente, o software permite a criação de templates de requisitos para diferentes tipos de edificações, capacitando o gerenciamento de um grande conjunto de requisites.

Entretanto, o software que mais se destaca pela função de verificação é o Solibri Model Checker, o qual permite a verificação de códigos legais, normativos e corporativos (EASTMAN et al., 2008). Esta verificação também está baseada em modelos IFC (EASTMAN et al., 2008). Contudo, o Solibri não permite a verificação de todos os tipos de requisitos, mas apenas requisitos normativos que podem ser transformados em regras, como por exemplo, requisitos de acessibilidade.

Este levantamento inicial apontou que não existe uma única ferramenta que pode apoiar de forma completa todas as atividades envolvidas no gerenciamento de requisitos, indicando a necessidade de utilizar ferramentas que se complementem. No presente trabalho optou-se por se utilizar o dRofus na modelagem de requisitos. Este software foi o único entre os analisados que permite ser utilizado nas distintas etapas da gestão de requisitos. O mesmo facilita a organização, disponibilização e controle dos requisitos além de permitir alguns tipos verificações de requisitos. Adicionalmente, com o dRofus é possível fazer a conexão entre requisitos e o modelo do produto, o que facilita a visualização das informações pela equipe de projeto.

Método de pesquisa

Neste estudo adotou-se a estratégia de pesquisa construtiva (constructive research ou design science research¹³), que é uma abordagem de pesquisa para o desenvolvimento de construções inovadoras, cujo objetivo é solucionar os problemas enfrentados no mundo real e contribuir para teoria das disciplinas nas quais é aplicada (KASANEN; LUKKA; SIITONEN, 1993; LUKKA, 2003). As construções inovadoras são denominadas de artefatos (LUKKA, 2003), tais como modelos, métodos, constructos e implementações (MARCH; SMITH, 1995).

O artefato proposto nesse estudo é o método de modelagem de requisitos de clientes de empreendimentos habitacionais de interesse social. Foram identificados dois possíveis usuários deste método:

(a) empresas da construção de EHIS, responsáveis pelo desenvolvimento do produto e construção de empreendimentos imobiliários; e

(b) e agências de financiamento e as municipalidades, que são responsáveis pela avaliação do projeto de habitação social, e às vezes também realizam a inspeção durante a execução.

A Figura 1 apresenta o delineamento da pesquisa, a qual foi dividida em três etapas:

(a) compreensão;

(b) desenvolvimento; e

(c) consolidação.

Na primeira etapa foi realizada uma análise do Programa Habitacional Minha Casa Minha Vida (PMCMV), particularmente na atividade de análise técnica das propostas que são encaminhadas ao agente financeiro (CAIXA). Assim, foi possível identificar as principais dificuldades e oportunidades de melhoria desse processo, além de analisar como cada um dos requisitos é verificado e em que documentos são disponibilizados. Um conjunto de entrevistas foi realizado com profissionais envolvidos no processo de revisão de projetos, o qual é desempenhado pela CAIXA, assim como entrevistas com a equipe técnica de uma empresa construtora-incorporadora que desenvolve empreendimentos de habitação de interesse social.

A partir das entrevistas, foram identificados os principais requisitos do PMCMV que constam em uma lista de especificações mínimas elaborada pelo Ministério das Cidades, bem como requisitos específicos determinados pelo agente financiador. Os requisitos identificados referem-se aos EHIS destinados às famílias que possuem renda familiar mensal de até R$ 1.600,00 (faixa 1¹⁴). Essas informações foram estruturadas conforme categorias de requisitos identificadas na hierarquia proposta por Kiviniemi (2005), resultando em uma versão inicial da estrutura de requisitos. Cabe salientar que esta pesquisa tem como foco requisitos utilizados durante o processo de análise das propostas. Dessa forma, não foram analisados os requisitos de todos os intervenientes do processo de desenvolvimento de EHIS, apenas aqueles considerados pela CAIXA e pela construtora-incorporadora.

A revisão bibliográfica inicial, focada nas diferentes formas de modelagem de requisitos, contribuiu para estabelecer um referencial teórico, ao mesmo tempo em que, juntamente com a recomendação de especialista em gestão de requisitos, permitiu selecionar uma ferramenta BIM (dRofus) para a apoiar a gestão de requisitos. O software dRofus foi disponibilizado para uso acadêmico pela empresa Nosyko AS. Ainda na primeira etapa do trabalho, foi realizada uma avaliação preliminar da ferramenta selecionada, assim como o treinamento da pesquisadora e auxiliar de pesquisa na utilização da mesma. O treinamento do software ocorreu com demonstrações realizadas pelo representante da empresa, auxílio de guias de usuário, bem como vídeos¹⁵ disponibilizados no website do fabricante do programa. Na sequência, um conjunto de requisitos foi armazenado no software dRofus, com o objetivo de melhorar a compreensão dessa ferramenta. Para isso, utilizou-se um empreendimento de habitação de interesse social (empreendimento A1) modelado no software Autodesk Revit para conectar com o conjunto de requisitos armazenados no dRofus. O software Autodesk Revit foi utilizado para a modelagem do produto por possuir uma prática interoperabilidade com o software dRofus. Isso ocorre devido a um plugin do dRofus que pode ser instalado no Autodesk Revit facilitando a troca e atualização das informações.

Na segunda etapa do estudo, a estrutura foi revisada e avaliada pela equipe de técnicos da CAIXA, bem como, com profissionais da empresa construtora-incorporadora. Nessa etapa também foi realizada a comparação de empreendimentos habitacionais desenvolvidos pela empresa construtora-incorporadora e comparação entre requisitos de diferentes tipologias de empreendimentos com a finalidade de avaliar a aplicabilidade da estrutura de requisitos em diferentes contextos.

Na sequência, os requisitos foram atualizados na ferramenta dRofus e, em paralelo, foi realizada a modelagem do empreendimento B1 no software Autodesk Revit. O empreendimento B1 foi selecionado por pertencer à faixa 1 do Programa Minha Casa Minha Vida e ter sido recentemente aprovado pela CAIXA. Posteriormente os espaços ou objetos do modelo do empreendimento EHIS B1 foram conectados com os espaços definidos no dRofus. Posteriormente, foram identificados os tipos de requisito que podem ser verificados automaticamente com uso desta ferramenta.

Na última etapa, de consolidação, o método para modelagem de requisitos de clientes de EHIS com uso de BIM foi proposto, baseado nas atividades desenvolvidas nas etapas anteriores. Cabe ressaltar que não foi possível implementar a solução em outros estudos devido ao longo tempo que seria despendido para a realização do treinamento e aplicação das ferramentas BIM por parte da CAIXA ou da empresa construtora-incorporadora. Posteriormente, ocorreu a avaliação do artefato, que, segundo March e Smith (1995), possibilita verificar o progresso alcançado e a sua funcionalidade. Na avaliação do método para modelagem de requisitos de clientes de EHIS com uso de BIM proposto foi utilizados dois constructos principais: utilidade e aplicabilidade.

Quanto à utilidade do método, foi considerada a potencial contribuição do mesmo para a melhoria da gestão de requisitos dos clientes envolvidos no processo de desenvolvimento de EHIS e, dessa forma, apoiar o processo de tomada de decisão. Assim, para a avaliação da utilidade do método proposto considerou-se os seguintes constructos:

(a) visualização dos requisitos;

(b) disponibilização dos requisitos;

(c) controle e rastreabilidade de requisitos;

(d) padronização do processo de verificação das propostas;

(e) abrangência de critérios de verificação; e

(f) automatização do processo de verificação de requisitos.

Para avaliação do constructo utilidade foram consideradas as seguintes fontes de evidências: entrevistas abertas realizadas com profissionais da CAIXA e da empresa construtora-incorporadora durante a apresentação de resultados preliminares do estudo, reunião de apresentação de resultados finais realizada com profissionais da CAIXA e percepção da pesquisadora.

O constructo aplicabilidade da solução diz respeito à facilidade de utilização e à viabilidade de utilização em uma gama de contextos diferentes e foi desdobrado em:

(a) facilidade de uso, relacionada à facilidade em modelar o produto e os requisitos dos clientes e desenvolver uma interface para os usuários; e

(b) transferência da solução, relacionada à adaptação da estrutura de requisitos para diferentes programas e empreendimentos habitacionais de interesse social.

Para avaliação do constructo aplicabilidade foram consideradas as seguintes fontes de evidências: percepção da pesquisadora acerca das dificuldades e do tempo de realização das atividades de modelagem, análise de documentos acerca dos memoriais descritivos dos EHIS comparados, análise e comparação das duas listas contendo especificações mínimas para EHIS de casa e apartamento e entrevista aberta realizada com profissionais da empresa construtora-incorporadora.

Após a avaliação das contribuições práticas do estudo, foi realizada uma reflexão das contribuições teóricas do método proposto em relação à gestão de requisitos.

Resultados

dificuldades no processo de desenvolvimento de projetos do PMCMV

A partir das entrevistas realizadas com profissionais da CAIXA e profissionais da empresa construtora-incorporadora foi constatado que o processo de verificação de adequação do produto (EHIS) à demanda ou às características do programa apresenta algumas dificuldades:

(a) um longo tempo é necessário para verificação das propostas, principalmente se o projeto retorna várias vezes para correções;

(b) há pouca uniformidade de critérios nesta verificação, uma vez que o escopo da avaliação e os parâmetros adotados dependem de cada profissional, o qual pode priorizar requisitos distintos dos demais responsáveis pelas avaliações de propostas;

(c) as diferenças entre as análises ocasionam perda de credibilidade do proponente, gerando diversas reclamações por causa da falta de clareza na definição de critérios;

(d) existência de grande quantidade de informações qualitativas, resultando em avaliações fortemente subjetivas por parte dos profissionais da CAIXA;

(e) dificuldades de visualização das informações devido à existência de diferentes documentos e incompatibilidade entre os mesmos;

(f) falta de organização das informações;

(g) dificuldades na disponibilização das informações aos projetistas; e

(h) falta de controle das alterações realizadas nos requisitos ao longo do processo de desenvolvimento de projetos de EHIS.

Estruturação dos requisitos

A estruturação inicial dos requisitos, desenvolvida na etapa 1 desta pesquisa, considerou as 13 categorias apresentadas por Kiviniemi (2005) e seus desdobramentos. Dessa forma foi possível analisar com quais categorias os requisitos do PMCMV estão relacionados. Para os requisitos que não tinham relação com o segundo e terceiro níveis de requisitos, foi necessário incluir novas subcategorias (nível 2). Para facilitar o armazenamento dos requisitos no software dRofus optou-se por organizar a estrutura a partir das categorias funcionais (Requisitos de localização, segurança, etc.) já que o software permite fazer agrupamentos de requisitos conforme as partes do produto (Unidade habitacional, Condomínio, Entorno).

A versão inicial da estrutura de requisitos, desenvolvida na etapa 1 desta pesquisa, necessitou de um refinamento, realizado a partir da avaliação por parte dos técnicos da CAIXA e profissionais da construtora-incorporadora, resultando em uma estrutura de requisitos adaptada ao contexto de EHIS. As Figuras 2, 3, 4 e 5 apresentam na primeira coluna as categorias e subcategorias da estrutura de requisitos proposta por Kiviniemi (2005). Na segunda coluna são apresentados os motivos para a exclusão de determinadas categorias e subcategorias e a terceira coluna, as categorias e subcategorias semelhantes ou que foram renomeadas para adaptar-se aos empreendimentos habitacionais de interesse social (Figuras 2, 3, 4 e 5). A coluna 4 apresenta apenas categorias e subcategorias de requisitos utilizadas para compor a estrutura dos requisitos adaptada aos EHIS (Figuras 2, 3, 4 e 5).

Apesar de Kiviniemi (2005) não considerar no escopo do seu trabalho requisitos para estruturas e sistemas, as categorias Sistemas Elétricos e Hidrossanitários (Figura 6) foram adicionadas à estrutura, devido à identificação desses requisitos nas listas de especificações mínimas do PMCMV. Dessa forma, a estrutura de requisitos adaptada a EHIS contempla 9 categorias (nível 1), 13 subcategorias (nível 2), conforme Figura 6. Por sua vez, as subcategorias são desdobradas em 53 requisitos (nível 3) e 105 atributos e especificações mínimas do PMCMV para a tipologia de apartamento.

A partir de entrevistas realizadas com profissionais da empresa construtora-incorporadora, foi constatado que a estrutura de requisitos estava adequada, mas alguns requisitos foram interpretados de forma diferente pela mesma, gerando novas soluções de projeto. Exemplo disso é a exigência de bacia sanitária com caixa acoplada no banheiro de portador de necessidades especiais (PNE). Esse requisito necessitou alterações, pois, para possibilitar a colocação de barra de apoio, a construtora-incorporadora optou por uma caixa semiembutida. Essa alteração foi aceita na análise realizada pela CAIXA. Outro exemplo de solução adotada nos projetos de EHIS dessa empresa é que, para atender a área de circulação de um cadeirante (1,20 m x 1,50 m) no dormitório de solteiro, foi necessário adotar um beliche para adequar o dormitório aos requisitos do PMCMV.

Outra questão importante percebida durante a reunião com profissionais da empresa construtora-incorporadora está relacionada à lista de especificações mínimas utilizada por essa empresa. Essa lista não possui alguns dos requisitos definidos pela CAIXA, pois apenas inclui requisitos definidos pelo Ministério das Cidades. Contudo, a construtora-incorporadora foi aconselhada a considerar esses requisitos definidos pela CAIXA no momento em que o projeto retornou para realização de ajustes das soluções adotadas. A CAIXA por ser um agente operador, importante para o desenvolvimento de programas habitacionais, possui grande influência na tomada de decisão no sentido de solicitar requisitos aos proponentes dos EHIS.

A Figura 7, a título de exemplo, representa o detalhamento da categoria de Requisitos de Localização. Observa-se que a estrutura de requisitos é desdobrada em quatro colunas: nível 1, formado pela categoria primária; nível 2, formado por subcategorias de requisitos; nível 3, inclui requisitos e atributos; e, na coluna 4, são inseridos atributos e especificações mínimas do Programa Minha Casa Minha Vida e especificações da CAIXA. A última coluna, objetos do produto, indica as partes do projeto com as quais as informações de requisitos estão relacionadas. Essas relações foram feitas para auxiliar os agrupamentos de requisitos no software dRofus.

Durante a reunião com profissionais da empresa construtora-incorporadora, além de avaliar a estrutura de requisitos foram identificadas algumas diferenças entre requisitos quando a aprovação dos projetos ocorre em diferentes prefeituras, em função da legislação específica para cada município. As diferenças de requisitos também podem estar relacionadas à atuação do órgão financiador de cada município ou região na qual é influente. Com isso, foi realizada uma comparação entre empreendimentos de mesma faixa de renda e entre EHIS com diferentes faixas de renda para a tipologia de apartamento. A comparação entre EHIS é importante para avaliar a aplicabilidade da estrutura de requisitos aos diferentes empreendimentos e programas habitacionais. Para avaliar, portanto, a aplicabilidade da estrutura de requisitos para a tipologia de casas foi necessário comparar a lista de especificações mínimas dessa tipologia com a de especificações para apartamento (CAIXA..., 2013). Apesar das diferenças identificadas, a estrutura de requisitos desenvolvida nessa pesquisa poderia ser utilizada para aprovação de projetos de EHIS de faixa 1 nas duas Prefeituras Municipais analisadas, de Caxias do Sul e Canoas, pois dos 105 atributos e especificações mínimas do PMCMV, apenas 3 são diferentes. Além disso, para aplicação da estrutura de requisitos à faixa 2 do PMCMV, pelo menos 30% das informações precisariam ser ajustadas, pois, para essa faixa de renda, não existem exigências, por exemplo, em relação à acessibilidade universal ou a acabamentos específicos da edificação. A estrutura de requisitos também pode ser aplicada para diferentes tipologias de empreendimentos habitacionais de interesse social, pois não foram identificadas muitas diferenças entre os requisitos das tipologias casas e apartamentos.

Armazenamento dos requisitos no software

O dRofus é organizado em departamentos e subdepartamentos conforme a Figura 8. Os departamentos foram criados e nomeados conforme as partes do produto (Unidade habitacional, Condomínio e Entorno) na coluna da esquerda da Figura 8.

O departamento "Unidade Habitacional" é composto por subdepartamentos, tais como, "Cozinha, Sala de estar/jantar, Dormitórios, Banheiro, Área de serviço". O subdepartamento "Dormitórios", por exemplo, é configurado por espaços¹⁶, tais como "Dormitório casal" e "Dormitório de solteiro" (coluna da direita da Figura 8).

Ao selecionar um dos espaços, o software abre uma janela denominada Room Data Sheet¹⁷ (RDS) (Figura 8), na qual são inseridas as informações a respeito dos espaços. As planilhas RDS são formadas por categorias funcionais (nível 1), tais como Requisitos dos Espaços e Requisitos de Acessibilidade. Dentro de cada planilha são inseridas as informações referentes ao espaço selecionado (Figura 8), sendo que as informações sobre requisitos podem ser inseridas em diferentes níveis de detalhe. As categorias de requisitos são visualizadas para todos os espaços que configuram o empreendimento como um todo. No software só é possível criar uma única RDS, a qual é utilizada para inserir as informações relacionadas a todos os espaços, porém, caso um espaço não necessite das informações de determinada categoria, essa ou apenas parte das informações poderá ser bloqueada para aquele espaço específico por meio de filtros. Os filtros podem ser utilizados para diferenciar um espaço do outro, e assim conter requisitos específicos da RDS. Além disso, dentro de cada categoria do Nível 1 (planilhas RDS) é possível criar campos editáveis, ou seja, podem ser preenchidos com informações específicas do espaço selecionado.

Os requisitos, portanto, foram inseridos no dRofus conforme os níveis de detalhamento da estrutura de requisitos. A Figura 9 representa na parte superior a captura de tela do software, na qual é visualizada a RDS contendo os requisitos do Dormitório de casal do EHIS B1. Na parte inferior da Figura 9 pode-se visualizar uma parcela da estrutura de requisitos referente à categoria Requisitos dos Espaços.

As categorias (nível 1), tais como Espaços¹⁸, Acessibilidade, dentre outros, nomearam as planilhas RDS, conforme exemplo da Figura 9. Os demais níveis de desdobramento de requisitos foram inseridos conforme a indicação das setas na Figura 9. A marcação com retângulo vermelho na Figura 9 aponta um campo no qual podem ser inseridas informações relacionadas às especificações mínimas do PMCMV. Essas informações foram extraídas do memorial descritivo do EHIS B1.

Modelagem do produto e conexão com os espaços

Ao mesmo tempo em que os requisitos foram armazenados no dRofus, foi desenvolvida a modelagem do empreendimento escolhido no software Autodesk Revit. Para essa modelagem foram utilizados documentos disponibilizados pela construtora-incorporadora que projetou o empreendimento. Após modelar o produto, os espaços criados no modelo foram conectados com os espaços criados no dRofus (Figura 10a). No exemplo da Figura 10a, o banheiro PNE modelado no Revit foi conectado com o espaço Banheiro PNE do dRofus. Com isso, qualquer alteração nas dimensões desse banheiro pode ser automaticamente atualizada no dRofus. Além dos espaços, os equipamentos projetados no Revit podem ser conectados com os equipamentos planejados no dRofus.

A conexão entre os espaços modelados no Revit e os espaços criados no dRofus, em adição à importação das informações em IFC, permitem que o modelo do produto EHIS seja visualizado no dRofus (Figura 10b).

Verificação de requisitos

O software dRofus possibilita realizar algumas verificações automáticas. Por exemplo, um dos requisitos para Sistemas Hidrossanitários, "prever solução para máquina de lavar roupas (ponto hidráulico e de esgoto)", foi verificado por meio da comparação entre modelo do produto, produzido no Revit, e requisitos planejados no dRofus.

A Figura 11 apresenta os pontos hidrossanitários e equipamentos da área de serviço planejados no dRofus em comparação aos pontos e equipamentos projetados no Revit. No software de gestão de requisitos, dRofus, estavam planejados dois pontos hidrossanitários (um ponto hidráulico e um ponto de esgoto). Entretanto, nota-se que um ponto hidrossanitário não foi projetado (informação marcada em vermelho na tabela de comparação entre Revit e dRofus da Figura 11).

A verificação entre requisitos planejados e atendidos pelo projeto pode ser bastante útil durante o processo de análise das propostas que são encaminhadas à CAIXA, bem como para que os projetistas tenham controle no atendimento dos requisitos. Entretanto, percebe-se que apenas requisitos de caráter quantitativo podem ser verificados automaticamente por meio do uso do software dRofus. Esses podem ser requisitos de áreas, pé-direito, equipamentos, mobiliário, pontos elétricos e hidrossanitários.

Cabe ressaltar que o dRofus possui, além da possibilidade de verificação de requisitos, a função de controle de todas alterações realizadas e evolução dos requisitos. O software cria um histórico das operações executadas em cada um dos espaços. É possível identificar os espaços e as informações alteradas, a data e horário destas modificações e o profissional que a realizou. Este controle das alterações de requisitos durante o processo de desenvolvimento do produto é importante para transferir o conhecimento dessas alterações, por exemplo, aos novos projetistas e profissionais encarregados da análise de projetos. Além disso, permite que os requisitos sejam rastreados pela equipe de projeto, ou seja, os projetistas podem identificar com maior facilidade a origem de determinado requisito e com quais espaços ou objetos do produto esses requisitos estão relacionados.

Método para modelagem de requisitos de clientes de EHIS

Com base no estudo realizado, pôde-se definir uma sequência de passos para o processo de modelagem de requisitos, apresentada a seguir:

(a) identificação de requisitos: na etapa de identificação de requisitos é necessário definir o contexto do projeto, definir e explicitar os objetivos do empreendimento, identificar os grupos de interesse de clientes e responsáveis pela tomada de decisão além de obter os requisitos de todos os clientes envolvidos no processo de desenvolvimento de empreendimentos da construção. A identificação de requisitos pode ocorrer durante todo o processo de desenvolvimento dos empreendimentos, incluindo desde a identificação de requisitos em documentos secundários (projetos semelhantes) até a coleta de requisitos com usuários finais dos empreendimentos por meio de avaliações pós-ocupação;

(b) processamento de requisitos: durante essa etapa é importante estruturar os requisitos, pois somente com requisitos estruturados e organizados é possível realizar a efetiva modelagem de requisitos. A partir da estruturação de requisitos, muitas vezes, é necessário priorizar os grupos de interesse bem como priorizar os requisitos para garantir que os requisitos mais importantes sejam considerados no produto final. Com a priorização dos requisitos a próxima atividade é a tradução dos requisitos em atributos de projeto;

(c) disponibilização e Controle dos requisitos: para facilitar a etapa de disponibilização dos requisitos, deve-se primeiramente inserir requisitos e atributos estruturados no software de gestão de requisitos simultaneamente à modelagem do produto da construção. Após, conectar requisitos planejados, que estão inseridos no software de gestão, com o modelo do produto. O uso de ferramentas de gestão de requisitos auxilia na disponibilização dos requisitos aos tomadores de decisão e facilita a visualização dessas informações através da conexão entre requisitos estruturados e o modelo do produto. O controle de requisitos deve ocorrer durante todo o processo de gestão de requisitos, já que muitos requisitos podem ser alterados ao longo do processo de projeto e execução do produto da construção; e

(d) verificação de requisitos: no final do processo deve-se verificar se os requisitos designados estão sendo atendidos por meio de soluções de projeto. A utilização de ferramentas BIM pode facilitar o processo de verificação dos requisitos reduzindo tempo despedido e possibilitando a padronização nesse processo de verificação.

O método proposto pode auxiliar na melhoria da visualização das informações sobre os requisitos tanto para agentes da CAIXA como para os profissionais de empresas da construção que desenvolvem empreendimentos de habitação social. A visualização das informações é melhorada devido à conexão entre os requisitos e o modelo do produto, bem como em função da melhor organização das informações dentro da ferramenta de gestão de requisitos, o dRofus. Além disso, o método foi percebido como uma ferramenta de apoio à disponibilização dos requisitos aos proponentes de novos empreendimentos, devido à interface prática entre os usuários do software e por possibilitar o reaproveitamento das informações de requisitos em distintos programas e empreendimentos habitacionais por meio da criação de diferentes templates de requisitos. O controle das alterações de requisitos também foi apontado como uma atividade importante já que os requisitos muitas vezes sofrem alterações ao longo do processo de desenvolvimento de EHIS e essas alterações nem sempre são bem documentadas. É importante que tanto o agente operador (CAIXA) quanto as empresas da construção civil tenham conhecimento e controle das alterações de requisitos realizadas ao longo do processo de desenvolvimento de EHIS. Dessa forma, pode-se reduzir o retrabalho em relação às correções do projeto, assim como, garantir que estão sendo atendidos os requisitos corretos ou mais atualizados.

Além disto, foi percebido que o método facilita a rastreabilidade dos requisitos, permitindo identificar a origem de determinado requisito e com quais espaços ou objetos do produto esses requisitos estão relacionados. O método pode ser considerado como uma ferramenta capaz de padronizar o processo de verificação das propostas em função da possibilidade de realizar verificações automáticas. A automatização do processo de verificação é percebida como importante, pois pode auxiliar na redução do tempo despedido na realização das análises das propostas. Além disso, o método permite aumentar a quantidade de critérios de verificação possibilitando a melhoria das soluções de projeto.

Em relação à facilidade de uso, foram avaliados aspectos quanto à facilidade em modelar o produto e os requisitos dos clientes e desenvolver uma interface para os usuários. Esses aspectos foram avaliados a partir da percepção da pesquisadora. Em relação ao tempo despendido para realização das atividades de modelagem, foi percebido um tempo muito maior para a modelagem do produto, com duração de 30 horas, em comparação com a modelagem de requisitos, a qual levou 4 horas e 30 minutos. Contudo, o tempo de modelagem do produto não deve ser considerado com um desafio para o desenvolvimento de projetos, pois há uma tendência crescente de exigir que todos os projetos sejam modelados.

Conforme mencionado anteriormente, não foi possível implementar o método em outros estudos. Para aplicação do método proposto seria necessário adquirir ferramentas BIM e realizar treinamento de pessoal na utilização das mesmas, além da necessidade de o agente operador (CAIXA) exigir projetos no padrão IFC. Entretanto, além das exigências de projetos no padrão IFC é necessário definir quais os objetos do produto devem ser modelados e o nível de detalhe dos mesmos para que não haja equívocos no momento em que o modelo do produto é comparado com os requisitos dos clientes. Dessa forma, para dar continuidade a este estudo, poderiam ser desenvolvidos checklists com as informações necessárias e nível de detalhe de cada parte do produto de empreendimentos de habitação social. Esses checklists seriam utilizados pelos projetistas no desenvolvimento de novos projetos de habitação social.

Quanto à transferência da solução, constatou-se, a partir da análise e comparação entre empreendimentos, que, apesar das diferenças, a estrutura de requisitos desenvolvida nessa pesquisa poderia se adaptar aos diferentes empreendimentos de faixa 1, independente do município em que é executado, além de possibilitar a aplicação para EHIS de faixa 2. Na comparação entre tipologias de casas e apartamentos verificou-se que a estrutura de requisitos pode ser aplicada com pequenas adaptações para diferentes tipologias de empreendimentos habitacionais de interesse social.

Conclusões

A presente pesquisa salientou a importância de gerenciar os requisitos dos clientes de empreendimentos habitacionais de interesse social a fim de auxiliar na tomada de decisão e possibilitar o desenvolvimento de melhores soluções de projeto. Com esta finalidade foi proposto um método para a modelagem de requisitos com suporte de ferramentas BIM.

A modelagem apontou várias utilidades, tais como:

(a) auxiliar na padronização do processo de avaliação de projetos;

(b) aumentar o escopo de critérios de avaliação;

(c) facilitar a disponibilização de requisitos aos projetistas;

(d) reutilizar as informações em diferentes programas de habitação de interesse social;

(e) controlar a evolução de requisitos; e

(f) auxiliar a visualização e organização de requisitos.

No entanto, a aplicação da modelagem de requisitos em habitação social é uma tarefa complexa, pois envolve a necessidade de adquirir ferramentas BIM e treinamento dos profissionais.

Além disso, a agência de financiamento deve exigir projetos no padrão IFC.

Por fim, cabe ressaltar que o processo de modelagem de requisitos com uso de BIM envolve uma fase de identificação de requisitos dos clientes, estruturação, bem como conecta os requisitos estruturados com software do projeto, que representam modelos do produto edifício. Através da modelagem de requisitos de clientes, é possível organizar, disponibilizar, controlar e verificar os requisitos com as soluções de projeto adotadas e, assim, auxiliar na tomada de decisão dos diferentes envolvidos no processo de desenvolvimento de projetos de habitação de interesse social. O uso do método de modelagem de requisitos poderá auxiliar na geração de valor para o projeto de habitação social, atendendo às necessidades e expectativas dos clientes finais.

Contudo, existem ainda algumas lacunas a serem preenchidas, tais como:

(a) avaliar e aprimorar o método de modelagem proposto a partir da sua aplicação durante as etapas de desenvolvimento de empreendimentos habitacionais de interesse social;

(b) investigar mais profundamente como a modelagem de requisitos pode auxiliar no desenvolvimento de melhores soluções de projetos de EHIS; e

(c) realizar a gestão sistemática de requisitos ao longo do processo de desenvolvimento do produto EHIS já que esta pesquisa dedicou-se principalmente à estruturação de requisitos e utilização dessas informações no processo de projeto através do uso de BIM.

Agradecimentos

Os autores agradecem à Caixa Econômica Federal de Porto Alegre, pela participação e informações fornecidas; à FINEP e CNPq, pelo financiamento do projeto TICHIS (Tecnologia de Informação e Comunicação em Habitação de Interesse Social); à CAPES e ao CNPq, pela bolsa de mestrado concedida; à empresa participante do estudo, pela concessão de dados; e à empresa NosyKo AS que colaborou para o desenvolvimento desta pesquisa através do suporte técnico e disponibilização do software dRofus para uso acadêmico.

Carlos Torres Formoso

Núcleo Orientado para a Inovação da Edificação | Universidade Federal do Rio Grande do Sul

E-mail: [e-mail]

Luciana Inês Gomes Miron

Núcleo Orientado para a Inovação da Edificação | Universidade Federal do Rio Grande do Sul

E-mail: [e-mail]

Recebido em 02/04/13

Aceito em 06/07/13

• ANJARD, R. P. Management and Planning Tools. Training for Quality, v. 3, n. 2, p. 34-37, 1995.
• ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR-ISO 12006-2: construção de edificação: organização de informação da construção: parte 2: estrutura para classificação de informação. Rio de Janeiro, 2010.
• CAIXA ECONÔMICA FEDERAL. Selo Casa Azul Boas Práticas Para Habitação Mais Sustentável 2010. Disponível em: <http://downloads.caixa.gov.br/_arquivos/desenvolvimento_urbano/gestao_ambiental/SELO_CASA_AZUL_CAIXA_versaoweb.pdf>. Acesso em: 28 fev. 2013.
• CAIXA ECONÔMICA FEDERAL. Programas de Habitação Disponível em: <http://www1.caixa.gov.br/gov/gov_social/municipal/programas_habitacao/pmcmv/saiba_mais.asp>. Acesso em: 28 fev. 2013.
• DIKMEN, I.; BIRGONUL, M. T.; KIZILTAS, S. Strategic Use of Quality Function Deployment (QFD) in the Construction Industry. Building and Environment, v. 40, p. 245-255, 2005.
• EASTMAN, C. et al BIM Handbook: a guide to building information modeling for owners, managers, architects, engineers, contractors, and fabricators. Hoboken: John Wiley and Sons, 2008.
• EASTMAN, C. M. et al Automatic Rule-Based Checking of Building Designs. Automation in Construction, v. 18, n. 8, p. 1011-1033, dez. 2009.
• HÄKKINEN, T. et al. ICT For Whole Life Optimization of Residential Buildings Finland: Technical Research Center, 2007. Research Notes 2401.
• HOOPER, M.; EKHOLM, A. A Pilot Study: towards BIM integration, an analysis of design information exchange & coordination. In: INTERNATIONAL CONFERENCE APPLICATIONS OF IT IN THE AEC INDUSTRY & ACCELERATING BIM RESEARCH WORKSHOP, 27., Cairo, 2010. Proceedings... Cairo, 2010. p. 16-18.
• HUOVILA, P.; PORKKA, J. Conclusions and Recommendations on Decision Support Tools for Performance Based Building Espoo: VTT Building Transport, 2005.
• INSTITUTO DE PESQUISA ECONÔMICA APLICADA. O Planejamento da Habitação de Interesse Social no Brasil: desafios e perspectivas. Brasília, DF: Secretaria de Assuntos Estratégicos da Presidência da República, 2011.
• KAMARA, J. M.; ANUMBA, C. J. ClientPro: a prototype software for client requirements processing in construction. Advances in Engineering Software, v. 32, n. 2, p. 141-158, 2001.
• KAMARA, J. M.; ANUMBA, C. J.; EVBUOMWAN, N. F. O. Client Requirements Processing In Construction : a new approach using QFD. Journal of Architecture Engineering, v. 5, n. 1, p. 8-15, 1999.
• KAMARA, J. M.; ANUMBA, C. J.; EVBUOMWAN, N. F. O. Capturing Client Requirements in Construction Projects London: Thomas Telford Publishing, 2002. p. 172.
• KASANEN, E.; LUKKA, K.; SIITONEN, A. The Constructive Approach in Management Accounting Research. Journal of Management Accounting Research, v. 5, p. 243-264, autumn1993.
• KIVINIEMI, A. Requirements Management Interface to Building Product Models Stanford, 2005. Dissertation (Doctor of Philosophy) - Department of Civil and Environmental Engineering and the Committee of Gradudate Studies, Stanford University, Stanford, 2005.
• KOPPINEN, T. et al. Putting the Client in the Back Seat: philosophy of the BIM guidelines. In: JOINT CIB CONFERENCE, Helsinki, 2008. Proceedings... Helsinki, 2008. p. 391-404.
• KOTT, A.; PEASANT, J. L. Representation and Management of Requirements: the RAPID-WS project. Concurrent Engineering: Research and Applications, v. 3, n. 2, p. 93-106, 1995.
• KWONG, C. K.; BAI, H. A Fuzzy AHP Approach to the Determination of Importance Weights of Customer Requirements in Quality Function Deployment. Intelligent Manufacturing, v. 13, n. 5, p. 367-377, 2002.
• LEINONEN, J.; HUOVILA, P. The House of the Rising Value. In: ANNUAL CONFERENCE ON LEAN CONSTRUCTION, 8., Brighton, 2000. Proceedings... Brighton: IGLC, 2000.
• LEINONEN, J.; HUOVILA, P. Requirements Management Tool as a Catalyst For Communication. In: WORLDWIDE ECCE SYMPOSIUM, 2., Espoo, 2001. Proceedings... Espoo: VTT Building Technology, 2001.
• LIMA, L. P.; FORMOSO, C. T.; ECHEVESTE, M. E. S. Proposta de Um Protocolo Para o Processamento de Requisitos do Cliente em Empreendimentos Habitacionais de Interesse Social. Ambiente Construído, v. 11, n. 2, p. 21-37, abr./jun. 2011.
• LUKKA, K. The Constructive Research Approach. In: OJALA, L.; HILMOLA, O.-P. (Eds.). Case Study Research in Logistics Turku: Turku School of Economics and Business Administration, 2003. Series B 1, p. 83-101.
• MARCH, S. T.; SMITH, G. F. Design and Natural Science Research on Information Technology. Decision Support Systems, v. 15, n. 4, p. 251-266, dez 1995.
• MINISTÉRIO DAS CIDADES. Déficit Habitacional no Brasil 2008 Secretaria Nacional de Habitação. Brasília: Secretaria Nacional de Habitação, 2011. Disponível em: <http://www.fjp.mg.gov.br/index.php/indicadores-sociais/deficit-habitacional-no-brasil>. Acesso em: 2 mar. 2013.
• NOSYKO AS. dRofus: users' guide. Version 1.5. Oslo: Nosyko AS, 2013.
• SOMMERVILLE, I. Engenharia de Software São Paulo: Perason Addion-Wesley, 2007.
• SOUZA, R. DE; ABIKO, A. Metodologia Para Desenvolvimento e Implantação de Sistemas de Gestão da Qualidade em Empresas Construtoras de Pequeno e Médio Porte São Paulo: Escola Politécnica da Universidade de São Paulo; Departamento de Engenharia de Construção Civil, 1997. Boletim Técnico da Escola Politécnia da USP.
• ULRICH, K. T.; EPPINGER, S. D. Product Design and Development 4. ed. Nova York: McGraw-Hill, 2008. p. 368.

1

A tradução para

Building Information Modeling é Modelagem de Informações da Construção (ABNT, 2010).

2

Quality Function Deployment.

3

Client Requirements Processing Model (CRPM).

4

Software desenvolvido pelo VTT - Tecnhnical Research Center da Finlândia. Disponível em: <

http://cic.vtt.fi/ecoprop/ecoprop_web_site/Mainpage.html>.

5

Na área de Ciências da Computação a palavra

template refere-se a um documento ou arquivo com um formato pré-definido, utilizado como ponto de partida para uma determinada aplicação, de modo que não há a necessidade de criar um novo formato cada vez que é utilizado (

http://www.thefreedictionary.com).

6

Whole Building Functionality and Serviceability (INTERNATIONAL..., 2000

apud KIVINIEMI, 2005). INTERNATIONAL CENTRE FOR FACILITIES: ASTM Standards on Whole Building Functionality and Serviceability. 2

^nd. ed. [s.l.]: American Society for Testing and Materials, 2000.

7

O IFC (

Industry Foundation Classes) é um padrão internacional para troca de dados em projetos de construção entre diferentes programas de computador. Isto proporciona novas oportunidades para a troca de dados e interação entre todos os tipos de aplicações envolvidas no processo de construção (

www.buildingsmart.com).

8

DOORS, ferramenta disponível em: <

http://www-03.ibm.com/software/products/us/en/ratidoor?S_CMP=wspace>.

9

RequisitePro, ferramenta disponível em: <

http://www-03.ibm.com/software/products/us/en/reqpro>.

10

dRofus, Software desenvolvido pela empresa Nosyko As, disponível em: <

http://www.drofus.no/en/index.html>

11

Solibri Model Checker, Software desenvolvido pela Solibri, Inc., disponível em: <

http://www.solibri.com>.

12

O

software Autodesk Revit foi desenvolvido especificamente para a modelagem de informação da construção (BIM). O software permite, dentre outros, a utilização de componentes paramétricos, o desenvolvimento de cronogramas, auxilia no detalhamento, colaboração e visualização de projetos, bem como permite a interoperabilidade entre outros

software (

http://www.autodesk.com.br).

13

A tradução das palavras

constructive e

design science research é Pesquisa Construtiva e Pesquisa da Ciência do Design, respectivamente.

14

Adotou-se a palavra faixa 1 para especificar renda familiar mensal de até R$ 1.600,00; faixa 2 para famílias com renda entre R$ 1.600,00 a R$ 3.100,00 ; e faixa 3 para famílias com renda até R$ 5.000,00.

15

Disponível em: <

http://drofus.no/en/product/videos.html>.

16

No

software a palavra espaços é denominada

Rooms

17

A melhor tradução para

Room Data Sheet (RDS) é Planilha com informações dos espaços.

18

A categoria Requisitos dos Espaços foi dividida em duas planilhas devido à grande quantidade de informações bem como para facilitar a visualização dessas informações.

Datas de Publicação

• Publicação nesta coleção
  29 Out 2013
• Data do Fascículo
  Set 2013

Histórico

• Recebido
  02 Abr 2013
• Aceito
  06 Jul 2013