Week 1

Question 1

Software Development Cycle Components

Answer 1

1. Requirements
2. Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance

Question 2

Waterfall Method

Answer 2

1. Requirements engineering
2. Specification
3. Design
4. Implementation
   - includes iteration and feedback

Question 3

Validation

Answer 3

ensuring that the right system is being created by checking whether stakeholder expectations are met

Question 4

Verification

Answer 4

ensuring that the system is being built in the right way according to the specified design and development standards

Question 5

Problems with Waterfall Method

Answer 5

• too rigid, no freedom in approach
• may not allow developers to move between various abstraction levels freely
• stakeholder involvement limited to initial requirements gathering phase

Question 6

V-Model

Answer 6

extension of Waterfall method that specifies for each development phase its corresponding testing phase

Requirements Engineering - Acceptance Testing

Specification - Integration Testing

Design - System Testing

Implementation - Unit Testing

Question 7

Acceptance Testing

Answer 7

testing whether the currently created requirements meet stakeholders’ expectations for the products

Question 8

Integration Testing

Answer 8

checks whether the different components in the specification can be integrated easily, and specifies which errors could arise

Question 8

System Testing

Answer 8

tests whether the system design as a whole meets the specified requirements, validating its overall functionality, performance and behaviour

Question 8

Unit Testing

Answer 8

tests each module or component of the implementation independently to ensure its functions are carried out correctly

Question 8

Agile Development

Answer 8

1. Requirements
   Then, loop:
2. Design
3. Develop
4. Test
5. Deploy
6. Review

Prioritises:
- flexibility
- collaboration
- customer feedback

Question 8

Principles of Agile development

Answer 8

1. Individuals, interactions more important than processes, tools.
2. Working software more important than comprehensive documents.
3. Customer collaboration more important than contract negotiation.
4. Responding to change more important than following a plan.

Question 8

Drawbacks of Agile Development

Answer 8

1. Lack of extensive design phase.
2. Lack of energy spent on documentation.

Question 8

Requirement

Answer 8

a statement expressing a need and its associated constraints and conditions

Question 8

Steps of Requirements Engineering

Answer 8

1. Requirements elicitation
2. Requirements specification
3. Requirements verification and validation
4. Requirements management

Question 8

Requirements elicitation

Answer 8

the gathering and identifying of user needs and expectations through interviews, surveys, workshops, etc.

Question 9

Requirements specification

Answer 9

the documentation and definition of clear, concise and unambiguous requirements to serve as the basis for subsequent stages of software development

Question 10

Requirements verification and validation

Answer 10

ensuring that the specified requirements are accurate, complete, consistent, and realisable

Question 11

Requirements management

Answer 11

systematically handling changes to the requirements as the software development process advances

Question 12

Important Elements of Requirements Specification

Answer 12

1. Identification: clear labelling of each requirement for easy distinguishing and tracking
2. Dependencies: documenting interdependencies between different requirements
3. Source(s): specifying the origin or stakholder providing each requirement
4. Rationale: providing the reasoning or justification behind each requirement
5. Priorities: categorising requirements using the MoSCoW method

Question 13

Steps for Requirements Specification

Answer 13

General:

1. Identifying actors and their goals
2. Specifying inputs and outputs of the system
3. Writing requirements

Given informal text:

1. Identifying the system
2. Identifying actors and their goals
   3 Identifying inputs and outputs of the system
3. Going through each sentence, writing down requirements that arise.

Question 14

Properties of Good Requirements

Answer 14

Unambiguous
Consistent
Verifiable
Appropriate
Necessary
Complete
Singular
Feasible
Correct
Conforming

Question 15

Structure of Semi-Informal Requirements

Answer 15

1. Condition (when the requirement is applicable)
2. Subject (the actor carrying out the requirement)
3. Action (the action or verb of the requirement - shall …)
4. Object (the entity that the action is carried on)
5. Constrain of Action (a restriction on the nature of the action, such as a time limit)

