CSE360 Lecture 09

Introduction to Software Engineering
User Stories
(201805)

Transcript

1. CSE360 Introduction to Software Engineering Lecture 09: User Stories Javier Gonzalez-Sanchez javiergs@asu.edu javiergs.engineering.asu.edu Office Hours: By appointment
2. 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
3. User Stories
4. 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
5. 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.
6. 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.)
7. 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)
8. 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.
9. Use Cases Diagrams
10. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 10 5. Graphical Representation
11. 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.
12. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 12 Introducing UML
13. 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
14. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 14 Example 1
15. CSE360 – Introduction to Software Engineering Javier Gonzalez-Sanchez javiergs@asu.edu 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.