Unit 2 - Requirements concepts

Question 1

Which parties will be involved during requirements engineering?

Answer 1

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

Question 2

Why is specifying the requirements for a system not an easy task?

Answer 2

. requirements are not usually stable and they tend to change as the environment changes

. there are usually many stakeholders and they do not always have the same view or priorities for the system to be developed

. it is not always clear and easy to identify what the requirements for a system are

. there are many factors that influence what the requirements are and these are not always explicit

Question 3

List the main properties requirements must exhibit

Answer 3

. 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. The level of completeness of requirements will 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.

Question 4

What are the 4 main activities during the requirements engineering process?

Answer 4

Requirements elicitation,
Requirements analysis and negotiation,
Requirements documentation
Requirements validation.

Question 5

What are some of the modelling techniques used in elicitation?

Answer 5

Activity diagrams,
Use cases,
Scenarios,
User stories.

Question 6

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

Answer 6

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.

Question 7

Identify the stakeholders for a system to book appointments for a hospital.

Answer 7

Hospital administrators, receptionists, doctors, nurses, patients, general public.

Question 8

Suggest ways in which requirements may evolve.

Answer 8

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.

Question 9

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

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

Answer 9

(a) The requirement is ambiguous and not verifiable. How can performance be measured? What is maximum load?
(b) The requirement is ambiguous and not verifiable. What is minimal loss of data?
(c) The requirement is ambiguous. What are the usability criteria?

Question 10

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

Answer 10

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 11

What are the benefits of documenting requirements within a project?

Answer 11

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.

Question 12

What is an agile approach to requirements engineering documentation?

Answer 12

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 13

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

Answer 13

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.

Question 14

Who are the stakeholders in a hotel reservation system?

Answer 14

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

Question 15

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

Answer 15

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.

Question 16

Give definitions for functional requirements

Answer 16

Functional requirements are things the product must do.

A requirement is a statement of need, something that some class of user or other stakeholder wants

A function is something that a system or subsystem does, presumably because a requirement made it necessary. … A functional requirement … in
practice just means the same as function.

Question 17

What typical terminology identifies a functional requirement (i.e. how should it be expressed)?

Answer 17

The system ‘shall’ accept/allow…

‘the system shall allocate a room’

Question 18

What does the MoSCoW scheme help define in terms of requirements prioritisation

Answer 18

Must have
Should have
Could have
Wont have (this time)

Question 19

What is a typical format for a user story

Answer 19

As a [role] I want [feature] so that [reason]

Question 20

What are the purposes of requirements?

Answer 20

Communication – from the requirements engineer to the designer.
As a contract with the client (and other stakeholders) for what the system must do.

Question 21

What is a functional requirement?

Answer 21

A functional requirement describes an action that the product must take if it is to carry out the work it is intended to do.

Question 22

Indicate one property that a functional requirement should not possess?

Answer 22

A functional requirement should not be a statement about a general property such as usability, reliability or maintainability.

A functional requirement should not be about the implementation of a solution.

Question 23

What is a non-functional requirement?

Answer 23

A non-functional requirement is a requirement about a quality that the product must have.

Question 24

What are a technical solution requirement and a business functional requirement? Why is it useful to distinguish them?

Answer 24

A technical solution requirement is a constraint on the product resulting from the technology of the solution that must be adopted.

Business functional requirements are a specification of the work,or business, independent of the way that work will be carried out.

The two types of requirement therefore arise from different domains – the business domain and the solution domain. It is important to keep issues related to the business separate from those of the solution.

Question 25

What overarching property should the set of functional requirements that result from a requirements-gathering process possess?

Answer 25

The set of functional requirements must fully describe the actions that the intended product should perform. That is, the product’s builder must be able to construct the product desired by the client from the descriptions contained in the functional requirements.

Question 26

How do business events and use cases help in determining functional requirements?

Answer 26

One way to discover the requirements of a system is to use the steps in use case scenarios. Use cases are derived from business events and each use case is described by a set of scenarios.

Each step in a scenario details a functional task. All the functional requirements associated with a use case can be collected from these tasks.

Question 27

How do user stories help in determining functional requirements?

Answer 27

User stories are written by the people who will get some value out of the system and therefore highlight elements of functionality relevant to them.

User stories encourage communication and involvement of users and customers with the development process, allowing for change and discovery of requirements throughout.

Question 28

How do you discover whether or not a set of functional requirements is sufficient for the product to be useful and whether the functionality is correct?

Answer 28

Ask the user.

Question 29

Why must functional requirements be testable?

Answer 29

So that it is possible to determine whether the delivered product meets the intention of the user.

Question 30

Can you think of some generic questions to ask that can help in making requirements precise and complete?

Answer 30

Questions of the form ‘when should something happen?’ and ‘to whom should something be sent?’ are useful. You may have thought of others.

Question 31

What is the major problem with a requirement that is written in a natural language such as English?

Answer 31

Ambiguity.

Question 32

Is it possible or desirable to avoid ambiguity entirely in a requirements specification? What steps can you take to reduce ambiguity in a requirements specification?

Answer 32

It might be possible to avoid ambiguity entirely, but the cost of being so precise can be enormous and the result unreadable. To avoid ambiguity attention has to be given to the language used to represent requirements.

Question 33

Why record the meaning of business and technical words in a requirements specification?

Answer 33

To avoid ambiguity and aid clarity in the usage of terms.

Question 34

Summarise the overall process (based on use cases) for determining a set of functional requirements.

Answer 34

(a) Understand the domain and determine the business processes and business events.
(b) Determine the scope of the new system and which business events are relevant.
(c) Draw up a set of use cases for the product associated with those events.
(d) Describe each use case by one or more scenarios – a set of steps.
(e) Work through each step of each scenario to determine a set of system requirements.
(f) Check for similar requirements from different use cases.
(g) Search out and remove ambiguity.

Question 35

Describe a process for capturing a set of functional requirements based on user stories.

Answer 35

A requirements capture process based on user stories usually starts with a brainstorming workshop with users and customers to generate an initial set of stories.

A story is recorded on a card and triggers a conversation which helps with understanding the detail, and outline tests for each story. Stories are prioritised, grouped and allocated to an iteration.

The outcome of an iteration is validated against its user stories.

Question 36

Identify the eight classes of non-functional requirements.

Answer 36

. Look-and-feel requirements. The spirit of the product’s appearance.

. Usability and humanity requirements. The product’s ease of use and any special usability considerations.

. Performance requirements. How fast, how safe, how accurate, how reliable, and how available the functionality must be.

. Operational and environmental requirements. The environment on which the product will have to work (under water, for example), and what considerations must be made for this environment.

. Maintainability and support requirements. Expected changes, and the time allowed to make them.

. Cultural requirements. Special requirements that come about because of the people involved in the product’s development and operation.

. Legal requirements. The laws and standards that apply to the product.

. Security requirements. The security and confidentiality of the product.

Question 37

What does the phrase ‘look and feel’ refer to?

Answer 37

Look-and-feel requirements describe the overall appearance of the product to its users.

Question 38

When identifying non-functional requirements for the look and feel of a product, why should you avoid the temptation to provide a design for the user interface?

Answer 38

The production of a design is the task of the product’s designers, once they know the requirements. The look-and-feel requirements are not about the specifics of the user interface.

Question 39

The description of a look-and-feel requirement is often loosely worded and therefore difficult to turn into a good design. What should be done to rectify this situation?

Answer 39

Fit criteria should be added to the requirements in order to make each one measurable.

Question 40

What general characteristics should the look and feel of a consumer product have?

Answer 40

The look and feel is concerned with the impression you wish to make. You want it to reflect the distinctive values, ethos and style of your organisation.

Question 41

What do usability and humanity requirements describe?

Answer 41

They describe how easy to use the product should be for its intended users under specified circumstances, and how satisfied they are with it. This includes how easy it is to learn to use the product.

Question 42

What are the effects of usability and humanity on a product?

Answer 42

Usability and humanity impacts on productivity, error rates, stress levels and acceptance. It determines how well the human part of the system can perform.

Question 43

How might you express a usability and humanity requirement more precisely than simply ‘easy to learn’?

Answer 43

A usability and humanity requirement can be expressed more precisely by describing the level of achievement required after the required training or learning period.

Question 44

What are the main kinds of performance requirements?

Answer 44

Normally the main performance requirements involve speed (the time to do something), capacity, safety, accuracy, reliability and availability.

Question 45

Rather than accept requirements that state that something should be done speedily and/or efficiently, what should you aim for?

Answer 45

You should look for requirements that specify the speed and efficiency in ways that can be measured objectively. Take into account the possible effects of throughput and volume.

Question 46

What are the problems of specifying performance requirements for web-based systems?

Answer 46

It is hard to specify performance of web-based systems because there are too many unknowns, for example the speed of connection.

Question 47

How do operational requirements differ from performance requirements?

Answer 47

Operational and environmental requirements describe the operational environment (factors external to the product) in which the product must function correctly, whereas performance requirements deal with issues such as speed and size (factors internal to the product).

Question 48

When do cultural requirements usually arise?

Answer 48

Cultural requirements usually arise when:

(i) the aim is to sell a product in a different country,
particularly a country with a different culture and language from the one that the product was initially designed for

(ii) eliciting requirements in an organisation different from one’s own.

Question 49

What is the best approach to dealing with cultural issues?

Answer 49

Obtain the help of stakeholders from that culture.

Question 50

Why are cultural requirements often difficult to deal with?

Answer 50

Cultural and political requirements often involve having to ask personal questions and can be difficult to quantify. Such questioning is likely to be sensitive.

Question 51

What is the most pressing reason for considering legal requirements?

Answer 51

