An empirical study in requirements engineering in cross domain - - PowerPoint PPT Presentation

an empirical study in requirements engineering in cross
SMART_READER_LITE
LIVE PREVIEW

An empirical study in requirements engineering in cross domain - - PowerPoint PPT Presentation

An empirical study in requirements engineering in cross domain development Sara Nilsson, Lena Buffoni, Kristian Sandahl, Hanna Johansson, Bilal Tahir Sheikh Accepted for presentation at DESIGN 2018 SIGNAL'18/Kristian Sandahl 2018-05-07 2


slide-1
SLIDE 1

An empirical study in requirements engineering in cross domain development

Sara Nilsson, Lena Buffoni, Kristian Sandahl, Hanna Johansson, Bilal Tahir Sheikh Accepted for presentation at DESIGN 2018

slide-2
SLIDE 2

Challenge: integrated offerings with cross- domain content

2018-05-07 2 SIGNAL'18/Kristian Sandahl

Software Services Hardware

How do companies work with requirements?

slide-3
SLIDE 3

Purpose

2018-05-07 3 SIGNAL'18/Kristian Sandahl

Analyze current internal work with requirements for the purpose of exploring practices with respect to efficiency and effectiveness form the point of view of the developers in the context of four large companies with cross-domain development.

slide-4
SLIDE 4

Method

  • Recorded interviews with eleven, self-selected

subjects in four companies (Johansson, Tahir Sheikh)

  • Analyzing recordings, classification (Buffoni)
  • Discussion and conclusion (Nilsson, Sandahl)
  • Results verified with involved companies

2018-05-07 4 SIGNAL'18/Kristian Sandahl

slide-5
SLIDE 5

Context

Four companies:

  • A has software as the main product, hardware is a

special branch

  • B develops hardware and electronics
  • C develops hardware and services
  • D develops both hardware and software
  • Interviewees were developers or their immediate

supervisors

  • Development cycles 2-5 years

2018-05-07 5 SIGNAL'18/Kristian Sandahl

slide-6
SLIDE 6

Generic Workflow

2018-05-07 6 SIGNAL'18/Kristian Sandahl

Requirements sources Product management product department team Breakdown classification Levels:

slide-7
SLIDE 7

Requirements sources

  • sales and after sales departments
  • senior management that lays out the large-scale goals

and road maps to follow

  • a selected group of customers, customer visits
  • focus or analytic groups that study market trends,

buzz words that are often vague concepts identified by use-cases (e.g Internet of Things)

  • previous products or projects, experience

2018-05-07 7 SIGNAL'18/Kristian Sandahl

Important for hardware

slide-8
SLIDE 8

Requirements classification

  • Component or part of system specific requirements
  • Trust mark or quality level requirements
  • Cross function requirements, involving the whole

system or behavioural requirements

  • User experience requirements, using language such

as comfortable, responsive, faster (than previous product) etc.

  • Performance requirements (number of faults

allowed, lifespan, etc.)

2018-05-07 8 SIGNAL'18/Kristian Sandahl

slide-9
SLIDE 9

Requirements analysis

  • Specifications are never complete, salient knowledge

is assumed to be present

  • Conflicts are detected by cross-functional teams and

negotiated (typically performance vs. cost)

  • Decomposition down to team level
  • Prioritization eats resources, more with larger
  • projects. Company D prioritize to avoid future issues.

2018-05-07 9 SIGNAL'18/Kristian Sandahl

slide-10
SLIDE 10

Standards

  • Internal standards for requirements used.
  • No mention of an external standard
  • Growing interest for standards for product safety
  • “Standards are (too) open for interpretation”

(Company A)

2018-05-07 10 SIGNAL'18/Kristian Sandahl

slide-11
SLIDE 11

Tools

  • Company A and C use PLM tools based on a global

relational database

  • Company D has a textual database
  • Company B use Excel, each department has their
  • wn, but public format
  • DOORS is mentioned by two companies, but deemed

to cumbersome

2018-05-07 11 SIGNAL'18/Kristian Sandahl

slide-12
SLIDE 12

“Traceability can always be improved” (*)

2018-05-07 12 SIGNAL'18/Kristian Sandahl

  • rigin

exact hardware specifications

?

(*) all companies

slide-13
SLIDE 13

Interdisciplinary requirements

you have to consider all the requirem ents all the tim e” (Company C)

com m unication is key for successful cooperation and the people factor is very im portant”(Company A)

2018-05-07 13 SIGNAL'18/Kristian Sandahl

slide-14
SLIDE 14

Interdisciplinary requirements

2018-05-07 14 SIGNAL'18/Kristian Sandahl

Cross-functional teams (A and D) Interdependency tracker (B) Moderators (A) Representatives (D)

Illustrations: openclipart.com

slide-15
SLIDE 15

Interdisciplinary requirements - challenges

  • Have other departments re-prioritize takes time
  • Differences in department size
  • Physical distance
  • Lack of tools for international collaboration
  • Cost of constant organizational review

2018-05-07 15 SIGNAL'18/Kristian Sandahl

slide-16
SLIDE 16

Interdisciplinary requirements

Thinking of other departm ents … a m ore integrated m ind set is som ething that should be aim ed for” (Company D)

2018-05-07 16 SIGNAL'18/Kristian Sandahl

slide-17
SLIDE 17

Verification methods differ

2018-05-07 17 SIGNAL'18/Kristian Sandahl

Verification methods Company: A B C D Comparison to previous versions of the product X NDS NETWORK description specification - use case diagrams, flows, use case realisation documents, classes Data structures X Prototypes X Providing third party suppliers with rigorous testing protocols X Quality test stack - about 10 levels of testing X Root cause analysis for unpredicted issues X Simulation X Test laboratories or centres X X Test rigs X X Test specifications X Tests on actual hardware X X Verification standard for tests unique to each type of product X Virtual verification of the system, up to a year before the release of the product, currently parts still need to be built physically, but the aim is to be fully virtual X

slide-18
SLIDE 18

Some take-aways

  • Processes remarkably similar
  • Human communication is the key practice
  • No formal specification notations
  • Increased focus on safety requirements
  • Problem of combining safety and agile methods
  • Cost-effectiveness of traceability and prioritization
  • Some interest in modelling

2018-05-07 18 SIGNAL'18/Kristian Sandahl

slide-19
SLIDE 19

Conclusion and future work

  • The challenges are similar
  • Efforts in requirements reduce problems later
  • It is possible to identify good practices
  • Practices vary between companies
  • Will continued studies form a more coherent picture

?

2018-05-07 19 SIGNAL'18/Kristian Sandahl

Illustration: Christina Hendricks, CC BY 4.0

slide-20
SLIDE 20

www.liu.se

Welcome

slide-21
SLIDE 21

Workflow company A

2018-05-07 21 SIGNAL'18/Kristian Sandahl

slide-22
SLIDE 22

Workflow company B

2018-05-07 22 SIGNAL'18/Kristian Sandahl

slide-23
SLIDE 23

Workflow company C

2018-05-07 23 SIGNAL'18/Kristian Sandahl

slide-24
SLIDE 24

Workflow company D

2018-05-07 24 SIGNAL'18/Kristian Sandahl