Requisitos e Arquitetura de Software
Objetivos
Objectivo: estudo dos vários tipos de requisitos como pilares orientadores da arquitetura de software. Os requisitos da sustentabilidade, os requisitos não-funcionais (NFRs) e análise de conflitos servem de base para a derivação sistemática da arquitetura de software.
Compreender:
- Fundamentos da engenharia de requisitos
- Métodos de especificação e análise de requisitos
- Fundamentos da arquitetura de software
- Estilos e padrões arquiteturais
- As bases para derivação sistemática de arquiteturas de software
Saber:
- Lidar com desafios colocados pela dimensão, objectivos contraditórios e descrição deficiente dos problemas reais.
- Compreender as vantagens da sistematização e reutilização planeada para a derivação da arquitetura.
- Ponderar a arquitectura com base em alternativas nem sempre disjuntas.
Saber fazer:
- Aplicar abordagens ágeis e orientadas a objectivos para identificar, especificar, validar e gerir requisitos.
- Identificar requisitos que contribuem para a sustentabilidade e para o desenvolvimento de sistemas de software sustentáveis.
- Usar técnicas para refinar os requistos a sustentabilidade e os NFRs, e resolver conflitos.
- Analisar alternativas arquiteturais e escolher as mais adequadas para satisfazer as restrições impostas pelos requisitos da sustentabilidade e pelos NFRs, promovendo a derivação sistemática da arquitetura.
- Descrever arquiteturas usando visões, padrões e estilos.
- Utilizar linguagens de descrição arquitetural e ferramentas automáticas.
Caracterização geral
Código
11171
Créditos
6.0
Professor responsável
Ana Maria Diniz Moreira
Horas
Semanais - 4
Totais - 52
Idioma de ensino
Português
Pré-requisitos
Métodos de Desenvolvimento de Software
Engenharia de Software
Linguagens de Modelação para Domínios Específicos
Bibliografia
- An Introduction to requirements Engineering, I. K. Bray, Addison-Wesley, 2002
- K. Wiegers, J. Beatty, Software Requirements, Microsoft Press, 2013
- J.Dick, E. Hull, K. Jackson, Requirements Engineering, Springer-Verlag, 2010
- A. Lamsweerde, Requirements Engineering, Wiley, 2009
- I. Alexander, N. Maiden, Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Wiley, 2004
- G. Kotonya, I. Sommerville, “Requirements Engineering: Processes and Techniques”, Wiley, 1998
- I. Alexander, R. Stevens, “Writing Better Requirements”, Addison Wesley, 2002
- R. N. Taylor, et al, "Software Architecture: Foundations, Theory, and Practice" John Wiley and Sons, 2009
- L. Bass, et al, "Software Architecture in Practice", 2nd edition, Addison-Wesley, 2003
- P. Clements, et al "Documenting Software Architectures: Views and Beyond", Addison-Wesley, 2003.
Método de ensino
As aulas teóricas são tradicionalmente dadas em sala de aula com um projetor, e as aulas práticas em laboratório equipado com computadores e projetor com o objetivo de aplicar e aprofundar as matérias lecionadas nas aulas teóricas anteriores.
Todavia, dada a situação pandémica que vivemos, pode ser que estas aulas, tradicionalmente muito interactivas, tenham que ser dadas online.
Os alunos podem esclarecer dúvidas durante as aulas ou nos horários de atendimento.
Método de avaliação
A avaliação desta unidade curricular (UC) tem uma componente teórica (com dois testes) e uma componente prática (um projeto com dois entregáveis). Tanto os testes como os entregáveis são classificados numa escala de 0 a 20 valores, arredondados às décimas. (Apenas a nota final será arredondada às unidades.)
I. Avaliação Teórica
1. Os alunos estão autorizados a consultar uma página A4 escrita à mão e validada pelo professor no início da avaliação.
2. A classificação da componente teórica (NT) é a média aritmética arredondada às décimas das notas obtidas nos dois testes presenciais (a classificação de cada teste é arredondada às décimas).
3. Os alunos que obtenham uma classificação NT igual ou superior a 9,5 valores obtêm aprovação na componente teórica.
4. Os testes são presenciais e resolvidos no próprio enunciado.
5. A identificação de fraude numa prova de avaliação (Teste ou Exame) resulta na anulação da prova, reprovação na unidade curricular e perda da frequência obtida.
II. Avaliação Prática
1. Na primeira semana de aulas os alunos recebem um caderno de encargos sobre o projeto a desenvolver ao longo do semestre (maioritariamente fora das aulas).
2. O projeto é desenvolvido em grupos de 3 ou 4 alunos. A constituição dos grupos é da responsabilidade dos alunos. A constituição dos grupos é entregue ao docente até ao final da primeira semana de aulas.
3. O projeto é entregue em duas fases, cada uma com um entregável. O relatório de cada entregável contém e discute todos os elementos requeridos no enunciado, segue o template discutido nas aulas, e é submetido eletronicamente juntamente com todos os artefactos produzidos (como por exemplo, modelos).
(i) Especificação de requisitos, ou SRS (System Requirements Specification). Este documento é submetido aproximadamente na oitava semana do semestre. O docente faz uma avaliação sumária e dá feedback a cada grupo sobre os pontos a melhorar ou problemas encontrados.
(ii) Documento de descrição arquitetural. Este documento é submetido no início da última semana do semestre.
4. O projeto é discutido oralmente no na última semana de aulas.
5. A nota da componente projeto (NP) é atribuída individualmente e é determinada pelo conjunto da avaliação dos dois entregáveis e discussão oral, numa escala de 0 a 20.
III. Frequência
Os estudantes que obtenham Nota do Projecto (NP) >=9,5 obtêm frequência à unidade curricular.
IV. Classificação final
1. A nota final é uma média dos quatro elementos de avaliação, cada um com um peso de 25%.
2. A classificação final (CF) é o resultado da seguinte expressão aproximado às unidades:
CF=NT×0.5+NP×0.5
3. Os alunos que apresentem uma discrepância superior a 4 valores entre a NT e a NP poderão ter que defender a nota final numa prova oral individual.
4. A ausência à prova oral resulta numa classificação final igual à nota teórica (NT).
Conteúdo
1. Introdução
1.1 A natureza e a importância da Engenharia de Requisitos
1.2 Requisitos como drivers da Arquitetura de Software
1.3 Arquitetura de software e sua importância na evolução do software
2. Processo de Engenharia de Requisitos
2.1 Processos e modelos de engenharia de requisitos
2.2 Elicitação, Especificação e Exploração de Requisitos
2.3 Análise e Negociação de Requisitos (gestão de conflitos e priorização)
2.4 Validação de Requisitos (inspeções, protótipos, validação de modelo e teste de requisitos)
2.5 Gestão de Requisitos
2.6 Padrões de documentação de requisitos (por exemplo, IEEE 830-1998)
3. Técnicas de engenharia de requisitos
3.1 Métodos para elicitação de requisitos (e.g., Design Thinking, Brainstorming, Checklists)
3.2 Métodos para especificação de requisitos (e.g., Goal-oriented, Object-Oriented)
3.3 Estrutura de requisitos de sustentabilidade e dos requisitos não funcionais (Refinamento e operacionalização)
3.4 Modelação baseada em objetivos (modelagem organizacional intencional)
3.5 Derivação de modelos orientados a objetos (mapeamentos entre paradigmas, modelos e conceitos)
4. Fundamentos de desenho arquitetural
4.1 Princípios de arquitetura de software
4.2 Mapeamento de requisitos para conceitos arquiteturais
4.3 Documentação da arquitetura de software
5. Técnicas de arquitetura de software
5.1 Estruturação do sistema e decomposição modular
5.2 Vistas arquiteturais
5.3 Estilos e padrões arquiteturais (catálogos de arquiteturas de software)
5.4 Linguagens de descrição arquiteturais
5.5 Avaliação da arquitetura