3. Work products and documentation practices

Question 1

Work product (Artifact)

Answer 1

a recorded intermediate or final result generated in a work process

Question 2

Characteristics of work products

Answer 2

1. purpose
2. size
3. representation
4. lifespan
5. storage

Question 3

Representation of requirements

Answer 3

1. natural language
2. templates
3. models

Question 4

Overview of RE work products

Answer 4

Single requirements
1. Individual requirement
2. User story

Coherent sets of requirements
1. Use case
2. Graphic model
3. Task description
4. External interface description
5. Epic
6. Feature

Documents of documentation structures
1. System requirement specification
2. Product and sprint backlog
3. Story map
4. Vision

Other WP
1. Vision
2. Textual note or graphic sketch
3. Prototype

Question 5

Categories of Work Products w.r.t. lifespan

Answer 5

1. temporary
2. evolving
3. durable

Question 6

Temporary requirements

Answer 6

created to support communication and create shared understanding.

discarded after use, no metadata is kept

Question 7

Evolving work products

Answer 7

emerge in several iterations

metadata shell be kept

change control might be needed

Question 8

Durable work products

Answer 8

baselined or released

full set of metadata should be kept

strickt change procedure

Question 9

Typical levels of abstraction for requirements

Answer 9

1. business
2. system
3. component

may co-evolve

Question 10

Typical levels of abstraction for requirements depends on

Answer 10

1. subject to be specified
2. purpose of the specification

do not mix the levels!

Question 11

The level of details of the requirements depends on

Answer 11

1. problem and project context
2. degree of shared understanding of the problem
3. degree of freedom left to designers and programmers
4. ability of rapid stakeholder feedback
5. cost vs value of a detailed specification
6. Standards and regulations

Question 12

General RE documentation guidelines

Answer 12

1. Select a wp type that fits the intended purpose
2. Avoid redundancy by referencing content instead of repeating the same content again
3. Avoid inconsistencies between wp, particularly when they cover different aspects
4. use terms consistently
5. structure was appropriately

Question 13

Work product planning

Answer 13

1. in which wp shall the requirements be recorded and for what purpose
2. which abstraction level to take
3. up to which level of detail to document at each level
4. how shall the requirements be represented in these was

Question 14

Why define RE work products at an early stage

Answer 14

1. Help in the planning of efforts and resources
2. ensures that appropriate notations are used
3. ensures that all results are recorded in the right wps
4. ensures that no major reshuffling of information and final editing is needed
5. helps to avoid redundancy

Question 15

Aspects to be considered

Answer 15

1. aspects within functional requirements
2. quality requirements (usability, reliability, security, performance)
3. constraints
4. context and boundary / domain assumptionsG

Question 16

Aspects within functional requirements

Answer 16

1. Structure and data (requirements concerning static structure of the system and data the system must know)
2. Function and flow (functions that a system shall provide and flow of control)
3. State and behavior (state dependent behavior of a system - how react to external events, depending on the current state)

Question 17

Performance requirements deal with

Answer 17

1. Time
2. Volume
3. Frequency
4. Throughput
5. Resource consumption

Question 18

Documenting quality requirements

Answer 18

Very difficult

1. qualitative representation - hard to validate, ambiguous
2. quantitative representation - measurable, but can be expensive to specify
3. operationalised representations - quality requirement in terms of functional requirements for achieving the desired quality (i.e. no login possible)

Question 19

Quantitative representation of quality requirements suffice in the following situations

Answer 19

1. there is sufficient implicit shared understanding
2. stakeholders, RE and developers agree on a known solution that satisfies the requirements
3. stakeholders only want to give general quality directions and trust the developers to get the detail right
4. short feedback loops are in place and can be detected early
5. able to generalise from examples
6. requirements are not safety critical

Question 20

Categories of constraints

Answer 20

1. technical
2. legal
3. organisational
4. cultural
5. environmental
6. physical
7. particular solutions required by stakeholders

Question 21

Glossary content

Answer 21

1. definitions for all terms that are relevant for the system
2. all abbreviations and acronyms
3. homonyms shell be avoided

helps to establish shared understanding

Question 22

Glossary rules

Answer 22

1. creation and maintenance (centrally over the entire project, one person responsible, stakeholders must agree on terminology)
2. usage: must be mandatory

Standard best practice in RE

Question 23

Frequently used requirements documents

Answer 23

1. stakeholder requirements specification
2. user requirements specification
3. system requirements
4. business requirements
5. vision documents (conceptual imagination of a future system describing its key characteristics and how it creates value to the user)

Question 24

Frequently used documentation structures

Answer 24

1. product backlog
2. sprint backlog
3. story map (time & content)

Question 25

The choice of documentation structure depends on

Answer 25

1. development process chosen 2. project type and domain 3. contract 4. size of the document

Question 26

Prototype

Answer 26

A preliminary partial realisation of certain characteristic of a system

Question 27

Usage of prototypes

Answer 27

1. exploratory prototypes 2. experimental prototypes 3. evolutionary prototypes

Question 28

exploratory prototypes

Answer 28

used to create shared understanding, clarify requirements, validate requirements at different levels of fidelity. temporary work products discarded after use specification by example

Question 29

Evolutionary prototype

Answer 29

pilot systems that form the core of a system to be developed.

Question 30

Types of exploratory prototypes (by degree of fidelity)

Answer 30

1. wireframes 2. mock-ups 3. native prototype

Question 31

Quality criteria for single requirements

Answer 31

1. adequate !(true and agreed stakeholder needs) 2. necessary 3. unambiguous 4. complete (self contained) 5. understandable ! 6. verifiable

Question 32

Quality criteria for RE work products

Answer 32

1. consistent 2. non-redundant 3. complete (all relevant requirement at this point in time) 4. modifiable (without degrading its quality) 5. traceable 6. conformant

Question 33

Kano model

Answer 33

classifies features of a system into categories. looks at requirements from the perspective of the customers 1. Delighters 2. Satisfiers 3. Dissatisfies 4. (old) indifferent 5. (old) hate Q1. What would you feel if the feature was present in the system Q2. What would you feel if the feature was absent? NB all categories can be linked to distinct elicitation techniques

Question 34

Delighters

Answer 34

1. excitement factors / unconscious feature the customer is unaware of if absent, no-one complains, if present - can fe a differentiating feature

Question 35

Satisfiers

Answer 35

something a customer specifically asks for the more you put, the more people are happy

Question 36

Dissatisfies

Answer 36

feature is so obvious, customer can't imagine it not being part of the system tacitly considered as must-haves

Question 37

Elicitation techniques

Answer 37

1. Gathering techniques 2. Design and idea generation techniques Careful: functional requirements are overrated and quality and constraints get less attention

Question 38

Selecting the right elicitation technique

Answer 38

1. type of system 2. software development life cycle model 3. people involved 4. organisation setup

Question 39

Gathering techniques an be subdivided

Answer 39

1. questioning techniques 2. collaboration techniques 3. observation techniques 4. artefact based techniques

Question 40

Questioning techniques

Answer 40

1. interviews 2. quetionnairs

Question 41

Interviews

Answer 41

1. can be used to elicit high level requirements as well as specific ones 2. typically requirements are satisfiers 3. need clear goals and good preparation

Question 42

Questionnaires

Answer 42

1. larger group of stakeholders 2. Quantitative questionnaires - confirm hypothesis or previously elicited requirements 2. Qualitative quetionnaires - open ended questions - find new requirements 4. Often a next step after obtaining a preliminary idea based on a series of interviews in order to validate these ideas with a large group

Question 43

Collaboration techniques

Answer 43

1. Workshops 2. Crowd-based requirements engineering

Question 44

Observation techniques

Answer 44

1. Field observation 2. Apprenticing stakeholders are observed while they are engaged in their normal processing their usual context NB Particularly useful for identifying dissatisfies

Question 45

Artifact based techniques

Answer 45

1. system archeology 2. feedback analysis 3. reuse of requirements do not use stakeholders (directly) but rather work products. NB can find satisfiers and dissatisfiers Very useful if stakeholders are not available

Question 46

Workshops

Answer 46

1. umbrella term for group-oriented techniques 2. a requirements workshop is a structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine and reach a closure on deliverables that represent user requirements 3. yield good global insight in a short time 4. both gathering and creativity technique

Question 47

Crowed based requirements engineering

Answer 47

1. elicitation is a participatory effort with a crowd of stakeholder, in particularly users 2. diversity of talents an expertise 3. need a platform for user engagement

Question 48

Apprenticing

Answer 48

