Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

ASY IREB > 3. Work products and documentation practices > Flashcards

3. Work products and documentation practices Flashcards

1
Q

Work product (Artifact)

A

a recorded intermediate or final result generated in a work process

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Characteristics of work products

A
  1. purpose
  2. size
  3. representation
  4. lifespan
  5. storage
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Representation of requirements

A
  1. natural language
  2. templates
  3. models
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Overview of RE work products

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Categories of Work Products w.r.t. lifespan

A
  1. temporary
  2. evolving
  3. durable
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Temporary requirements

A

created to support communication and create shared understanding.

discarded after use, no metadata is kept

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Evolving work products

A

emerge in several iterations

metadata shell be kept

change control might be needed

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Durable work products

A

baselined or released

full set of metadata should be kept

strickt change procedure

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Typical levels of abstraction for requirements

A
  1. business
  2. system
  3. component

may co-evolve

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Typical levels of abstraction for requirements depends on

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

do not mix the levels!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

The level of details of the requirements depends on

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

General RE documentation guidelines

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Work product planning

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Why define RE work products at an early stage

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Aspects to be considered

A
  1. aspects within functional requirements
  2. quality requirements (usability, reliability, security, performance)
  3. constraints
  4. context and boundary / domain assumptionsG
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Aspects within functional requirements

A
  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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Performance requirements deal with

A
  1. Time
  2. Volume
  3. Frequency
  4. Throughput
  5. Resource consumption
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Documenting quality requirements

A

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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Quantitative representation of quality requirements suffice in the following situations

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Categories of constraints

A
  1. technical
  2. legal
  3. organisational
  4. cultural
  5. environmental
  6. physical
  7. particular solutions required by stakeholders
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Glossary content

A
  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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Glossary rules

A
  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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Frequently used requirements documents

A
  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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Frequently used documentation structures

A
  1. product backlog
  2. sprint backlog
  3. story map (time & content)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

The choice of documentation structure depends on

A
  1. development process chosen
  2. project type and domain
  3. contract
  4. size of the document
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Prototype

A

A preliminary partial realisation of certain characteristic of a system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Usage of prototypes

A
  1. exploratory prototypes
  2. experimental prototypes
  3. evolutionary prototypes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

exploratory prototypes

A

used to create shared understanding, clarify requirements, validate requirements at different levels of fidelity.

temporary work products discarded after use

specification by example

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Evolutionary prototype

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Types of exploratory prototypes (by degree of fidelity)

A
  1. wireframes
  2. mock-ups
  3. native prototype
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Quality criteria for single requirements

A
  1. adequate !(true and agreed stakeholder needs)
  2. necessary
  3. unambiguous
  4. complete (self contained)
  5. understandable !
  6. verifiable
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Quality criteria for RE work products

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Kano model

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Delighters

A
  1. excitement factors / unconscious

feature the customer is unaware of

if absent, no-one complains, if present - can fe a differentiating feature

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Satisfiers

A

something a customer specifically asks for

the more you put, the more people are happy

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Dissatisfies

A

feature is so obvious, customer can’t imagine it not being part of the system

tacitly considered as must-haves

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Elicitation techniques

A
  1. Gathering techniques
  2. Design and idea generation techniques

Careful: functional requirements are overrated and quality and constraints get less attention

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Selecting the right elicitation technique

A
  1. type of system
  2. software development life cycle model
  3. people involved
  4. organisation setup
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Gathering techniques an be subdivided

A
  1. questioning techniques
  2. collaboration techniques
  3. observation techniques
  4. artefact based techniques
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Questioning techniques

A
  1. interviews
  2. quetionnairs
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Interviews

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Questionnaires

A
  1. larger group of stakeholders
  2. Quantitative questionnaires - confirm hypothesis or previously elicited requirements
  3. 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Collaboration techniques

A
  1. Workshops
  2. Crowd-based requirements engineering
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Observation techniques

A
  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

45
Q

Artifact based techniques

A
  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

46
Q

Workshops

A
  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
47
Q

Crowed based requirements engineering

A
  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
48
Q

Apprenticing

A
  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
49
Q

System archeology

A
  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
50
Q

Feedback analysis

A

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

51
Q

Reuse of requirements

A

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

52
Q

Creativity techniques

A

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

53
Q

