Tm354 - Unit 2.1 And 2.2

Front 1

What is end product of software development called?

Back 1

The end product of software development is a software system.

Front 2

What is requirements engineering and who are the typical 4 types of people it involves?

Back 2

Requirements engineering is the process of reaching and documenting an agreed set of requirements.

This is a complex process that involves diverse interested parties:

They are all collectively known as stakeholders.

• The people who are going to use the system.

• Those who are paying for it (the clients).

• Those who are to benefit from it.

• Those who are developing it.

Front 3

What are the 3 typical consequences of poor requirements engineering?

Back 3

• the system is delivered late and/or is more expensive than initially thought

​

• the system does not deliver what the end-users want

​

• the system is unreliable and has errors.

Front 4

Requirements have to be carefully defined and checked for different properties. What are the 5 things they need to be checked for?

Back 4

They need to be:

• Necessary and traceable – each requirement should fulfil a purpose and it should be clear where each requirement comes from.

​

• Non-ambiguous and realistic – there should be no alternative interpretations for one requirement and it should be possible to carry each requirement through to development.

​

• Complete – in a plan-driven development all the intended functionality is described as completely as possible, although in practice it is often not possible to be absolute about this and it is important to allow for requirements that emerge later in the system development and during maintenance. Agile development makes a strong argument that requirements will emerge during development and cannot be considered complete in advance. The level of completeness of requirements will also depend on the system to be developed and on the development environment.

​

• Consistent – requirements should not contradict each other.

​

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

Front 5

What are the four activities that can be identified as common to many requirements engineering processes?

Back 5

The four activities that can be identified as common to many requirements engineering processes are:

• Requirements elicitation
• Requirements analysis and negotiation
• ​Requirements documentation and
• Requirements validation

Front 6

What is Requirements elicitation?

Back 6

Requirements elicitation is the activity concerned with identifying the requirements.

Front 7

What is requirements analysis and negotiation?

Back 7

Requirements analysis and negotiation is the activity where requirements are categorised, prioritised and examined for their properties of consistency, completeness and ambiguity.

Front 8

What is requirements validation?

Back 8

Requirements validation consists of a careful check of the overall requirements documentation, usually following a checklist of questions.

Front 9

According to Robertson and Robertson, if requirements are to be implemented successfully what two things must they be?

Back 9

Requirements, if they are to be implemented successfully, must be measurable and testable.

(Robertson and Robertson, 2012, Truth 10, Chapter 1)

Front 10

Where and when does the requirements engineering process take place in an iterative and incremental development process?

Back 10

The main output of a requirements engineering process is the contract between those commissioning the system and the developers of the system. It has therefore to take place early in the software development process. However, an iterative and incremental process recognises that requirements are not stable and revisiting, clarifying and specifying requirements occur in parallel with the other phases of development.

Front 11

1. Identify the stakeholders for a system to book appointments for a hospital.
2. Suggest ways in which requirements may evolve.

Back 11

1. Hospital administrators, receptionists, doctors, nurses, patients, general public.
2. Examples are:

• new requirements may be added
• existing requirements may change because of changes in the environment or in the organisation
• some requirements may become obsolete
• technologies may evolve
• other systems may emerge that introduce interoperability requirements
• regulations may change.

Front 12

Consider the following list of poorly expressed requirements, indicate which properties are not respected and ask questions to clarify their meaning:

1. The software system should provide acceptable performance under maximum load conditions.
2. If the system fails in operation there should be minimal loss of data.
3. The software should be developed so that it can be used by inexperienced users.

Back 12

1. The requirement is ambiguous and not verifiable. How can performance be measured? What is maximum load?
2. The requirement is ambiguous and not verifiable. What is minimal loss of data?
3. The requirement is ambiguous. What are the usability criteria?

Front 13

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

Back 13

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.

Front 14

What are the benefits of documenting requirements within a project?

Back 14

Requirements record decisions. They 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 that they can be used throughout development.

Front 15

What is an agile approach to requirements engineering documentation?

Back 15

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.

Front 16

Which other activities will be taking place in parallel with requirements engineering?

Back 16

The definition of the system architecture and an elaboration of tests for the requirements. When defining requirements there are implications for the architecture of the system and each requirement will be related to some test of the final system.

Front 17

Who are the stakeholders in a hotel reservation system?

Back 17

The hotel owners, receptionists, existing customers, the general public accessing the system to make a reservation.

Front 18

Consider the example of a hotel reservation system and invent some examples of the main inputs for a requirements engineering process.

Back 18

Examples include:

• stakeholder needs – there should be a help system for first-time users of the system

​

• domain information – rooms are identified by a number where the first digit indicates the floor and the subsequent digits indicate the number of the room in a floor

​

• existing documentation – the manual system used for reservations

​

• regulations and organisational standards – an acknowledgement is sent to every customer who makes a reservation.