The first week we will be discussing about the course modality: content of the course, evaluation, pre-requisites, goals of the course. We will have an introduction about Software Requirements Engineering: why it is so important nowadays and why most of the project failures derive from this phase of software development (contrary to what one might think at first).

Time permitting, we will be  covering  an introduction of Lean and Agile Methodologies to give the savour of what has to come: a short introduction of the principles behind them and why they emerged in the first place in response to more heavy-weight methods.

Lecture

• Course Introduction
• Introduction to Software Requirements Engineering
• Introduction to Agile Methodologies

In-Course Project

Teaching about Requirements Engineering and Agile development without some practical application would be impossible (and very boring, keeping all theoretical). For this reason there will be a small project during the semester in groups of 4 that will be formed to have more heterogeneous experience/background of students as possible. Most of the effort of the project will be kept during lecture (e.g. when looking at user stories / CRC cards / prioritization) each group will use their requirements. The main points:

• every student will contribute with their own expertise (i.e. you do not have to develop software if you never did so before);
• the idea is that the project should be fun. We will be following as project motivational reading the following link: Magicka post-mortem - a successful project developed by students. Your project does not need to be a game. You should spend time to think about the "selling" idea of your project, that is the characteristic that will make the project emerge in comparison to other products;
• the final evaluation is based on the process, not on the product - we care about the requirements engineering process, not the finalized product that can be absolutely incomplete, as long as the requirements were modelled, prioritized, discussed, scheduled, etc.. according to the practices we will discuss during the course;
• given the previous point, you are absolutely free to adopt the technology you think fits best for you. Although some mobile application would be nice to have, also just a plain command line interface  or just an HTML prototype would be equally fine;
• The project outcome will be just a Pass/Fail evaluation, with up to 5 bonus points for exceptional performance;
• 2 bonus points will be also awarded during the final presentation by other students to the project with the best idea;

 

 

This week we will look at the main problems in software development and requirements engineering - and how typically these are addressed by different development methodologies. We see how to start modelling system requirements and the typical indications given by standards such as IEEE 29148 (that replaced IEEE830) and how this differs in the agile context.

 

Lecture

• The three beasts in Software development: uncertainty, irreversibility, complexity [not at the exam]
• The top-10 Requirements Traps [annotated version] [not at the exam]
• The main IEEE standard for requirements: IEEE29148 [annotated version]

 

Additional Material

The following are the more recent IEEE standard about requirements engineering (IEEE29148-2011) and the old standard IEEE830-1998 (replaced by the new one, but still useful).

• IEEE Std 29148-2011 - Systems and software engineering - Life cycle processes - Requirements engineering
• IEEE Std 830-1998 - IEEE Recommended Practice for Software Requirements Specifications (this is the old one and superseded by 29148!) 

This week we start look at requirements elicitation phase, that is the collection of requirements for a specific project. We look initially about all the different types of requirements there can be in a project with a focus on business requirements. We see several ways to model business requirements.

We look in particular at the importance of business requirements: how these can be modelled (by means of context diagram, eco-system map, feature tree or events list). Independently for the methodology of development, business requirements should always be specified at the beginning of a software project.

Lecture

• Software Requirements types & Business Requirements

 

Sorry, the lecture was cancelled due to illness of the teacher

We start discussing user requirements and two of the most representative ways are use cases and user stories. We will discuss both of them: what they are about, differences between them and how the modelling process goes on after their definition. We also look into how to write effective user stories for their management and implementation, looking at some suggestions.

Lecture

• User Requirements: Use Cases vs User Stories
• Agile Requirements: Elicitation & User Stories
• Additional slides about  wicked problems in requirements engineering and the goal-design scale [not at the exam]
• Example for the user story structure
• Suggestions on how to split user stories (part 1, part 2), from Leffingwell's book

Additional Material

