Unit 2 - Requirements Concepts Flashcards
Where and when does the requirements engineering process take place in an iterative and incremental development process?
The main output of a requirements engineering process is the contract between those commissioning the system and the developers of the system. It therefore has to take place early in the software development process. However, an iterative and incremental process recognises that requirements are not stable, and that revisiting, clarifying and specifying requirements occurs in parallel with the other phases of development.
(a) Identify the stakeholders for a system to book appointments for a hospital.
(b) Suggest ways in which requirements may evolve.
(a) Stakeholders include hospital administrators, receptionists, doctors, nurses, patients and the general public.
(b) New requirements may be added. Existing requirements may change because of changes in the environment or in the organisation. Some requirements may become obsolete.
Consider the following list of poorly expressed requirements. Indicate which of the properties introduced in Subsection 2.1 are not respected, and ask a question to clarify the meaning of the requirement.
(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.
(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?
(a) What are requirements and stakeholders, and how do they relate to each other?
(b) What are the benefits of documenting requirements within a project?
(a) Requirements are the functions and qualities we want of a product. Stakeholders are the people and organisations with a vested interest in the product. Requirements arise from stakeholders’ needs.
(b) Requirements documentation records decisions; it is the main reference for what should be built, and the basis for validation of the built system.
(a) Who are the stakeholders in a hotel reservation system?
(b) Consider the example of a hotel reservation system, and invent some examples of the main inputs for a requirements engineering process.
(a) The stakeholders include the hotel owners, receptionists, existing customers and the general public accessing the system to make reservations.
(b) Examples of inputs 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 on that floor;
existing documentation
– there is a manual system currently used for reservations;
regulations and organisational standards
– an acknowledgement is sent to every customer that makes a reservation.
(a) What are the purposes of a requirements document?
(b) What is a functional requirement?
(c) What is one property that a functional requirement should not possess?
(d) What is a non-functional requirement?
(e) What is a technical solution requirement and what is a business functional requirement? Why is it useful to distinguish them?
(f) What overarching property should the set of functional requirements that result from a requirements gathering process possess?
(g) How do business events and use cases help in determining functional requirements?
(a) A requirements document is for communication – from the requirements engineer to the designer. It serves as a contract with the client (and other stakeholders) for what the system must do.
(b) A functional requirement describes an action that the product must take if it is to carry out the work it is intended to do.
(c) A functional requirement should not be a statement about a quality.
(d) A non-functional requirement is a requirement about a quality that the product must have.
(e) A technical solution requirement is a constraint on the product due to the technology of the solution that must be adopted.
A business functional requirement is a specification of the work, or business, independent of the way that work will be carried out.
Thus the two types of requirement arise from different domains: the business domain and the solution domain. We want to keep issues related to the business separate from those of the solution.
(f) The set of functional requirements must fully describe the actions that the intended product can 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.
(g) Use cases are derived from business events, and each use case is described by a set of scenarios. A scenario is a series of steps that complete the functional tasks of a use case. A task is something that the actor identifies as being part of the work of the use case. Thus the steps in a scenario provide a mechanism (thinking technique) for determining all the functional requirements needed by each step.
(a) How do you discover whether a set of functional requirements are sufficient for the product to be useful, and whether the functionality is correct?
(b) Why must functional requirements be testable?
(c) Can you think of some generic questions to ask that can help in making requirements precise and complete?
(d) What is the major problem with a requirement that is written in a natural language such as English?
(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?
(f) Why should you record the meanings of business and technical words in a requirements specification?
(a) Ask the user!
(b) It can then be determined whether the delivered product meets the intention of the user.
(c) Questions of the form ‘When should something happen?’ and ‘To whom should something be sent?’ are useful. You may have thought of others.
(d) Natural language is often ambiguous.
(e) It may be possible to avoid ambiguity entirely, but the cost of being so precise can be enormous and the result unreadable. Therefore, we accept having to live with some ambiguity, but try to ensure that the risk of doing so is acceptably small. One way in which you can try to reduce ambiguity is by providing clear definitions of any technical terms you use. A second way is by ensuring that requirements are not stated in too general terms.
(f) They should be recorded to avoid ambiguity and aid clarity in the usage of terms.
Summarise the overall process described above for determining a set of functional requirements.
1 Understand the domain, determining the business 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 – sets of steps.
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.
Here is a list of requirements that apply to the product X. For each requirement, say whether it is a functional or non-functional requirement, and if it is a functional requirement, say 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 3 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.
(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, but biometrics may be more appropriate to this product).
(c) Functional, business requirement (the requirements 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.
Derive some functional requirements for the following step of a scenario in a hotel management system: ‘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.
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.
Imagine that you have been commissioned to produce a Requirements Recording Tool. The purpose of the tool is to enable a requirements analyst to record information about each requirement for a product. An important requirement for the tool is that it should give its users the impression that they are dealing with a set of cards, each recording a requirement.
Without considering the detail of the information to be kept about each requirement, identify four functional requirements for managing a collection of such records. That is, what could the tool to do to help you record the requirements you have elicited so far, and maintain those requirements as you learn more about the required product? If the tool is to be used on different projects, what additional functionality should the tool possess?
Here are some of the functional requirements that relate to the management of a set of requirements. Yours may differ.
- The product shall enable a new requirement to be entered.
- The user shall be able to view each requirement in the set.
- The product shall enable a user to amend (edit) an individual requirement.
- The product shall enable the user to delete a selected requirement from the set of requirements.
- The product shall enable the user to view a summary of all requirements.
- The product shall show all requirements that conflict with a given requirement.
- The product shall perform a range of checks on the set of requirements.
- The user shall be able to view all requirements satisfying a given criterion, for example, those that mention particular terms.
- The product shall show a list of all requirements associated with a selected business event.
- The product shall enable the user to create and amend a set of requirements for a new product.
(a) What does the phrase ‘look and feel’ refer to?
(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?
(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?
(d) What general characteristics should the look and feel of a consumer product have?
(a) Look-and-feel requirements describe the overall appearance and behaviour of the product to its users.
(b) The production of a design is the task of the product’s designers, once they know the requirements. The look and feel are not about the specifics of the user interface.
(c) Fit criteria (dealt with in detail later in the unit) should be added to the requirements, to make them measurable.
(d) The look and feel is concerned with the impression we wish to make; we want it to reflect the distinctive values, ethos and style of our organisation.
(a) What do usability requirements describe?
(b) What are the effects of usability on a product?
(c) How might you express a usability requirement more precisely than simply ‘easy to learn’?
(a) Usability requirements specify how easy to use a product should be for its intended users under specified circumstances. They include requirements for how easy it should be to learn to use the product.
(b) Usability impacts on productivity, error rates, stress levels and acceptance. It determines how well the human part of the system can perform.
(c) A usability requirement can be expressed more precisely by describing the level of achievement required after the required training or learning period.
(a) What are the main kinds of performance requirement?
(b) Rather than accept requirements which state that some thing should be done speedily and/or efficiently, what should you aim for?
(a) Normally, the main performance requirements involve speed (the time to do something), capacity, reliability and accuracy.
(b) Look for requirements which specify the speed and efficiency in ways that can be measured objectively.
How do operational requirements differ from performance requirements?
Operational 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).