Requirements Engineering

Question 1

Requirement Elicitation

What techniques can you use for requirement elicitation?

Answer 1

• Interviews
• Workshops
• Observations
• Surveys
• Prototyping
• Document analysis
• Scenario analysis

Question 2

Requirements Framework

What does the requirements engineering framework include:

Answer 2

• Elicitation
• Analysis
• Documentation
• Validation
• Management

Question 3

Requirement Elicitation

What are the two knowledge types?

Answer 3

• Tacit
  knowledge, skills, and abilities gained through experience
• Explicit
  knowledge that can be easily expressed, documented, and shared between people

Question 4

Requirement Elicitation

What insight can tacit knowledge bring?

Answer 4

• Norms
• Culture
• Back story
• Organisation history
• Community of practice

Question 5

Requirement Elicitation

What are examples of explicit knowledge?

Answer 5

• Procedures
• Style guides
• Processes
• Organisation structure
• Manuals
• Organisation guidance

Question 6

Requirement Elicitatiaon

What is the difference between requirement elicitation and requirement analysis?

Answer 6

Elicitation is around collecting information and data, documenting and understanding business needs, process, assumptions and risks

Analysis refines the requirements to ensure that they are clear, complete & represent the business and user needs.

Question 7

Requirements Analysis

What are key activities in requirements analysis?

Answer 7

• aligning with business objectives/case
• aligning with quality measures
• feasible
• prioritised
• correctly structured
• has handled duplicate requirements
• collated for delivery
• include prototypes
• includes user analysis

Question 8

Requirements Analysis

Why do we need to check that requirements align with business objectives/case?

Answer 8

Requirements should address a root problem and be in scope

out of scope requirements might sit with other projects

Question 9

Requirements Analysis

What quality attributes should a requirement include?

Answer 9

Requirements should be:
* Clear
* Complete
* Consistent
* Traceable
* Unambigous
* Relevant
* Testable

if it doesnt adhere to these then the wrong thing could be delivered

Question 10

Requirements Analysis

What categories should we be looking at to ensure something is feasible?

Answer 10

• techincally possible
• possible within business
• financially possible

Question 11

Requirement Analysis

How might a requirement be prioritised?

Answer 11

**MOSCOW
**
* Must Have
* Should Have
* Could Have
* Won’t Have

Backlog prioritisation
* Dependancies
* Size / Complexity
* Impact

Question 12

Requirement Analysis

What are the qualities of a well structured requirement?

Answer 12

• Follow a consistent pattern
• Correctly labelled

Linear you might use req catalogue, Agile you might use user stories,

Question 13

Requirement Analysis

How do you handle overlapping / duplicate requirements?

Answer 13

• Remove duplicates
• Merge requirements
• Break down into smaller requirements

Question 14

Requirements Analysis

How can Scenario analysis , prototypes & process maps help with requirement analysis?

Answer 14

• visualise the problem
• identify gaps in requirements

Question 15

Requirements Analysis

What can you use to understand user perspective?

Answer 15

• User/Customer Journeys
• Personas
• Use case diagrams

use case diagrams show who needs to interact with a system

Question 16

Requirement Validation

How might requirements be validated in a linear delivery?

Answer 16

• Quality Checks
• Informal Reviews
• Formal Reviews
• Sign off by SME’s , Owners, Developers, Testers

Question 17

Requirement Validation

How are requirements be signed off in an agile delivery?

Answer 17

• Backlog grooming
• Stories refined (3 amigos etc)
• Accepted

Question 18

Requirement Management

Why is it important to have a well defined set of requirements?

Answer 18

A good set of requirements will support a successful delivery

Question 19

Requirement Management

What are the key elements of requirements management?

Answer 19

• Identification
• Source
• Owner
• Change Control
• Version Control
• Storage
• Traceability

Question 20

Requirement Traceability

What is meant by Vertical Traceability?

Answer 20

Requirements that are traceable from the source to the business objectives

eg. we know the ownership

Question 21

Requirements Traceability

What is meant by Horizontal Traceability?

Answer 21

Traceability from origin to delivery and back.

Question 22

Requirement Change Control

What are the stages of change control?

Answer 22

• Document
• Analyse
• Consult
• Decide
• Implement or Reject

Question 23

Requirements Change Control

What can be the source of a change?

Answer 23

