Padres de Escrita de Requisitos: um mapeamento sistemtico da literatura

Rodrigo Cezario da Silva1 and Fabiane Barreto Vavassori Benitti1

Universidade do Vale do Itaja (UNIVALI) Mestrado em Computao Aplicada Caixa Postal 360 88302-202 Itaja SC Brasil rodrigo@studiodesigner.com.br, fabiane.benitti@univali.br
1

Abstract. The requirements elicitation is reported in the literature as essential to the success of software development projects. The existence of requirements patterns aimed at not only improving the quality of requirements specifications, but also the reuse of successful solutions of previous experience in new projects. In this paper, we present the results of a systematic literature mapping on requirements patterns. The results show that there is a diverse range of patterns for the process of requirements engineering, but there are still few studies addressing the requirements patterns that deal specifically with the documentation of software requirements. Keywords: Requirement Pattern, Systematic mapping study

1 Introduo
A utilizao de padres apontada como uma soluo emergente para ajudar as organizaes a estruturar melhor o seu conhecimento [1] [2], considerado um instrumento eficaz para reutilizar o conhecimento adquirido no desenvolvimento de software, sendo eficiente para resolver problemas inesperados ou acidentais, pois trata de conhecimentos baseados em experincias reais [3]. Alm disso, os padres auxiliam no processo interno de comunicao, pois trata de uma soluo de identificao e de registro de uma soluo empregada, sendo realizada de forma que seja mais fcil a sua localizao, uso ou sua disseminao [4]. A utilizao de padres na rea de requisitos considerada uma soluo que agiliza o processo de elicitao de requisitos de software e tambm pode aumentar a qualidade dos documentos gerados [5]. Withall [6] tambm enfatiza que padres de requisitos tm o objetivo de estabelecer requisitos com uma maior qualidade de escrita, isso com maior agilidade e menor esforo. Mas, quais so os padres existentes para escrita de requisitos de software? Atualmente, a Engenharia de Software baseada em evidncias desempenha um papel importante, melhorando a tomada de decises relacionadas ao desenvolvimento e manuteno de software, integrando as evidncias das pesquisas com a experincia prtica e os valores humanos [7] [8]. Uma das principais ferramentas do paradigma baseado em evidncias a reviso sistemtica, que tem recebido muita ateno

ultimamente na rea de engenharia de software [8] [9] [10]. Ainda, h outros dois tipos de anlise que complementam as revises sistemticas da literatura: estudos de mapeamento sistemtico e reviso terciria [10]. O estudo de mapeamento sistemtico permite que as evidncias de um domnio possam ser identificadas em um alto nvel de granularidade, permitindo a descoberta de evidncias ou falta delas, para direcionar o foco de futuras revises sistemticas e para identificar reas para estudos primrios a serem realizados [10]. Diversos mapeamentos e revises sistemticas envolvendo a rea de requisitos tm sido realizados recentemente [11] [12] [13]. No entanto, no foi localizado um estudo que focasse especificamente em padres de requisitos, permitindo identifica-los e compar-los. Desta forma, este artigo tem como objetivo apresentar os resultados de um mapeamento sistemtico da literatura envolvendo padres de requisitos para escrita de requisitos de software, visando conhecer, de maneira imparcial, o estado da arte referente a padres de escrita de requisitos para Engenharia de Requisitos. Para tanto, apresentado o protocolo do mapeamento sistemtico da literatura utilizado pelos autores, observando as etapas propostas por [10]. Assim, este artigo apresenta na seo 2 o protocolo utilizado e na seo 3 o detalhamento e discusso dos estudos selecionados. Na seo 4 apresentada a concluso da pesquisa.

2 Mapeamento Sistemtico da Literatura

Segundo Kitchenham et al.[10] e Brereton et al. [9] uma reviso sistemtica deve ser realizada seguindo as etapas de planejamento da reviso, conduo da reviso e documentao da reviso, podendo estes passos serem observados tambm para um mapeamento sistemtico. Assim, as sees seguintes detalham cada etapa realizada. 2.1 Planejamento Tendo em vista o objetivo de conhecer o estado atual sobre padres de escrita de requisitos de software e mapear os padres existentes, estabeleceu-se a seguinte pergunta de pesquisa: Quais os padres para a escrita de requisitos de software so propostos atualmente? Para Kitchenham et al. [10], alguns critrios devem ser respondidos para enquadrar as questes de pesquisa de Engenharia de software para a orientao da seleo dos estudos primrios, aplicando-se estes critrios tem-se que: A populao que esta pesquisa explora a de publicaes em engenharia de software com o foco em engenharia de requisitos. Com esta interveno pretende-se encontrar catlogos, padres ou categorias de padres para escrita de requisitos de software. Com esses resultados entende-se que o autor poder ter subsdios para elaborao de um catlogo de padres para escrita de requisitos de software. O contexto no qual incide esta pesquisa na comunidade de engenharia de software. No desenho do experimento no foi aplicado nenhum mtodo estatstico. A pesquisa aplicada em projetos de desenvolvimento de software na atividade de elicitao de requisitos.

