Ivan Marsic Rutgers University

LECTURE 5: Requirements Engineering Ivan Marsic Rutgers University

Topics • Requirements Engineering Components • Requirements and User Stories • Agile Methods for Effort Estimation and Work Organization • Requirements Analysis • Acceptance Tests • Types of Requirements

Software Requirements • A requirementspecifies the business functions that the user will be able to perform using the system-to-be in different “situations” or “contexts”, and the kind of experience the user will have during this work • Other concerns, such as how the system will manage the resources (computing, network, …), how the system will manage and protect user’s data, etc. • User requirements will often be high-level, vague and incomplete. They are more like high-level goals, or business goals, rather than software requirements needed by the developer • When trying to achieve a given high-level goal, we will need to consider what matters, what are the important parameters, so that we can derive the detailed technical requirements • Only based on deeper understanding of detailed issues, we can identify important "scenarios" or "situations" and identify what parameters should be considered in each situation • Then using these parameters, we decide what the system should do, or how to respond to this situation (i.e., inputs)

Aspect-Oriented Requirements Object-Oriented Analysis & Design Requirements gathering Requirements analysis Requirements specification Structured Analysis & Design Agile Development User Stories Requirements Process

Requirements Engineering Components • Requirements gathering • (a.k.a. “requirements elicitation”) helps the customer to define what is required: what is to be accomplished, how the system will fit into the needs of the business, and how the system will be used on a day-to-day basis • Requirements analysis • refining and modifying the gathered requirements • Requirements specification • documenting the system requirements in a semiformal or formal manner to ensure clarity, consistency, and completeness

Practical Requirements Engineering • Test your idea in practice and use the result in further work, iterating through these creative and evaluative steps until a solution is reached • No one can know all the constraints for a solution before they go through the solving experience • Define the criteria for measuring the success (“acceptance tests”) • Avoid randomtrial-and-error by relying on domain knowledge (from publications or customer expertise)

Requirements and Specification Problem domain Software (Solution) domain Describes problem Specification Requirements Program Customer Specifies Analyzes Develops We receive “customer problem statement,” not the requirements! Software Engineer

Requirements Derivation Detecting that a problem exists is different from defining the problem and its causes, and solution constraints.Depending on the cause, the solution will be different. Requirements are determined by: • Judgment about customer’s business needs and causes preventing their achievement • Conditions on solutions imposed by real-world constrains: • Physical • Social/Cultural • Legal • Financial • … • Threats created by adversaries  Requirements are not simply desires! • Requirements are desires adjusted to real-world constraints and threats

Problem Analysis Examples • Traffic Monitoring: • Problem: User is delayed to work and needs help • Cause A: Traffic is unpredictable (predictably high if repeated delays?!) • Cause B: User is unfamiliar with the route • Cause C: User has a habit of starting late • Restaurant Automation: • Problem: Restaurant is operating at a loss and customers are unhappy • Cause A: Staff is encumbered with poor communication and clerical duties, resulting in inefficiencies • Cause B: The menu does not match the likeliest customer’s taste • Cause C: Staff is misbehaving with customers or mismanaging the food supplies • Health Monitoring: • Problem: User is leading unhealthy lifestyle and experiencing health problems • Cause A: User is trying to be active but unsure about sufficient level of activity • Cause B: User is trying to be active but too busy with other duties • Cause C: User cannot find affordable solutions for active lifestyle • Cause D: User has poor sleep • Cause E: User is aware of issues but not motivated to act

Problem Example: Safe Home Access • Problem detected: difficult access or unwanted intrusion(plus: operating household devices and minimizing living expenses) • Analysis of the Causes: • User forgets to lock the door or turn off the devices • User loses the physical key • Inability to track the history of accesses • Inability to remotely operate the lock and devices • Intruder gains access • System Requirements: based on the selected causes

As a tenant, I can unlock the doors to enter my apartment. user-role (benefactor) capability business-value Requirements as User Stories • Preferred tool in agile methods. • Focus on the user benefits, instead on system features as in older,IEEE Standard 830 type “requirements”. • User stories are less formal and emphasize automated acceptance tests.

Example User Story Requirements • Note no priorities for user stories • Story priority is given by its order of appearance on the work backlog (described later) • Estimated size points (last column) will be described later (also see 1st lecture)

Compare to IEEE-830 Style Requirements https://en.wikipedia.org/wiki/Software_requirements_specification • IEEE Standard 830 style requirements are more formal and cover more scenarios and details • When prioritizing requirements, “important” and “urgent” aspects can be confused • It is also difficult to assign a numeric value of priority to each requirement • It requires more mental effort than just rank-ordering the requirements in a linear sequence

Requirements Analysis • Requirement REQ-3 states that intruders will not be able to succeed with a “dictionary attack,” but many details need to be considered and many parameters determined (“business policies”) • What distinguishes user’s mistakes from “dictionary attacks” • The number of allowed failed attempts, relative to a predefined threshold value • The threshold shall be small, say three  business policy! • How is the mechanical lock related to the “blocked” state? • Can the user use the mechanical key when the system is “blocked”? • Requirement REQ-5 states that the keypad should be backlit when dark • Is it cost-effective to detect darkness vs. keep it always lit? • Etc. Requirements analysis should not be exhaustive,but should neither be avoided.

From Requirementsto Business Policies Explicit identification of business policies is important for two reasons: • Making the need for BP explicit allows involving other stakeholders, particularly the customer, in decision making about the BP solutions to adopt • Helps to anticipate potential future changes in the policies, so mechanisms can be implemented in the code that localize the future changes and allow quick substitution of implemented business policies These issues too important to be left to the programmer to make ad-hoc decisions and hard-code them.

Requirements Analysis Activities • Not only refinement of customer requirements, but also feasibility and how realistic • Needs to identify the points where business policies need to be applied. • Explicit identification of business policies (BP) is important for two reasons: • Making the need for BP explicit allows involving other stakeholders in decision about the solutions to adopt—Helps to involve others, particularly the customer, in decision making about each policy to adopt • Helps to anticipate potential future changes in the policies, so mechanisms can be implemented in the code that localize the future changes and allow quick substitution of business policies

Types of Requirements • Functional Requirements • Non-functional requirements (or quality requirements) • FURPS+ • Functionality (security), Usability, Reliability, Performance , Supportability • User interface requirements

User Interface Requirements • Do not waste your time and your customer’s time by creating elaborate screen shots with many embellishments, coloring, shading, etc., that serves only to distract attention from most important aspects of the interface • Hand-drawing the proposed interface forces you to economizeand focus on the most important features • Only when there is a consensus that a good design is reached, invest effort to prototype the interface https://arstechnica.com/gadgets/2018/01/with-ink-to-code-microsoft-is-turning-back-of-napkin-sketches-into-software/

Example: Safe Home Access User interface requirement: The UI must be simple for occasional visitors who will not have time to familiarize or to study user’s documentation. Initial design of the door keypad: • Analysis: • If “Unlock” button is not available, then the system could simply take the firstN digits and validate as the key. • If “Unlock” button is available, then the system could take the lastN digits and validate as the key (and ignore any number >N of previously entered digits). • The advantage of the latter approach is that it allows correcting for unintentional mistakes during typing, so the legitimate user can have more opportunities to attempt. • Note that this feature will not help the burglar trying a dictionary attack.

Example: Safe Home Access Redesigned door keypad: includes the “Unlock”&“Lock” buttons • Analysis: • When a user types in the key and the system reports an invalid key, the user may not know whether the problem is in his fingers or in his memory: “did I mistype the correct key, or I forgot the key?” • To help the user in such a situation, we may propose to include a numerical display that shows the digits as the user types.

Example: Safe Home Access Re-redesigned door keypad: includes the keycode display • Analysis: • There are several issues to consider about the display feature: • How much this feature would increase the overall cost? • Would the display make the door device bulky and inconvenient to install? • Would it be significantly more sensitive to rain and other elements? • Would the displayed information be helpful to an intruder trying to guess a valid key?

Tools for Requirements Eng. • Tools, such as user stories and use cases,used for: • Determining what exactly the user needs (“requirements analysis”) • Writing a description of what system will do (“requirements specification”) • Difficult to use the same tool for different tasks (analysis vs. specification)

Acceptance Tests • Means of assessing that the project success criteria • The requirements are met as expected • Conducted by the customer throughout the project, not only at the end • An acceptance test describes whether the system will pass or fail the test, given specific input values • We cannot ever guarantee 100% coverage of all usage scenarios, but systematic approach can increase the expecteddegree of coverage

