Requirements Engineering Practicum

Describing the practical exercises with illustrations

By: Maurice ter Beek, Slinger Jansen, and Tom Groentjes

Outline

• Three assignments– Requirements Scenarios (33%)– Testing Requirements with Formal Descriptions (33%)– Testing Requirements with Behavioral Descriptions

(33%)• All will be graded• All can be done in teams of two (but team needs to

stay a team)• This presentation is the most detailed description of

the practicum

P1: Requirements Scenarios

its

Use of Diagrams

• Sequence diagrams• Activity diagrams• Use case diagrams

Requirements Scenarios• Aim: Familiarize students with different scenario types and

formulations.

• Pick an example feature request from here: https://docs.google.com/spreadsheet/ccc?key=0AnnmW7Q08K0xdDZkWjlfZ1l5NW9kbXozZ1huTENoRGc#gid=0

• And write scenarios for it: Current-state and desired state scenarios, positive and negative scenarios, misuse scenarios, descriptive, exploratory, and explanatory scenarios, instance and type scenarios, system-internal scenarios, interaction scenarios, context scenarios, and exception scenarios.

• Scenarios need not overlap or be related, although a sufficient understanding needs to be shown of the application.

Scenarios: Grading

• Scenario correctness (50%) • Creativity (15%)• Presentation (20%) • Language (15%)

P2: Formal Specification

Formal Specification

• Aim: Familiarize students with formal requirements specification without “implementation clutter”

• Use VDM++ to expand the reduced VDM++ Alarms example for a chemical factory

• Deliver the UML, the code, and tests• Requirements are changed, removed, and

added

Formal Specification: VDM++

• See this document for a tutorial: http://wiki.overturetool.org/images/d/d1/VDMPPGuideToOvertureV1.pdf

• Install Eclipse• Install the VDM++ plugin for Eclipse:• http://sourceforge.net/projects/overture/files/• Get a copy of the alarms example from the tutorial

document mentioned in the first bullet• See if the test is running (define entry point)• Details on the VDM++ language can be found here:

http://wiki.overturetool.org/images/c/cb/VDM10_lang_manV2.pdf

Formal Specification: Alarms• R1. A computer-based system is to be developed to manage the alarms of

this plant.

• R2. Four kinds of qualifications are needed to cope with the alarms: electrical, mechanical, biological, and chemical.

• R3. There must be experts on duty during all periods allocated in the system.

• R4. Each expert can have a list of qualifications.

• R5. Each alarm reported to the system has a qualification associated with it along with a description of the alarm that can be understood by the expert.

• R6. Whenever an alarm is received by the system an expert with the right qualification should be found so that he or she can be paged.

• R7. The experts should be able to use the system database to check when they will be on duty.

• R8. It must be possible to assess the number of experts on duty.

Formal Specification: New Requirements

• R9. Please introduce another expert: The Requirements Engineer.• R10. Some experts are interested in becoming an expert in one other area as

well. If they are, they should be paged also.• R11. There is a new alarm class <Meltdown> that is basically a call to all available

experts.• R12. If an expert has more than two expertises, she is more expensive to page.

These experts should only be paged when no other experts are available. In case of a Meltdown, these should be called first.

• R13. Experts can cancel an alarm after reaching the scene, to reduce the number of experts coming.

• R14. Experts need a car to get to the location of the mishap. If there are no cars available an exception request needs to be sent to factory management.

• R15. Cars can hold a maximum of 2 experts.• R13. Experts that have two similar expertises should never be in the same car

together.

Formal Specification: Grading

• Please add comments to your own code.• Write some of your own tests.• We will create several tests to confirm your

code is working correctly. Here are some examples to get you started.

Formal Specification: Grading

• Correctly working: 60%• Comments: 20%• Your own tests: 20%

Formal Specification: some tests

• Some tests can already be found here.• Deze test doen basale functie checks namelijk:– checken welke expert gepaged moet worden bij een

specifiek alarm in een specifieke tijdsspanne– checken hoeveel experts aan het werk zijn in een