1. the apprentice participates but does not interfere, they act as a novice I the field and are allowed to make mistakes 2. aim - create deeper understanding of the domain, the business and processes

Question 49

System archeology

Answer 49

1. requirements are extracted from existing systems - legacy systems, competitor systems or analogous systems by analysing their documentation or implementation 2. useful if an old system is replaced by the new one 3. can detect many requirements / constraints that would not have been revealed otherwise 4. need to check whether requirements are still valid and relevant

Question 50

Feedback analysis

Answer 50

useful to gain insight into the user's pains and gains negative sources and critical remarks help to detect unnoticed dissatisfies might even contains innovative ideas and be turned into delights

Question 51

Reuse of requirements

Answer 51

many of requirements from old systems can be applicable to new - especially requirements that have been derived from an overarching domain model can save time and money because can skip elicitation only works if the requirements are up-to-date and are managed effectively need to validate whether requirements are valid and relevant in the new situation

Question 52

Creativity techniques

Answer 52

stimulate creativity in order to find or to create new requirements that cannot be gathered directly from the stakeholders because stakeholders are not aware of the feasibility of certain new features or technical innovations stimulate out of the box and borderless thinking and elaboration of each other's ideas

Question 53

Preconditions for creativity

Answer 53

1. chance and time for an idea to come up 2. knowledge of the subject matter 3. motivation 4, safety and security

Question 54

Guidelines for brainstorming

Answer 54

1. defer judgement by separating the finding of ideas from the analysis of ideas 2. quantity prevails over quality 3. free association and visionary thinking are explicitly desired 4. taking on and combining expressed ideas is allowed and desired 5. criticising other participants' ideas is forbidden even if an idea seems absurd 6. after the session, the ideas that have emerged are categorised, assessed and prioritised. Selected ideas then serve as input for further elicitation

Question 55

Analogy techniques

Answer 55

1. success of failure is influenced mainly by the selection of a proper analogy for the given problem Steps 1. elaborate the aspects of the selected analogy in detail without referring to the original problem 2. transfer all identified aspects of the analogy back to the original problem 3. the resulting concepts and ideas will then be a starting point for additional elicitation

Question 56

Basic principles of design thinking

Answer 56

1. empathy (personas, empathy mapping, customer co-creation) 2. creativity: diamond - divergent and convergent thinking

Question 57

Divergent thinking

Answer 57

exploring an issue more widely and deeply - generating lots of different ideas

Question 58

Convergent thinking

Answer 58

focuses, selects, prunes, combines these ideas into a single final delivery

Question 59

General documentation guidelines

Answer 59

1. select the wp type that fits the intended purpose 2. avoid redundancy by referencing content instead of repeating the same content again 3. avoid inconsistencies between WPs, particularly when they cover different aspects 4. use terms consistenty as defined in the glossary 5. structure WPs appropriately, for example by using standard structures

Question 60

Problems with natural-language-based work products

Answer 60

1. not optimised for unambiguous and comprehensive communication 2. spoken - immediate feedback, written - harder detect ambiguities, omissions, inconsistencies

Question 61

Rules for writing documentation

Answer 61

1. write short well structured sentences. one requirement one sentence 2. create well structured work products => hierarchical structures of parts, sections, subsections + document templates 3. use uniform terminology 4. avoid using vague or ambiguous terms and phrases 5. know and avoid pitfalls of technical writing

Question 62

Things to avoid in text requirements

Answer 62

1. incomplete descriptions 2. unspecific nouns 3. incomplete conditions 4. incomplete comparisons Careful 1. passive voice (who is responsible) 2. universal quantifiers 3. nominalisation

Question 63

Types of templates for natural language WPs

Answer 63

1. phrase template 2. form template 3. document template

Question 64

Phrase template

Answer 64

A template for the syntactic structure of a phrase that expresses an individual requirement or a user story in natural language NB using phrase templates is a best practice when writing individual requirements in natural language and writing user stories

Question 65

Phrase template examples

Answer 65

1. ISO/IEC/IEE 29148 phrase template 2. EARS template

Question 66

Auxiliary verbs in the ISO/IEC/IEE 29148 phrase template

Answer 66

1. shall - mandatory requirement 2. should - not mandatory but strongly desirable 3. may - suggestion 4. will / present tense - factual statement that is not considered as a requirement NB make sure there is a common understanding!

Question 67

ISO/IEC/IEE 29148 phrase template

Answer 67