Padrões de requisitos
 | Este artigo ou secção contém uma lista de referências no fim do texto, mas as suas fontes não são claras porque não são citadas no corpo do artigo, o que compromete a confiabilidade das informações. (Março de 2016) |
Padrões de Requisitos são soluções comprovadamente boas para resolver problemas recorrentes na área de engenharia de requisitos. Um padrão de requisito não oferece uma solução de aplicação direta, requerendo antes uma adaptação de acordo com o problema concreto; é essa abstracção que o torna genérico e aplicável a um conjunto variado de situações. (Robertson, 2006) define padrão como um guia (e não um conjunto rígido de instruções) a seguir quando se tenta replicar ou aproximar algum trabalho já realizado. Aplicando esse conceito na área de requisitos, (Robertson, 2006) caracteriza um padrão como sendo um mini-sistema independente que captou no seu interior a essência do processamento de um determinado caso de uso de um processo de negócio.
História
[editar | editar código-fonte]A noção de padrão surgiu na década de 70 na área da arquitectura, com o trabalho de Christopher Alexander. Já na década de 90, essa noção foi aplicada ao desenvolvimento de software, tendo surgido pela primeira vez o termo design pattern em (Gamma, 95). Foi a partir daí, com a constatação da atractividade do uso de padrões, que se generalizou a sua aplicação a outras áreas de engenharia de software, como a área de análise de requisitos.
Propósito
[editar | editar código-fonte]Ao reutilizar um grupo funcional de requisitos que já tenha sido solução de qualidade para um problema semelhante está-se a reutilizar conhecimento, pelo que o principal propósito da aplicação de padrões de requisitos reside na diminuição do tempo necessário para completar a fase de análise de requisitos (que normalmente não é muito) e no aumento da exactidão e integralidade que se consegue obter (SoftwareProjects, 2006). (Saeki, 1999) apresenta uma técnica de extracção de padrões de casos de uso, sob a forma de componentes reusáveis, a partir das descrições dos casos de uso, tornando mais fácil todo o processo de análise de requisitos e permitindo a partilha de experiências nessa área. Através da aplicação de padrões de requisitos, (Konrad, 2003) concluiu que estes levam os engenheiros de requisitos a dar mais atenção a aspectos muitas vezes negligenciados nas fases iniciais de desenvolvimento, como a segurança e tolerância a falhas. Além disso, a aplicação de padrões de requisitos permite documentar as soluções obtidas, oferece um vocabulário comum a ser usado pelos engenheiros de requisitos, bem como uma forma de expressar soluções complexas através do nome do padrão, e facilita a aprendizagem por parte de pessoas menos experientes.
Com os prazos atribuídos à fase de análise de requisitos cada vez mais curtos, a utilização de padrões de requisitos apresenta-se como uma solução viável e atractiva.
Atividades Típicas
[editar | editar código-fonte]Existe um conjunto de actividades que giram em torno dos padrões de requisitos, nomeadamente (Ademar, 2006):
- Abstracção: para criar um padrão é necessário criar abstracções dos casos de uso reutilizáveis; irá ser essa abstracção que guiará o reutilizador na escolha de um determinado padrão.
- Selecção: nesta actividade procede-se à classificação, pesquisa, comparação, compreensão e escolha de padrões.
- Especialização: consiste na fase em que um padrão é aplicado a uma solução em particular; como o padrão é uma solução genérica, é necessário especializá-la à situação concreta.
- Integração: consiste na possibilidade de integrar vários padrões de requisitos numa determinada solução.
Criação de um Padrão de Requisito
[editar | editar código-fonte]Para criar um padrão de requisito é necessário analisar um determinado processo de negócio em diversos contextos, de modo a que se consiga abstrair uma solução genérica e aplicável a uma diversidade de situações. As particularidades de um processo de negócio numa determinada organização devem ser eliminados da solução, de modo a que se obtenham as características comuns: o objectivo é ter uma solução genérica que posteriormente possa ser particularizada para cada problema concreto. Possuindo essa solução, interessa torná-la acessível através da sua documentação; com o objectivo de tornar a consulta de padrões num processo consistente, (Alexander, 1977) definiu um template para a documentação de padrões, o qual se encontra adaptado área de requisitos em (Robertson, 2006):
- Nome do Padrão: Um nome descritivo que permita a fácil comunicação do padrão.
- Forças: As razões para a existência do padrão.
- Contexto: A área de aplicabilidade do padrão.
- Solução: A descrição do padrão.
- Padrões Relacionados: Outros padrões que possam ser aplicados em conjunto com o padrão descrito ou que possam ajudar a compreendê-lo melhor.
Exemplo
[editar | editar código-fonte]O seguinte exemplo foi adaptado de (Robertson, _):
- Nome do Padrão: Cliente Pretende Comprar Produto
- Forças: Uma organização é procurada pelos seus clientes para fornecer bens ou serviços. Se essa procura não é satisfeita, existe o risco de o cliente escolher outra organização. Por vezes, a o produto está indisponível para venda imediata.
- Contexto: Um padrão para receber pedidos dos clientes, processar a encomenda e emitir a factura.
- Solução:
Partes do padrão:
Relação entre os objectos que participam no padrão:
- Padrões Relacionados: Cliente Cancela Pedido; Cliente Efectua Pagamento; Cliente Devolve Produto com Falhas.
(Creel, 2006) apresenta outros exemplos de padrões de requisitos.
Referências
[editar | editar código-fonte]- Robertson, Suzanne; James Robertson (1977). A Pattern Language: Towns, Buildings, Construction. [S.l.]: New York: Oxford University Press. ISBN 0-321-41949-9
- Alexander, Christopher (2006). Mastering the Requirements Process. [S.l.]: Addison Wesley Professional. ISBN 0-195-01919-9
- Saeki, Motoshi (1999). Reusing Use Case Descriptions for Requirements Specification: Toward Use Case Patterns. [S.l.]: IEEE. ISBN 0-7695-0509-0
- Gamma, Erich; Richard Helm, Ralph Johnson, John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. [S.l.]: Addison-Wesley. ISBN 0-201-63361-2
- Creel, Christopher (2006). Requirements by Pattern. http://www.ddj.com/dept/architect/196600223 Último acesso: 14/12/06
- Robertson, Suzanne. Requirements Patterns via Events / Use Cases. http://systemsguild.com/GuildSite/SQR/Requirements_Patterns.html Último acesso: 14/12/06
- Konrad, Sascha; Laura Campbell, Betty Cheng, Min Deng (2003). A Requirements Patterns-Driven Appoach to Specify Systems and Check Properties. [S.l.: s.n.]
- SofwareProjects (2006). The Microwave Way to Software Requirements. http://www.softwareprojects.org/software-requirement-management-05.htm Último acesso: 14/12/06
- Aguiar, Ademar (2006). Reutilização de Software, Padrões e Frameworks. http://paginas.fe.up.pt/~aaguiar/as/AS-200506-Patterns.pdf Último acesso: 14/12/06