Rohela Raouf @rohelaraouf 

§ Everyone introduce themselves § Name § Project § Non-functional requirement engineering experience 

§ Is to understand: § What are non-functional requirements § When can they be used § How acceptance criteria should be used to support NFR § Elicitation requirements 

Participate Ask questions Share your experience Make mistakes & learn from them Request a break when you need to Respect break times Have fun 

REQUIREMENTS § The IIBA BaBOK defines requirements as: § A condition or capability needed by stakeholder to solve a problem or achieve an objective § A condition or capability that must be met or possessed by solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents § A documented representation of a condition or capability as in (1) or (2) 

Business Requirements: High level business needs and organisational/ IT policies to be satisfied, including project and other constraints- General: high level business requirements from which lower level, usually more specific, functional and non-functional Technical: specify the technical architecture for the solution Solution requirements: Specific requirements describing the solution to be developed. What the solution will do and how it will do it- Functional: defines what facilities and features the solution must provide and what rules it must follow = WHAT Non-functional: how solution will operate and include aspects such as solution performance, ease of use and security = HOW 

BATMOBILE EXAMPLE Functional: The batmobile shall: • Start when the key is turned • Accelerate from 0.60 in 3 seconds • Decelerate when the brakes are passed Vs Non-Functional: The batmobile shall be: • Fast • Fuel efficient • Maintainbility • Reliable • Bulletproof • Security 

Basically: Non-functional requirements describe how the product works, while functional requirements describe what the product should do 

TWITTER FAIL WHALE § Fail whale became famous because Twitter could not scale to meet the demands of rapidly growing user base § We don't know if Twitter team planned for scalability, but demand simply outstripped it or maybe they failed to plan for it 

Usability: Prioritize the important functions of the system based on usage patterns. 1 Reliability: Users have to trust the system, even after using it for a long time. 2 Performance: What should system response times be, as measured from any point, under what circumstances? 3 Supportability: The system needs to be cost-effective to maintain 4 

Execution qualities: such as performance and usability, which are observable at run time 1 Evolution qualities: such as testability, maintainability- which are embodied in the static structure of the software system 2 

Availability/Recoverability/Performance - The service needs to meet a standardised SLA tier which the Product Owner has assigned. Portability - To enable flexibility of technology choice and hosting platforms the service shouldn’t be tied to specific OS, DB, Cloud Provider etc. Usability - All applications should be available via a web interface and, where appropriate, a common user interface. Integration - To enable integration between services, all elements (data and functions) of the service should be exposed via APIs etc. Auditability - Transactions can be traced across systems for clarity and assurance. Maintainability - The service can be managed in the most efficient way by WebOps Engineers Security - The service must meet the constraints of applicable legislation and certification (DPA, CESG etc.) 

§ What are the functional requirements § What are the non- functional requirements 

No content

§ Two types of behaviour: § Behavioral diagrams shows what should happen in a system. They describe how the objects interact with each other to create a functioning system. Examples: Sequence Diagram/ Interaction Diagram/ Use Case Diagram § Structure diagrams show the things in a system being modelled. In a more technical term, they show different objects in a system. Examples: Object diagram/ deployment diagram/ class diagram 

Use Case Diagram is a behavioural UML Diagram Type and frequently used to analyse various systems. They enable the user to visualise different types of roles in a system and how those roles interact with the system Depending on your requirement you can use that data in different ways. Below are few ways to use them. To identify functions and how roles interact with them – The primary purpose of use case diagrams. For a high level view of the system – Especially useful when presenting to managers or stakeholders. You can highlight the roles that interact with the system and the functionality provided by the system without going deep into inner workings of the system. To identify internal and external factors – This might sound simple but in large complex projects a system can be identified as an external role in another use case. 

Actor (M): Actor in a use case diagram is any entity that performs a role in one given system. This could be a person, organization or an external system and usually drawn like skeleton shown below. 01 Use case (M): A use case represents a function or an action within the system. Its drawn as an oval and named with the function. 02 System (O): System is used to define the scope of the use case and drawn as a rectangle. For example you can create all the use cases and then use the system object to define the scope covered by your project. Or you can even use it to show the different areas covered in different releases 03 Package (O): Package that enable the users to organise Use Cases into groups. Packages should only be used when diagrams become unwieldy, which generally implies they cannot be printed on single page, to organise a large diagram into a smaller ones. It is similar to to Class diagram 04 

§ There are five types of relationships in a use case diagram: § Association between an actor and a use case § Generalization of an actor § Extend relationship between two use cases § Include relationship between two use cases § Generalization of a use case 

§ What will the use case diagram look like for Ebay 

§ The class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application § So the purpose of the class diagram can be summarized as: § Analysis and design of the static view of an application. § Describe responsibilities of a system. § Base for component and deployment diagrams. § Forward and reverse engineering. 

§ In class diagram, classes are represented with boxes that contain three compartments: § The top compartment contains the name of the class. It is printed in bold and centered, and the first letter is capitalized. § The middle compartment contains the attributes of the class. They are left-aligned and the first letter is lowercase. § The bottom compartment contains the operations the class can execute. They are also left-aligned and the first letter is lowercase. § In the design of a system, a number of classes are identified and grouped together in a class diagram that helps to determine the static relations between them. With detailed modelling, the classes of the conceptual design are often split into a number of subclasses 

§ What will the Class diagram for Amazon look like? 

No content

# § Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. § What’s the purpose of acceptance criteria? § Define the boundaries for a user story/feature § Help the product owner answer what they need in order for this feature to provide value (typically these are the minimum functional requirements) § Help the team gain a shared understanding of the story/feature § Help developers and testers to derive tests § Help developers know when to stop adding more functionality to a story 

§ State an intent not a solution (e.g. “The user can choose an account” rather than “The user can select the account from a drop-down”) § Are independent of implementation (ideally the phrasing would be the same regardless whether this feature/story would be implemented on e.g. web, mobile or a voice activated system) § Are relatively high level (not every detail needs to be in writing) 

§ BDD provides a formal application building framework that combines agile software development (ASD), test driven development (TDD) and other principles to build software products. § BDD works by associating business outcome as a "story" or specification that defines its requirements, business benefits and common testing methodology used to ascertain the completion of a software unit.BDD distributes stakeholders between two distinct classes, as follows: § Core stakeholders: Focus on business objectives, outcomes and application behavior § Incidental stakeholders: Functional and non-functional people work to provide the desired application behavior and outcome § * source: https://www.techopedia.com/definition/28738/behavior-driven-development-bdd 

No content

§ Acceptance criteria are story specific requirements that must be met for the story to be completed. § They are a technique for adding functional detail to user stories. VS § The definition of done is a list of things that need to be completed for any story to be considered done. § The definition of done is agreed by the team prior to starting work. It covers what the team feels is necessary to consider any story done 

As a customer, I want to withdraw cash from an ATM, so that I don’t have to wait in line at the bank. User story +Scenario 1: Account is in credit+ Given the account is in credit And the card is valid And the dispenser contains cash When the customer requests cash Then ensure the account is debited And ensure cash is dispensed And ensure the card is returned +Scenario 2: Account is overdrawn past the overdraft limit+ Given the account is overdrawn And the card is valid When the customer requests cash Then ensure a rejection message is displayed And ensure cash is not dispensed And ensure the card is returned * Dan North 

No content

*google image 

No content

YOUR TURN: MOBILE PHONE § What are the non-functional requirements for mobile phones: § Think about: § Security § Portability § Availability § Maintability § Usability § Integration § Performance § Recoverability 

No content