Question 16

Requirement No-Go’s:

Answer 16

1. Shall be able to (just say shall do action directly)
2. Negative statements (shall not move the door)
3. Passive voice: (the engine will turned off - no Subject)
4. Superlatives (e.g., best or most)
5. Subjective-language (user friendly, easy to use, cost effective)
6. Vague pronouns (e.g., it, this, that)
7. Ambiguous adverbs and adjectives (e.g., significant, minimal)
8. Open-ended, non-verifiable terms (e.g., provide support, as a minimum, but not limited to)
9. Comparative phrases (e.g., better than, higher quality)
10. Loop holes (e.g., if possible, as appropriate,

Question 17

Use Case Diagram

Answer 17

illustrate the interactions between actors and a system to depict the functionality and behavior of the system from an external user's perspective

Question 18

Main Components of a Use Case Diagram

Answer 18

1. The system being described 2. The actors interacting with the system 3. The use cases (what the actors can do)

Question 19

Use Cases

Answer 19

describe the expected functionality of a system represented by a circle with the use case name inside or below it, or by a rectangle with the use case name inside and an oval in the upper right corner

Question 20

Actors

Answer 20

entities that interact with the system by 1. using use cases (i.e., initiating the execution of use cases) or 2. being used by use cases (i.e., providing functionality for the execution of use cases) represent roles that users can adopt

Question 21

Are actors part of the system?

Answer 21

No, which is why they are also drawn outside the system boundaries

Question 22

Categories of Actors:

Answer 22

1. Human vs Non-human 2. Primary vs Secondary (has primary benefit of execution of use case or receives no direct benefit) 3. Active (initiates use case) or Passive (provides functionality for use case)

Question 23

Detailed Description Structure for Use Cases

Answer 23

1. Name of Use Case 2. Short Description of Use Case 3. Preconditions for Successful Execution 4. Postconditions (System State after Successful Execution) 5. Error Situtations (errors relevant to the problem) 6. System State on the Occurrence of an Error 7. Actors involved in Use Case 8. Trigger Event (Initiates Use Case) 9. Standard Process (Individual Steps to be Taken) 10. Alternative Process (Deviations from Standard Process)

Question 24

What are relationships between use cases and actors called?

Answer 24

Associations

Question 25

How are associations in use case diagrams represented?

Answer 25

Solid lines

Question 26

With how many use cases must an actor be associated?

Answer 26

At least one

Question 27

Can associations be non-binary?

Answer 27

No

Question 28

Are multiplicities possible for associations in use case diagrams?

Answer 28

Yes

Question 29

Types of Relationships between Use Cases

Answer 29

1. <>: - represented by dashed line with <> label - if A includes B, there is a dashed line from A to B, and whenever A is run, B is also run - B can be executed on its own 2. <>: - represented by dashed line with <> label - behaviour of the extending use case may be integrated in the behaviour of the base use case but does not have to - both use cases may be executed independently of one another 3. Use Case Generalisation: - if use case A generalises use case B, then: 1. B inherits all behaviour of A and may extend/change it 2. B inherits all relationships from A 3. B adopts basic functionality of A but decides what part of A is executed or changed 4. A may be labeled {abstract}, meaning that it cannot be executed directly, and that only B is executable

Question 30

Extension Point

Answer 30

defines at which point the behaviour of an extending use case is integrated extension points for a given use case are written directly within the use case then, for a given association, the condition (circumstances under which behaviour is integrated) and the specific extension points for this association are written outside of the use case in a rectangle like shape Format: Condition: {condition} Extension point: extension point

Question 31

Generalisation of Actors

Answer 31

if actor A inherits from actor B, actor A can communicate to all use cases that B can

Question 32

Is multiple inheritance of actors permitted?

Answer 32

Yes

Question 33

Are abstract actors possible?

Answer 33

Yes

Question 34

Should actors be linked the including and included use cases, or just to the including?

Answer 34

Both