• Change in objectives
• Change in stakeholders
• Change of legislation
• Competitor action
• Change in technology
• Change in priorities
• Users develop better understanding of need

Question 24

Requirements Version Control

What is a baselined version of requirments?

Answer 24

A frozen version of requirements that has been signed off by stakeholders

Question 25

# Requirements Version Control What must be recorded as part of version control?

Answer 25

* Version number * Who has signed it off * every iteration or change but be signed off and assigned a version number

Question 26

# Requirements Version Control Why should old versions of requirements never be thrown away?

Answer 26

* To enable the ability to roll back if needed * To provide context to changes made

Question 27

# Requirement Documentation What is the benefit of linking requirements together?

Answer 27

* It helps to ascertain dependent requirements & cross over * Changes to one requirements might have a knock on effect to another

Question 28

# Requirements Management What are the two types of **Business** requirement?

Answer 28

* General * Technical | These are at the enterprise/business level

Question 29

# Requirement Management What are the two types of **Solution** requirement?

Answer 29

* Functional * Non-Functional | These are at the product level

Question 30

# Requirement Management What type of requirement would be classed as a **general** requirement? | as a type of business requirement

Answer 30

* **Business constraints** *budget, timescales, resources* * **Business policies** *Standards, business rules* * **Legal** *Legislative and regulatory constraints* * **Branding** *Image, style guide* * **Cultural** *Vision, approach, management style* * **Language** *If operating across international boundarys*

Question 31

# Requirements Management What type of requirement would be classed as a **Technical** requirement? | as a type of business requirement

Answer 31

* **Hardware** *IT and other hardware* * **Software** *Operatinve systems, package applications, networking , communications* * **Interoperability** *Standards for communicating between systems and devices* * **Internet** *Policies on internet user and web services*

Question 32

# Requirements Management What does a functional requirement represent? | as a type of solution requirement

Answer 32

What we want the solution to do. * **Data Entry** *Changes to data including deletion* **Procedural** *Implementation of business rule* * **Retrieval Requirements** * **Reporting, responding to enquiries** * **CRUD** | The system shall - As a User

Question 33

# Requirements Management What does a non-functional requirement represent? | as a type of solution requirement

Answer 33

How we want the solution to behave * Performance * Security * Access * Backup and Recover * Archiving & Retentional * Robustness * Business Continuity * Availability * Usability * Capacity * Accessibility

Question 34

# Requirements Management What **legislation** do you have to consider when compiling requirements?

Answer 34

* Data Protection * Disability Access | GDPR, W3C AA

Question 35

# Requirements Documentation What should be recorded in a requirements document?

Answer 35

* ID/Reference Number * Name * Description * Owner * Acceptance Criteria * Priority * Linked Business Rules * Traceability * Status * Date * Signed off by

Question 36

# Requirements Documentation What is the purpose of a **User Story**?

Answer 36

A user story provides information on The action/outcome that a user needs to acomplish and why. It ensure thats that the requirement addresses the users why and not the how.

Question 37

# Requirements Documentation What format does a **User Story** take?

Answer 37

**Gherkin Model: ** **AS a** business analyst **I Need/Want** good reading materials **So that** I can pass my exam

Question 38

# Requirements Documentation What information do you display in a **Use Case** diagram?

Answer 38

A use case diagram helps to understand the scope of a system - it displays: * the system * the action within the system * the actors / other systems that interact with the activity within the system * the association with other actions * NFR's that can be linked to each action

Question 39

What is included in a data model?

Answer 39

* entity - *it's name* * attributes - *it's data items* * relationships - *1to1 etc*

Question 40

# Requirement Documentation What us the purpose of a process map?

Answer 40

A process map outlines: * the high to low level process * the inputs and the outputs * the actors / teams / systems / data involved

Question 41

How can process maps, use case diagrams and data models, user story's be used together?

Answer 41

Using a combination of different models can highlight gaps that have not been considered

Question 42

What is the purpose of a prototype?

Answer 42

A high/low fidelity model can show how the solution **COULD** work. Benefits: * Easily to visualise & spot gaps Risk: * When sharing people can be fixated on the wrong thing * Difficult to throw away if spent a long time on them

Question 43

# Documenting Requirements What does a decision table do?

Answer 43

A decision table, or other cross referencing tools can help to spot gaps and ensure all requirements have been accounted for. EG. CRUD