TM354 Unit 2 - Requirements Concepts Flashcards

1
Q

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

A

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.

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

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

A

Hospital administrators receptionists doctors nurses patients general public.

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

Suggest ways in which requirements may evolve.

A

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.

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

Consider the following 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.

A

The requirement is ambiguous and not verifiable. How can

performance be measured? What is maximum load?

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

Consider the following poorly expressed requirements indicate which properties are not respected and ask questions to clarify their meaning:
(b) If the system fails in operation there should be minimal loss of data.

A

(b) The requirement is ambiguous and not verifiable. What is minimal loss of data?

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

Consider the following poorly expressed requirements indicate which properties are not respected and ask questions to clarify their meaning:
(c) The software should be developed so that it can be used by inexperienced users.

A

(c) The requirement is ambiguous. What are the usability criteria?

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

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

A

(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
8
Q

(b) What are the benefits of documenting requirements within a project?

A

(b) 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.

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

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

A

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.

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

What are the purposes of requirements?

A

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

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

What is a functional requirement?

A

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

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

Indicate one property that a functional requirement should not possess?

A

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.

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

What is a non-functional requirement?

A

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

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

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

A

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.

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

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

A

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.

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

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

A

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.

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

How do user stories help in determining functional requirements?

A

(h) 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.

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

(a) 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?

A

(a) Ask the user.

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

(b) Why must functional requirements be testable?

A

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

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

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

A

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

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

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

A

(d) Ambiguity.

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

(e) 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?

A

(e) 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.

24
Q

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

A

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

25
Q

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

A

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

26
Q

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

A

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.

27
Q

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

A

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

28
Q

(b) 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?

A

(b) 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.

29
Q

(c) 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?

A

(c) Fit criteria (dealt with in detail in Section 5) should be added to the requirements in order to make each one measurable.

30
Q

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

A

(d) 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.

31
Q

(a) What do usability and humanity requirements describe?

A

(a) 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.

32
Q

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

A

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

33
Q

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

A

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

34
Q

(a) What are the main kinds of performance requirements?

A

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

35
Q

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

A

(b) 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.

36
Q

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

A

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

37
Q

How do operational requirements differ from performance requirements?

A

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

38
Q

(a) When do cultural requirements usually arise?

A

(a) 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.

39
Q

(b) What is the best approach to dealing with cultural issues?

A

(b) Obtain the help of stakeholders from that culture.

40
Q

(c) Why are cultural requirements often difficult to deal with?

A

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

41
Q

(a) What is the most pressing reason for considering legal requirements?

A

(a) The cost of litigation is a risk for commercial software and can be expensive for other software. There are penalties for nonconformance with the law – fines imprisonment and loss of reputation.

42
Q

(b) How should you determine the appropriate law that affects the product?

A

(b) Obtain help from the company’s lawyers.

43
Q

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

A

Answer

(a) Security is about the prevention of unauthorised access to the system.

44
Q

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

A

(b) 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.

45
Q

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

A

(c) 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.

46
Q

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

A

(a) Access privacy integrity audit and immunity.

47
Q

(b) Distinguish between the five aspects of security.

A

(b) 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.

48
Q

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

A

(a) 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.

49
Q

(b) What is a fit criterion?

A

(b) 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.

50
Q

(a) Who needs the fit criteria?

A

(a) 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.

51
Q

(b) When are fit criteria specified?

A

(b) 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.

52
Q

(a) What is a fit criterion for a functional requirement?

A

(a) A fit criterion for a functional requirement specifies the completion of the function of the product that is specified by that functional requirement. For example if the required function is to send an email to a student after a marked TMA has been uploaded by the tutor then the fit criterion for this requirement is that an email has indeed been sent to the student and reflected in the receiving mailbox.

53
Q

(b) Do the fit criteria of functional requirements have scales of measurement?

A

(b) 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.

54
Q

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

A

(c) 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.

55
Q

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

A

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 as discussed in the performance requirements example.

56
Q

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

A

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.