Requirements

Outline Definition Requirements Process Requirements Documentation Next Steps 1

Definition Recall that Requirements is the first step in the software engineering process Requirements state the purpose of the software system 2 Requirements Design Implementation Testing Deployment

Definition Requirements state the purpose of the software system Extremely useful for: Communicating with customers Communicating with co-workers Keeping track of what needs to get done Helping you and the customer decide what really needs to get done 3

Definition Good requirements are: 4 Correct Consistent Unambiguous Complete Feasible Relevant Testable Traceable

Standish survey (1994) 350 companies surveyed 8000 software projects 31% cancelled before finished 9% delivered on time and within budget (large companies) 16% delivered on time and within budget (small companies) 5

Standish survey (1994) Top factors for failed software projects: 1.Incomplete requirements (13.1%) 2.Lack of user involvement (12.4%) 3.Lack of resources (10.6%) 4.Unrealistic expectations (9.9%) 5.Lack of executive support (9.3%) 6.Changing requirements and specifications (8.7%) 7.Lack of planning (8.1%) 8.System no longer needed (7.5%) 6

Outline Definition Requirements Process Requirements Documentation Next Steps 7

Elicitation Requirements Process 8 Software Requirements Specification (SRS) Software Requirements Specification (SRS) Analysis Specification Validation

Requirements Process Elicitation Collecting the user’s requirements Analysis Understanding and modeling the desired behavior Specification Documenting the behavior of the proposed software system Validation Checking that our specification matches the user’s requirements 9

Requirements Process: Elicitation Critical part of requirements process Variety of techniques to determine what customers want Rarely as simple as “asking the right questions” Communication gap between engineers and customers Engineers don’t know business jargon Customers don’t understand computer science jargon 10

Requirements Process: Elicitation Know your stakeholders: People who have something to contribute to the requirements Has particular view(s) of how system should work Example stakeholders: Clients: paying for the software development Customers: buy software after developed Domain experts: familiar with problem Software engineers: technical feasibility of problem Market researchers, lawyers, auditors… 11

Requirements Process: Elicitation How to gather requirements: Interview stakeholders (individually and in groups) Review available documentation and standards Observe current systems (if available) Observe manual processes Brainstorm with future users Requires interpersonal skills!!! 12

Requirements Process: Elicitation Robertson & Robertson model for requirement sources 13 elicit requirements stakeholder wants and needs current organizations and systems existing documents suggested requirements reusable requirements current situation model domain models

14

Requirements Process: Analysis “Understanding and modeling the desired behavior” Transforming elicited requirements into specifications… Types of requirements: Functional requirements Nonfunctional requirements 15

Requirements Process: Analysis Functional requirements Required behavior of software system Reactions to inputs State before / after events 16 ???

Requirements Process: Analysis Nonfunctional requirements Quality characteristic of software How “well” the system works Ease of use Response time Reliability Maintenance 17

Requirements Process: Analysis Conflict resolution is part of requirements analysis With multiple stakeholders, conflicts bound to occur Opinions on what requirements should be One way to resolve: prioritize requirements 1.Essential? 2.Desirable? 3.Optional? 18

Requirements Process: Specification “Documenting the behavior of the proposed software system” 1.Requirements definition What software system should do 2.Requirements specification How software system will work 19

Requirements Process: Specification Requirement definition Role of the system External From perspective of client, user, or business Non-technical in nature Treats software system as “black box” Inputs and outputs only Doesn’t care what’s inside 20 ?

Requirements Process: Specification Requirements specification How the system works Internal Perspective of software engineer Technical in nature Inside the “black box” 21

Break Time!!! 22

Outline Definition Requirements Process Requirements Documentation Next Steps 23

Requirements Documentation Typical parts of Requirements Document Functional requirements Behavior of the software system Nonfunctional requirements Quality characteristics of software system Diagrams (more on this next time..) 24

Functional Requirements Documentation Unstructured: more general Requirement definitions Requirement specifications Structured: more formal and precise Use cases describe ways to “use the system” Each use case “like a bundle of scenarios” All the same except minor details 25

Use Case Name: Succinct and meaningful Actor: Who “does” the activity? Preconditions: What is true before the activity? Postconditions: What is true after the activity? Flow of events: What steps to the actor and system perform during the scenario? 26

Use Case #1: “Report Avalanche” Name: Report Avalanche Actor: backcountry skier with avalanche reporting app Preconditions: Skier has cell phone service Skier reports avalanche using app Postconditions: System has recorded avalanche event, location, and time of day. 27

Use Case #1: “Report Avalanche” (cont.) Flow of events: User reports avalanche using Smartphone app System retrieves avalanche event System parses avalanche location and time of day If location and time unknown, system asks user for more information (use case #2) 28

Use Case #2: “Clarify Location and Time” Name: Clarify Location and Time Actor: backcountry skier with avalanche reporting app Preconditions: Skier sent information without location and time Postconditions: System updates avalanche event’s location and time of day. Flow of Events: System contacts user, asks to update location and time of avalanche User estimates the location and time of reported avalanche System receives updated location and time, updates avy info 29

Use Case Diagrams 30 backcountry skier Use Case #2: Clarify Location and Time Use Case #2: Clarify Location and Time Use Case #1: Report Avalanche

31 backcountry skier Use Case #2: Clarify Location and Time Use Case #2: Clarify Location and Time Use Case #1: Report Avalanche avalanche forecaster Use Case #3: View Recent Avalanche Activity Use Case #3b: View by Location Use Case #3b: View by Location Use Case #3a: View by Time Use Case #3a: View by Time

Requirements Documentation Typical parts of Requirements Document Functional requirements Behavior of the software system Nonfunctional requirements Quality characteristics of software system Diagrams (more on this next time..) 32

Nonfunctional Requirements Documentation Define quality characteristics of software system Describe “how well” the system should function Can be written as unstructured text Often written in terms of fit criteria How good does the system need to be? Fit criteria should not be imagined, but based on client needs 33

Nonfunctional Requirements Documentation Typical quality characteristics: 34 Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reusability Interoperability

Requirements Documentation Typical parts of Requirements Document Functional requirements Behavior of the software system Nonfunctional requirements Quality characteristics of software system Diagrams (more on this next time..) 35

Diagrams (preview) Use case diagram Shows supported activities UML class and entity-relationship diagrams Shows entities, attributes, and relationships Dataflow diagram Shows flow of information Message sequence diagram Shows flow of control State chart Shows change over time 36

Outline Definition Requirements Process Requirements Documentation Next Steps 37

Next Steps… Meet your “customer” today Start with obtaining use cases Homework 1 is due soon… Next time: Notation 38