Visando identificar se alguma reviso j havia sido realizada, respondendo a pergunta de pesquisa, foi executada uma busca por revises sistemticas na web (fonte: Google) pelos termos reviso sistemtica and padres de requisitos em portugus e systematic review and requirements pattern, a qual no identificou nenhum trabalho semelhante ao proposto. Ainda, conforme abordado na seo anterior, h alguns mapeamentos e revises sistemticas focando a rea de Engenharia de Requisitos [11] [12] [13], no entanto, no possvel responder a pergunta de pesquisa a partir destes estudos j realizados. Sendo assim, foram identificadas e analisadas as possveis fontes de busca (bases de dados eletrnicas), a seleo dos idiomas e as palavras chaves que formaram as strings de busca (quadro 1). Na Tabela 1, dentre outras informaes, constam as fontes de dados utilizadas no mapeamento sistemtico, contemplando 7 das 9 bases de dados (para busca na lngua inglesa) recomendadas por [10] - no foram includas as bases de dados Scopus e EI Compendex por dificuldade no acesso, alm de bases de dados conhecidas nacionalmente as quais os autores possuem acesso. A busca iniciou-se dando preferncia por estudos na lngua inglesa, por se tratar de uma lngua universalmente aceita para trabalhos cientficos e por ter conhecimento de que os estudos mais atuais encontram-se nesta lngua. Posteriormente, estudos em lngua portuguesa tambm foram considerados. O quadro 1 ilustra as strings de busca elaboradas para utilizao nas bases de dados.
Quadro 1. Strings de busca Ingls: ((pattern OR catalog OR category) AND (software requirement OR requirements engineering OR requirements elicitation)) Portugus: ((padres OR catlogo OR categoria) AND (requisito de software OR engenharia de requisitos OR elicitao de requisitos))

Optou-se por no restringir o perodo de publicao dos estudos, pois se verificou que as strings de busca no retornavam um nmero muito grande de estudos, sendo vivel a anlise. Contudo, alguns critrios para incluso e excluso dos estudos foram estipulados para orientar quanto seleo dos estudos primrios que ajudassem a responder a pergunta de pesquisa. Desta forma, os critrios definidos foram: estudos que apresentam padres para escrita dos requisitos de forma a permitir a sua aplicao, ou seja, estudos que expem o padro de forma detalhada viabilizando sua utilizao; estudos que evidenciassem a aplicao do padro proposto em projetos reais ou acadmicos. Consequentemente, considerou-se como critrios de excluso: estudos em que o padro proposto no abordava aspectos relacionados com a forma de escrita/documentao de requisitos de software; estudos nos quais o padro no era apresentado detalhadamente, inviabilizando sua aplicao; estudos que no evidenciavam a aplicao do padro, seja no meio acadmico, seja na indstria;

2.2 Conduo do Mapeamento A conduo do mapeamento sistemtico foi realizada no perodo de junho a agosto de 2010, consistindo na execuo do protocolo de busca (detalhado na seo 2.1). A execuo da string de busca formatada para cada base de dados resultou na localizao de 56 estudos, distribudos conforme consta na Tabela 1.
Tabela 1. Resultado da busca nas fontes de dados
Base de dados IEEEXplorer String de busca formatada Resultado 9

