Software Requirements and Architecture

Objectives

Objective: studying requirements as the foundation for developing a software product. The various types of requirements, particularly non-functional requirements (NFRs) and sustainability requirements are the driving pillars for the software architecture design.

To understand:

  • The importance of requirements and the fundamentals of Requirements Engineering (RE)
  • The main RE activities and techniques and the impact of requirements on software architectures
  • The fundamentals for the systematic derivation and specification of software architectures
  • A subset of the architectural styles and patterns

To know:

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

Know how to:

  • Apply agile and goal-oriented approaches to identify, specify and validate requirements.
  • Identify requirements that contribute to sustainability and the development of sustainable software systems.
  • Use techniques to refine sustainability requirements and NFRs, and resolve conflicts.
  • Analyze the architectural choices and choose the most adequate to meet the restrictions imposed by the sustainability requirements and NFRs, promoting the systematic derivation of the architecture.
  • Specify software architectures using views, patterns, and styles.

General characterization

Code

11171

Credits

6.0

Responsible teacher

Ana Maria Diniz Moreira, João Baptista da Silva Araújo Júnior

Hours

Weekly - 4

Total - 52

Teaching language

Português

Prerequisites

Software Development Methods

Software Engineering

Domain-Specific Modeling Languages

Bibliography

  • Wiegers, Karl, and Candase Hokanson. Software Requirements Essentials: Core Practices for Successful Business Analysis. Addison-Wesley Professional, 2023
  • Chung, Lawrence, Brian A. Nixon, Eric Yu, and John Mylopoulos. Non-functional requirements in software engineering. Vol. 5. Springer Science & Business Media, 2012
  • I. Alexander, N. Maiden, Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Wiley, 2004
  • 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

Lectures are typically given in a classroom with a projector, and the practical classes are in a lab with computers and a projector aiming at applying and deepening the topics taught in previous theoretical lectures.

In the initial phase of this curricular unit, students must interview potential users of their work project outside the classroom.

Students may clarify doubts during classes and office hours.

Evaluation method

The assessment of this curricular unit (UC) consists of a theoretical component (with two tests) and a practical component (a project with two deliverables). Both tests and deliverables are rated on a scale of 0 to 20, rounded to the nearest tenth. Only the final grade will be rounded to the nearest integer.

I. Theoretical Assessment

1. Students are allowed to consult one handwritten A4 page validated by the lecturer at the beginning of the assessment.

2. The classification of the theoretical component (NT) is the arithmetic average rounded to the tenth of the scores obtained in the two face-to-face tests (the classification of each test is rounded to the tenth).

3. Students who obtain an NT classification equal to or greater than 9.5 (out of 20) ​​pass the theoretical component.

4. The tests are face-to-face and solved in the test document received.

5. The identification of fraud in an assessment (Test or Exam) results in the cancellation of the test, failure in the curricular unit, and loss of the frequency obtained.

II. Practical Assessment

1. At the beginning of the semester, students receive a description of the project to be developed throughout the semester (mostly outside classes).

2. The project is developed in groups of 3 or 4 students. The composition of the groups is the responsibility of the students and should be delivered to the lecturer by the end of the first week of classes.

3. The project is delivered in two phases, each with a deliverable. The report of each deliverable contains and discusses all the elements required in the statement, follows the template discussed in the classes, and is submitted electronically together with all artefacts produced (such as models). The deliverables are the following:

(i) The first deliverable is SRS (System Requirements Specification). This document is submitted approximately the eighth week of the semester. The lecturer makes a summary assessment and gives feedback to each group on points to improve or problems encountered.

(ii) The second deliverable is the Architectural Description document. This document is submitted at the beginning of the last week of the semester.

4. The project is discussed orally in the last week of classes.

5. The grade of the project component (NP) must be at least 9.5 points. This grade is assigned individually and is determined by the assessment of the two deliverables and the oral discussion, on a scale from 0 to 20.

III. Frequency

Frequency is guaranteed to students who comply with the following three components:

(i) Attendance of a minimum of 50% of the lectures & and 50% of the labs

(ii) Project Grade (NP) >=9.5 

(iii) Positive feedback during the interim project assessments conducted during some practical classes 

IV. Final Classification

1. The final classification (CF) is the result of the following expression approximated to the units:

 CF=NT×0.6+NP×0.4

2. Students with a discrepancy of 4 points (out of 20) or more between NT and NP may be required to defend their final grade through an individual oral examination.

3. Absence from the oral test results in a final grade equal to the theoretical grade (NT).

V. Use of AI Tools (eg, ChatGPT, Gemini)

1. During an assessment, students may not have in their possession any electronic devices capable of accessing the internet or with Bluetooth connectivity (e.g., smartphones, smartwatches, smartglasses, tablets, laptops), even if they are turned off. Violation of this rule will result in immediate failure of the curricular unit through disqualification and will be reported to the Scientific Committee of the respective program.

2. Students who use AI tools in the final project are required to report their usage. Failure to disclose this information will result in immediate exclusion and subsequent failure. 

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, Specification and Exploration
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 elicitation (e.g., Design Thinking, Brainstorming, Checklists)
3.2 Methods for requirements specification (e.g., Goal-oriented, Object-Oriented)
3.3 Sustainability and non-functional requiremements refinment and operationalization methods
3.4 Goal-based Modelling (intentional organizational modeling)
3.5 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

Programs

Programs where the course is taught: