Unit 2

Question 1

What is meant by requirements engineering?

Answer 1

An activity in the process of developing software that aims to elicit and specify the requirements of the client(s)/user(s) in a form that can be used in the design of the software and in assessing its quality once it is built. It can be divided into two main activities: requirements elicitation and requirements analysis.

Question 2

What is meant by a stakeholder of a system?

Answer 2

An individual and/or an organisation affected by the success or failure of a software system.

Question 3

What are the properties that requirements must be checked for?

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

Question 4

What are the inputs of a requirements engineering process?

Answer 4

The stakeholders’ needs are one of the inputs into this process. Other inputs come from existing knowledge of the domain, existing regulations, the organisation’s standards, and existing systems.

Question 5

What are the outputs of a requirements engineering process?

Answer 5

The outputs of a requirements engineering process are a set of artefacts that can help in understanding the intended requirements for a system. In plan-driven development, this output takes the shape of a requirements document and the models of what the system is intended to do.

Question 6

List the different activities associated with the requirements engineering process.

Answer 6

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

Question 7

What happens during the requirements elicitation activity of the requirements engineering process?

Answer 7

Requirements elicitation is the activity concerned with identifying the requirements. This is done by consulting the stakeholders, reading existing documents, understanding the domain, defining the boundaries of the system, and understanding the possibilities of change.

There are many techniques for elicitation such as interviews, focus groups, team meetings, brainstorming sessions, and more recent approaches such as crowd sourcing. Often several of these techniques are used in conjunction. There are also modelling techniques to help this process such as activity diagrams, use cases, scenarios, and user stories.

The goal of elicitation is to find out what the system to be developed will do. This involves finding the system’s stakeholders, defining the boundaries of the system, and discovering the main objectives the system has to meet. At this stage the requirements engineer is discovering and recording requirements.

Question 8

What happens during the requirements analysis and negotiation activity of the requirements engineering process?

Answer 8

Requirements analysis and negotiation is the activity where requirements are categorised, prioritised and examined for their properties of consistency, completeness and ambiguity. This activity also involves the negotiations around conflicting interests and requirements. Models of requirements are created to help communication with the customers and developers.

Question 9

What happens during the requirements documentation activity of the requirements engineering process?

Answer 9

Requirements documentation is usually done through a template document. Documentation also includes the modelling artefacts.

Question 10

What happens during the requirements validation activity of the requirements engineering process?

Answer 10

Requirements validation consists of a careful check of the overall requirements documentation, usually following a checklist of questions. This is a way of ensuring that the requirements correspond to what is really intended of the system.

Question 11

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

Answer 11

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 12

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

Answer 12

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

Question 13

Suggest ways in which requirements may evolve.

Answer 13

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 14

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 14

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 15

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

Answer 15

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 16

What are the benefits of documenting requirements within a project?

Answer 16

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 17

What is an agile approach to requirements engineering documentation?

Answer 17

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 18

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

Answer 18

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 19

Who are the stakeholders in a hotel reservation system?

Answer 19

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

Question 20

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

Answer 20

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 21

What is a business event?

Answer 21

A business event is something that a system must respond to.

Question 22

What is a business process?

Answer 22

Definition of what gets done in the business: by whom, in what order, needing what and with what consequences.

Question 23

What is meant by the term ‘actor’?

Answer 23

A representation of users of a software system in a particular role, when interacting with use cases. An actor can also represent the role of an external system that interacts with a software system.

Question 24

Briefly describe the MoSCoW scheme.

Answer 24

A scheme in DSDM classifying requirements into Must have, Should have, Could have, and Won’t have.

Question 25

What is meant by a user story?

Answer 25

A story written by an intended user of a system; it describes some functionality that is of value to the person(s) writing the story. It represents a user’s expectation of the system.

Question 26

Give an example of the typical format of a user story.

Answer 26

An example of a typical format is ‘as a [role] I want [feature] so that [reason]’.

Question 27

What are the step used in the user story technique as defined by Beck and West (2004)?

Answer 27

• The customer (user) thinks of something she wants the system to do.
• The desire is written down on an index card, given a name and a number.
• An estimate is made of how long it will take to realize the story in fully functional and releasable form.
• Stories are factored – split into smaller stories – if it appears they will take too long to implement as written.
• Stories are factored if one aspect of the story is more important than others.
• Stories are factored if they are long and rambling or overly general.
• Stories are prioritized.
• Stories are aggregated into collections, each collection defining the scope of work undertaken by the team this period.
• Work products are validated. Their ability to satisfy the original story is confirmed.
• The customer uses the developed system and new stories are conceived.
• Iterate.

Question 28

What are the essential characteristics of a good user story as listed by Cohn (2004) and Beck and West (2004)?

Answer 28

Cohn (2004) lists the following characteristics as essential for a good story: independent, negotiable, valuable to users and customers, estimable, small, testable.