The cost of litigation is a risk for commercial software and can be expensive for other software. There are penalties for non-conformance with the law – fines, imprisonment, and loss of reputation.

Question 52

How should you determine the appropriate law that affects the product?

Answer 52

Obtain help from the company’s lawyers.

Question 53

In the context of a computer system, what is meant by security?

Answer 53

Security is about the prevention of unauthorised access to the system.

Question 54

There are two problem areas for a distributed computing system that go beyond the normal security requirements. What are they?

Answer 54

The additional security problems that arise with a distributed system are:

(i) the communication medium is insecure and users’
communications may be intercepted en route and read or altered

(ii) on an external network communications will pass through many third-party systems with unknown security measures which cannot be controlled.

Question 55

From the point of view of a security administrator, suggest a useful starting point to monitor potential threats.

Answer 55

One useful focal point is at the boundary of the security domain for which the administrator is responsible. In practice, this is likely to be a firewall for a protected network.

Question 56

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

Answer 56

Access, privacy, integrity, audit and immunity.

Question 57

Distinguish between the five aspects of security.

Answer 57

Access – authorised users of data should not be prevented or unnecessarily delayed from accessing that data. This implies that steps should be taken to prevent loss of data and to prevent denial of
service attacks.

Privacy – data must not be made available to anyone except authorised users. This implies identification of those who are authorised to access specific items of data.

Integrity – the data held by the system corresponds to the data supplied to the system. Integrity implies that data does not become corrupted.

Audit – the data and functionality of the product can be verified and inappropriate access can be traced.

Immunity – the product is protected against external threats and attacks.

Question 58

What is the first step towards finding whether a solution fits a requirement?

Answer 58

The first step towards finding whether a solution fits a requirement is to attach a quantifiable measure to the requirement so that it is testable.

Question 59

What is a fit criterion?

Answer 59

A fit criterion is a quantification or measurement of a requirement, such that the design solution can be measured to find if it unambiguously meets the requirement.

Question 60

Who needs the fit criteria?

Answer 60

The developers of the product use the fit criteria to develop the product to meet those criteria. The testers use the fit criteria to determine whether the delivered product meets the original requirements. The clients for whom the product is being developed use the fit criteria as acceptance criteria for the product.

Question 61

When are fit criteria specified?

Answer 61

The fit criteria can be written or elicited as the requirements are elicited, for example once use cases have been drawn up and the requirements for each task in each use case have been determined.

Question 62

What is a fit criterion for a functional requirement?

Answer 62

A fit criterion for a functional requirement specifies the completion of the function of the product that is specified by that functional requirement.

Question 63

Do the fit criteria of functional requirements have scales of measurement?

Answer 63

No, the fit criteria of functional requirements do not have scales of measurement. Success is tested in terms of a yes/no answer that implies whether the required function is achieved or not.

Question 64

Does a fit criterion indicate how the functional requirement would be tested?

Answer 64

No, a fit criterion provides some target which, when the solution is tested, reveals whether the solution conforms to the requirement.

The fit criterion does not indicate how the product will be tested. It merely states that the tester should ensure that the product complies with that fit criterion.

Question 65

What does the fit criterion for a non-functional requirement specify?

Answer 65

A fit criterion for a non-functional requirement specifies a value or values, on a particular scale of measurement, that must be attained by the property or quality that the requirement is concerned with.

These values should be realistic.

Question 66

How might you determine the fit criterion for the performance requirement, ‘The customer services personnel should be able to respond rapidly to
customer queries’?

Answer 66

The fit criterion for this requirement might
be something like, ‘The customer services personnel must be able to find an answer to a customer’s query in not more than one minute of a customer’s call.’

Question 67

Give suggestions of possible fit criteria for performance requirements to address the following situations:

(a) Customers return the product if they are unhappy with it after a purchase has been made.
(b) Users don’t find the system user-friendly because of the number of errors that are made in completing a task.
(c) Staff members are satisfied and fewer of them are leaving the organisation.

Answer 67

(a) To determine customer satisfaction, a possible fit criterion would be the percentage of product items returned within a particular time period as compared with the number of products sold within that time period.
(b) A possible fit criterion would be that errors shall not occur on more than a specified proportion of the occasions on which the task is executed.
(c) A possible fit criterion would be that the staff turnover does not exceed some specified level and there is a month-on-month reduction in the number of staff leaving.

Question 68

What are the 5 main sections in the Volere Template

Answer 68

1. Project drivers
2. Project constraints
3. Functional requirements
4. Non-functional requirements
5. Project issues

Question 69

What is the advantage of capturing requirements using a template rather than adopting your own format?

Answer 69

The template is divided into a fixed set of categories, which means you are less likely to forget some types of requirements.

It also saves having to work out what categories of requirements to deal with each time you start a
new document. It helps to communicate requirements to other developers because if there is a standard template then everyone will know what information to expect and in what order.

It might also allow projects to be compared and even requirements to be reused more easily.