Software Requirements and Architecture
Code
11171
Academic unit
Faculdade de Ciências e Tecnologia
Department
Departamento de Informática
Credits
6.0
Teacher in charge
Ana Maria Diniz Moreira
Weekly hours
4
Teaching language
Português
Objectives
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.
Knowledge:
- Deal with the challenges imposed by the size, conflicting goals and poor requirements.
- Understand the advantages of systematic development and planned reuse.
- Consider the structure based on a range of possibly disjoint alternatives.
Application:
- 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 existing architectural description languages and automated tools.
Prerequisites
Software Development Methods
Software Engineering
Domain-Specific Modeling Languages
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
Bibliography
- 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.
Evaluation method
**Can be subjtect to small changes **
Assessment consists of two mandatory components: a practical project (50%); 2 tests (50%). The project (and respective report) is done in groups of 2 students, and the tests are individual.
The final grade is the weighted average of the grades obtained in theproject (50%), and the tests (50%, 25% each).
The project is mandatory and students with an average grade lower than 9.5 fail the subject.
Students who do not submit a component of the evaluation process are classified as “Reprovado” (fail), while others, that did not take part in any evaluation process are classified with "Ausente" (absent).
Access to the re-sit exam period are for students who have frequency, but not achieved a satisfactory performance in continuous assessment (with an average between 9.5 and 20), or who wish to improve their grade.
Grade improvement for students registered in the semester when they passed the course is done at the time of the re-sit exam of the semester, and the rules are those of the "Época de Recurso" (thus the final grade is given by the grade obtained in the exam grade).
Students that succssfully finished the course in previous years can improve their grade by taking the final exam, and the final grade will be the final mark obtained in the exam. Similarly, for tudents taking the special exam ("época especial").