Requirements Engineering Flashcards

1
Q

Definition of a requirement

A

A condition that must be met by a system to satisfy a contract

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

Definition of requirements analysis?

A

the process of studying user needs to arrive at a definition of software requirements

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

Why make a requirements specification?

A

negotiation with customer, consistent design and implementation, preparation of tests, later re-implementations

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

What are the requirements of the requirements specification?

A

correct, complete, relevant, consistent, neutral/abstract, traceable (source of req is clear), testable/objective

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

Describe the pitfall of vagueness v. abstraction in requirements engineering?

A

Requirements specification should always be as precise as possible, but does not give exactly one solution.

  1. vague (not precise): list should be sorted logically
  2. precise (abstract): list of participants should be sorted by immatriculation number, lowest first
  3. precise (non-abstract): list should be sorted by public static void Collections::sort( List list, Comparator c );
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is the difference between requirements and design?

A
requirements = what is to be done,
design = how are things to be done
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Kinds of Requirements: Functional vs. Non-Functional

A

View software as a function that maps sequences of inputs to sequences of outputs. Functional req = every constraint on things which are observable in the sequences. Non-functional = programming language, coding conventions, etc

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

Kinds of Requirements: Hard vs. Soft Requirements

A

Flexibility of requirements. Example of hard: cashing a check must increase balance by exactly the amount of the check. Example of soft: vending machine must dispense item “quickly”. Difficult to make req hard.

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

Kinds of Requirements: Open vs. Tacit

A

open = customer is aware of and able to explicitly communicate the requirement, tacit = customer not aware of something being a requirement (obvious to the customer
but not considered relevant by the customer, not known to be relevant). Example: buttons and screen of a mobile phone
should be on the same side

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

What are the tasks of an analyst?

A

ask what is wanted, ask what is NOT wanted, establish precision, look for contradictions, anticipate exceptions/difficulties, understand technical difficulties, communicate formal specification to customer

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

What are requirements documents?

A

dictionary, specification

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

What is a dictionary?

A

A dictionary comprises definitions and clarifications of terms that are relevant to the project and of
which different people (in particular customer and developer) may have different understandings before
agreeing on the dictionary

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

What are some things to include in a dictionary entry?

A

meaning, synonyms, where NOT to use the term, validness in time/space

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

What is the definition of a requirements specification?

A

a document that specifies in a complete, precise, verifiable manner, the functions, performance, design constraints, and attributes of the software and its external interfaces

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

What is the definition of a requirements specification language?

A

A specification language (combination of formal and natural language) with special constructs
and, sometimes, verification protocols, used to develop, analyze, and document hardware
or software requirements.

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

What should analysts focus on when they use natural language in requirements specifications?

A

Make the language as complete and precise as possible (ex. use active not passive voice, use full verbs: NOT “when data is consistent”, but “after program P has checked the consistency”)

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

What are natural language patterns?

A

Sentence structure should follow a certain pattern. Example: After office hours (=A), the system (=C) should (=B) offer to the operator (=D) a backup (=F) of all new registrations to an external medium (=E)

18
Q

Why use decision tables?

A

OBJECTIVE/COMPLETE (hopefully)/CONSISTENT

19
Q

Define decision table completness?

A

A decision table T is called complete iff the disjunction of all rules’ premises is a tautology: OR F_pre(r) is always true

20
Q

What does it mean if a decision table is formally incomplete? formally complete?

A
  1. formally incomplete: there is a case not yet discussed with the customer
  2. formally complete (whether or not is decidable – SAT): if there are no misunderstandings, then all cases were discussed
21
Q

Definition of uselessness for a decision table?

A

A rule r is called useless (redundant) iff there is another different rule r’, whose premise is implied by the one of r and whose effect is the same as r’s (r is called subsumed by r’)

22
Q

Definition of deterministic for a decision table?

A

A decision table T is called deterministic iff the premises of all rules are pairwise disjoint (for all r1 neq r2 : NOT (F_pre(r1) AND F_pre(r2)))

23
Q

Define relative completeness (completeness wrt. conflict axiom)

