Software Requirements and Architecture
Objective: study the various types of requirements as drivers of the software architecture. Sustainability requirements, non-functional requirements (NFRs) and conflict analysis form the basis for the systematic derivation of the software architecture.
- Fundamentals of Requirements Engineering
- Requirements specification and analysis methods
- Fundamentals of software architecture
- Architectural styles and patterns
- Fundamentals for the systematic derivation of software architectures
- 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 agile and goal-oriented approaches to identify, specify and validate requirements.
- Identify requirements that contribute to sustainability and to 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, styles.
- Use architectural description languages and automated tools.
Ana Maria Diniz Moreira
Weekly - 4
Total - 52
Software Development Methods
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.
Lectures are typically given in a classroom with a projector, and the practical classes are in a lab with computers and projector aiming at apply and deepen the topics taught in previous theoretical lectures.
However, given the pandemic situation, it may happen that these lectures, traditionally very interactive, must be given in online sessions.
Students may clarify doubts during classes and office hours.
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. In the first week of classes, students receive a specification on 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 resposnsibility 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 artifacts produced (such as models).
(i) The first deliverable is SRS (System Requirements Specification). This document is submitted approximately the eighth week of the semester. The teacher 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) is assigned individually and is determined by the assessment of the two deliverables and the oral discussion, on a scale from 0 to 20.
Students who obtain Project Grade (NP) >=9.5 obtain attendance to the curricular unit.
IV. Final classification
1. The final grade is an average of the four assessment elements, each with a weight of 25%.
2. The final classification (CF) is the result of the following expression approximated to the units:
3. Students who present a discrepancy greater than 4 values between NT and NP may have to defend their final grade in an individual oral test.
4. Absence from the oral test results in a final grade equal to the theoretical grade (NT).
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 where the course is taught: