Part I - Requirements Engineering Flashcards

1
Q

Define software engineering

A

Responsible application of theories of software development, to provide cost effective construction of software systems, that provides value to users

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

What is software?

A

Anything in a computing system that is of value to stakeholders

Stakeholders include:
- users
- customer
- developers
- regulators
- etc

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

What are attributes that determine software quality?

A

Fitness for use
Correctness - does it contain faults
Reliability - how likely is it to fail
Performance - is it fast enough/how much space does it use
Maintainability - how easy is it to do maintenance in the future
Modifiability - how easy is it to change
Availability - how likely is it to be around when the user wants it
Reusability - how easy is it to reuse in different systems
Usability - how painful is it to use

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

What is quality assurance?

A

Making sure the process of developing software has good quality (fitness for purpose)

Making sure the product has good quality

ie making sure the client is satisfied with the result such that it is fit for their purpose and the product is made to a high standard

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

What are the stages of software development?

A

Requirements
Specification
Architecture
Detailed Design
Implementation
Testing
Deployment
Operation
Maintenance
Retirement

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

What is meant by the requirements stage?

A

Determine what the system should be (functional and non-functional requirements)

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

What is meant by the specification stage?

A

Describe the requirements precisely

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

What is meant by the architecture stage?

A

Make high-level decisions about design

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

What is meant by the detailed design stage?

A

Make low-level decisions about design

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

What is meant by the implmentation stage?

A

Create an executable system based on the requirements

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

What are the two examples of common software development processes?

A

Waterfall - idealised view of software development based on lifecycle (take in stages)

Agile - plan to react to change, takes iteration to the extreme

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

Describe the features of waterfall as a development process

A

Project is divided into sequential phases
Backtracking and change are discouraged
Focus on planning, scheduling ahead and following a budget
Fixed contract in the beginning on something that will be delivered in a set timeframe

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

Describe the features of agile as a development process

A

Flexible, iterative development
Short iterations called sprints are used for software development
Work is planned at the start of each sprint
Allows changing goals

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

What is requirements engineering?

A

An iterative process used to accurately determine the requirements of the product that is to be built

Follows an iterative process which includes 4 stages:
Elicitation
Analysis
Specification
Validationh

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

What are the two types of requirements?

A

Functional - things the product must do
e.g. the app should tell the time
Non-functional - qualities the product must have (Quality attributes)
e.g. the app should load in 3 seconds of the user’s request

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

What are quality attributes?

A

Non-functional requirements that a software product must have

Different to functional attributes which outline what the product should do

e.g.
Performance
Accuracy and Precision
Modifiability
Portability
Reliability
Availability
Security
Legal
etc

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

What are common problems that arise during requirements engineering?

A

Ambiguity - diverse interpretation of the same requirement

Change - clients make changes to what they require as the development is happening

Terminology - use of jargon can lead to different interpretations between clients and developers

Different perspectives - differences in how the stakeholders understand the requirement

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

What is the what vs how tension?

A

It is the idea that during requirements engineering, a requirement should describe what needs to be solved rather than how it needs to be solved ie should not describe the solution

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

Why is it important that a requirement does not describe the solution to a problem?

A

Closes doors to other, potentially better possibilities

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

What are the two domains of requirements engineering?

A

Application domain -> the world in which the problem exists (contains the domain properties and requirements)

Machine domain -> the world in which software solutions are developed (contains the computers and programs)

For good requirements engineering, these two domains must be separated. The problem that needs to be solved should come from application domain and the how should be implemented into the machine domain

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

When do you solve the problem?

A

There are various ways to define requirements

e.g. Just-in-time RE is a method in which it is only defined when needed and only at the detail required.

A good balance between a method like this and strategic, in advance RE is useful

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

Describe the elicitation stage of RE

A

The actions that are taken to understand the users and discover their needs
e.g. interviews, questionnaires, document analysis

Iterative process as participants will not think of everything up front (thinking will change during the project)

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

Describe the features of questionnaires as an elicitation activity

A

Good for answering specific questions

Can receive quantitative and qualitative data

Can reach many people easily (not a lot of resources required)

Design is crucial, response rate may be low, responses might not be what you want

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

Describe the features of interviews as an elicitation activity

A

Good for exploring issues

Mostly qualitative data

Interview can adjust questions as it occurs encouraging contact between developers and users

Time consuming, artifical environment, may intimidate interviewee

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

Describe the features of focus groups and workshops as an elicitation activity

A

Good for collecting multiple viewpoints

Mostly qualitative data

Highlights areas of consensus and conflict, encourages customer developer interaction

Possibility of dominant characters

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

Describe the features of naturalistic observation as an elicitation activity

A

Good for understanding context of user activity

Qualitative data

Observing actual work gives insight that other techniques cannot give

Very time consuming

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

Describe the features of studying documentation as an elicitation activity

A

Good for learning about procedures, regulations, and standards

Quantitative data

No time commitment from users are required

28
Q

What is CrowdRE?

A

A new elicitation technique in which user feedback is received through online posts, app stores, social media and forums

Problem is that it is only for after your product is released

29
Q

What is market research?

A

Looking at what existing products are doing well and not well

Can also refer to crowdRE on already existing products

30
Q

What are features of good questions?

A

Context-free -> do not imply an answer
Open-ended -> more than yes/no response
Avoid biased terms or terms that lead you towards a specific answer

31
Q

What is SRS?

A

Software requirements specification -> a specification for a particular software product, program or set of programs that performs certain functions in a specific environment. SRS may be written by developer or customer or both (DOCUMENTATION)

Should include the following:
Functionality - what is software meant to do?
External interfaces - how does the software interact with people, hardware and other software?
Performance - what is the speed, availability, response time, recovery time of various software functions
Attributes - what are the portability, correctness, maintainability, security considerations

32
Q

What are the characteristics that determine the quality of SRS?

A

Unambiguous
Modifiable
Complete
Traceable
Verifiable
Ranked for importance
Consistent
Correct

33
Q

What is a user story?

A

As a <role?
I want to do <do>
So that <rationale></rationale></do>

Documents a user need - suited for agile development

34
Q

What are characteristics of good user stores?

A

INVEST

Independent - do not have dependence between stories
Negotiable - can be changed, open to discussion
Valuable - adds value to users or customers (meets a need)
Estimable - enough detail for dev team to estimate the size
Small - can be developed in a sprint
Testable - story is clear enough to assess if the story is done

35
Q

What is the difference between SRS and User stores?

A

Both are specification methods

SRS:
- encourages upfront requirement work
- can be used as a contract
- many details

User stories:
- describe user needs
- small size easy to plan
- encourage deferring detail
- good for iterative development

36
Q

What is a story map?

A

Select high level activities a user will perform when using product
e.g. select movie, buy movie, watch movie

Add user stories that support each high level activity and rank them in order of priority

37
Q

What is an acceptance criteria?

A

Defines the boundaries of a user story

Used to confirm when a story is completed and working as intended

Forms the tests that will confirm the system addresses the user needs

38
Q

What are two forms of acceptance criteria?

A

Checklists

“Given, when, then” structure

39
Q

What is the Given, when, then structure?

A

Can be used as acceptance criteria for user stories

Given <some>
When <some>
Then <a></a></some></some>

40
Q

What is MoSCoW?

A

Key that can be used with story maps to rank order of importance

Must have -> has to be satisfied or final solution to be acceptable

Should have -> high-priority requirement that should be included if possible, within the delivery time frame

Could have -> desirable requirement but the solution will still be accepted without it

Would have -> stakeholders want to have, but have agreed not to implement in current version (next round postpone)

41
Q

What are the common user story problems?

A

Conflate problems with solutions
Misplaced requirements and missing rationale
Ultra-huge story
Technical User story
Poorly defined user roles
Parakeet value

42
Q

What is conflate problems with solutions?

A

Common user story problem where too much detail is provided such that devs are locked into a specific implementation

e.g. i want to tell the time using a clock that is present in the menu bar

43
Q

What is misplaced requirements?

A

The so that section of the user story should describe the rationale, not additional requirements

e.g. I want to withdraw cash from the ATM so that I can check the balance from the ATM after

