Software Requirements and Architecture


Objective: study the various types of requirements as drivers of the software architecture. Non-functional requirements (NFRs) and conflict analysis form the basis for the systematic derivation of the software architecture.

To understand:

  • Fundamentals of Requirements Engineering
  • Requirements specification and analysis methods
  • Fundamentals of software architecture
  • Architectural styles and patterns

To know:

  • Dealing with the challenges imposed by the size, conflicting goals and poor requirements.
  • Understanding the advantages of systematic development and planned reuse.
  • Selecting the structure based on a range of possibly disjoint alternatives.

Know how to:

  • Apply goal-oriented approaches to identify, specify and validate requirements.
  • Use the NFR Framework to refine NFRs and resolve conflicts.
  • Analyze the architectural choices and choose to meet the restrictions imposed by the NFRs, promoting the systematic derivation of the software architecture.
  • Specify software architectures using views, patterns, styles.
  • Use architectural description languages and automated tools.

General characterization





Responsible teacher

Ana Maria Diniz Moreira


Weekly - 4

Total - Available soon

Teaching language



Software Development Methods

Software Engineering

Domain-Specific Modeling Languages


  • 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.

Teaching method

Available soon

Evaluation method

**Can be subject to small changes during the first two weeks of classes**

Assessment components

Assessment consists of two mandatory components: 

(i) A project  with two deliverables;

(ii) Tow tests.

Practical component

The practical (lab) component consists of a project to develop throughout the semester, with two deliverables spaced in time and evaluated separatedly. The first deliverable (submitted approximately in week 7) is the “requirements specification" document. The second (submitted in week 13) is the “architecture specification" document.

Each deliverable, submitted to Moodle, is a zip file that includes a report documenting the various steps, activities and results developed, as well as the source models created.

This project is carried out in groups of 2-3 students.

Theoretical component

The theoretical component consists of two individual tests. The tests are carried out in person, if the sanitary conditions permit, with consultation of two handwritten pages. If face-to-face tests are not possible, they will be replaced by online assessments (one test and one oral examination).

Preferred test dates:

(i) First test: on April 26 or May 3

(ii) Second test: between June 14 and 17


The frequency is given by the project deliverables and only students with an average ≥ 9.5 values (out of 20) ​​have frequency. Frequencies obtained in the previous year remain valid, as well as the respective grade. 

Final grade

The grade is the weighted average of the practical work (20% first deliverable and 30% the second deliverable) and the grade of the two tests (25% each). 

To pass, a student must have frequency and a final grade > = 9.5.

Subject matter

1. Introduction
1.1 The nature and importance of Requirements Engineering
1.2 Requirements as drivers of Software Architecture
1.3 Software Architecture and its importance in software evolution

2. Requirements Engineering Process
2.1 Requirements engineering processes and models
2.2 Requirements Elicitation and Exploration (Design Thinking, Brainstorming)
2.3 Requirements Analysis and Negotiation (Conflict management and prioritisation)
2.4 Requirements Validation (Inspections, prototypes, model validation and requirements testing)
2.5 Requirements Management  
2.6 Requirements documentation standards ( (e.g., IEEE 830-1998) 

3. Requirements Engineering Techniques
3.1 Methods for requirements specification
3.2 Non-Functional Requirements Framework (Refinement and operationalization)
3.3. Goal-based Modelling with iStar (Intentional organizational modeling)
3.4 Derivation of object-oriented models (Mappings between paradigms, models and concepts)

4. Software Architecture Design Fundamentals
4.1 Software Architecture principles
4.2 Mapping requirements to architectural concepts
4.3 Documenting Software Architecture

5. Software Architecture Techniques
5.1 System structuring and modular decomposition
5.2 Architectural views
5.3 Architectural styles and patterns (catalogs of software architectures)
5.4 Architectural description languages
5.5 Architecture evaluation

6. Advances in requirements and architecture
6.1 Crosscutting concerns
6.2 Domain Analysis and Software Product Lines 


Programs where the course is taught: