Slide 1

Slide 1 text

CSE360 Introduction to Software Engineering Lecture 09: User Stories Javier Gonzalez-Sanchez [email protected] javiergs.engineering.asu.edu Office Hours: By appointment

Slide 2

Slide 2 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 2 Where we are? Process Requirements Concepts functional non-functional Specification user stories Scenarios (use cases) SRS Planning Modeling Coding Deployment

Slide 3

Slide 3 text

User Stories

Slide 4

Slide 4 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 4 1. Natural Language • Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. • Use text highlighting to identify key parts of the requirement. • Avoid the use of computer jargon (clarity) • Include an explanation (rationale) of why a requirement is necessary. • Split large stories into multiple smaller user stories • Customer is available for clarification

Slide 5

Slide 5 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 5 1. Example (good) • As a user, I can backup my entire hard drive. • As a power user, I can specify files or folders to backup based on file size, date created and date modified. • As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.

Slide 6

Slide 6 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 6 1. Example (better) • 3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.) • 3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.)

Slide 7

Slide 7 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 7 1. Example (better) • 3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.) • 3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.) Did you notice: What and Why but not How (not at computer level)

Slide 8

Slide 8 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 8 Problems with User Stories It is all about writing skills: • Lack of clarity. Precision is difficult without making the document difficult to read. • Requirements confusion. Functional and non- functional requirements tend to be mixed-up. Or non-functional tend to be ignored • Requirements amalgamation. Several different requirements should not be expressed together.

Slide 9

Slide 9 text

Use Cases Diagrams

Slide 10

Slide 10 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 10 5. Graphical Representation

Slide 11

Slide 11 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 11 UML Unified Modeling language (UML) is a standardized modeling language enabling developers to specify, visualize, construct and document artifacts of a software system.

Slide 12

Slide 12 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 12 Introducing UML

Slide 13

Slide 13 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 13 Use Case Diagram • A use case is an scenario • A use cases identify actors (user roles and/or systems) • A use case identify sets of related requirements and their interconnections

Slide 14

Slide 14 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 14 Example 1

Slide 15

Slide 15 text

CSE360 – Introduction to Software Engineering Javier Gonzalez-Sanchez [email protected] Summer 2017 Disclaimer. These slides can only be used as study material for the class CSE360 at ASU. They cannot be distributed or used for another purpose.