The following is a sample from the book G. Adzic and D. Evans, Fifty Quick Ideas to Improve your User Stories. Leanpub, 2013, that takes a practice-oriented approach in giving suggestions about the improvement of the creation of User Stories (http://leanpub.com/50quickideas).

• Sample from "Fifty Quick Ideas to Improve your User Stories"

Tools for User Stories / Use Cases Support

The following tools can be useful to create user stories and use cases:

User Stories:

• Trello (probably fastest tool to start using to write user stories)

Use Cases

• Any UML tool supporting Use Cases
  • ArgoUML (probably fastest to start using, there is also a webstart application)
  • Visual Paradigm (more complete but you will need a license after the trial and takes more time to learn)

Requirements prioritization is important to define the ordering of requirements for each iteration. As we will see, there are many aspects that can be considered to run effectively a prioritization process. One of the most important is the evaluation of the effort associated with the requirements: this will the focus of this lecture. In the agile context, one of the most used approaches for effort estimation is planning poker. Aspects of effort are then used within the planning game to consider also the value for the customer to reach an agreement on the priority of the customer for one iteration

Lecture

• Towards Requirements Prioritization: Effort Estimation

After having seen requirements definition (with User Stories) and effort estimation (e.g. with Planning Poker) we deal now with Software Requirements Prioritization, that is how to decide which requirements should be scheduled. We see both examples from heavy-weight methods (AHP, SQF), and Agile Requirements (Planning Poker + Planning Game).

Lecture

• Software Requirements Prioritization

Additional Material

• describing how AHP can be applied: Saaty, Thomas L. "Decision making with the analytic hierarchy process." International journal of services sciences 1.1 (2008): 83-98.
• the importance of eigenvalues in AHP: Saaty, Thomas L. "Decision-making with the AHP: Why is the principal eigenvector necessary." European journal of operational research 145.1 (2003): 85-91.
• the application of QFD (interesting pages to look at as an example are pages 50-65): Kivinen, Terhi. "Applying QFD to improve the requirements and project management in small-scale project." University of Tampere, Department of Computing Sciences, Computer sciences (2008).

 

In this lecture we will examine the usage of CRC cards for the modelling of user stories that were prioritized for one specific iteration. As well, each story will need to have acceptance tests in place to have the customer's acceptance.

Lecture

• CRC Cards: how to go from user stories to object oriented representation
• CRC & Acceptance testing exercise

This week we deal with Business Rules that can constrain software project development to be complaint with domain rules (e.g. corporate policies, government regulations, industry standards, computational algorithms, etc...). We look at the main definitions and a taxonomy that divides rules in facts, constraints, action enablers, inferences and computations. Being able to recognize the difference is important to use the best modeling representation. We see in particular several approaches to model business rules. The more popular is represented by decision tables, but we see also textual process descriptions, state diagrams & state transition matrices and activity diagrams.

Lecture

• Defining & Modeling Business Rules

 

 

This lecture we focus on Non-Functional Requirements (NFR or also known as quality requirements) and the link from these to the software architecture. Both of them are relevant aspects within a software project especially in case of large projects and projects in which NFR are very relevant. In Agile methodologies there are different ways to deal with NFRs, so we look at them and we see which ones could be more or less useful depending on the project's characteristics.

Lecture

• Non-Functional Requirements in Agile
• The Software Architecture in Agile

Suggested Read

• The Attribute-Driven Design (ADD) Method: shows an approach to link NFRs to the Software Architecture

Projects Checklist:

Ensure that at - at this stage - you have the following material for your project:

• Context diagram & Business Vision (see lecture about business requirements)
• User Stories and/or Use Cases (see lecture about users requirements)
• Prioritization of the Stories (you should have done this during the lecture on software requirements prioritization)
• CRC Cards (see lecture about CRC analysis)

This week we deal with Requirements Validation and Verification. In the Agile context we have seen how acceptance testing is important and how it is used to drive both validation and verification of user stories. We also briefly see some more practical aspects, as one framework (Fitness) that can be used for automated acceptance testing and another interesting approach called Behaviour Driven Development (BDD) implemented within JBehave. Both approaches can help in nearing requirements and actual implementation - to discover problems as early as possible.

Lecture

• Requirements Verification & Validation
• Using Fitnesse for acceptance testing and JBehave for BDD

Additional References

• Fitnesse.org
• JBehave

This lecture we focus on the holistic view of different agile development methods (e.g. SCRUM, XP, Crystal Clear, etc...). We see how these agile development models combine some different requirements engineering practices we have seen during the course.

Lecture

• Control & coordination mechanisms in Agile
• Agile Development Models & Scaling Agile (we covered slides up to 34 included and 56-57. We did not cover FDD and DSD)

Additional Material

Linked material that we did not cover in the previous lectures and that can be interesting (will not be part of the exam): a) Wicked vs Tame problems, b) Uncertainty, Irreversibility, Complexity in Software Development

 

Instructions for Project Presentations:

Thursday 19th May 12:00, A319 (usual time/place for lecture).

For each group, the presentation will take 15 minutes plus 5 questions.

About the content, your project must have the following parts:

• Context diagram & Business Vision (see lecture about business requirements);
• User Stories and/or Use Cases (see lecture about users requirements);
• Prioritization of the Stories (you should have done this during the lecture on software requirements prioritization);
• CRC Cards (see lecture about CRC analysis);
• A small prototype that can be used to show how the system would be implemented;

Some indications about aspects that you can cover during the presentation:

• The project idea from a business perspective (business requirements, e.g. context diagram, vision);
• How requirements were collected, and modelled, in particular user requirements but you can discuss also other types of requirements;
• How requirements were prioritized;
• How you would identify non-functional requirements within your project and which ones do you think would be relevant;
• Implications of the non-functional requirements on the development;
• Your effort estimation for the whole project: how would you do it and what would be the current estimate of time required to finish the project;
• sample prototype (like said previously, as much as you have ready from the iterations);

Please ensure that you have most of the material uploaded in the homework vault by Monday 16th May.

About the Project evaluation, this is a pass/fail project presentation, with up to 5 bonus points for really good projects & presentation (as there are only two groups, it does not make sense to have the voting for the best idea as it was presented at the beginning of the course - last year groups were voting for other projects).
 

---

Exam Information

There are overall 60 points from the exam, divided into 7, 8 or more questions depending on the type and expected complexity - the minimum number of points to pass the course is 36 points. The following are two sample exams selected randomly from the last two editions of the course (topics have been covered in different ways than this year). There is also an (incomplete) set of questions, based on questions that were given in the past years:

• Sample Exam 2013/2014
• Sample Exam 2014/2015
• Sample Questions (not a a complete set!)