Beck and West (2004) highlight four characteristics of a story: discrete, estimable, testable and prioritised.

Question 29

Give an example of the typical format of a requirement.

Answer 29

‘The system shall …’

Question 30

List some ways in which you can avoid ambiguity when specifying requirements.

Answer 30

Pronouns (for example ‘it’, ‘their’) should be avoided, as should words with multiple meanings.

Avoid using words with multiple meanings.

Any words that have technical meanings or meanings specific to the business should be given definitions that get recorded in the requirements specification. For similar reasons, abbreviations, including acronyms, should be defined there.

Question 31

How does Sommerville (2011) define a user requirement?

Answer 31

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

Question 32

How does Sommerville (2011) define a system requirement?

Answer 32

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

Question 33

Why is it important to make a distinction between a requirement and its solution?

Answer 33

It is important to understand the essence of the business, not its implementation. This is vital because it is too easy to hide significant functionality by describing an implementation, and too easy to select one implementation when better ones may exist.

Question 34

What are the purposes of requirements?

Answer 34

Communication – from the requirements engineer to the designer.

As a contract with the client (and other stakeholders) for what the system must do.

Question 35

What is a functional requirement?

Answer 35

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 36

Indicate one property that a functional requirement should not possess?

Answer 36

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 37

What is a non-functional requirement?

Answer 37

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

Question 38

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

Answer 38

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 39

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

Answer 39

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 40

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

Answer 40

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 41

How do user stories help in determining functional requirements?

Answer 41

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 42

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 42

Ask the user.

Question 43

Why must functional requirements be testable?

Answer 43

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

Question 44

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

Answer 44

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

Question 45

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

Answer 45

Ambiguity.

Question 46

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 46

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 47

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

Answer 47

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

Question 48

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

Answer 48

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 49

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

Answer 49

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 50

Here is a list of requirements that apply to a product X. For each requirement say whether it is a functional or non-functional requirement and, if it is a functional requirement, whether it is a business requirement or a technical solution requirement.

a. X must check a user’s identity
b. X must check a user’s password
c. X must produce a statement of the user’s account
d. X must validate the user’s identity and password within three seconds
e. X must be usable by users with limited dexterity
f. X must employ the company’s proprietary password maintenance system
g. X must operate in arctic climates

Answer 50

a. functional, business requirement (the requirement states what needs to be done, not how to do it)
b. functional, technical solution requirement (access to the system can be achieved in many ways – passwords are just one mechanism, biometrics may be more appropriate to this product)
c. functional, business requirement (the requirement states what needs to be done, not how to do it)
d. non-functional
e. non-functional
f. functional, technical solution requirement (a specific technology is mandated)
g. non-functional

Question 51

Derive some functional requirements for the step of a scenario in a hotel management system stated as, ‘The system shall allocate an available cleaner to each occupied room’. Confine yourself to what must be done, not how it is to be done.

Answer 51

Here are some suggestions:

• the system shall identify occupied rooms
• the system shall identify available cleaners
• the system shall allocate occupied rooms among the available cleaners while balancing their workloads.

Question 52

From the following list of user stories indicate which ones are good stories and why.

a. As a user I can select the language for the pages of the website because I am not a native speaker.
b. As a user I can learn how to use the system easily so that I do not spend too much time.
c. As a chief information officer (CIO) I want the software to be written in C++.
d. As a user I want to be able to run the system on an Android phone.

Answer 52

a. Good, but may be too small
b. Not a good story because it is not measurable
c. Not a good story because it is a constraint on development. It could be a good story if the users were programmers wanting some library to be developed, or if there was a good reason for it. (Notice that the reason part of the story is missing in ‘as a [role] I want [feature] so that [reason]’.)
d. Good story. Notice that you can write a user story for a non-functional requirement.

Question 53

What is meant by a non-functional requirement?

Answer 53

A quality that a system must have.

Question 54

What are the eight classes of non-functional requirements as identified by Robertson and Robertson (2012)? Give a brief description for each requirement.

Answer 54

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 55

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

Answer 55

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

Question 56

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 56

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 57

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 57

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

Question 58

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

Answer 58

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 59

What do usability and humanity requirements describe?

Answer 59

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 60

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

Answer 60

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 61

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

Answer 61

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 62

What are the main kinds of performance requirements?

Answer 62

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

Question 63

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

Answer 63

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 64

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

Answer 64

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

Question 65

How do operational requirements differ from performance requirements?

Answer 65

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 66

What are the two main kinds of maintainability and support requirements?

Answer 66

The first is to do with keeping the product updated in the light of expected changes. For example you may know that new requirements are likely to occur at some point in the future e.g the product may need to be modified to accommodate changes in the law.

The second notion of maintainability is to do with mending the product when it fails. Support requirements concern any decisions on how the product is going to be supported that may affect the design, for example is there going to be a help desk?