(("Document Title":pattern OR "Document Title":catalog OR "Document Title":category) AND ("Document Title":"software requirement" OR "Document Title":"Requirements Engineering" OR "Document Title":"Requirements Elicitation")) ACM ((Title:pattern or Title:catalog or Title:category) and (Title:"software requirement" or Title:"Requirements Engineering" or Title:"Requirements Elicitation")) IET Digital ((pattern or catalog or category <IN> (abstract,title,keywords)) Library <and>("software requirement" or "requirements engineering" or "requirements elicitation" <IN> (abstract,title,keywords))) SpringerLink ((ti:(pattern) OR ti:(catalog) OR ti:(category)) AND (ti:("software requirement") OR ti:("Requirements Engineering") OR ti:("Requirements Elicitation"))) Science Direct ((title(pattern) or title(catalog) or title(category)) and (title("software requirement") or title("Requirements Engineering") or title("Requirements Elicitation"))) Google Scholar ((nottulo:pattern OR nottulo:catalog OR nottulo:category) AND (nottulo:"software requirement" OR nottulo:"requirements engineering")) CiteSeer ((title:pattern OR title:catalog OR title:category) AND (title:"software requirement" OR title:"requirements engineering") OR title:"Requirements Elicitation") Biblioteca Digital ((titulo:padres OR titulo:catlogo OR titulo:categoria) AND Brasileira de Teses (titulo:"requisitos de software" OR titulo:"engenharia de requisitos" OR e Dissertaes titulo:" elicitao de requisitos")))) Google Scholar ((nottulo:padres OR nottulo:catlogo OR nottulo:categoria) AND (nottulo:"requisitos de software" OR nottulo:"engenharia de requisitos" OR nottulo:" elicitao de requisitos")) Banco de Teses e ((padres OR catlogo OR categoria) AND ("requisitos de software" OR Dissertaes da "engenharia de requisitos" OR "elicitao de requisitos")))) UFRGS Domnio Publico ((padres OR catlogo OR categoria) AND ("requisitos de software" OR "engenharia de requisitos" OR "elicitao de requisitos")) Banco de Teses e ((padres OR catlogo OR categoria) AND ("requisitos de software" OR Dissert. da USP "engenharia de requisitos" OR "elicitao de requisitos")) Biblioteca Dig. de ((padres OR catlogo OR categoria) AND ("requisitos de software" OR Teses e Dissert. "engenharia de requisitos" OR "elicitao de requisitos")) UFSCar Biblioteca Digital ( ( WTI = ( padres ) OR WTI = ( catlogo ) OR WTI = ( categoria ) ) de Teses e Dissert. AND ( WTI = ( Requisitos de software ) OR WTI = ( Engenharia de - UFRJ Requisitos ) OR WTI = ( Elicitao de Requisitos ) ) ) Biblioteca digital ((padres OR catlogo OR categoria) AND ("requisitos de software" OR da SBC "engenharia de requisitos" OR "elicitao de requisitos"))

13

16 7

0 0 1

Conforme pode ser observado, foram identificados 53 estudos nas bases de dados internacionais e 3 estudos nas bases nacionais. No entanto, alguns desses estudos eram apontados por mais de uma base de dados, resultando em 36 estudos nicos, distribudos conforme consta na tabela 2.
Tabela 2. Matriz dos estudos encontrados*
IET Digital Library Google Scholar (ING) Google Scholar (POR) Google Scholar (ING) Google Scholar (POR) Bco/UFSCar Scince Direct SpringerLink

Bco/UFSCar

IEEEXplorer

Scince Direct

IET Digital Library SpringerLink

Base dados

CiteSeer

Base dados
IEEEXplorer

ACM

ID
E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E12 E13 E14 E15 E16 E17 E18