44
Q

What is the Odyssey?

A

Term used for ultra-huge stories in which the requirements that it tells you are too broad - lots of “ands” or “ors”

Should be broken down into multiple stories

45
Q

What are technical user stories?

A

Stories in which the so that part is a technical capability, not any value to end user

46
Q

What are poorly defined user roles?

A

Roles are too vague or too specific

Roles should be categorised into groups of people that have similar purposes

e.g. As a user
As a marketing advisor/As a marketing director

47
Q

What is parakeet value?

A

When the so that phrase is a restatement of the I want phrase -> the so that should provide the rationale for what they want to do (tell you how does the requirement add value)

e.g. As a student, I want to redo my flashcards so that I can study them over and over again

48
Q

What does the analysis stage of RE involve?

A

Clarify and refine requirements
Begin to prioritise requirements
Evaluate technical feasibility and risk

49
Q

What is the minimum viable product?

A

Minimum functionality to be useful
Minimum features to solve core problem
Enables early feedback, and quick to market

50
Q

What is the minimum lovable product

A

Minimum functionality to be loveable - goes a step further than the minimum viable product by focusing on elements other than functionality.

51
Q

What does the validation stage of RE involve?

A

Review requirements (users, developers, testers)

Review requirement models

Write/review acceptance criteria)

52
Q

What is requirements modelling?

A

When a description of the story is too complex for natural language and the business cannot afford to have the specification misunderstood, the team should augment the story with a more precise specification method

53
Q

What are requirement modelling techniques?

A

Flowcharts
Truth Tables
Structured English
UI Mock-up

54
Q

What is requirements management and why do we need it?

A

Managing requirements that have already formed:
- Scope
- Change
- Traceability
- Stakeholders

55
Q

What is agile scope management? How is it different to traditional scope management

A

Agile scope management:
- slightly less important in agile that traditional development
- you only choose a small subset of the requirements to do in each iteration

Traditional:
- write a contract upfront with all the requirements
- final product must include all requirements

56
Q

What is traceability?

A

Ability to link requirements throughout the project lifecycle - ensures every requirement is addressed, documented and verifiable

Backwards:
- source (who requested the requirement)
- rationale (what is the business goal)

Forwards:
- design
- code
- tests

57
Q

What are prioritisation techniques that can be used in requirements management?

A

Top Ten - Very coarse, very easy
Numerical - Coarse, very easy
MoSCoW - Coarse, very easy
Ranking - Medium, Easy
Cumulative voting - Fine, complex

58
Q

What is optimism bias?

A

Humans tend to believe good things will happen in the future - this can be a problem when estimating how long a task would take

59
Q

What is anchoring bias?

A

Bias that forms due to the wording of a question e.g. is the height of the tallest redwood tree more or less than 55 metres?

60
Q

What are the qualities of a good estimation?

A

Relative
Collaborative
Fast

61
Q

What is the agile manifesto?

A

A public declaration which describes Agile’s values and principles

We have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

62
Q

What is planning poker estimation?

A

Each member gives an independent estimate on one user story at a time

Lowest and highest people describe why they gave that estimate

Repeat until you come to a consensus

63
Q

What are the principles behind agile manifesto?

A

Highest priority is to satisfy the customer, through early, and continuous delivery of valuable software

Welcoming changing requirements

Delivery working software frequently

Build projects around motivated individuals

Working software is the primary measure of progress

64
Q

What is scrum?

A

Scrum requires a scrum master to foster an environment where:

  1. A product owner orders work into a product backlog
  2. The scrum team turns a selection of the work into an increment of value during a sprint
  3. The scrum team and its stakeholders inspect the results and adjust for the next spring
65
Q

What are the scrum pillars?

A

Transparency -> work is visible to all involved

Inspection -> progress is inspected often

Adaption -> applying adjustments when aspects are unacceptable

66
Q

What are the roles of scrum?

A

Developers -> contribute to the Sprint’s increment (selection of work from product backlog)

Product Owner -> presents needs of the product’s stakeholders (responsible for managing the product backlog)

Scrum master -> responsible for implementing scrum