Question 67

When do cultural requirements usually arise?

Answer 67

Cultural requirements usually arise when:

a) 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
b) eliciting requirements in an organisation different from one’s own.

Question 68

What is the best approach to dealing with cultural issues?

Answer 68

Obtain the help of stakeholders from that culture.

Question 69

Why are cultural requirements often difficult to deal with?

Answer 69

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 70

What is the most pressing reason for considering legal requirements?

Answer 70

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 71

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

Answer 71

Obtain help from the company’s lawyers.

Question 72

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

Answer 72

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

Question 73

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

Answer 73

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

a) the communication medium is insecure and users’ communications may be intercepted en route and read or altered
b) on an external network communications will pass through many third-party systems with unknown security measures which cannot be controlled.

Question 74

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

Answer 74

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 75

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

Answer 75

Access, privacy, integrity, audit and immunity.

Question 76

Distinguish between the five aspects of security.

Answer 76

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 77

Briefly describe the four forms an attack might take.

Answer 77

Disclosure of private information or the unauthorised release of information. For example, an intruder might intercept the network and read your messages en route.

Modification, loss of integrity, or the unauthorised alteration of data or information. Intruders might change messages or stored data.

Denial of use or service or loss of access, where there is some denial of network service to its authorised (legitimate) users. The intruder redirects messages or creates congestion by recycling messages.

Repudiation, where a legitimate user claims that they did not send or receive a particular message that was sent or received.

Question 78

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

Answer 78

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 79

What is a fit criterion?

Answer 79

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 80

Who needs the fit criteria?

Answer 80

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 81

When are fit criteria specified?

Answer 81

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 82

What is a fit criterion for a functional requirement?

Answer 82

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.

Question 83

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

Answer 83

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 84

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

Answer 84

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 85

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

Answer 85

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.

Question 86

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 86

Talking to the users about their own expectations and those of their customers might reveal that the preferred task time is one minute and currently it takes three minutes to answer a customer query because of a cumbersome search facility on the existing system. So 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.’

This example shows that the fit criterion is backed by empirical data of the current situation.

Question 87

Here is an example of a situation and a possible fit criterion for a requirement to address it.

Situation - Customers send letters to the customer services department complaining about unsatisfactory experiences with a particular product.

Fit criterion - To determine customer satisfaction, a possible fit criterion would be the number of letters complaining about the product within a defined time period.

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 87

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 88

Are fit criteria always attainable?

Answer 88

No. Fit criteria should specify realistic values, but even then they are not always attainable. Whether they are actually attainable or not depends on what happens during the development cycle. Constraints can arise when attempting to achieve the fit criteria because of, for example, the product’s operating environment, the client’s budget, or time. Measurements of fit criteria can only be made in reasonable ways and in reasonable times.

Question 89

What is the Volere template used for?

Answer 89

It is a template for a document that collates all the requirements of a system, together with other issues that may affect those requirements. The template provides a sort of container in which the information can be organised systematically.

Question 90

What are the five main sections of the Volere template? Give a brief description of each.

Answer 90

1. Project drivers - these are the reasons and motivators of the project. This section covers what the purpose of the project is and who the stakeholders are.
2. Project constraints - these are restrictions and limitations that apply to the project and the product. In this section of the template information about mandated constraints, naming conventions and terminology, and relevant facts and assumptions is recorded.
3. Functional requirements - these cover the functionality of the product. This section includes the scope of the work, the business data model and data dictionary, the scope of the product and the functional requirements.
4. Non-functional requirements - these are the properties the product must have. This section includes look-and-feel requirements, usability and human requirements, performance requirements, operational and environmental requirements, maintainability and support requirements, security requirements, cultural requirements, and legal requirements.
5. Project issues - these are not requirements, but concerns that are brought to light by the requirements activities. They appear in the requirements document because they help to clarify the requirements further. This section includes open issues, off-the-shelf-solutions,, new problems, tasks, migration to the new product, risks, costs, user documentation and training, waiting room, and ideas for solutions.

Question 91

The Volere template makes use of requirements shells (also known as snowcards) to record information about functional and non-functional requirements. What information should be recorded on these requirement shells?

Answer 91

• requirement number – this is to identify the requirement uniquely
• event/use case – identify which use case or event is associated with this requirement
• description – a one-sentence statement of the intent of the requirement
• rationale – why the requirement is considered important or necessary
• originator – who raised the requirement in the first instance
• fit criterion – this is the acceptance criterion, written in a quantified manner so that the solution can be tested against the requirement
• customer satisfaction/dissatisfaction – this is an indication of the customer’s reaction to the requirement’s omission from the solution
• priority – a mark of the value of the requirement for the customer
• conflicts – requirements that contradict this one or make this one less feasible
• supporting materials – link to other documents to help understand the requirement
• history – origin of and changes to the requirement.

Question 92

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

Answer 92

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.