Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Requirements Engineering > Software Development Processes > Flashcards

Software Development Processes Flashcards

1
Q

software engineering

A

Engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use

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

requirements engineering

A

system specification

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

Software Development Processes

A

Set of related activities that lead to the production of a software product

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

main development activities

A
  1. specification → RE
  2. design & implementation
  3. validation
  4. evolution
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

software product

A

generic software systems sold to a variety of users

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

software engineering emerged as a discipline in the

A

1970s

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

Software projects

A

“one-off” systems, with the software system based on a set of software requirements
involve an external client or customer who decides on the functionality of the system and enters into a legal contract with the software development company
The customer’s problem and current processes are used as a basis for creating the software requirements, which specify the software to be implemented

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

customer
reqs
software

A

customer: generates a problem
reqs: implemented by developer
software: helps the customer with the problem

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

Software products

A

no external customer who creates requirements that define what the software must do
The software developer decides on the features of the product, when new releases are to be made available, the platforms on which the software will be implemented, and so on

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

opportunity
features
software

A

developer:
has an opportunity -> inspires features -> implements them -> realises the opportunity

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

Project vs Product based SE

A
  1. Product companies can decide when to change their product or take their product off the market. Custom software developed in a software project usually has a long lifetime and has to be supported throughout that lifetime.
  2. For most products, getting the product to customers quickly is critical. Excellent products often fail because an inferior product reaches the market first and customers buy that product. In practice, buyers are reluctant to change products after they have invested time and money in their initial choice.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Product vision

A

a simple and succinct statement that defines the essence of the product that is being developed

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

The product vision should answer three fundamental questions:

A
  1. What is the product that you propose to develop? What
    makes this product different from competing products?
  2. Who are the target users and customers for the product?
  3. Why should customers buy this product?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

product vision qs

A
  • FOR (target customer)
  • WHO (statement of the need or opportunity)
  • The (PRODUCT NAME) is a product (product category)
  • THAT (key benefit, compelling reason to buy)
  • UNLIKE (primary competitive alternative)
  • OUR PRODUCT (statement of primary differentiation)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Software product management

A

a business activity focusing on the software products that are developed and sold by the business

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

Product managers (PMs)

A

take overall responsibility for the product and are involved in planning, development, and marketing

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

Key components of Software product management

A
  • Product vision management
  • Product roadmap development
  • User story and scenario development
  • Product backlog management
  • Acceptance testing
  • Customer testing
  • User interface design
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Agile methods are incremental development processes with

A
  • frequent releases of the product
  • continuous interaction between dev. team and customer
  • reduced product documentation
  • continuous and systematic assessment of produced value and risks
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Agile in practice

A
  1. you make a list of features/reqs
  2. you estimate
  3. you set priorities
  4. you start executing
  5. you update the plan @run-time
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Scrum

A

A framework for agile project organizations with designated individuals, who act as an interface between the development team and the organization

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

Scrum roles

A

product owner
scrum master
scrum team
stakeholder

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

product owner

A
  • identifies product features and attributes
  • reviews the work and ensures that the development team focuses only on the
    product, rather than on technically appealing tasks
23
Q

scrum master

A
  • guides the team in effective use of scrum
  • Not a conventional project manager, rather a coach having authority
    on how scrum is used in the team
24
Q

scrum team

A

self organizing team responsible for developing the product

25
stakeholder
- customer/end user - in general, anyone directly or indirectly impacted by the product
26
Scrum life cycle
27
Time boxed sprints
- Period of 2-4 weeks - Activities: - Planning - Execution - Review - Benefits: - Demonstrable Progress - Limited rework - Improved planning - Sprints are not extended for unfinished items
28
Self organising teams
- 5–8 people with no project manager - Diverse Effective and informal communication - Decisions are made by mutual consensus. - Involvement of developers with management and customers is limited - Coping with team changes is easy - Communication may be hurdled by: - All team members not working at same physical place - Everyone not being able to attend morning meetings - External interactions - Team focused (Scrum Master) - Product focused (Product Owner)
29
Kanban
30
Requirement
- A need perceived by a stakeholder. - A capability or property that a system shall have. - A documented representation of a need, capability or property.
31
Requirements Specification
A systematically represented collection of requirements, typically for a system or component.
32
“Requirement specifications” in agile projects
- Agile projects frequently do not produce a comprehensive requirements specification - Instead they express requirements in: - user stories, issues, storyboards, acceptance criteria associated with user stories, etc. - a vision document - implicit shared understanding among the people involved
33
Requirements Engineering: the classic notion
The application of a systematic, quantifiable approach to the specification and management of requirements; that is the application of engineering to requirements. - **Metaphor**: upfront engineering - **Goal**: complete, unambiguous requirements prior to design - **Smells**: paper, process - **Reality check**: Does this always work?
34
Requirements Engineering [Customer oriented]
Understanding and documenting the customers’ desires and needs. - **Metaphor**: Customer satisfaction - **Goal**: Understand the customer - **Reality check**: 1.- Why not just code what the customer desires and needs? 2.- Who is “the customer”?
35
Requirements Engineering [Risk-oriented]
Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs. - **Metaphor**: Balancing effort and value - **Goal**: Mitigate risk
36
A synoptic definition of RE
- A systematic approach for the specification and management of requirements with the following goals: - (1) Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards, and managing them systematically, - (2) Understanding and documenting the stakeholders’ desires and needs - (3) Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.
37
Why do RE?
- **Lower cost** - Reduce error cost - Reduce rework cost → Supplier makes profit - **Manage risk** - Meet stakeholders’ desires and needs - Reliable estimates for deadlines and cost → Customer is satisfied
38
Stakeholder
A person or organisation that has a (direct or indirect) influence on the system’s requirements
39
Types of Requirements
a function a behaviour a project requirement a legal constraint a performance attribute a quality attribute
40
a function
The turnstile control software shall count the number of ‘unlock for a single turn’ commands that it issues to the controlled turnstile
41
a behaviour
The operator shall be able to run the system in three modes: normal (turnstile unlocked for one turn when a valid card is sensed), locked (all turnstiles locked), and open (all turnstiles unlocked)
42
a project requirement
The system shall be deployed at most five months after signing the contract.
43
a legal constraint
The system must comply with the privacy law of the country where the resort is located.
44
a performance attribute
The reaction time from sensing a valid card to issuing an ‘unlock for a single turn’ command must be shorter than 0.5 s
45
a quality attribbute
The system shall be highly available
46
constraint or
non-functional requirement
47
classification according to concerns
project <-> process quality req-attribute : performance + specific quality
48
functional requirement
Was this requirement stated because we need to specify some of the system’s behaviour, data, input, or reaction to input stimuli - regardless of the way this is done?
49
performance requirement
Was this requirement stated because we need to specify restrictions about timing, processing or reaction speed, data volume or throughput?
50
requirements in order of application
functional perfromance specific quality constraint
51
specific quality
Was this requirement stated because we need to specify a specific quality that the system or a component shall have?
52
constraint
Was this requirement stated because we need to specify any other restriction about what the system shall do, how it shall do it, or any prescribed solution or solution element?
53
functional reqs
prescribe what services the software-to-be should provide
54
non-functional reqs
constrain how services should be provided

Requirements Engineering (7 decks)

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