requirements engineering i - uzh ifi371cac4b-ccbd-4a5b-8712-9... · 2017-10-23 · 2.1 further...
TRANSCRIPT
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