NF+FR requirements User.pptxxxxxxxxxxxxxx

user requirements

1. Requirements Engineering Stakeholders, Requirements Engineering and Elicitation 1

2. What is Requirements Engineering? “The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.” “A systematic approach to eliciting, organising, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.”

3. Requirements Engineering Activities Elicitation: Identify and gather sources of information about the software system. Analysis: Understand the requirements of the customers including overlaps and conflicts. Validation: Check whether the requirements are what stakeholders expect. Negotiation: Reconcile requirement conflicts in order to reach the consistency. Documentation: Document all the requirements in formal documents. Management: If requirement changes occur, they should be managed carefully.

4. Requirements Engineering Activities Requirements Management Requirements Documentation

5. Functional and non-Functional Requirements Stakeholders, Requirements Engineering and Elicitation 5

6. What is a Requirement? A statement of needs from a stakeholder for a planned system Description of the system services and constraints that are generated during the requirements engineering process May range from A high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification May be Functional (FR) or Non-functional (NF)

7. Functional Requirements What the user will be able to do using the system. “Check room availability” “Make payment” “Cancel room booking” Usually involved with data being processed in some ways. “Register new member” ... data being stored. “Update profile” ... old data being changed to new. “Produce sales report” ... Data being organised and presented in a specified format. Sometimes having interactions with other (external) systems. “Make payment” ... credit card companies, PayPal, etc. “Check credit” ... checking your credit score with credit reference agencies. These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract. Example . A system must send an email whenever a certain condition is met (e.g., an order is placed, a customer signs up, etc.).

8. Naming a Requirement Name functional requirements as GOALs i.e., something you are trying to achieve Write requirement names in verb - noun format, e.g. Print invoice Set alarm Check room availability Make a call Delete message

9. Search product; View search results; Read review Add to buy list; Check out; View product detail; View Deals of the Week; Manage my account; View order history; Manage payment detail; Sell books Buy gift certificates Manage address book Manage communications with Amazon Manage my profile Write review Read reviews Manage wish list Contact s eller Examples of Amazon.co.uk FRs

10. Activity Create a set of Functional Requirements for a Learning Management System like Teams Begin with a list, remember the format is ‘verb-noun’

11. Activity Now what are the different types of users? List these. What additional functional requirements do you need? Begin to categorise your requirements by user type

12. Activity Different types of users: Staff – lecturers, librarians, system administration, course administrators etc. Students External staff Etc. What have you missed out? How can we best illustrate / analyse these lists?

13. Non-functional Requirements Constraints on the services or functions offered by the system (e.g.) timing constraint developmental constraint Standards constraint NFRs are a statements of constraints that may impact Functional Requirements Also sometimes called Quality requirements Simple Example: Create report = FR Report must be accessible in PDF format = NFR

14. Non-functional Requirements Examples of NFR characteristics include: Performance Safety Security Dependability Usability Costs Timescales Format

15. Non-functional Requirements May be system wide ( i.e. standalone) audit and control, system constraints, archival, usability “System must be able to operate in depot environment” “Software must run under Windows 10” May be associated with a specific functional requirement service level requirements, access restrictions, security “Check room availability response within 5 secs” Should be quantifiable (measurable) and testable wherever possible “One hour training should enable user to perform Booking Confirmation in less than 2 minutes unaided.”

16. Naming a Non-Functional Requirement How to present non-functional requirements? Use the following naming construct: Example outcomes “The system must support customer bookings online.” “The fleet database must provide vehicle availability in real-time.” “The accounting system should facilitate multi-user access.” NOUN AUXILIARY VERB VERB REGION OF INTEREST CONSTRAINT Examples: System Fleet Database Booking Database Accounting system Examples: Should Must Examples: Detail Facilitate Support Operate Enable Update Provide Show Examples: Customer Bookings Vehicle Availability Driver Availability Multi-user Examples: In real-time Online From all local offices Access

17. Examples of System-Wide NFRs Development Constraints (DC) Example DC-1: The Booking System shall operate with the following Web DC-2: Workstations installed in depots must be protected and resilient to that physical environment. User Interfaces (UI) Example UI-1: The Booking System screen displays, shall conform to the company’s Internet Application User Interface Standard, Version 4.1.5 Examples: Emails should be sent with a latency of no greater than 12 hours from such an activity.

18. Some Non-functional Requirements Measures Non-FR Category Measure Performance number of transactions per unit time; response time; turnaround time Usability Training time; number of assists; time-on-task; % errors Availability Time duration Reliability Fail rate; probability of unavailability Robustness Time to recover from failure; % of events causing failure; probability of data corruption on failure Portability number of target systems Size Gigabyte; Terabyte

19. Documenting Requirements Textual form Requirement description Requirement catalogue Use case description Diagram form Hierarchical diagram Use Case diagram* Context diagram ER diagram (class diagram)

20. User Stories  Brief description of functionality as viewed by a user or customer. Free form without mandatory syntax. Useful template: “As a <type of user> I want <capability> so that <business value>.”

21. Summing as an example

22. Forthcoming Workshop You will be identifying requirements for your application. You will need to create a set of: Functional requirements Non-functional requirements, and User stories