Estudo
[19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [3] [29] [30] [31] [32] [33] [1] [34]

ID Estudos
E19 E20 E21 [35] [36] [37] [38] [16] [39] [6] [40] [41] [42] [43] [15] [14] [44] [45] [46] [47] [48]

X X X X X X X X X X XX X XX X X X X X X X X X X X X X X X X X

CiteSeer

ACM

X X X X X X X X X X X X X X XX X XX X X X X X

E22 E23 E24 E25 E26 E27 E28 E29 E30 E31 E32 E33 E34 E35 E36

*A marcao XX representa que o mesmo estudo foi encontrado em duplicidade na base de dados.

Com isto, iniciou-se o processo de seleo preliminar dos estudos primrios, sendo realizado atravs da leitura do resumo dos estudos encontrados, visando identificar os estudos que atendiam aos critrios descritos anteriormente (seo 2.1) ou que foi detectada alguma relevncia em relao a pergunta de pesquisa. Nesta etapa 18 estudos foram descartados (E2, E4, E7, E8, E10, E12, E13, E14, E20, E21, E22, E27, E28, E29, E32, E33, E34 e E35), sendo os demais separados para uma leitura detalhada posteriormente. Aps a seleo preliminar, a quantidade de estudos foi reduzida para 18. Nestes foi realizada, prioritariamente, a leitura da introduo e concluso, a exceo foi o estudo E26 o qual no possua o texto completo disponvel na base de dados. Como resultado desta etapa de anlise do texto foram descartados 14 estudos, sendo identificados apenas 4 estudos primrios, a citar: [14], [6], [15] e [16] Na anlise do estudo de Franch et al. [16] e Renault et al. [15], constatou-se que so resultados de um mesmo grupo de pesquisadores e que se referem a um mesmo padro. Alm disso, foi possvel identificar, a partir destes estudos, outras publicaes do grupo que complementavam as informaes dos estudos selecionados. Assim, na discusso os padres selecionados destes 2 estudos foram analisados em conjunto,

incluindo ainda os estudos [17] e [2] do mesmo grupo para uma anlise mais completa.

3 Discusso dos Dados Extrados

Esta seo trata da apresentao dos padres e anlise dos estudos selecionados na conduo deste mapeamento sistemtico. Inicialmente, os padres identificados so apresentados, bem como os principais resultados observados pelos autores so descritos, alm disso, procurou-se identificar a forma de avaliao dos resultados apresentados. Posteriormente, uma anlise comparativa entre os estudos realizada. 3.1. Abordagem de Toro et al. (1999) No estudo [14], so apresentados templates de requisitos que podem melhorar a atividade de elicitao dos requisitos e sua expresso, isso porque estrutura as informaes dos requisitos de uma forma fixa. Para isso o autor descreve dois tipos de padres: (i) padro lingustico (Figura 1a): que se refere s frases que so normalmente utilizadas nas descries dos requisitos em linguagem natural, s quais os autores fazem uma parametrizao e integrao em um template; e (ii) padro de requisitos (Figura 1b): so templates de requisitos genricos que podem ser reutilizados com algumas adaptaes durante a atividade de elicitao de requisitos. Com isso o analista auxiliado a encontrar as informaes que faltam para preencher os requisitos, alm de poderem ser incorporados a uma ferramenta computacional.
RI-<id> Version Author Source Purpose Description Specific data Time interval Importance Urgency Comments <descriptive name> <current version number> (<current version date>) <current version author> (<authors organization>) <current version source> (<sources organization>) <purpose of requirement> The system shall store the information corresponding to <relevant concept>. More precisely: <specific data about the relevant concept> {past and present, only present} <importance of requirement> <urgency of requirement> <additional comments about the requirement>

Fig. 1a. Exemplo de padro lingustico Toro et al. (1999)

RF- Precondition Ordinary sequence {Create, Register} <new information> <new information> is not stored yet Step Action 1 The <some actor> requests the system to start the <create new information> procedure 2 The system requests for <new information> 3 The <some actor> provides <new information> <new information> is stored

Postcondition

Fig. 1b. Exemplo de padro de requisito Toro et al. (1999)

Como resultado os autores afirmam que o preenchimento dos espaos em branco dos formulrios dos templates facilita e agiliza a atividade de elicitao de requisitos. Alm disso, os autores observam que a reutilizao dos templates pode ser realizada diversas vezes, desde que tenha sido identificado e/ou adaptado para um projeto especfico. Segundo os autores, esta abordagem j foi aplicada com sucesso em mais de 40 prticas acadmicas e em dois projetos reais de uma organizao, a qual obteve melhorias na comunicao com os stakeholders. 3.2. Abordagem de Withall (2007) No estudo [6], so apresentados 37 padres de requisitos que foram organizados em oito domnios, conforme ilustrado na Figura 2. Os domnios classificados em [6] possuem padres que objetivam atender as funcionalidades de seu domnio em especfico, porm alguns padres podero compartilhar e integrar informao, conforme pode ser visto com a sinalizao de setas entre alguns padres na Figura 2. Segundo Withall [6], juntos esses padres podem representar mais da metade de um conjunto de especificao tpicas de requisitos de um sistema comercial.

Fig. 2. Catlogo de padres de requisitos apresentado em Withall (2007)

Segundo o autor, o emprego de padres de requisitos fornece orientaes sobre como fazer a especificao (escrita) dos tipos mais comuns de requisitos, tornando a tarefa de escrita mais fcil e rpida de ser realizada e melhorando a qualidade desses requisitos. No entendimento de Withall [6] a introduo da noo de padres de requisitos para a escrita de requisitos um esforo extra que permite especificar os

requisitos de uma forma mais consistente. Segundo Withall [6], os padres de requisitos fornecem orientaes de como escrever os requisitos, sugerindo informaes, ajudando com alertas e sugestes que devem ser consideradas. Tambm colabora na produtividade, por no ser necessria a escrita dos requisitos a partir do zero, fornecendo um ponto de partida, uma estrutura para sua construo. Os padres que compem o catlogo foram identificados a partir do estudo em projetos reais. No estudo apresentado pelo autor, mais de 400 exemplos de escrita de requisitos so apresentados. Segundo o autor, muitos podem ser aplicados sem nenhuma alterao a quaisquer sistemas, e os demais servem de ponto de partida para que possam ser adequados a necessidade dos usurios. 3.3. Abordagem de Franch et al. (2010), Renault et al. (2009a), Renault et al. (2009b) e Mendez-Bonilla, Franch e Quer (2008) Nos estudos do grupo apresentada uma verso inicial do catlogo de padro de requisitos em [17], a sua evoluo e a apresentao do mtodo para sua utilizao, intitulado PABRE, em [2] e [15]. J no estudo publicado em [16], proposto um metamodelo para padres de requisitos de software que composto de trs conceitos: (i) a estrutura de um padro de requisitos de software (Figura 3); (ii) o relacionamento entre esses padres; e (iii) a classificao para agrup-los.
Requirement Pattern Failure Alerts Goal Satisfy the customer need of having a system that provides alerts when system failures occur The system shall trigger different types of Template alerts depending on the type of failure Fixed Part Extended Parts multiplicity(Alerts for Failure Types) = 0..* Constraint The system shall trigger %alerts% alerts in Requirement Template case of %failures% failures Form Extended Heterogeneous Parameter Metric Part Failure Alerts alerts: non-empty set alerts: Set(AlertType) Alerts for of alert types AlertType: Domain of possible types of alerts Failure failures: Set(FailureType) Types failures: non-empty FailureType: Domain of possible types of set of failure types failures The system shall trigger an alert in case of Template failure. Fixed Part Extended Parts multiplicity(AlertsTypes) = 0..1 and Constraint multiplicity(Failure Types) = 0..1 Requirement Form Homogeneous Failure Alerts Extended Part Alert Types Template Parameter alerts: non-empty set of alert types Templates Parameter failures: non-empty set of failure types The solution shall trigger %alerts% alerts in case of failure Metric alerts: Set(AlertType) AlertType: Domain of possible types of alerts The system shall trigger alerts in case of %failures% failures Metric failures: Set(FailureType) FailureType: Domain of possible types of failures

Extended Part Failure Types

Fig. 3. Exemplo de padro de requisito proposto em Franch et al (2010)

De forma geral, os estudos apresentam uma proposta de ter padres de requisitos que poderiam ser aplicados em diferentes projetos, a inteno obter a especificao de requisitos mais unificada, padronizada e til. O catlogo de padres de requisitos dos autores endereado a requisitos do tipo no funcionais e no tcnicos, pois, na concepo dos autores, padres de escrita de requisitos funcionais seriam mais adequados para uso em projetos de domnio especfico, j padres de escrita de requisitos no funcionais e no tcnicos poderiam ser adequados mais facilmente a quase todos os tipos de domnio de aplicao. A construo dos padres realizada a partir da observao de requisitos similares j utilizados em vrios projetos de software. Quando a similaridade identificada, os autores realizam um estudo para verificar se h um padro de forma a generalizar. O objetivo a gerao de um catlogo de padres de requisitos, ento, aps a identificao de um padro o mesmo adicionado a esse catlogo. Para organizar os padres em um catlogo, os autores utilizaram a norma ISO/IEC 9126-1. Segundo os autores, uma classificao ajuda os analistas a localizarem mais facilmente um padro para o seu uso. O catlogo proposto de forma aberta, evoluindo a partir de experincias adquiridas em novos projetos. 3.4. Comparativo dos Padres Os estudos selecionados a partir do mapeamento sistemtico diferem em suas abordagens. Assim, alguns aspectos foram estabelecidos para permitir a comparao entre os padres: Templates para escrita de requisitos: observa se o estudo apresentava um (ou mais) template para orientar a escrita do padro e analisa qual o escopo do template, se est limitado a escrita do requisito ou contempla tambm outros dados para gerenciamento dos requisitos. Base para o padro: descreve o mtodo (origem) utilizado para obter o padro proposto. Relacionamento entre os padres: um padro pode se referir a outros padres por diversas razes, assim, este aspecto observa se o padro proposto composto ou se prev relacionamento entre diferentes padres. Categorias de padres: uma classificao dos padres em categorias permite demonstrar um pouco sobre a natureza do requisito que se pretende obter com a utilizao do padro de requisito, alm de ser uma forma de facilitar a seleo dos padres de requisitos adequados ao seu objetivo. Assim, este aspecto observa se o estudo prope/envolve algum tipo de catlogo ou categorizao para os padres propostos. Existncia de metamodelos: um metamodelo um modelo para modelos [18], podendo ajudar a entender conceitos sobre os padres de requisitos de software ou orientar a estruturao de novos padres. Portanto, este aspecto analisa se o estudo prope um metamodelo de seu(s) padro(es). Ferramenta: a utilizao de padres de escrita de requisitos pode ser facilitada a partir da utilizao de uma ferramenta, portanto, este aspecto analisa se o padro proposto foi incorporado em alguma ferramenta computacional.

Aplicao do padro: observa as evidncias de aplicao dos padres em projetos de software. A Tabela 3 mostra um comparativo das caractersticas entre os trabalhos selecionados neste mapeamento sistemtico.
Tabela 3. Comparativo entre os estudos encontrados
Toro et al. (1999) Sim (Figura 1) Engloba alm do padro de redao do requisito, campos para gerenciamento dos requisitos. Withall (2007) Sim O padro descrito a partir da definio de 9 campos. Os templates apresentados compreendem apenas a redao do requisito, sem prever informaes complementares. Padres identificados a partir do estudo das necessidades em projetos reais. Franch et al. (2010) Sim (Figura 3) O template envolve apenas a escrita do requisito, sem prever campos para informaes complementares.

Templates

Base para construo do padro

Padres propostos a partir da anlise de 2 outros estudos (de outros autores).

Relacionamento entre padres Categorias de padres

No aborda. - Requisitos funcionais (CRUD). - Requisitos no funcionais (sem determinar categorias). No apresenta H um prottipo descrito em [14].

Aborda (conforme figura 2). - Requisitos funcionais - Requisitos no funcionais (com padres por categorias Figura 2). No apresenta H uma ferramenta descrita no website do autor (1)

Padres generalizados a partir da anlise de 7 documentos de especificao de requisitos de projetos finalizados (Mdia de 70 requisitos no funcionais em cada documento). Aborda, mas no explicitamente. - Requisitos no funcionais (extenso da ISO/IEC 91261).

Metamodelo Ferramenta

Aplicao (2)

Mais de 40 projetos Apresenta exemplos de mais acadmicos e em 2 de 400 requisitos projetos reais. empregando os padres. (1) http://www.withallyourequire.com/reqtssoftware.html (2) Informaes obtidas diretamente dos estudos, desta forma, no foi possvel utilizar uma mesma unidade de medida.

Apresenta O desenvolvimento de uma ferramenta proposto como passo futuro. Validao em 2 projetos reais.

4 Concluses
A conduo do mapeamento sistemtico e a criao do protocolo de busca uma forma de identificar, analisar e interpretar todos os estudos disponveis sobre um determinado tema. Sua conduo evita vis e permite auditoria sobre o processo de pesquisa [9] [10]. Com o mapeamento sistemtico apresentado neste artigo foi possvel documentar e conhecer, de maneira imparcial, o estado da arte sobre os padres disponveis para escrita de requisitos de software. A partir da localizao de 6 estudos possvel responder a pergunta de pesquisa Quais os padres para a escrita de requisitos de software so propostos atualmente?

Identificou-se 3 padres distintos para escrita de requisitos (apresentados em [14], [6] e [16]), podendo-se destacar os seguintes aspectos: o uso de templates para conduzir a escrita dos requisitos uma opo de consenso na literatura, tendo em vista que todos os estudos utilizaram deste instrumento, nenhum mtodo alternativo foi encontrado; alguns autores [16][17] priorizam o uso de padres para requisitos no funcionais, no entanto, o mapeamento demonstrou ser vivel a utilizao de padres tanto para requisitos funcionais quanto para requisitos no funcionais. Neste ponto, dois aspectos merecem citao: o quando o padro se aplica a requisitos no funcionais recomendado faze-lo por categorias; e o o uso de padres para requisitos funcionais normalmente assume o escopo de sistemas comerciais (sistemas de informaes), reduzindo a adequao para outros tipos de sistemas. deve ser considerada a possibilidade de relacionamento entre os padres, permitindo padres compostos de outros padres. O estudo permitiu ainda observar que o desenvolvimento de uma ferramenta que suporte o uso de padres parece ser um caminho natural para a sua adoo, no entanto, as ferramentas citadas so verses preliminares, pouco consolidadas. No foi encontrada citao do uso dos padres propostos por ferramentas tradicionais (consolidadas ou bem conhecidas no que tange o suporte rea de requisitos). Um aspecto importante observado refere-se ao fato que em nenhum dos estudos houve uma avaliao formal dos padres, ou seja, os benefcios atribudos ao uso dos padres decorrem de uma avaliao bem informal, mais no sentido de expresso de opinio ad-hoc. Esta constatao apresenta uma oportunidade de nova pesquisa. Por fim, faz-se importante analisar as ameaas inerentes ao processo adotado nesta pesquisa, que consiste, principalmente, no fato de ocorrer o descarte de um estudo por no se ter acesso ao texto completo. Outra ameaa decorre da conduo do mapeamento, a qual foi realizada por apenas um pesquisador, j as etapas de planejamento e discusso envolveram dois pesquisadores. Para minimizar esta ameaa, foi realizada aps a concluso da conduo uma anlise dos ttulos descartados e, em casos especficos, tambm do resumo, por um segundo pesquisador (como forma de reviso). Tambm se deve considerar que os padres apresentados so resultantes de uma string de busca especfica em um conjunto de 15 fontes de dados limitado a busca por termos em ingls e portugus, a ampliao dos termos, lngua e fontes de dados pode revelar novos padres.

Referncias
1. Hagge, L., Lappe, K. Using Requirements Engineering (RE) Patterns for Organizational Learning, Journal of Universal Knowledge Management, vol. 1, no. 2 (2006), p.137-148 (2006) 2. Renault, S., Mndez-Bonilla, ., Franch, X., Quer, C. A Pattern-based Method for Building Requirements Documents in call-for-tender Processes, International Journal of Computer Science and Applications, Vol. 6, No. 5, pp 175-202 (2009a) 3. Tsumaki, T. Requirements Engineering Pattern Structure. APSEC'04, (2004)

4. Cunha, G. E., Herbert, J. S. Proposta de Padres de Software para a Reutilizao Sistemtica em Sistemas de Software Orientados a Objetos, SugarloafPlop 2003 Conference (2003) 5. Oliveira, K., Spinola, M. POREI: Patterns-Oriented Requirements Elicitation Integrated Proposta de um Metamodelo Orientado Padro para Integrao do Processo de Eliciao de Requisitos, In. SugarLoafPLoP'2007 - 6 Latin America Conference on Pattern Languages of Programming, Pernambuco (2007) 6. Withall, S. Software Requirement Patterns. Washington: Microsoft Press.Appendix: Springer-Author Discount (2007) 7. Dyb, T., Dingsyr, T.. Strength of evidence in systematic reviews in software engineering, Proceedings of the Second International Symposium on Empirical Software Engineering and Measurement, ESEM, October 9-10, Kaiserslautern, Germany, pp. 178187, (2008) 8. Kitchenham, B.; Pearl O.; Budgen, D.; Turner, M.; Bailey, J.; Linkman, S. Systematic Literature reviews in software engineering A systematic literature review, Information and Software Technology, 51(1): 7-15, January (2009). 9. Brereton, P., Kitchenham, B. A., Budgen, D., Turner, M., Khalil, M. Lessons from applying the systematic literature review process within the software engineering domain, Journal of Systems and Software 80 (2007) 10. Kitchenham, B.; Charters, S. Guidelines for performing systematic literature reviews in software engineering, Technical Report EBSE 2007001, Keele University and Durham University Joint Report (2007) 11. Davis, A.; Dieste, O.; Hickey, A.; Juristo, N.; Moreno, A.M.. Effectiveness of Requirements Elicitation Techniques: Empirical Results Derived from a Systematic Review. In Proceedings of the 14th IEEE International Requirements Engineering Conference (RE '06). IEEE Computer Society, Washington, DC, USA, 176-185. DOI=10.1109/RE.2006.17 (2006) 12. Condori-Fernndez, N.; Daneva, M.; Sikkel, K.; Wieringa, R.; Dieste, O.; Pastor, O. A systematic mapping study on empirical evaluation of software requirements specifications techniques. Third International Symposium on Empirical Software Engineering and Measurement ESEM 2009, IEEE Computer Society, Florida, USA, pp 502-505, (2009) 13. Dieste, O.; Juristo, N. Systematic Review and Aggregation of Empirical Studies on Elicitation Techniques, IEEE Transactions on Software Engineering, 11 Feb. 2010. IEEE computer Society Digital Library. IEEE Computer Society, (2010) 14. Toro, A. D., Bernrdez, B., Ruz, A., Toro, M. A Requirements Elicitation Approach Based in Templates and Patterns, In Proceedings 2nd Workshop on Requirements Engineering (WER99) (1999) 15. Renault, S., Mndez-Bonilla, ., Franch, X., Quer, C. PABRE: Pattern-Based Requirements Elicitation, Third International Conference on Research Challenges in Information Science, RCIS 2009 (2009b) 16. Franch, X., Palomares, C., Quer, C., Renault, S. A Metamodel for Software Requirement Patterns*, REFSQ 2010, Springer-Verlag: Berlin, p.85-90 (2010) 17. Mendez-Bonilla, O., Franch, X., Quer, C. Requirements Patterns for COTS Systems, Seventh International Conference on Composition-Based Software Systems. (2008) 18. Amatriain, X. An Object-Oriented Metamodel for Digital Signal Processing with a focus on Audio and Music, Universitat Pompeu Fabra, Departament de Tecnologia. Tese de doutorado em informtica e comunicao digital (2004)