A

When decision table does NOT contain all cases (formally incomplete), BUT the cases that are not included will never occur (requires domain knowledge). Disjunction of conflict axiom and all premises is a tautology. Ex: on and off are opposites so (on AND off) is never true

24
Q

What is the purpose of a conflict axiom?

A

A conflict axiom over conditions C is a propositional formula over C. A conflict axiom characterises those cases that will never occur according to the domain knowledge. Written under the decision table.

25
Q

What is a vacuous rule?

A

A rule r is called vacuous wrt. conflict axiom iff the premise of r implies the conflict axiom.

26
Q

Symbol for conflict relation?

A

lightning bolt

27
Q

Definition of consistent for decision table?

A

Rule r is called consistent with conflict relation iff there are no conflicting actions in its effect. A table T is called consistent with [conflict action] iff all rules are consistent with [conflict action] (including after collecting semantics)

28
Q

What does collecting semantics mean?

A

F_coll(T): all actions of all enabled rules given system state (ex. whenever button is pressed, let it blink and start ventilation)

29
Q

Notation for software (S) satisfies software specification (fancy S)?

A

S |= fancy S (slash through |= means does not satisfy)

30
Q

What is the formal definition of software?

A

Software is a finite description S of a (possibly infinite)
set [| S |] of (finite or infinite) computation paths of the form sigma –> sigma –> … (alpha over the arrow). sigma = state, alpha = action. The function [| |]: S |—> [| S |] is called an interpretation of S (intuitively: [| S |] is behavior of S).

31
Q

What is the formal definition of a software specification:

A
A software specification is a finite description S
of a (possibly infinite) set [| fancy S |] of softwares, ie 
[| fancy S |] = {(S1, [| |]1), (S2, [| |]2), ...}. The (possibly partial) function [| |]: fancy S --> [| fancy S |].
32
Q

Formal definition of software satisfying a specification?

A

Software (S,[| |]) satisfies a software specification fancy S, iff (S,[| |]) IN [| fancy S |]

33
Q

Give example of software specification and software.

A

Software specification fancy S = decision table.
Define (S,[| |]) IN [| fancy S |] (S satisfies specification) iff every state satisfies a rule in the decision table. Behavior of S is set of computation paths. ex. {b –> 0, off –> 0} –> (push button) {b–>0, off –> 1} –> …

34
Q

What are the “words” in a Symbolic Büchi Automaten when applied to software?

A

Büchi Automaten = specification

words = computation paths of software

35
Q

Difference between “acceptance” definition (of a word) of finite v. infinite words in TBA?

A

Finite word: accepted if there exists the corresponding edges and it ends in a fair/accepting state.

Infinite word: accepted if there exists the corresponding edges and it visits a fair/accepting state infinitely many times.

36
Q

When is a non-deterministic Symbolic Büchi Automaten satisfied?

A

When there exists a way for the word to satisfy the TBA

37
Q

What is the formal definition of a symbolic Büchi Automaton (TBA)?

A

a tuple: (C, Q, q_ini, –>, Q_F) where
C = set of atomic propositions, Q = finite set of states, q_ini = initial state, –> = transition relation between states, Q_F = set of fair or accepting states)

38
Q

Definition of “run” over Büchi Automaten?

A

Infinite sequence of states is called “run” iff first state = q_ini and for each state, there is a transition st that the state satisifies the transition

39
Q

What is the “language” of a Büchi Automaten?

A

set of accepted words

40
Q

Describe general uses of “use cases,” “LSCs”

when speaking with customer

A
  1. example usages given by customer – positive use-cases, existential LSC
  2. things that must NOT happen – negative use cases, LSC’s with pre-chart and hot false
  3. ask for pre conditions, exceptions, corner cases – extend use cases, add conditions/local invariants to LSC
  4. generalize into universal LSCs
41
Q

List all methods for representing requirements

A

natural language, decision tables, user stories, use cases, live sequence charts

42
Q

Advantages of formal representations over informal/semi-formal?

A

precise, can be analyzed for completeness/consistency, can be verified against design description