Preconditions for creativity

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

Guidelines for brainstorming

A
  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
55
Q

Analogy techniques

A
  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

56
Q

Basic principles of design thinking

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

Divergent thinking

A

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

58
Q

Convergent thinking

A

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

59
Q

General documentation guidelines

A
  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
60
Q

Problems with natural-language-based work products

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

Rules for writing documentation

A
  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
62
Q

Things to avoid in text requirements

A
  1. incomplete descriptions
  2. unspecific nouns
  3. incomplete conditions
  4. incomplete comparisons

Careful
1. passive voice (who is responsible)
2. universal quantifiers
3. nominalisation

63
Q

Types of templates for natural language WPs

A
  1. phrase template
  2. form template
  3. document template
64
Q

Phrase template

A

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

65
Q

Phrase template examples

A
  1. ISO/IEC/IEE 29148 phrase template
  2. EARS template
66
Q

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

A
  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!

67
Q

ISO/IEC/IEE 29148 phrase template

A

<Condition><Subject><Action><object><Restrictions>

When a valid card is sensed the system shell display "enter the pin" message on the dialog screen within 200ms
</Restrictions></object></Action></Subject></Condition>

68
Q

EARS template types of requirements

A

Easy approach to requirements syntax

  1. ubiquitous requirements
  2. event-driven requirements
  3. unwanted behaviour
  4. state-driven requirements
  5. optional features
69
Q

EARS: ubiquitous requirements

A

The <system> shall <system></system></system>

70
Q

EARS: event-driven requirements

A

WHEN <optional> <trigger> the <system> shall <system></system></system></trigger></optional>

71
Q

EARS: unwanted behavior

A

IF <optional> <trigger>, THEN the <system> shall <system></system></system></trigger></optional>

72
Q

EARS: state driven requirements

A

WHILE <in> the <system> shall <system></system></system></in>

73
Q

EARS: optional features

A

WHERE <feature> the <system> shall <system></system></system></feature>

74
Q

Cohn’s user story template

A

As a <role> I want <requirement> so that <benefit></benefit></requirement></role>

NB every user story shell include acceptance criteria

75
Q

Form template

A

A template providing a form with predefined fields to be filled in

Used to structure WPs of medium size (i.e. use cases)

76
Q

Use case template

A
  1. Precondition
  2. Success end condition
  3. Failed end condition
  4. Primary actor
  5. Other actors
  6. Trigger (initiates execution of the use case)
  7. Normal flow
  8. Alternative flows
  9. Extensions (to the normal flow)
  10. Related information
77
Q

Measurable quality requirement template

A
  1. ID
  2. Goal
  3. Scale
  4. Meter
  5. Minimum
  6. OK range
  7. Desired
78
Q

Document template

A

A template providing a predefined skeleton structure of a document

help to systematically structure requirements documents

79
Q

Limitation of the requirements in the natural language

A
  1. ambiguity
  2. confusion
  3. omission of requirements
  4. loose overview if the number of requirements is too big
  5. complexity
  6. abstraction
80
Q

Model

A

An abstract representation of an existing part of reality or a part of reality to be created

A model is made for a specific purpose and a specific context

81
Q

Use case

A

a set of possible interactions between eternal actors and a system that provide a benefit for the actor(s) involved

82
Q

Actor

A

Represents the role performed by another system or persons that interact with the system

83
Q

Requirements model

A

a conceptual model that depicts the requirements for the system to be developed

84
Q

Properties of a model

A
  1. made for a specific purpose
  2. gives a representation of reality
  3. used to reduce information to enable understanding or focus on the part of the reality
85
Q

Descriptive modeling

A

modelling existing original. shows current reality and reflects the requirements that are met

86
Q

Prescriptive modelling

A

modelling an original to be created. what future reality is expected or required

87
Q

How to reduce information

A
  1. compression or aggregation
  2. selection
88
Q

Advantages of models

A
  1. elements and their connections are easier to understand
  2. focus on a single aspect reduces cognitive load
  3. reduced ambiguities and omissions
  4. higher potential of automated analysis and processing of requirements
89
Q

Disadvantages of models

A
  1. keeping different models consistent with each other is hard
  2. integrating information from different models
  3. models focus primarily on functional requirements
  4. not every relevant item of information can be expressed in a model
