Welcome to ETSN15 Requirements Engineering (Kravhantering)

Welcome to ETSN15 Requirements Engineering (Kravhantering) http://cs.lth.se/krav Lecture 1: Sign-up, Introduction, Requirements in Context Björn Regnell Lectures, Lab Examination Elizabeth Bjarnason Course coordinator, Exercises Johan Linåker Lecture, Project, Lab Daniel Helgesson Project

cs.lth.se theses in Requirements Engineering supervised by Professor Björn Regnell Lic. Eng. Johan Linåker Towards Strategic Support for Requirements Engineering in Open Source Software Ecosystems - What to reveal, when and to whom? Licentiate Thesis, 2016, ISSN: 1652-4691 Dr. Elizabeth Bjarnason Integrated Requirements Engineering Understanding and Bridging Gaps within Software Development Doctoral Dissertation, 2013, ISBN 978-91-7473-732-5 Dr. Krzysztof Wnuk Visualizing, Analyzing and Managing the Scope of Software Releases in Large-Scale Requirements Engineering Doctoral Dissertation, 2012, ISBN 978-91-976939-7-4 Dr. Richard Berntsson Svensson Supporting Release Planning of Quality Requirements: The Quality Performance Model Doctoral Dissertation, 2011, ISBN 978-91-976939-4-3 Dr. Lena Karlsson Requirements Prioritisation and Retrospective Analysis for Release Planning Process Improvement", Doctoral Dissertation 2006 ISSN 1101-3931 Dr. Johan Natt och Dag Managing Natural Language Requirements in Large Scale Software Development, Doctoral Dissertation 2005, ISSN 1101-3931

Requirements Engineering (RE) Kravhantering RE means to... innebär att... dig up, learn, understand, write down, check, prioritize, decide, follow up gräva fram, lära, förstå, skriva ner, kolla, prioritera, besluta om, följa upp... the features of software products... mjukvaruprodukters egenskaper

Upprop Lista skickas runt nu Kryssa om du ska gå kursen Kryssa om du vill vara kursombud I samband med rasten: Skapa grupper Tar ställning till efteranmälda baserat på antalet deltagare

You will soon be working as an engineer

Words from a former RE student I took the requirements engineering course at LTH in 2004, and it was so interesting that I have focused my entire career on requirements and project management. Lessons from the course text book and my experiences from the course project are still with me every day :) Hannes Lindbeck Requirements specialist, Project Manager, Outsourcing specialist at Sogeti

Economic consequences of requirements engineering problems

Uppropslistan? Går uppropslistan runt? (så den inte fastnar...)

Course contents 7,5 credit points Lectures (W1-W4 Tue+Wed, W7: Project Oral Exam) Give overview and structure (not all theory is covered) Guest lecturer: Hampus Jacobsson in W3 Mandatory project examination in W7 5 exercises (W1-5 Thurdays, sign-up today with project group) How to use the theory in the project, prepare for the written exam Sign up for one exercise time slot ideally with your project team! Computer Lab sessions (W2, W4, sign-up lists later) Focus on requirements modelling, preparations mandatory Project (3 credit points ~ 80 h per person, 6-8 persons, sign-up list today) Purpose: to apply theory in practical work Do requirements engineering for an idea from a startup company Written exam on all literature (4,5 credit points) Literature: Lauesen + papers Papers available via login to Moodle, se email for enrollment key Hand in survey after the break Hand-outs: course program + project description+ introduction survey

Examination Project grade (Fail,3,4,5); groups based grade Labs (Fail, Pass); graded in pairs based on preparations and examination at the lab Written exam; individual grade. Total 100p; 50p is required for pass Final grade (Fail,3,4,5); mapped from exam points with limits based on project grade...

Final grade

Inlärningsmål: Kunskapsmål English version in course program 1. definiera grundläggande begrepp och principer inom kravhantering 2. redogöra för ett flertal olika typer av krav 3. redogöra för och värdera ett flertal olika metoder och tekniker för kravhantering 4. beskriva och relatera olika delprocesser inom kravhantering 5. beskriva kravhanteringsprocessens relation till övriga processer i produktlivscykeln 6. redogöra för kravhanteringens relation till marknadsorienterad produktledning 7. diskutera några forskningsresultat inom kravhanteringsområdet