Acceptance Tests • Each requirement describes for a given “situation” (i.e., system inputs), the output or behavior the system will produce • The “output” represents the user’s need or business goal • An acceptance test specifies a set of scenarios for determining whether the (part of the) system meets the customer requirements • An acceptance test casespecifies, for a given “situation” or “context” (defined by current system inputs), the output or behavior the system will produce in response • [See examples in Appendix G of the lecture notes]

Path size Travel velocity Agile Methods for Effort Estimation and Work Organization • Recall “hedge pruning points” from the first lecture • Size points assigned to each user story • Total work size estimate: • Total size =  (points-for-story i), i = 1..N • Velocity (= productivity) estimated from experience • Estimate the work duration Project duration =

Agile Estimation of Project Effort 2 points per day 1 = 4 pts (2 days) 2 = 7 pts (3.5 days) 3 = 10 pts (5 days) 4 = 3 pts (1.5 days) 5 = 4 pts (2 days) 6 = 2 pts (1 day) 7 = 4 pts (2 days) 8 = 7 pts (3.5 days) • Prune Section 6 1 day (2pts) • Prune Section 4 1.5 days (3pts) • Prune Section 1 2 days (4pts) • Prune Section 5 2 days (4p) • Prune Section 2 3.5 days (7p) • Prune Section 7 2 days (4p) • Prune Section 8 3.5 days (7p) • Prune Section 3 5 days (10p) 21 days Estimated work duration Work backlog 1) Prune Section 6 1 day (2pts) 2) Prune Section 4 1.5 days (3pts) Items pulled by the team into an iteration 3) Prune Section 1 2 days (4pts) 4) Prune Section 5 2 days (4pts) 5) Prune Section 2 3.5 days (7pts) 6) Prune … Work items 21 days 1st iteration 2nd iteration n-th iteration 5 days Time List prioritized by the customer Estimated completion date

Example User Stories

Agile Estimation of Project Effort 1 point per 2 days R1 = 4 pts (8 days) R2 = 7 pts (14 days) R3 = 7 pts (14 days) R4 = 6 pts (12 days) R5 = 3 pts (6 days) R6 = 2 pts (4 days) R7 = 10 pts (20 days) R8 = 6 pts (12 days) R9 = 6 pts (12 days) • Default Locked 8 day (4pts) • Unlock 14 days (7pts) • Prevent Attack 14 days (7pts) • Autolock 12 days (6p) • Backlit 6 days (3p) • Lock 4 days (2p) • Manage Users 20 days (10p) • View History 12 days (6p) • Set Preferences 12 days (6p) Estimated work duration To-do List 1) ST-4: Unlock 11 days (6pts) 2) ST-2: Lock 4 days (2pts) Items pulled by developers into an iteration 3) ST-5: Manage Users 14 days (8pts) 4) ST-7: Set Preferences 10 days (6pts) 102 days 5) ST-6: View History 7 days (4pts) 6) ST-_: Work items Work in progress 102 days 1st iteration 2nd iteration n-th iteration 30 days Time List prioritized by the customer Estimated completion date

Agile Prioritization of Work • Instead of assigning priorities, the customer creates an ordered list of user stories • Developers simply remove the top list items and work on them in the next iteration Work backlog 1) ST-4: Unlock 11 days (6pts) 2) ST-2: Lock 4 days (2pts) Items pulled by developers into an iteration 3) ST-5: Manage Users 14 days (8pts) 4) ST-7: Set Preferences 10 days (6pts) 5) ST-6: View History 7 days (4pts) 6) ST-_: 117 days 1st iteration 30 days Time List prioritized by the customer Estimated completion date

Tradeoff between Customer Flexibility and Developer Stability • Items pulled by developers into an iteration are not subject to further customer prioritization • Developers have a steady goal until the end of the current iteration • Customer has flexibility to change priorities in response to changing market forces Step 1: Remove from the backlog user stories scheduled for the next iteration Work backlog • ST-4: Unlock 11 days (6pts) • ST-2: Lock 4 days (2pts) 1) ST-5: Manage Users 14 days (8pts) 2) ST-7: Set Preferences 10 days (6pts) 3) ST-6: View History 7 days (4pts) 4) ST-_: Step 2: Shift remaining user stories to the top of the backlog and allow customer re-prioritization 117 days 1st iteration 30 days Time Work iteration currently in progress Estimated completion date