specifieke periode– list all experts– check in welke perioden een expert aan het werk is

• Heb verder 9 soorten alarmen, 1 meltdown, 20 experts, 27 tijdsspannes, en 1 plant.

• (met dank aan Tom)

Some Important Remarks (1)

• Overloaden van constructors/functies werkt niet (had aparte constructor gemaakt die alarm meltdown aanriep en daar kreeg ik geen errors bij totdat ik het programma ging draaien)

• -Comments worden geschreven door de regel te starten met --

• -De examples die ze moeten hebben zijn niet makkelijk te vinden in de link van de slides maar kunnen beter gehaald worden van hier. Anders hebben ze grote kans dat ze de AlarmErrPP en Alarm++tracesPP niet in de examples hebben zitten.

• (credits go to Tom)

Remarks (2)

• Verder vroeg ik mij af of het de bedoeling is dat ze zelf Experts aanmaken (en dus zelf kunnen kiezen welke expertise deze hebben) of dat ze die van ons krijgen. Het zelfde geld voor de de timeschedules en de soorten alarmen.

• Wat betreft de naming conventies denk ik dat we makkelijk kunnen zeggen dat we alles in het engels willen waarbij classes met een hoofdletter beginnen. Zover ik het nu zie zijn de waardes die in mijn tests gebruikt gaan worden effectief alleen de classnaming waarvan het grootste deel al bestaat (Plant, Alarm, Expert,Period,Meltdown,Car)

Remarks (3)

• Verder heb ik gezien dat UML diagrammen uit EA ingeladen kunnen worden, en waarschijnlijk gaat daarmee het implementeren van de systemen makkelijker (diagrammen maken is makkelijker dan VDM++ coden), echter EA is geen freeware, dus ik denk niet dat veel studenten die weg zullen bewandelen.

P3: Behavioral Descriptions

Behavioral Descriptions

• Aim: Get students familiarized with behavioral descriptions and behavior driven development.

• Install Ruby, Cucumber, and Selenium.

Behavioral Descriptions

• Write Cucumber tests for a complex feature of a current web site, such as:– Moneybird’s invoice creation and deletion feature– GitHub’s ticketing features– Facebook’s picture upload feature– Lighthouse’s ticketing feature– … Or e-mail us if you have a better idea!

Write Behavioral Tests

• At least 10 tests for a common web app• Make sure one of them fails and explain why

(you probably want the behavior of the app to be different)

• Give a half page description for each test• Provide instructions if necessary (other gems

needed?), it should be VERY easy for us to run your tests

Install Ruby & Rails

• See http://rubyonrails.org/

Install Cucumber

• Voeg cucumber toe aan de Gemfile:

• gem “cucumber-rails”, :group => :test• gem “database_cleaner”, :group => :test

• Installeer via bundler en initialiseren:

• $ bundler install• $ rails generate cucumber:install

Eerste Setup• Een simpele resource om mee te testen:• • rails g scaffold user \• name:string email:string password:string• • Voeg validatie toe:• • class User < ActiveRecord::Base• attr_accessible :email, :name, :password, :password_confirmation• validates_presence_of :name, :email, :password• validates_confirmation_of :password• end

• (Please note: this is only to test a local rails app, not for testing an external app with Selenium)

Create Test File

• Maak een nieuw bestand aan:• $ vi features/users.feature

Test• Feature: Sign up• As an unauthorized user• I want to sign up• So that a new account is created• Scenario:• Given I am on the signup page• When I fill in “Name” with “Test User”• And I fill in "Email" with "test_user@gmail.com"• And I fill in "Password" with "secret"• And I fill in "Password confirmation" with "secret"• And I press “Create User”• Then the Show User page should be shown• And I should see “User was successfully created”• And a user with name “Test User” should be registered

Execute tests• Voer nu de test uit:• $ bundle exec cucumber• • Het resultaat:• ...• Undefined step: "I am on the signup page" (Cucumber::Undefined)• ...• You can implement step definitions for undefined steps with these