Inlärningsmål: Färdighetsmål English version in course program 1. kunna välja lämplig kravhanteringsteknik för sammanhanget 2. kunna använda flera olika tekniker för att... 2. elicitera (identifiera) 3. specificera 4. validera 5. prioritera... krav

Inlärningsmål: Attitydmål English version in course program 1. medvetet kunna välja arbetssätt efter hur kravbilden ser ut 2. visa prov på ett systematiskt och långsiktigt arbetssätt 3. medvetet kunna problematisera över kravkvalitetens påverkan på slutproduktens kvalitet 4. på ett adekvat sätt kunna involvera användare i kravprocessen 5. medvetet kunna problematisera över kravhanteringens relation till ekonomiska aspekter i produktutveckling

Kursinnehåll 1. 2. 3. 4. 5. 6. 7. 8. 9. English version in course program Krav på olika abstraktionsnivåer och i olika sammanhang Kravhanteringens delprocesser och deras relation Specificering av datakrav, t ex med virtuella fönster och datamodeller Specificering av funktionella krav, t ex med egenskapskrav och uppgiftsbeskrivningar Specificering av olika typer av kvalitetskrav (icke-funktionella krav), t ex användbarhet, prestanda, och tillförlitlighet Olika tekniker för elicitering, t ex fokusgrupper, prototyper Olika tekniker för validering, t ex granskningar Olika tekniker för prioritering, t ex parvisa jämförelser Marknadsorienterad kravhantering, produktledning och prioritering

Project organization Project Mission StartUp acts as your product owner Your Group P3RM (proj mgr) System Requirements SPOC (stakeholder mgr.) Project Supervisor

Project Roles P3RM Project, Process, Prioritization, and Release Manager (1) SPOC Stakeholder and Product Owner Communication (1) TDEVM Tools, Documents, Experiences and Version Manager (1-2) EPM Elicitation and Prototyping Manager (1-2) QRM Quality Requirements Manager (1) DRVM Data Requirements and Validation Manager (1)

Project 6 persons per project group TODAY Sign-up list for project teams during the break defines exercises time slot Read Project Missions from ALL start-up companies DURING Lecture 2 (Tomorrow) Start-up companies will pitch their ideas Each group will choose Project Mission The choice order is randomized. Mandatory oral project exam in last week: W7

Project deadlines Project Mission v1 Iteration 2 Iteration 1 v2 R1 R2 R3 W2 Thu W4 Meeting w Mon supervisor W6 Meeting w Mon supervisor W7 Sun PM W2 Meeting w supervisor Iteration 3 See exact dates in Project Description hand-out and course program: http://cs.lth.se/krav/proj/ http://cs.lth.se/krav/kursplan/

Actions during the brake Sign up on a project team Sign up on exercises (whole team!) Fill in the introductory survey and hand it in after the break UPPROPSLISTA ELIZABETH

Discussion to activate prior knowledge What was realistic or unrealistic with the requirements engineering you did in previous project courses? What different types of requirements did you encounter? Vad var realistiskt eller orealistiskt med den kravhantering ni varit med om i tidigare projekt (tex i PUSS-kursen)? Vilka olika sorters krav stötte ni på?

Intro to the theory part of the course Motivation The role of Requirements Engineering (RE) Basic concepts Different types of RE Different types of requirements (reqs) Reqs at different abstraction levels Lau Motivering Kravhanteringens roll Grundläggande begrepp Olika sorters kravhantering Olika sorters krav Krav på olika abstraktionsnivå Research Papers in pdf accessed after enrollment in Moodle: http://cs.lth.se/krav/moodle

READ THE LITERATURE!!! READ THE TEXT BOOK

GO TO EXERCISES!!! READ THE TEXT BOOK

Basic terminology Lausen: A requirement specification is a document that describes what the system should do. What is what and what is how? Always a document? What is the system? How much about the domain?

Definition enl. IEEE [1990] A requirement is: (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. (3) A documented representation of a condition or capability as in (1) or (2).

What are requirements? Requirements are similar to shopping lists You can't always get what you want... You often want things you don't need...

What is a req? Idé Idé Idea Idea Måste Måste Must Must Önskemål Önskemål Wish Wish Behov Behov Need Need Kvalitet Kvalitet Quality Quality Begränsning Begränsning Constraint Constraint? Dokumenterad Dokumenterad representation representation Documented Documented representation representation ProduktProduktegenskap egenskap Feature Feature Beslut Beslut Decision Decision Funktion Funktion Function Function

Requirements Engineering Important sub-processes: Elicitation to identify the requirements Specification to document the requirements Validation to check the requirements Selection to select the best requirements These processes are interdependent and are best done iteratively, in parallel and continuously. When are we ready?

The Requirements Engineering process is also a... Learning process... Intelligence process... Decision process... Innovation process

Example: MOBILE VENDOR X Where do requirements come from? Who are the stakeholders?

External stakeholders Internal stakeholders Customers Direct customers Operators Global customers Regional customers Other key customers Retailers Indirect customers Consumers Market segments Service providers Content providers Product providers Direct Competitors Mobile phone developers Indirect Competitors Cameras Mobile music players consumer wallet competition Platform providers Operating Systems Technical Platforms Network system providers Standardization bodies Legislation and authorities National International Manufacturing sub-contractors Component providers Marketing Long term branding Customer relations Product management Product planning Roadmapping and portfolios Product development Hardware design Electronics Analog Digital Mechanics Software design User interface Service logic Network access Codecs Platform development Mother, daughters, cluster Global functions Sub-contracting management Technical platforms Operating systems Original Design Manufacturing Technology forecasting Market research Customer Services Support Repair Legal Sourcing Accessories find the right person to talk to get the deep domain knowledge

SW Value chains are getting more and more complex...

Software Ecosystems

Orders of magnitude in Requirements Engineering Abrev. Level Order of magnitude Managing a complete set of interdependencies SSRE Small-Scale Requirements Engineering ~10 reqs requires small effort. MSRE Medium-Scale Requirements Engineering ~ 100 reqs is feasible but requires large effort. LSRE Large-Scale Requirements Engineering ~1000 reqs is practically unfeasible, but feasible among small bundles of requirements. VLSRE Very Large-Scale Requirements Engineering ~10000 reqs among small bundles of requirements is unfeasible in practice.

Dealing with very large sets of requirements Requirements Database Too much Strategic? Profitable? Related? Ambiguous? Group? Complete? Split? Reject? Expensive?

Different contexts and project types In-house Internutveckling för egna behov Product Development Produktutveckling för öppen marknad, t.ex. inbyggda system, generella appar för en marknad (COTS), etc. Time & Materials Utveckling på löpande räkning, rörligt pris Commercial Off-The-Shelf software (COTS) purchase Inköp av generisk (hyll-) programvara Customization Kundspecifik anpassning av generisk programvara Tender Anbudsförfrågan Customer specific: för upphandling av kundspecifik utveckling Generic (COTS): för upphandling av generisk programvara Contract development Kontraktsbaserad utveckling med fast/rörligt pris Sub-contracting Underleverantörskontrakt med fast/rörligt pris Unknown, pre-study Okänd, förstudie för att utreda lämplig projekttyp Hybrid kombinationer av ovanstående...? The context is critical to the requirements engineering!

Fig 1.2 Project types Internutveckling för egna behov (In-house) Produktutveckling för öppen marknad (Product Dev.) Utveckling på löpande räkning (Time&Materials) Inköp av generisk (hyll-)programvara (COTS purchase) Kundspecifik anpassning av generisk programvara Anbudsförfrågan (Tender) Project types Customer In-house User dept. IT dept. Prod. devel. Marketing SW dept. Time & materials Company SW house för upphandling av kundspecifik utveckling för upphandling av generisk programvara COTS purchase Company (Vendor) Tender Company Supplier Contract devel. Company SW house Kontraktsbaserad utveckling med fast/rörligt pris Underleverantörskontrakt med fast/rörligt pris Okänd förstudie för att utreda lämplig projekttyp Hybrider kombinationer av ovanstående Sub-contracting Unknown Supplier SW house Inhouse? COTS? From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Supplier Sammanhanget är avgörande för kravhanteringen!

Mutual relationship customer - supplier Who has the power? Who has the knowledge? Who takes the biggest risk? Wo takes the biggest profit? In the short term? In the long run? Mutual benefit?

Fig 1.1 The role of requirements Stakeholders Demands Elicitation Tacit demands & reqs Analysis Va lid Contract ati o Reqspec n Design Tracing: Forwards... Backwards... Req. management: Changing reqs Ve rif ica tio Program n Test Op & maint From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

Fig 1.3 Contents of ReqSpec User groups Platform: HW, OS, DB Spreadsheet Quality reqs: Performance Usability Maintainability... Ext. products: Sensors, dev. Special SW Other deliverables: Documentation Install, convert, train... Interfaces System Data requirements: System state: Database, comm. states Input/output formats Functional requirements, each interface: Record, compute, transform, transmit Theory: F(input, state) -> (output, state) Function list, pseudocode, activity diagram Screen prototype, support tasks xx to yy From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Managerial reqs: Delivery time Legal Development process... Helping the reader: Business goals Definitions Diagrams...

Requirements versus design Product Architecture REQ REQ REQ A B REQ C D REQ GUI L1 L2 DB Cost? Value? Long-term versus short term? Different types of requirements?

Fig 1.5A Domain and product level Business domain Actors? Domain Platform Product Clients Control computers User activities Domain I/O Product I/O Domain-level req: The product shall support the following user activities:... Elevators Product-level reqs: The product shall accept the following input:... From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

Fig 1.5B Redefined limits Business domain Beware: the word domain is used in many ways Domain Product Control computers Clients User activities Beroende på hur situationen ser ut kan ett nytt system innebära att domängränserna ritas om. Kanske sker en upphandling där styrsystemet ingår i produkten och då blir hissarna aktörer som kommunicerar direkt med systemet. Mycket av affärsutveckling handlar om att skaka om I domängränserna och tex låta användaren göra mer själv. Exempel: COOP Forums shop express. SAS web check-in. From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

Fig 1.6A The goal-design scale R1. Our pre-calculations shall hit within 5% Goal-level requirement R2. Product shall support cost recording and quotation with experience data Domain-level requirement R3. Product shall have recording and retrieval functions for experience data Product-level requirement R4. System shall have screen pictures as shown in app. xx Design-level requirement Mål-nivå bakomliggande syfte, affärsmål, användarnytta, effekt, vinst Domän-nivå sammanhang, omgivning, hur användarna och produkten samverkar för att ge nytta Produkt-nivå externt observerbara funktioner och egenskaper Design-nivå specifik utformning av produktens innehåll Which requirement to choose? From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 If the supplier is A vendor of business applications? A software house - programmers? PriceWaterhouseCoopers?

Functional Requirements Part 1 Summary Context Diagram Hotel system Diagram of product and its surrounding Defining product scope Very useful! booking, checkout, service note,... Account system confirmation, invoice Receptionist Telephone system Guest Event- and function lists Lists of events and functions Domain or product level Good as checklists at verification Validation at product level? Feature requirements Textual requirement: the product shall High expressive power Acceptable to most stakheolders Can lead to false sense of security How to ensure that goal-level covered? Screens and Prototypes Screen pictures + what buttons do Excellent as design-level requirements if carefully tested Not good when for COTS-based systems R1: The product shall support the following business events / user activities / tasks: R1.1 R1.2 R1.3 Guest books Guest checks in R1: The product shall be able to record that a room is occupied for repair in a specified period. R2: The product shall. R3: The product shall.

Fig 3.1 Human-computer - who does what? Domain model: parties joined guest s wishes FindFree Room guest name + chosen room# Rooms Physical model: work split guest s wishes FindFreeRoom period+room type User choice guest name chosen room# From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 free rooms Product Rooms

Fig 3.2 Context diagram R1: The product shall have the following interfaces: Receptionist booking, checkout, service note,... Hotel system confirmation, invoice Account system Telephone system Guest R2??: The reception domain communicates with the surroundings in this way: Receptionist Reception Hotel system Account system Accountant From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Waiter Guest

To do Hand in the introduction survey if not done it already Get the Lauesen text book (e.g. AdLibris, Bokus, ) Read Lauesen Chapter 1 a very important chapter of the book Exercise 1. Bring Lauesen s book!!! (Or team up with a friend who has the book...) Read the project description Meet with your project group and assign project management roles Study all Project Missions from start-up companies Arrive at a consensus in your group about a priority order of all missions You get to choose in random order per project tomorrow You will be assigned a project supervisor tomorrow Book meeting time with your project supervisor for W2, W4, W6