How To Combine the Part Sizes? Costs are not always additive But, solution (c) is not necessarily “cheaper” than (b) …

Additional Costs Highway traffic-circle interchange Traffic signs

Problem Decomposition System requirements provide the “projection axes” for problem decomposition —different subsets of requirements identify different sub-systems.

Software Engineering Problems • We assume that the computer/software helps the user to achieve a business goal in the problem domain • Problem domains can be virtual (e.g., text documents, relational databases), or physical world (a device to control, a person to notify and prompt to action) • Problem types: • Transforming one virtual object to another (document format conversion, e.g., from MS Word to PDF) • Modifying a virtual object (e.g., document editing) • Automatically controlling behavior of a physical object (e.g., thermostat) • Manually controlling behavior of a physical object (e.g., drone flying) • Observing behavior of a physical object (e.g., traffic monitoring)

Typical System Requirements REQ-1: Map/transform input data to output data as said by given rules REQ-2: Support repository (or document) editing, where “repository” is a collection of data items REQ-3: Automatically control a physical object/device REQ-4: Interactively control a physical object/device REQ-5: Monitor and display information about an object  Only a “5-dimensional” problem space! (Problem complexity can vary independently along each dimension) Note: These “typical requirements” will be discussed further under “Problem Frames”

Typical Software Eng. Problems 1.a) System transforms input document to output document 1. User works with computer system (problem domain is “virtual”, not physical) REQ-1: Map input data to output data as said by given rules IN doc System OUT doc 1.b) User edits information stored in a repository User System System REQ-2: Allow repository editing, where “repository” is a collection of data Repository User 2. Computer system controls the (physical) problem domain (user not involved) REQ-3: Automatically control a physical object/device System Problem domain 3.a) System observes the problem domain and displays information 3. Computer system intermediates between the user and the problem domain REQ-5: Monitor and display information about an object User System Problem domain 3.b) System controls the problem domain as commanded by the user User System Problem domain REQ-4: Interactively control a physical object/device Problem domain User System

Decomposition:Projection vs. Partitioning :Partitioning Projection: Projection-based decomposition helps us understand the components in the context of their use, relative to other parts of the system.

5-dimensional Problem Space • The five elementary problem types represent the coordinate system of the problem space • The “axis” projections represent the degree to which the whole problem contains a subproblem of this type • Each subproblem can be analyzed independently and eventually recombined into the whole problem • The structure of the solution should be selected to fit the problem structure Software problem to solve Simple editing (“Simple workpieces”) Data transformation Autonomous control (“Required behavior”) Manual control (“Commanded behavior”) Information display

Example: Problem Decomposition REQ1: keep door locked and auto-lock REQ2: lock when “LOCK” pressed REQ3: unlock when valid key provided REQ4: allow mistakes but prevent dictionary attacks REQ5: maintain a history log REQ6: adding/removing users at runtime REQ7: configuring device activation preferences REQ8: inspecting the access history REQ9: filing inquiries [ Case Study 1: Safe Home Access ] Required Behavior Commanded Behavior Information Display (database is the “display”) Simple Editing Simple Editing Information Display Simple Editing

Example: Problem Decomposition REQ1: view market prices and volumes Domains: exchange, display REQ2: place a trade Domains: investor, tradable-securities, pending-trades REQ3: execute trades when conditions matched Domains: exchange, pending-trades REQ4: generate periodic report Domains: portfolio, report REQ5: generate leaderboard Domains: all-portfolios, leaderboard REQ6: view leaderboard Domains: leaderboard, display REQ7: start a trading group/clique Domains: investor, group REQ8: invite to a trading group/clique Domains: investor, friends, group [ Case Study 2: Investment Fantasy League ] Information Display Simple Editing Required Behavior Transformation Transformation Information Display Simple Editing Commanded Behavior

Problem Domains &Their Interactions Software-to-be Physical (causal) domain Information (lexical) domain Human (biddable) domain Information controls physical world People control physical world Information observed from physical world People create/edit information Information transformed/summarized People interact/collaborate

Ivan Marsic Rutgers University