Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Spec > Week 1 > Flashcards

Week 1 Flashcards

1
Q

Software Development Cycle Components

A
  1. Requirements
  2. Design
  3. Implementation
  4. Testing
  5. Deployment
  6. Maintenance
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Waterfall Method

A
  1. Requirements engineering
  2. Specification
  3. Design
  4. Implementation
    - includes iteration and feedback
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Validation

A

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

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

Verification

A

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

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

Problems with Waterfall Method

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

V-Model

A

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

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

Acceptance Testing

A

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

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

Integration Testing

A

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

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

System Testing

A

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

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

Unit Testing

A

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

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

Agile Development

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

Prioritises:
- flexibility
- collaboration
- customer feedback

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

Principles of Agile development

A
  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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Drawbacks of Agile Development

A
  1. Lack of extensive design phase.
  2. Lack of energy spent on documentation.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Requirement

A

a statement expressing a need and its associated constraints and conditions

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

Steps of Requirements Engineering

A
  1. Requirements elicitation
  2. Requirements specification
  3. Requirements verification and validation
  4. Requirements management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Requirements elicitation

A

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

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

Requirements specification

A

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

10
Q

Requirements verification and validation

A

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

11
Q

Requirements management

A

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

12
Q

Important Elements of Requirements Specification

A
  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
13
Q

Steps for Requirements Specification

A

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.
14
Q

Properties of Good Requirements

A

Unambiguous
Consistent
Verifiable
Appropriate
Necessary
Complete
Singular
Feasible
Correct
Conforming

15
Q

Structure of Semi-Informal Requirements

A
  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)
16
Q

Requirement No-Go’s:

A
  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,
17
Q

Use Case Diagram

A

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

18
Q

Main Components of a Use Case Diagram

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

Use Cases

A

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

20
Q

Actors

A

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

21
Q

Are actors part of the system?

A

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

22
Q

Categories of Actors:

A
  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)
23
Q

Detailed Description Structure for Use Cases

A
  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)
24
Q

What are relationships between use cases and actors called?

A

Associations

25
Q

How are associations in use case diagrams represented?

A

Solid lines

26
Q

With how many use cases must an actor be associated?

A

At least one

27
Q

Can associations be non-binary?

A

No

28
Q

Are multiplicities possible for associations in use case diagrams?

A

Yes

29
Q

Types of Relationships between Use Cases

A
  1. «include»:
    - represented by dashed line with «include» 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. «extend»:
    - represented by dashed line with «extend» 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:
  4. B inherits all behaviour of A and may extend/change it
  5. B inherits all relationships from A
  6. B adopts basic functionality of A but decides what part of A is executed or changed
  7. A may be labeled {abstract}, meaning that it cannot be executed directly, and that only B is executable
30
Q

Extension Point

A

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

31
Q

Generalisation of Actors

A

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

32
Q

Is multiple inheritance of actors permitted?

A

Yes

33
Q

Are abstract actors possible?

A

Yes

34
Q

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

A

Both

Software Spec (7 decks)

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