TM354 Software Engineering Requirements - Arab Open University PDF

TM354: Software Engineering Block I: From domain to requirements Unit 2: Requirements concepts 1  Unit aims  In this unit, you will see an approach that stresses the importance of carefully documenting requirements, but y...

TM354: Software Engineering Block I: From domain to requirements Unit 2: Requirements concepts 1  Unit aims  In this unit, you will see an approach that stresses the importance of carefully documenting requirements, but you will also be reminded of an agile approach to documentation.  You will see the differences between functional and non-functional requirements, and the ways each of these can be recorded.  The importance of attaching measurable fit criteria to each requirement will be established.  Finally, you will see how you can make use of a template to help ensure you cover all the categories of requirements, and how you could document requirements in an agile approach. Note that: All SAQs and Exercises in this unit are required. 2  Section 1: Introduction  In this unit we introduce the concepts of user and software requirements.  We discuss the importance of documenting and managing requirements, and the complexity of the requirements engineering process.  Sections 3 and 4 define the two main classes of requirements: functional and non-functional, and Section 5 discusses the links between requirements and testing.  In Section 6 we introduce a template for requirements documentation that is based on a well-known method in the literature. 3  Section 2: Requirements  Requirements are the information about what a system will be and do that needs to be known before development starts.  The process of reaching and documenting an agreed set of requirements is known as requirements engineering  This is a complex process that involves stakeholders of the system  Examples of stakeholders are: ◦ 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. 4  Section 2: Requirements  Requirements engineering is an important activity in software development and the consequences of poor attention to this activity are costly  The Standish Group has been publishing reports on the success of software projects since 1994. In its latest report (2012) it identified that: ◦ only 39 per cent of all projects were being delivered on time, on budget, with required features and function ◦ 43 per cent were late or over budget or not delivering all required features ◦ 18 per cent were either cancelled before delivery or delivered but never used.  In its 2010 report the Standish Group also identified major problems and proposed its own solutions. Among these problems were the following: ◦ poor, or lack of, user involvement ◦ lack of clear business objectives ◦ under and over building – building features that are never used and not building all the required. features ◦ lack of support for agile processes and poor support for requirements and solutions evolving. together through collaborative teamwork. 5  Section 2: Requirements The nature of requirements  The specification of the requirements for a system is not an easy task because: ◦ 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. 6  Section 2: Requirements Requirements need to be:  Necessary and traceable – each requirement should fulfil a purpose and it should be clear where each requirement comes from.  Non-ambiguous and realistic – there should be no alternative interpretations for one requirement and it should be possible to carry each requirement through to development.  Complete – in a plan-driven development all the intended functionality is described as completely as possible, although in practice it is often not possible to be absolute about this and it is important to allow for requirements that emerge later in the system development and during maintenance.  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.  independent of design, avoiding design decisions that are not relevant at this stage. However avoidance of all design issues is not always practical 7  Section 2: Requirements  Requirements have numerous complex and non-trivial dependencies: they often conflict with each other. ◦ For example: the required portability of the mobile phone, and therefore its small size and display area, conflicts with the usability of the phone.  The dependencies between requirements need to be investigated at this stage of the software development life cycle. ◦ A practical approach for investigating the dependencies between requirements is to consider a few representative scenarios from a set of all the possible scenarios that illustrate the requirements in practice. ◦ a scenario: is a specific sequence of activities that might occur when a system is used. ◦ Scenarios can be helpful in contextualising the requirements and for identifying the conflicts and cooperations between them. 8  Section 2: Requirements The requirements engineering process  The inputs of a requirements engineering process: 1. Information from the stakeholders’ needs; 2. Information from existing knowledge of the domain and associated regulations, the organization's standards, and any systems that are already in place.  The outputs of a requirements engineering process: 1. The main output is the contract between the customer and the developers of the system. 2. The requirements document and the models of what the system is intended to do.  The requirements document includes the requirements specification that contain the precise and accurate descriptions of each requirement. 9  Section 2: Requirements The requirements engineering process  Activitiesof the requirements engineering process: a. requirements elicitation, b. requirements analysis and negotiation, c. requirements documentation, d. requirements validation. 10  Section 2: Requirements The requirements engineering process (a) 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 for change.  There are many techniques for elicitation, such as: ◦ interviews, ◦ focus groups, ◦ team meetings, ◦ brainstorming sessions. ◦ crowd sourcing ◦ There are also modeling techniques to help this process (e.g. activity diagrams, use cases). 11  Section 2: Requirements The requirements engineering process (b) Requirements analysis and negotiation is the activity where requirements are categorized and prioritized, and examined for their properties of consistency, completeness and non-ambiguity. ◦ Models of requirements are created to help communication with the customers and developers. (c) Requirements documentation is usually done using a template document.  Documentation also includes the modelling artefacts 12  Section 2: Requirements The requirements engineering process (d) 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.  Elicitation and analysis occur primarily, but not exclusively, at the beginning of a project, and their relative importance and effort vary over time. ◦ The process of requirements engineering is not generally linear and sequential. ◦ At each iteration of the process, activities may be revisited and adjustments made. 13  Section 2: Requirements The requirements engineering process Figure illustrates the relative effort of requirements elicitation and analysis in the early phases of a project and is naturally a simplification because it omits the other activities of the requirements engineering process. Initially, elicitation is dominant. Most of the time the two activities interact and inform each other – requirements elicitation informs the modelling of functionality and data (which is part of analysis), while analysis helps Figure: Relative effort of requirements elicitation versus.to discover new requirements analysis over time 14  Section 2: Requirements An agile perspective of requirements  The agile approach to software development has emerged from concerns about the way software was being developed, the need for it and its usefulness.  Agile development stresses the importance of documenting only when there is a well-defined purpose.  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. ◦ In their latest edition of Mastering the Requirements Process (2012), Suzanne and James Robertson accept that ‘The requirements do not have to be written, but they have to become known to the builders’ (Truth 5, Chapter 1). 15  Section 2: Requirements Requirements and architecture  Requirements may contradict each other, for example portability and usability in a mobile device, and a compromise will need to be achieved.  Solving these conflicts involves taking decisions that will affect the architecture of a system.  Some techniques that we will use to represent requirements help in taking decisions that affect the overall architecture of the intended system 16  Section 2: Requirements Requirements and testing  Testing is usually regarded as an activity that takes place at the end of software development, and this is what a waterfall process model suggests.  Testing can be done as soon as requirements are being analysed.  Requirements do not make much sense if there is no way that they can be tested.  When defining requirements, a developer may be implicitly thinking about tests that a system will have to go through. Requirements, if they are to be implemented successfully, must be measurable and testable. (Robertson and Robertson, 2012, Truth 10, Chapter 1) 17  Section 2: Requirements Summary of section  In this section we introduced software requirements and discussed their relevance in software development and the consequences that arise from a poor effort at understanding the requirements for a system.  We discussed the importance of involving the various stakeholders in the definition of requirements and the need to document requirements as a contract for development.  We considered the perspectives on requirements documents of plan- driven and agile approaches.  We also described the activities that take place in a requirements engineering process and other activities happening in parallel with requirements engineering. 18  Section 3: Functional requirements  A functional requirement describes the behavior of the system. ◦ specifications of the product’s functionality; ◦ actions that the product must take – check, calculate, record, retrieve etc. (verbs are functions); ◦ derived from the fundamental purpose of the product; ◦ not a quality  For example, ‘fast’ is a quality, and is therefore a non- functional requirement.  Adjectives talks about quality. 19  Section 3: Functional requirements Elicitation, analysis and negotiation  When eliciting functional requirements, attention must be paid to their relative importance.  It is important to identify those requirements that are essential and those that are inessential but would be nice to have.  Identifying the core requirements ought to identify the minimum cost and time for development.  Functional requirements should be prioritised so that the most important requirements can be identified.  In practice, when eliciting requirements you would probably use a way that best suits your experience and applications and that results probably from a combination of different approaches. 2020  Section 3: Functional requirements Elicitation, analysis and negotiation  Iterative requirements gathering ◦ One approach to prioritisation, which is used in the DSDM framework (dynamic systems development method), is the MoSCoW scheme, where requirements are classified as must have, should have, could have, and won’t have. ◦ This classification scheme can be used at the level of each iteration, allowing an iteration to be timeboxed. ◦ When the time allocated runs out, ‘should have’ and ‘could have’ requirements are delayed to a later iteration.  Requirements through stories ◦ 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. 2121  Section 3: Functional requirements Types of functional requirements:  Business requirement: tasks that system should do. Examples:  X must check a user’s identity.  X must produce a statement of the user’s account. - The requirement states what needs to be done, not how to do it.  Technical solution requirements: is a constraint on the product due to the technology of the solution that must be adopted. ◦ X must check a user’s password ◦ X must employ the company’s proprietary password maintenance system  Specific technology is mandated. 22  Section 3: Functional requirements Overall process (based on use cases) for determining a set of functional requirements 1. Understand the domain, determining the business processes that rare triggered by 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. 23  Section 3: Functional requirements  User requirements are usually written in natural language for obvious reasons.  Natural language or more formal approaches such as mathematical specifications can be used for system requirements  the major problem with a requirement that is written in a natural language such as English is ambiguity.  To avoid ambiguity attention has to be given to the language used to represent requirements. 24  Section 3: Functional requirements Sommerville distinguishes two types of requirements as follows: Requirements specification [is] the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the software requirements for the customer and end- user of the system; system requirements are a more detailed description of the functionality to be provided. (Sommerville, 2011) 25  Section 3: Functional requirements Summary of section  In this section we defined functional requirements and illustrated a process for eliciting them.  Also we discussed briefly an alternative agile process for dealing with requirements based on user stories.  We considered issues around the documentation of requirements and distinguished between technical solution requirements and business functional requirements. 26  Section 4: Non-Functional requirements  Non-functional requirements are qualities that the system should have: such as being secure, fast, usable or maintainable.  Examples of NFR: ◦ X must validate the user’s identity and password within 3 seconds: ◦ X must be usable by users with limited skills. ◦ X must operate in arctic climates (freezing weather). ◦ X must work fast, secure, etc. 27  Section 4: Non-Functional requirements Important points about NFR:  Non-functional requirements may be associated with a particular piece of functionality or with the overall system  One useful way to think of non-functional requirements is as constraints on the functional requirements ◦ From this perspective, functional requirements tell you what the system should do, and non-functional requirements constrain the ways in which those things are done – securely, quickly, and so on.  Non-functional requirements make sense only in relation to what they say about functional requirements  To have useful NFR, NFR must be testable (measurable) as well as FR.  In this respect the idea of fit criteria is introduced.  A fit criterion is a measurement of a requirement that will ultimately enable a tester to determine whether or not the delivered product satisfies, or fits, the requirement. 28  Section 4: Non-Functional requirements Robertson and Robertson (2012) identify the following eight classes of nonfunctional requirements: 1. Look-and-feel requirements. The spirit of the product’s appearance. 2. Usability and humanity requirements. The product’s ease of use and any special usability considerations. 3. Performance requirements. How fast, how safe, how accurate, how reliable, and how available the functionality must be. 4. 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. 5. Maintainability and support requirements. Expected changes, and the time allowed to make them. 6. Cultural requirements. Special requirements that come about because of the people involved in the product’s development and operation. 7. Legal requirements. The laws and standards that apply to the product. 8. Security requirements. The security and confidentiality of the product 29  Section 4: Non-Functional requirements  1. Look-and-feel requirements describe the overall appearance of the product to its users.  The look-and-feel requirements are not about the specifics of the user interface.  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  Some examples of look-and-feel requirements are: ◦ the product shall comply with the iOS human interface guidelines ◦ the product shall use only two colours ◦ the product should use a lot of animation ◦ the product shall use a large range of exciting sounds. 30  Section 4: Non-Functional requirements  2. Usability and humanity requirements: 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  Usability and humanity impacts on productivity, error rates, stress levels and acceptance. It determines how well the human part of the system can perform  A usability and humanity requirement can be expressed more precisely by describing the level of achievement required after the required training or learning period.  Some examples of usability and humanity requirements are: ◦ a university graduate should be able to learn to use 50 per cent of the functionality of the product in 2 hours ◦ ninety per cent of the general population should be able to place an order from a web interface within 5 minutes – 90 per cent of elderly users should be able to place an order from a web interface within 10 minutes ◦ it should be possible to use the system to pay in different currencies ◦ the system should comply with the Disability Discrimination Act. 31  Section 4: Non-Functional requirements Usability and humanity requirement can be split into two requirements:  An Easy to learn requirement: is contextual ◦ An easy-to-learn website for buying books might require zero training. ◦ An easy-to-learn accounts package might require a two-hour tutorial rather than a week of onsite training. ◦ An easy-to-learn nuclear reactor control system might require several months of training but not several years of experience  Easy-to-learn products are often aimed at tasks that are performed infrequently and that therefore have to be relearned from time to time, and are often aimed at the public market.  An easy to use product: ◦ Easy-to-use products are designed to facilitate efficiency and users may require training to be done before the product can be used effectively. 32  Section 4: Non-Functional requirements 3. Performance requirements: relate to the effectiveness of a system in carrying out its tasks.  Normally the main performance requirements involve speed (the time to do something), capacity, safety, accuracy, reliability and availability.  You should look for requirements that specify the speed and efficiency in ways that can be measured objectively.  It is hard to specify performance of web-based systems because there are too many unknowns, for example the speed of connection.  Some examples of performance requirements are: ◦ the product shall calculate a guest’s bill in 2 seconds ◦ the product shall handle up to 10 users simultaneously ◦ the product shall report wind speeds within 5 miles per hour of the actual speed ◦ the product shall, on average, operate without failure for 20 days. 33  Section 4: Non-Functional requirements 4. Operational and environmental requirements: relate to the environment in which a product is to be used.  Operational and environmental requirements describe the operational environment (factors external to the product) in which the product must function correctly  One approach to finding the operational and environmental requirements is to investigate the product boundary (the scope as defined by the use cases) and consider the needs of each system it interacts with  Some examples of operational and environmental requirements are: ◦ the product shall be usable above an altitude of x, in icy and wet conditions, and both in the dark and in bright sunshine ◦ the product will be used in a standard office environment, except that high levels of background noise may occur ◦ the product will need to be installed at 58 locations around the proposed route of the race in 2 days by 3 semi-skilled workers 34  Section 4: Non-Functional requirements 5. Maintainability and support requirements: There are two quite different notions of maintaining and supporting a product. 1. Keeping the product updated in the light of expected changes. 2. Fixing the product when it fails.  Some examples of maintainability and support requirements are: ◦ the product shall be able to be modified to cope with a new class of user ◦ the product shall be able to be modified to cope with minor changes to European law that occur every six months on average ◦ the product shall be portable to all the operating systems currently used in our Slough office. 35  Section 4: Non-Functional requirements (6) Cultural requirements  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  the best approach to dealing with cultural issues is to obtain the help of stakeholders from that culture.  Cultural and political requirements often involve having to ask personal questions and can be difficult to quantify. Such questioning is likely to be sensitive.  An example of a cultural requirement is: ◦ the language used in the interface should be formal and polite. 36  Section 4: Non-Functional requirements 7. Legal requirements : concern with two important areas from which requirements must be elicited are the law and the standards that apply to the product.  A third area related to law is the regulatory structure that controls some industries.  The cost of litigation is one of the major risks for commercial software, and can be expensive for other kinds of software. ◦ There are penalties for non-conformance with the law: fines, imprisonment and loss of reputation.  To determine the appropriate law that affects the product is to obtain help from the company’s lawyers. 37  Section 4: Non-Functional requirements 8. Security requirements  In the context of a computer system Security is about the prevention of unauthorised access to the system.  With a standalone computer it is possible to achieve security by physical means and you may wish to restrict the actions of individual users.  For a distributed computing system, which involves a number of interconnected computers, security becomes an issue.  On an external network, such as the internet, communications pass via a number of computer systems over which the user has no control.  A particular example where security is a major issue is that of ecommerce  Therefore security goes beyond the basic protection of resources to considering the computing system in its surroundings or environment 38  Section 4: Non-Functional requirements 8. Security requirements (contd.)  It is possible to make a system secure to deter unauthorised access but at the cost of making access by legitimate users extremely difficult.  Security requirements cover access, privacy, integrity, audit and immunity: ◦ access addresses uninterrupted or continual access to data and functionality by authorised users ◦ privacy addresses the protection of data from unauthorised access and disclosure ◦ integrity addresses consistency of data, the ability to prevent unauthorised modification or deletion of data ◦ audit addresses both how the correctness of product and data can be verified, and how to help detection of inappropriate access and intrusion ◦ immunity addresses the protection of a system against threats and attacks. 39  Section 4: Non-Functional requirements 8. Security requirements (contd.)  A computing system and its resources need to be protected from unauthorised access by those who seek to gain some advantage or act maliciously. They are intruders who try to read, change or delete the data that is stored, processed or passed around a computing system.  Some examples of intruders are: ◦ ‘crackers’ who test their skills against the security measures of a system for their personal pleasure ◦ competitors who try to gain access to commercially secret information ◦ fraudsters who try to obtain financial gain from the owner of the system or some third party. 40  Section 4: Non-Functional requirements 8. Security requirements (contd.)  The forms an attack might take are as follows:  Disclosure of private information or the unauthorised release of information ◦ Example, an intruder might intercept the network and read your messages en route. From an ecommerce transaction such as an electronic order you have placed, an intruder might be able to access your credit card details and illegally use them.  Modification, loss of integrity, or the unauthorised alteration of data or information ◦ Intruders might change messages or stored data. They might increase their bank balance either by directly modifying the data or by altering a message so that they become the payee of an online fund transfer, withdraw all the funds and then disappear.  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. They might also covertly gain control of the computers owned by innocent third parties and use these computers to bombard a site with messages. The intruder might be a competitor who is trying to put the company out of business by preventing access to its system by its customers.  Repudiation, where a legitimate user claims that they did not send or receive a particular message that was sent or received ◦ Example, somebody who ordered holiday insurance online might after the holiday claim that they did not order the insurance. The insurer could do a similar thing and repudiate that the customer ordered insurance if an insurance claim is made. 41  Section 4: Non-Functional requirements Summary of section  In this section we described the different types of non- functional requirements and their main characteristics and illustrated each type of non-functional requirement.  We looked in more detail at security requirements and the issues they raise. 42  Section 5: Conformance testing and fit criteria  The software product that we develop should satisfy all of the functional and nonfunctional requirements we identify.  Therefore, we need to test the product against its requirements. This test is known as conformance testing.  In order to do so, some criteria should be added to FR and NFR to make it measurable and testable at the end to see if they meet users’ need. These criteria are known as fit-criteria.  A fit criterion is a precise and testable statement of a requirement. It may specify: ◦ A quantitative measure for some aspect of the system’s behavior or performance; ◦ or define some other quality that the system must possess if it is to meet the requirement. 43  Section 5: Conformance testing and fit criteria  Benefits of attaching fit-criteria to requirements: ◦ Helps to clarify the requirement; ◦ Helpful communication tool for interacting with different stakeholders to check that the criteria being specified are acceptable and reflect the correct understanding of the requirement.  The fit criteria can be written or elicited as the requirements are elicited.  The parties that need fit criteria are: ◦ 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. 44  Section 5: Conformance testing and fit criteria  A fit criterion for a functional requirement specifies the completion of the function of the product that is specified by that functional requirement.  Example 1: FR fit criteria ◦ FR: send an email to the student after a marked TMA has been uploaded by the tutor, ◦ Fit criterion: an email should indeed be sent to the student and reflected in their mailbox on the forum.  Example 2: FR fit criteria ◦ FR: The system shall accept a credit card number from a client. ◦ Fit criterion: A valid credit card number has been stored in the system. 45  Section 5: Conformance testing and fit criteria  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 with which the requirement is concerned.  Example 1:  Look-and-feel requirement  Description. The student website for this module shall have a similar look and feel to other OU module websites.  Fit criterion. The TM354 module website shall conform to the OU web design and accessibility guidelines..  Example 2:  Maintainability and support requirement  Description. The websites of OU modules shall be updated frequently.  Fit criterion. Updates to OU module websites shall be made weekly and be visible to students within eight hours of being loaded.NFR fit criteria  Refer to the course material for more examples 46  Section 5: Conformance testing and fit criteria Summary of section  In this section we discussed the need for, and the concept of, fit criteria and applied them to different types of functional and non-functional requirements 47  Section 5: Representing the Requirements  Requirements need to be documented within a project.  Documentation may take many forms.  The one we adopt in this module is based on the Volere approach by Robertson and Robertson (2012),  The Volere template is a template for a document that collates all the requirements of a system, together with other issues that may affect those requirements. 48  Section 5: Representing the Requirements  The Volere template is organised into five main sections, each including a number of requirements categories. ◦ Project drivers ◦ Project constraints ◦ Functional requirements ◦ Non-functional requirements ◦ Project issues Please refer to page number 115-122  Functional and non-functional requirements are the core of the requirements document. While all other sections of the template can be filled in as freestyle text, the Volere approach recommends a more formal recording of functional and non- functional requirements. 49  Section 5: Representing the Requirements Information recorded for each FR/NFR:  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. 50 Section 5: Representing the Requirements Figure: Requirements snowcard 51  Section 5: Representing the Requirements Advantage of capturing requirements using a template  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. 52  Section 5: Representing the Requirements Summary  In this section we introduced the Volere template for the description of requirements.  We will give a detailed example of how the Volere template is used in Unit 4.  We also briefly introduced cards as a representation commonly used in agile development to trigger discussions on requirements. 53  Unit Summary After studying this unit you should be able to:  understand the nature and importance of requirements  describe the activities of a requirements engineering process  be aware of an agile approach to requirements  define and distinguish between functional and non-functional requirements  describe the various types of non-functional requirements  discuss the relation between requirements and testing  produce clear functional and non-functional requirements  produce measurable, and hence testable, functional and non-functional requirements  discuss the relation between requirements and testing  use a requirements template to write a requirements document in a structured way. 54