snippets:• • Given /^I am on the signup page$/ do• pending # express the regexp above with code• end• • Cucumber weet nog niet wat onze test betekent!

Instruct Cucumber• Om de tests uit te kunnen voeren moeten we Cucumber vertellen wat onze

stappen betekenen:• $ vi features/step_definitions/user_steps.rb• • 3 standaard keywords:• “Given”:• Given /^I am on the signup page$/ do• visit new_user_url• end• “When”• When /^I press "(.*?)"$/ do |button_name|• click_button button_name• end• “Then”• Then /^I should see "(.*?)"$/ do |content|• assert page.has_content?(content)• end

Instructions for the Example• Alle definities voor onze test:• Given /^I am on the signup page$/ do• visit new_user_url• end• When /^I fill in "(.*?)" with "(.*?)"$/ do |field, value|• fill_in field, :with => value• end• When /^I press "(.*?)"$/ do |button_name|• click_button button_name• end• Then /^I should see "(.*?)"$/ do |content|• assert page.has_content?(content)• end• Then /^a user with name "(.*?)" should be registered$/ do |username|• assert User.find_by_name(username) != nil• end

Execute test again• Voer de test opnieuw uit:• $ bundle exec cucumber• Using the default profile...• Feature: Sign up• As an unauthorized user• I want to sign up• So that a new account is created• Scenario: Proper signup• Given I am on the signup page• When I fill in "Name" with "Test User"• And I fill in "Email" with "test_user@gmail.com"• And I fill in "user_password" with "secret"• And I fill in "user_password_confirmation" with "secret"• And I press "Create User"• Then I should see "User was successfully created"• And a user with name "Test User" should be registered• 1 scenario (1 passed), 8 steps (8 passed), 0m0.436s

Deeper Testing• Meerdere velden met de zelfde naam? Scope met #within:• • within("#new_user") do• fill_in 'Email', :with => 'user@example.com'• fill_in 'Password', :with => 'password'• end• • Ambiguiteit? Als meerdere velden soortgelijke namen hebben kunnen

ok ID of CLASS tags gebruikt worden• • fill_in 'password', :with => 'foo'• fill_in 'password_confirmation', :with => 'foo'• • Meer informatie over selectors op de Capybara github:• https://github.com/jnicklas/capybara

Aanrader: gebruik deze frameworks

• Standaard gebruikt Cucumber Test::Unit, de Rails default. Maar is compatible met andere test frameworks zoals RSpec. Voeg de gewenste gems toe aan de Gemfile:

• gem 'rspec-rails', :group => :test• • Daarna kun je de rspec matchers gebruiken:• • Test::Unit:• assert page.has_content?(content)• • RSpec:• page.should have_content(content)

Now For Selenium• Cucumber heeft ingebouwde hooks voor testen met Selenium.

Deze hoeft alleen aan de Gemfile te worden toegevoegd:• • gem 'selenium-webdriver'• • Vervolgens vertellen we Cucumber dat we via de Selenium

webdriver willen testen, edit features/users.feature:• • ...• @selenium • Scenario: Proper signup• Given I am on the signup page• When I fill in "Name" with "Test User"• ...

Selenium Needs to Connect

• Start net als eerder de cucumber tests in jouw environment:

• • $ bundle exec cucumber• • Cucumber zal automatisch via de Selenium webdriver

jouw browser starten en de tests uitvoeren.• • Let op dat Selenium een server nodig heeft om mee

te verbinden, voor lokale developent kun je je rails app server starten met `rails s` in de console.

Funny…

• http://www.jimmycuadra.com/posts/please-don-t-use-cucumber

Grading:

• One half point per test, including description. (so 5 points in total)

• Overall impression (comments, completeness, coverage is worth 4 points)

• Bringing us to 9 points

Hand it in

• By sending an e-mail with attachments and perhaps some instructions to gentleman281083@gmail.com by the deadlines (although dropbox seems to be in place)