Os requisitos de sistema, assim como foi o caso dos requisitos de cliente, têm de ser especificados em um documento, de modo a poderem ser verificados e validados e posteriormente usados como base para as atividades subsequentes do desenvolvimento de software. O Documento de Especificação de Requisitos tem como propósito registrar os requisitos escritos a partir da perspectiva do desenvolvedor e, portanto, deve incluir os vários modelos conceituais desenvolvidos, bem como a especificação dos requisitos não funcionais detalhados.
Diferentes formatos podem ser propostos para documentos de especificação requisitos, bem como mais de um documento pode ser usado para documentar os requisitos de sistema. Neste texto, propõe-se o uso de um único documento, contendo as seguintes informações:
• Introdução: breve introdução ao documento, descrevendo seu propósito e estrutura. • Modelo de Casos de Uso: apresenta o modelo de casos de uso do sistema, incluindo
os diagramas de casos de uso e as descrições de casos de uso associadas.
• Modelo Estrutural: apresenta o modelo conceitual estrutural do sistema, incluindo os diagramas de classes do sistema.
• Modelo Dinâmico: apresenta os modelos comportamentais dinâmicos do sistema, incluindo os diagramas de estados, diagramas de interação e diagramas de atividades.
• Dicionário do Projeto: apresenta as definições dos principais conceitos capturados pelos diversos modelos e restrições de integridade a serem consideradas, servindo como um glossário do projeto.
• Especificação dos Requisitos Não Funcionais: apresenta os requisitos não funcionais descritos no nível de sistema, o que inclui critérios de aceitação.
É importante frisar que dificilmente um sistema é simples o bastante para ser modelado como um todo. Quase sempre é útil dividir um sistema em unidades menores, mais fáceis de serem gerenciáveis, ditas subsistemas. É útil organizar a especificação de requisitos por subsistemas e, portanto, cada uma das seções propostas acima pode ser subdividida por subsistemas.
Um modelo estrutural para uma aplicação complexa, por exemplo, pode ter centenas de classes e, portanto, pode ser necessário definir uma representação concisa capaz de orientar um leitor em um modelo dessa natureza. O agrupamento de elementos de modelo em subsistemas serve basicamente a este propósito, podendo ser útil também para a organização de grupos de trabalho em projetos extensos. A base principal para a identificação de subsistemas é a complexidade do domínio do problema. Através da identificação e agrupamento de elementos de modelo em subsistemas, é possível controlar a visibilidade do leitor e, assim, tornar os modelos mais compreensíveis.
A UML provê um tipo principal de item de agrupamento, denominado pacote, que é um mecanismo de propósito geral para a organização de elementos da modelagem em grupos. Um diagrama de pacotes mostra a decomposição de um modelo em unidades menores e suas dependências, como ilustra a Figura 4.4. A linha pontilhada direcionada indica que o pacote origem (no exemplo, o pacote Atendimento a Cliente) depende do pacote destino (no exemplo, o pacote Controle de Acervo).
Figura 4.4 – Exemplo de um Diagrama de Pacotes
Por fim, vale ressaltar que, caso uma abordagem baseada em objetivos (GORE) seja adotada e o modelo de objetivos seja considerado parte da especificação de requisitos, então uma seção adicional, no início do documento, deve ser adicionada para apresentar e descrever o modelo de objetivos.
Referências do Capítulo
AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements, Springer-Verlag, 2005.
BASS, L., CLEMENTS, P., KAZMAN, R., Software Architecture in Practice, Second edition, Addison Wesley, 2003.
BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML 2, Elsevier, 2006.
BOOCH, G., Object-Oriented Analysis and Design with Applications, 2nd edition, Benjamin/Cummings Publishing Company, Inc, 1994.
BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usuário, 2a edição, Elsevier Editora, 2006.
ISO/IEC 25010, System and Software Engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models, 2011. ISO/IEC 25023, System and Software Engineering - Systems and software Quality
Requirements and Evaluation (SQuaRE) - Measurement of system and software product quality, 2016.
ISO/IEC TR 9126-2:2003, Software Engineering – Product Quality – Part 2: External Metrics, 2003a.
ISO/IEC TR 9126-3:2003, Software Engineering – Product Quality – Part 3: Internal Metrics, 2003b.
JACOBSON, I.; Object-Oriented Software Engineering, Addison-Wesley, 1992.
LAMSWEERDE, A., Requirements Engineering – From System Goals to UML Models to
Software Specifications, Wiley, 2009.
LARMAN, C., Utilizando UML e Padrões, 3ª edição, Bookman, 2007. OLIVÉ, A., Conceptual Modeling of Information Systems, Springer, 2007.
PASTOR, O., MOLINA, J.C., Model-Driven Architecture in Practice: A Software Production
Environment Based on Conceptual Modeling, Springer, 2007.
ROBERTSON, S., ROBERTSON, J., Mastering the Requirements Process. 2nd Edition. Addison Wesley, 2006.
RUMBAUGH, J., et al.; Modelagem e Projetos Baseados em Objetos, 1ª Edição, Editora Campus, 1994.
WAZLAWICK, R.S., Análise e Projeto de Sistemas de Informação Orientados a Objetos, Elsevier, 2004.
WIEGERS, K.E., Software Requirements: Practical techniques for gathering and managing
requirements throughout the product development cycle. 2nd Edition, Microsoft Press, Redmond, Washington, 2003.
YOURDON, E., Object-Oriented Systems Design: an Integrated Approach, Yourdon Press Computing Series, Prentice Hall, 1994.
Capítulo 5 – Modelagem de Objetivos e de Casos de Uso
A análise de requisitos é um processo que envolve a construção de diversos modelos. Diagramas de classes e diagramas de interação incluem detalhes relacionados à estrutura interna dos objetos, suas associações, como eles interagem dinamicamente e como invocam o comportamento dos demais. Essas informações são necessárias para projetar e construir um sistema, mas não são suficientes para comunicar requisitos funcionais com clientes e usuários. Elas não capturam o conhecimento sobre as tarefas a serem realizadas e, portanto, é difícil avaliar se o sistema a ser construído a partir de um modelo desse tipo, isoladamente, vai realmente atender às necessidades dos usuários.
Assim, é importante construir, primeiro, um modelo que descreva o sistema em termos de suas tarefas, seu ambiente e como sistema e ambiente estão relacionados. Tal modelo deve ser passível de compreensão tanto por desenvolvedores – analistas, projetistas, programadores e testadores – como pela comunidade usuária – clientes e usuários. Modelos de casos de uso (use cases) são uma forma de estruturar essa visão. Como o próprio nome sugere, um caso de uso é uma maneira de usar o sistema. Usuários interagem com o sistema, interagindo com seus casos de uso. Tomados em conjunto, os casos de uso de um sistema definem a sua funcionalidade. Casos de uso são, portanto, os “itens” que o desenvolvedor negocia com seus clientes.
Como se pode perceber, casos de uso têm uma estreita relação com requisitos funcionais e podem ser derivados diretamente deles. Assim, quanto mais completa e correta for a identificação de requisitos funcionais, melhor será o modelo de casos de uso resultante. Obviamente, novos requisitos funcionais podem ser identificados quando se elabora um modelo de casos de uso, já que o processo é essencialmente iterativo. Contudo, se for possível utilizar outros mecanismos para apoiar a identificação de requisitos funcionais, tanto melhor. Neste contexto, a análise de objetivos pode ser uma importante aliada. Objetivos tanto proveem razões para os requisitos quanto direcionam a identificação de requisitos para suportá-los (LAMSWEERDE, 2009). Assim, antes de se realizar a modelagem de casos de uso é interessante fazer uma análise de objetivos.
Vale destacar que, ao contrário dos demais modelos discutidos ao longo deste texto, a análise de objetivos é uma abordagem que ainda não alcançou plenamente a indústria de software, sendo considerada, portanto, parte ainda do estado da arte. Neste sentido, este capítulo busca apoiar essa transição, introduzindo os principais conceitos da abordagem baseada em objetivos para a Engenharia de Requisitos (Goal-Oriented Requirements Engineering - GORE). Para maiores detalhes sobre GORE, recomenda-se ver o livro de Lamsweerde (2009).
Este capítulo aborda a análise de objetivos e a modelagem de casos de uso, discutindo os principais elementos de modelos de ambos. A Seção 5.1 trata da análise de objetivo. A Seção 5.2 enfoca a modelagem de casos de uso.