Apndice A Estudos Excludos do Mapeamento

Esta lista contempla todos os estudos retornados pelo protocolo de busca e excludos (em funo dos critrios definidos). Em funo do espao disponvel, as referncias foram agrupadas constando apenas o nome dos autores, ttulo e ano da publicao.
[19]Isazadeh, A., Macewen, G. H., Malton, A. Behavioral patterns for software requirement engineering (1995) [20]Maiden, N. A. M., Bright, B. P. Recurrent Communication Patterns in Requirements Engineering Meetings (1996) [21]Gaska, M. T., Gause, D. C. An Approach for Cross-Discipline Requirements Engineering Process Patterns (1998) [22]Maiden, N. A. M., Hare, M. Problem domain categories in requirements engineering (1998) [23]Gotzhein, R., Kronenburg, M., Peper, C. Reuse in Requirements Engineering Discovery and Application of a Real Time Requirement Pattern* (1998) [24]Fredj, M., Roudis, O. A Pattern Based Approach for Requirements Engineering (1999) [25]Hatebur, D., Heisel, M., Schmmidt, H. A Pattern System for Security Requirements Engineering (2007) [26]Sikkel, K., Wieringa, R., Engmann, R. A Case Base for Requirements Engineering: Problem Categories and Solution Techniques (2000) [27]Wahono, R. S. On the Requirements Pattern of Software Engineering (2002) [28]Pavan, P., Maiden, N. A. M., Zhu, X. Towards a Systems Engineering Pattern Language: Applying i* to Model Requirements-Architecture Patterns (2003) [29]Merrick, P., Barrow, P. Testing a Requirements Pattern Language through Reverse Engineering (2004) [30]Hagge, L., Houdek, F., Lappe, K., Paech, B. Using Patterns for Sharing Requirements Engineering Process Rationales (2006) [31]Zlatev, Z., Daneva, M., Wieringa, R. Multi-Perspective Requirements Engineering for Networked Business Systems: A Framework for Pattern Composition (2005) [32]Hagge, L., Lappe, K., Schmidt, T. REPARE: The Requirements Engineering Patterns Repository (2005) [33]Hagge, L., Lappe, K. Sharing Requirements Engineering Experience Using Patterns (2005) [34]Graf, C. A Requirements Engineering Perspective to Repositories for Interaction Patterns (2007) [35]Falbo, R. A., Martins, A. F., Segrini, B. M., Baico, G., Dal Moro, R., Nardi, J. C. Um Processo de Engenharia de Requisitos Baseado em Reutilizao de Ontologias e Padres de Anlise (2007) [36]Hermoye, L. A., Lamsweerde, A., Perry, D. E. Attack Patterns for Security Requirements Engineering (2008) [37]Compagna, L., Khoury, P. E., Krausov, A., Massacci, F., Zannone, N. How to integrate legal requirements into a requirements engineering methodology for the development of security and privacy patterns (2008) [38] Issa, A. A., Al-Ali, A. Use Case Patterns Driven Requirements Engineering (2010) [39]Toledo, D. E. F. Um Processo gil de Engenharia de Requisitos com Apoio de Padres de Software (2008) [40]Ang, A. Improving the quality of knowledge representation for requirements engineering through natural language requirements patterns (2010). [41]Silva, O., Garcia, A., Lucena, C. The Reflective Blackboard Pattern: Architecting Large Multi-agent Systems (2003) [42]Xuan, H., Bin, L., Yichen, W. Application of software requirement error pattern based on ontology (2009) [43]Gaska, M. T. Cross-discipline identification of a unified set of requirements engineering process patterns (1999) [44]Hironori, W., Atsuto, K., Yoshiaki, F. A Pattern Language for Requirements Elicitation in System Development (2006) [45]Kozima, A., Kiguchi, T., Yaegashi, R., Kinoshita, D., Hayashi, Y., Hashiura, H., Komiya, S. A System To Guide Interview-Driven Requirements Elicitation Work: Domain -- Specific Navigation Using The Transition Pattern Of Topics (2005) [46]Watahiki, K., Saeki, M. Scenario Evolution in Requirements Elicitation Processes: Scenario Pattern and Framework Approach (2001) [47]Whittle, J ; Araujo,J. Scenario modelling with aspects (2004) [48]Maiden, N. CREWS validation frames: validating systems requirements (1998)