Chapter 4(requirements) Flashcards

1
Q

The requirements for a system are …

A

the descriptions of the services that a system should provide and the constraints on its operation.

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

Types of requirement

A

User requirements, System requirements

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

User requirements are?

A

statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate. The user requirements may vary from broad statements of the system features required to detailed, precise descriptions of the system functionality.

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

System requirements are?

A

are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document (sometimes called a functional specification) should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

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

System stakeholders

A

Any person or organization who is affected by the
system in some way and so who has a legitimate interest

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

Stakeholder types

A

End users
System managers
System owners
External stakeholders

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

Agile methods requirements are

A

scenarios/user stories

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

classes of requirements:

A

Functional, non-functional, domain

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

Functional requirements are?

A

Statements of services the system should provide, how the system should react to particular inputs and how the system
should behave in particular situations.
May state what the system should not do.

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

Non-functional requirements are?

A

Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
Often apply to the system as a whole rather than individual features or services

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

Domain requirements are?

A

Constraints on the system from the domain of operation

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

Functional requirements describe and depend on what

A

Describe functionality or system services, depend on the type of software, expected users and the type of system where the software is used

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

requirements should be both

A

complete and consistent

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

what class is more important

A

Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be uselesa

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

Non-functional requirements may affect

A

the overall architecture of a system rather than the individual components

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

Non-functional classifications

A

Product requirements, organisational requirements, external requirements

17
Q

Goal

A

A general intention of the user such as ease of use

18
Q

Verifiable non-functional requirement

A

A statement using some measure that can be objectively tested

19
Q

Usability requirements

A

Requirements elicitation & analysis;
Requirements specification
Requirements validation;

20
Q

Requirements elicitation and analysis is also called

A

requirements elicitation or
requirements discovery.

21
Q

stakeholders are

A

end-users, managers, engineers involved in maintenance, domain experts, trade unions

22
Q

Requirements elicitation is

A

Software engineers work with a range of system
stakeholders to find out about the application domain,
the services that the system should provide, the required
system performance, hardware constraints, other
systems, etc.

23
Q

stages of elictation

A

Requirements discovery,
 Requirements classification and organization,
 Requirements prioritization and negotiation,
 Requirements specification.

24
Q

Problems of requirements elicitation

A

Stakeholders don’t know what they really want.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and political factors may influence the
system requirements.
 The requirements change during the analysis process.
New stakeholders may emerge and the business
environment may change.

25
Q

Types of interview and definition

A

Closed interviews based on pre-determined list of questions
Open interviews where various issues are explored with stakeholders

26
Q

Stories and scenarios

A

Scenarios and user stories are real-life examples of how a system can be used.

27
Q

Requirements specification

A

The process of writing down the user and system requirements in a requirements document for users.
System requirements are more detailed requirements and may include more technical information.

28
Q

Why requirements and design are inseparable

A

requirements should state what the system should do and the design should describe how it does this.

29
Q

Requirements validation

A

Concerned with demonstrating that the requirements
define the system that the customer really wants.
 Requirements error costs are high so validation is very
important

30
Q

Requirements checking

A

 Validity. Does the system provide the functions which
best support the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the
customer included?
 Realism. Can the requirements be implemented given
available budget and technology?
 Verifiability. Can the requirements be checked?

31
Q

Requirements validation techniques

A

Requirements reviews- systematic manual analysis of the requirements.
Prototyping - Using an executable model of the system to check requirements.
Test-case generation - Developing tests for requirements to check testability.