Unit 2

Question 1

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

Answer 1

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

Question 2

What is the Volere template?

Answer 2

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.

Question 3

Which 4 parties make up the stakeholders of a system?

Answer 3

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

Question 4

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

Answer 4

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

Question 5

What are the 4 difficulties when specifying requirements?

Answer 5

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

Question 6

RUN CCTV

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

Answer 6

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

Question 7

In what 6 ways may requirements evolve?

Answer 7

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

Question 8

What is an agile approach to requirements engineering documentation?

Answer 8

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.

Question 9

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

Answer 9

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.

Question 10

What are the benefits of documenting requirements within a project?

Answer 10

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.

Question 11

What are functional requirements?

Answer 11

Functional requirements specify the behaviour of a system.

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

Question 12

What are the 9 steps of the user story technique?

Answer 12

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

Question 13

Give three examples of functional requirements.

Answer 13

• 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.

Question 14

What is the benefit of user stories?

Answer 14

User stories emphasise communication between users, customers and developers.

Question 15

What is the difference between user requirements and system requirements?

Answer 15

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.

Question 16

What are non-functional requirements?

Answer 16

Non-functional requirements specify general properties.

E.g. must be reliable

Question 17

Give three examples of non-functional requirements.

Answer 17

• The system shall be reliable.
• The system shall be easily maintained.
• The system shall be usable.

Question 18

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

Answer 18

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

Question 19

MUSCLE FLOP

What are the 8 classes of non-functional requirements?

Answer 19

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

Question 20

AI API

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

Answer 20

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

Question 21

DR D M

What are the 4 forms an attack might take?

Answer 21

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

Question 22

What is a fit criterion?

Answer 22

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

Question 23

FIND C

What are the 5 main sections of the Volere template?

Answer 23

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

Question 24

What are the 2 project drivers in the Volere template?

Answer 24

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

Question 25

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

Answer 25

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

Question 26

What are the 4 functional requirements in the Volere template?

Answer 26

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

Question 27

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

Answer 27

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

Question 28

What are the 10 project issues in the Volere template?

Answer 28

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

Question 29

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

Answer 29

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