Brainscape's Knowledge GenomeTM

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


See full index

TM354 > Unit 2 > Flashcards

Unit 2 Flashcards

1
Q

What is the difference between functional and non-functional requirements?

A

Functional requirements specify the behaviour of a system.

E.g. must accept a credit card number from a client

Non-functional requirements specify general properties.

E.g. must be reliable

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

What is the Volere template?

A

The Volere template is a template for a document that collates all the requirements of a system, together with other issues that may affect those requirements.

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

Which 4 parties make up the stakeholders of a system?

A
  1. The people who are going to use the system
  2. Those who are paying for it
  3. Those who are going to benefit from it
  4. Those who are developing it
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What are the 3 categories of commonly cited problems with software products?

A
  1. System is delivered late and/or is more expensive than initially thought
  2. System does not deliver what the end users want
  3. System is unreliable and has errors
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are the 4 difficulties when specifying requirements?

A
  1. Requirements are not usually stable and tend to change as the environment changes
  2. There are usually many stakeholders and they do not always have the same view or priorities for the system to be developed
  3. It is not always clear and easy to identify what the requirements for a system are
  4. There are many factors that influence what the requirements are and these are not always explicit
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

RUN CCTV

What are the 5 properties of requirements that need to be checked?

A
  1. Realistic
    • It should be possible to carry each requirement through to development
  2. Unambiguous
    • There should be no alternative interpretations for one requirement
  3. Necessary
    • Each requirement should fulfil a purpose
  4. Consistent
    • Requirements should not contradict each other
  5. Complete
    • The level of completeness of requirements will depend on the system to be developed and on the development environment
  6. Traceable
    • It should be clear where each requirement comes from
  7. Verifiable and validated
    • It should be possible to check that a requirement has been implemented, and that what is implemented corresponds to what was intended
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

In what 6 ways may requirements evolve?

A
  1. New requirements may be added
  2. Existing requirements may change because of changes in the environment or in the organisation
  3. Some requirements may become obsolete
  4. Technologies may evolve
  5. Other systems may emerge that introduce interoperability requirements
  6. Regulations may change
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What is an agile approach to requirements engineering documentation?

A

In an agile approach, requirements documentation serves a purpose and should be done only to the extent that it contributes to that purpose. It should serve as a vehicle for common understanding, communication and future traceability.

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

What are requirements and stakeholders and how do they relate to each other?

A

Requirements are the functions and qualities that are wanted of a product.

Stakeholders are the people and organisations with a vested interest in the product.

Requirements arise from stakeholders’ needs.

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

What are the benefits of documenting requirements within a project?

A

Requirements record decisions and are the main reference for what should be built and the basis for validation of the built system. Therefore they need to be documented so they can be used throughout development.

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

What are functional requirements?

A

Functional requirements specify the behaviour of a system.

E.g. must accept a credit card number from a client

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

What are the 9 steps of the user story technique?

A
  1. User thinks of something they want the system to do
  2. Desire is written on an index card, and given a name and a number
  3. An estimate is made of how long it will take to realise the story in fully functional and releasable form
  4. Stories are factored (split into smaller stories) if:
    1. It appears they will take too long to implement as written
    2. One aspect of the story is more important than others
    3. They are long and rambling or overly general
  5. Stories are prioritised
  6. Stories are aggregated into collections, each collection defining the scope of work undertaken by the team this period
  7. Work products are validated and their ability to satisfy the original story is confirmed
  8. The user uses the developed system and new stories are conceived
  9. Iterate
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Give three examples of functional requirements.

A
  • The system shall accept a credit card number from a client.
  • The system shall email the customer confirmation of their order.
  • The system shall show the customer available products.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What is the benefit of user stories?

A

User stories emphasise communication between users, customers and developers.

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

What is the difference between user requirements and system requirements?

A

User requirements are abstract statements of the software requirements for the customer and end user of the system.

System requirements are a more detailed description of the functionality to be provided.

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

What are non-functional requirements?

A

Non-functional requirements specify general properties.

E.g. must be reliable

17
Q

Give three examples of non-functional requirements.

A
  • The system shall be reliable.
  • The system shall be easily maintained.
  • The system shall be usable.
18
Q

What is the overall 7 step process for determining a set of functional requirements?

A
  1. Understand the domain, buiness processes, and business events
  2. Determine the scope of the new system and which business events are relevant
  3. Draw up a set of use cases for the product associated with those events
  4. Describe each use case by one or more scenarios
  5. Work through each step of each scenario to determine a set of system requirements
  6. Check for similar requirements from different use cases
  7. Search out and remove ambiguity
19
Q

MUSCLE FLOP

What are the 8 classes of non-functional requirements?

A
  1. Maintainability and support
    • Expected changes and the time allowed to make them
      • e.g. the product shall be able to be modified to cope with a new class of user
  2. Usability and humanity
    • The product’s ease of use and any special usability considerations
      • e.g. the system should comply with the Disability Discrimination Act
  3. Security
    • The security and confidentiality of the product
  4. Cultural
    • Special requirements that come about because of the people involved in the product’s development and operation
      • e.g. the language used in the interface should be formal and polite
  5. Legal
    • The laws and standards that apply to the product
  6. Operational and environmental
    • The environment on which the product will have to work (e.g. under water) and what considerations must be made for this environment
      • e.g. the product shall be usable above an altitude of x
  7. Look-and-feel
    • The spirit of the product’s appearance
      • e.g. the product shall use only two colours
  8. Performance
    • How fast, how safe, how accurate, how reliable, and how available the functionality must be
      • e.g. the product shall handle up to 10 users simultaneously
20
Q

AI API

What are the 5 aspects of security from a requirements perspective?

A
  1. Audit
    • How the correctness of product and data can be verified, and how to help detection of inappropriate access and intrusion
  2. Immunity
    • Protection of a system against threats and attacks
  3. Access
    • Uninterrupted or continual access to data and functionality by authorised users
  4. Privacy
    • Protection of data from unauthorised access and disclosure
  5. Integrity
    • Consistency of data, the ability to prevent unauthorised modification or deletion of data
21
Q

DR D M

What are the 4 forms an attack might take?

A
  1. Disclosure of private information or the unathorised release of information
  2. Repudiation, where a legitimate user claims they did not send or receive a particular message that was sent or received
  3. Denial of use or service or loss of access, where there is some denial of network service to its authorised users
  4. Modification, loss of integrity, or the unauthorised alteration of data or information
22
Q

What is a fit criterion?

A

A fit criterion is a precise and testable statement of a requirement.

e.g. for the requirement:

the system shall accept a credit card number from a client

a fit criterion could be:

a valid credit card number has been stored in the system

23
Q

FIND C

What are the 5 main sections of the Volere template?

A
  1. Project drivers
    • Reasons and motivators of the project
  2. Project constraints
    • Restrictions and limitations that apply to the project and the product
  3. Functional requirements
    • Covers the functionality of the product
  4. Non-functional requirements
    • Cover the properties the product must have
  5. Project issues
    • Concerns brought to light by the requirements activities
24
Q

What are the 2 project drivers in the Volere template?

A
  1. Purpose of the project
    • The reason for building the product and the business advantage if it is done
  2. Stakeholders
    • The people and organisations, other than the users, with a vested interest in the product
25
Q

What are the 3 types of project constraint in the Volere template?

A
  1. Mandated constraints
    • Constraints on the way the product must be designed or on the project itself
  2. Naming conventions and terminology
    • Vocabulary of the project, including terms and definitions that are commonly usedin communication with stakeholders
  3. Relevant facts and assumptions
    • External facts that may have an effect on the product and the assumptions made by the project team, but do not necessarily translate into requirements
26
Q

What are the 4 functional requirements in the Volere template?

A
  1. The scope of the work
    • Defines the boundaries of the business area that will be improved by the product
  2. Business data model and data dictionary
    • Defines the data that is manipulated
  3. The scope of the product
    • Defines the product boundaries
  4. Functional requirements
    • What the product must do to contribute to the product goal
27
Q

MUSCLE FLOP

What are the 8 non-functional requirements in the Volere template?

A
  1. Look-and-feel requirements
    • The intended appearance and style of the product
  2. Usability and humanity requirements
    • These are based on the intended users and ergonomic acceptance of the product
  3. Performance requirements
    • How fast, safe, accurate, reliable, available the product must be
  4. Operational and environmental requirements
    • The product’s intended operating environment
  5. Maintainability and support requirements
    • How easily the product can change and what support is needed
  6. Security requirements
    • The access, integrity, privacy, audit, and immunity of the product
  7. Cultural requirements
    • Human factors that may affect the product
  8. Legal requirements
    • Conformance of the product to applicable laws and standards
28
Q

What are the 10 project issues in the Volere template?

A
  1. Open issues
    • Issues that have arisen from the requirements activities, but are not yet resolved
  2. Off-the-shelf solutions
    • A record of ready-made components that might be used in the project and their impact on the product requirements
  3. New problems
    • Used to highlight possible problems cause by the introduction of the product
  4. Tasks
    • Highlights the effort required to deliver the product, whether it is a complete build or the acquisition of existing off-the-shelf solutions
  5. Migration to the new product
    • Things that need to be done after the product has been installed but before it can work successfully
  6. Risks
    • The risks the project is likely to face, together with strategies for coping, should they become problems at some point during the project
  7. Costs
    • An estimate of the cost or effort needed to build the product
  8. User documentation and training
    • The plan for writing the user instructions and documentation
  9. Waiting room
    • Covers requirements that for some reason cannot be included in the current release of the product, but might be included in future releases
  10. Ideas for solutions
    • ​Design ideas that may become useful
29
Q

ORCHID CUPS F

What 11 pieces of information should be recorded for each functional and non-functional requirement?

A
  1. Originator
    • Who raised the requirement in the first place
  2. Rationale
    • Why the requirement is considered important or necessary
  3. Customer satisfaction/dissatisfaction
    • An indication of the customer’s reaction to the requirement’s omission from the solution
  4. History
    • Origin of, and changes to, the requirement
  5. ID (Requirement number)
    • To identify the requirement uniquely
  6. Description
    • A one-sentence statement of the intent of the requirement
  7. Conflicts
    • Requirements that contradict this one or make this one less feasible
  8. Use case
    • To identify which use case or event is associated with this requirement
  9. Priority
    • A mark of the value of the requirement for the customer
  10. Supporting materials
    • Link to other documents to help understand the requirement
  11. Fit criterion
    • The acceptance criterion, written in a quantified manner so that the solution can be tested against the requirement

TM354 (9 decks)

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