90
Q

Functional requirements are categorised in the following perspectives:

A
  1. structure and data (static)
  2. function and flow (sequence of actions)
  3. state and behavior (state dependent reactions to event)
91
Q

Benefits of models

A

NB take inventory of goals and context

  1. specifying (primary functional) requirements
  2. decomposing a complex reality into well-defined and complementing aspects
  3. paraphrasing textual representation requirements in order to improve their comprehensibility
  4. validating textually represented requirements with the goal of uncovering omissions, ambiguities and inconsistencies
92
Q

The quality of the model can be assessed against three criteria

A
  1. syntactic quality
  2. semantic quality
  3. pragmatic quality
93
Q

Syntactic quality

A

extend to which a single model element, requirements diagram or requirements model complies with the syntactic specifications (i.e. contains elements that are not parts of the syntax or missused)

94
Q

Semantic quality

A

the extent to which a single model element correctly and completely represents the fact

95
Q

Pragmatic quality

A

the extend to which a single model elements suitable for the intended use - whether the degree of detail and abstraction level is appropriate for the intended use and whether the appropriate model is selected with respect to the domain or context (provided that purpose, context and stakeholders are known)

96
Q

Context model

A

specify the structural embedding of the system in its environment, with its interactions to the users of the system as well as to other new or existing systems within the relevant context.

can reveal sources of requirements. The interfaces need to be defined later

97
Q

Context models are frequently represented by:

A
  1. Data flow diagrams
  2. UML use case diagrams
  3. Tailored box & line diagrams
  4. SysML block definition diagrams
98
Q

Data flow diagram

A
  1. structure analysis of the system => the system is represented by 1 process
  2. rectangle: terminator - sink and source of information / service in the system
  3. Arrows: flow of information, annotated by the information being transferred. no reference to how
99
Q

DFD use case

A
  1. provides insights in the interaction of the system with its environment, e.g. interfaces, objects received, objects / information produced
  2. indicates a clear boundary between the system and its environment - helps to reach a common understanding of the system boundary
100
Q

UML use case diagram elements

A
  1. Actor (user or system) - initiates the use case and receives benefit
  2. Use case - function that delivers benefits to the actor
  3. Association - does not document direction or data flow
  4. System boundary: scope of the system - separation between the actor and the boundary
101
Q

UML use case diagram

A
  1. common approach to model the functional aspect of the system, its boundaries and its interactions
  2. describe functions in the scope from a user perspective
  3. includes use case specifications: preconditions, trigger, actions, postconditions, actors
102
Q

Models for depicting structure and data

A
  1. Entity relationship diagram
  2. UML class diagrams
  3. SysML Block Definition Diagram
103
Q

UML Class Diagram

A

depicts a set of classes and associations between them

104
Q

UML class diagram notation elements

A

1 Class: set of objects that have a similar structure, behavior and relationships
2. Attribute: property of a class, has. type that restricts the values assigned to an attribute
3. Association: relates two classes to each other
4. Multiplicities: how many instances of the class at the corresponding association end can participate in the association to a given instance (0..* = zero or more, 0…1 - zero or one)

105
Q

Modelling function and flow

A
  1. describe how the (sub)system shall transform input into output.
  2. can document from different angles (unlike data) => more than one model might be needed to document the requirements about function and flow
106
Q

Common models for depicting function and flow

A
  1. UML case diagram
  2. UML activity diagram
  3. Data flow diagram
  4. Domain story model
  5. Business process modelling notation
107
Q

UML Activity diagram

A
  1. elements for modelling actions and the control flow between actions
  2. can express who is responsible for what
  3. expresses the control flow of activities of a (sub)system
108
Q

UML Activity diagram: basic notation elements

A
  1. start node: starting point of activity diagram
  2. end node: (can be multiple)
  3. control flow terminator: ends the activity flow
  4. Action/activity: non interruptible action on objects, results in a change in state of the system/result
  5. ## Action or control flow: transitions from one action state to another
  6. decision node: branches depending on a guard
  7. merge node: bring together multiple not concurrent flows
    Synchronization
  8. fork node: split into multiple concurrent calls
  9. join node: joins multiple concurrent flows back
109
Q

Common model to represent behavior and state

A
  1. Statecharts
  2. UML state diagram

ASY IREB (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions