Requirements Engineering I

Parisa Ghazi Christoph Vogel

Assignment 2 – Solution & Discussion

October 23rd, 2017

Overview

• The assignment is generally well solved

• Attention to detail: Read the tasks carefully

• For the exam:

•  Read the definition of the terms carefully from the slides

•  Refresh your UML knowledge

2.1 Further Requirements – Solutions

• Aviation authorities might not allow drone operation.

• This is a serious issue which could result in a failure of the whole project.

• Do not invite everyone you know, do not invite too many people.

• Let everyone talk, discuss and find a solution.

• This meeting may result in •  Requirement change

•  Process change •  …

•  In case no agreement is reached, set another meeting.

Par$cipa

nts

Reasons

2.1a Meeting Attendees – Good Example

[Fischer,Gugler,Loch]

Se:ngandgoalsofmee$ng

2.1b Meeting Plan – Good Example

[Bucher,Sommer,Bejta]Introduc$on/Presenta$on

Allpar$e

scan

voiceth

eir

stan

dpoint

Documen$ng

Solu$onfinding

2.1 Further Requirements – Remark

• Critical: You, Dave, Aviation authorities representative, Alice

• Possible: Pilot, Drone manufacturer

• Some data may lead to new requirements or to modification of existing requirements.

• Maybe some of the collected data requires project adjustments like:

•  An additional security test

•  Adjustment of the budget.

•  Adjustment of the project schedule.

Why having a requirements engineer is important: https://www.youtube.com/watch?v=BKorP55Aqvg

2.1 Further Requirements – Grading

Goal: Identify relevant stakeholders, predict the meeting and be ready for probable results Topics Criteria Max

a)  Meeting

Attendees

0.5p per relevant attendee 0.5p per reason

0.5p for meeting setup -1.0p if important person missing

-1,0p if random or too many people are invited

3.0

b) Meeting

2.5p for most important content parts

1.5p for time planning and responsibilities subtraction for unstructured representation

4.0

c) Usage of data

3.0p for a meaningful description of relevant usage of data (e.g. requirement and process

change, test change, informing stakeholders)

3.0

2.2 Requirements Documentation –General Remarks • Make sure to look at the definitions very carefully

• There are different kinds of goals

• There are different kinds of requirements

• And more important: goals and requirements are different

2.2b Requirements Documentation – Remarks •  Business Goal: What a hypothetical product owner who does

not know anything about software wants

•  “make the citizens run”

•  Application Goal: What a hypothetical software developer who is forced to develop the system against his will wants

•  “group similar routes”

•  Project Goal: What a hypothetical project manager who does not know much about designing and implementing wants

•  “finish the job on time”

These are my personal guidelines not rules Use them on your own responsibility

2.2b Requirements Documentation – Solutions

Top-level business goals • Taking online orders and deliver the goods immediately by drones • Acquire customers, ensure their satisfaction • Expand to more cities Goals for the DroceryControl application • Provide reliable control over drones for pilots • Provide user-friendly means to order grocery products for customers • Provide backend with statistics for management Goals for the Project • Develop a drone control system • Stay within deadline • Stay within cost limit

[Egli,Gresch,Oliveira]

2.2b Requirements Documentation – Good Example

2.2c Requirements Documentation –General Remarks

•  In this case, Volere is the better choice than IEEE Std 830.

• Prefer using known and tested templates (and probably adapted them) to developing your own custom structure.

2.2d Requirements Documentation – Good Examples

[Frey,Herdt,Hüsler]

2.2d Requirements Documentation – Good Examples

[Mar$,Siemon,Zobrist]

2.2e Requirements Documentation – Remarks

• Most of you wrote the functional requirements correct

• Constraint: Something that you can usually achieve your goals without them (but maybe not with the quality that stakeholders want)

•  “police should confirm mini-events” •  “The vouchers should not be sold or bought”

• Quality attribute: Something which is good to have but you could have reached your goals without it

•  “gathered data should be kept securely and confidentially

These are my personal guidelines not rules Use them on your own responsibility

2.2 Requirements Documentation - Grading Goal: Create a structure for requirements documents, identify top level goals, functional requirements, constraints and quality attributes

Topics

Criteria

Max

a) Characteristics of SRS 2.0p for characteristics 1.0p for reasons

3.0

b) Goals 0.5p per business goal 0.5p per application goal 0.5p per project goal 1.0p for discussion of relationships and conflicts

3.0

c) Draft Structure 2.5p for a complete and reasonable structure (in casu Volere) 2.5p for adequate content description

5.0

d) Functional requirements 4.0p for functional requirements (min. 6); formulated clearly, only one function per requirement; testable, traceable, prioritized 2.0p for two appropriate diagrams

6.0

e) Quality attributes and constraints 3.0p for constraints / attributes (min. 6) 3.0

2.3 Domain Analysis – Class Diagram

A static diagram describing the structure of a system by showing the system’s classes, their attributes, operations (or methods), and the relationships among objects.

Class •  Name •  Attributes •  Operations

Relations •  Association •  Aggregation •  Composition (cannot exist alone) •  Generalization (Inheritance) •  Dependency (uses)

Customer

Reserva-on1..*

1makes

2.3 Domain Analysis – Class Diagram

Reserva-on1..*

1makes

Customer

Reserva-on1..*

1..1

makes

Customer

madeby

Do not mix notations, always either use * or N.

Reserva-on1..*

makes

Customer

= ≠

2.3 Domain Analysis – Class Diagram

Leg2

Person

Engine1

Car

Composition Aggregation

2.3 Domain Analysis – Good Example

[Pelloni/Zumberi/Sivajothi]

GoodCardinali$esLabels

Inheritancerela$onships

2.3 Domain Analysis – Remarks

•  A class diagram is not a context diagram. Do not model individuals, do not model the system itself as class.

•  Make a model of the problem domain, without the solution. Application, data server,... usually do not need to be classes. Think: what classes would you create for your implementation?

•  Some groups did not define any attributes and methods (ok, since we did not explicitly ask)

•  Some groups did not define labels and cardinalities (not ok, they belong to class diagram)

•  Conform to standard, don’t mix notations

2.3 Domain Analysis - Grading

Goal: Document domain analysis in a correct class diagram.

Topics

Points given

Max

Classes &

Associations

5p for classes 2.5p for associations 2.5p for association cardinalities -0.5 for minor mistakes, -1.0 for bigger problems 50% if it is “depicting a context diagram”

10

2.4 Scenario Analysis

Describing scenarios and learning about different ways of representing them.

•  Natural Language – Not too much, not too little

•  Activity Diagram – Flow and decisions

•  Sequence Diagram – The interaction between objects

2.4 Scenario Analysis: Structured Language – Good Example

[Rüegg/Weiss/Wildhaber]

USECASEShipmentToCustomerActors:pilot,customerPrecondi$ons:[...]Dronesareequippedwithhigh-resolu-oncamerasandGPSreceivers.[...]

NormalFlow:1.Dronestarts.2.Systemassignsthestatus“indelivery”tothecorrespondingorder(s).3.Customercantracktheprogressofhis/herorder..4.Duringthewholeflightsensorswithinthetransportboxesmonitorthetemperature,thedronesendsimageryandposi-oninreal--metothesystem,thesystemcheckscon-nuouslywhetherthedroneiss-llwithinthedefinedregionoftheopera-onandmonitorscon-nuouslythebaUerystatusofthedrone.5.Thedronewiththeordereventuallyarrivesatthecustomerscoordinates..[...]

Alterna$veflows:4aIfthedroneisoutofrangeofitsdefinedregion,thesystemissuesawarningtothepilot.Ifthepilotreceivesthiswarning,he/shetakescontrolovertheassigneddronewithin3minutes….4bIfbaUerydropsbelow10%thesystemissuesawarningcontainingtheloca-onandroutetothenextchargingsta-ontothepilotwhothentakescontrolovertheassigneddronemanually

[...]

If/elsearemodeledasalterna$veflows

Onestep/ac$onpernumber

2.4 Scenario Analysis: Activity Diagrams – Good Example

Decisions

Swimlanes

[Pelloni/Zumberi/Sivajothi]

Mergenodes

Verbs,ac$veform

[Pelloni/Zumberi/Sivajothi]

2.4 Scenario Analysis: Sequence Diagrams – Good Example

Alterna$ves(coulduse“opt”iftheelse-

branchisempty)

Lifelines(onlycometolifewhenreceivingamessage,endwhentheirtaskare

finished.Note:lifelineofthesystemgoesonun$ltheveryend)

(amessagecomingfromoutsideshouldtriggerthestartofthesequence)

[Rüegg/Weiss/Wildhaber]

[Meuli/Schweizer/Wi_wer]

FeedbackMessages

2.4 Scenario Analysis: Method Assessment – Good Example

Straighttothepoint(alsomakesiteasytopresentJ)

[Egli,Gresch,Oliveira]

2.4 Scenario Analysis: Method Assessment – Good Example

[Mar$/Siemon/Zobrist]

2.4 Scenario Analysis – Remarks

Structured natural language:

•  Don’t put too much in a single step •  Don’t write if/else in a step: that’s what alternative flows are for •  A step can link to the number of another step, for loops or breaks

Activity diagrams:

•  Use swim lanes for different actors •  Activities: formulations with verb and active form

(not: “receive”, “await answer”...) •  Flows always split and merge (!) with special symbols

(decision nodes, fork/join), and never directly at an activity

2.4 Scenario Analysis – Remarks

Sequence diagrams: •  Show the lifelines of the objects •  Needs entry point! A lifeline cannot come to life by itself •  Don’t forget the return messages

Sequence and activity diagrams: •  Almost no group considered that the packaging staff need to use geodata service to choose a

good order and package •  Many forgot to include a loop for checking the position, temperature and battery multiple times

before reaching the destination (an alternative is to use events)

• Diagrams: make sure that you know the syntax

• Use decision nodes in activity diagrams

• Use ‘alternative’-, ‘optional’- and ‘loop’-fragments in sequence diagrams) to depict alternative scenarios and looping parts

2.4 Scenario Analysis - Grading

Goal: Create scenarios and learn about different ways of representing them.

Topics Points given Max

a) Structured nat. language b) Activity diagrams c) Sequence diagrams d) Assessment

Description with steps and alternatives Correct activity diagrams Correct sequence diagrams Adequate comparison

6 6 6 3

Final Exam

Date and time: Monday, November 6th, 10.00 to 12.00 h

Location:

AFL-F-121 (right behind Bahnhof Oerlikon)

Final Exam Guidelines

Time: 90 minutes, 90 points

Allowed materials: •  One double-sided self-written A4 auxiliary sheet, with handwritten notes. Any auxiliary

sheets which do not conform to these specification will be collected. •  For students, whose native language is not English: a foreign dictionary. This will be

checked by an exam supervisor. •  Only use black/blue pen (no pencil)

Hints: •  Always use the notation introduced in the lecture. •  Don’t forget to bring your student identification card.

Questions