Tweet
Tweet

Slide 1

Slide 1 text

CSE360 Introduction to Software Engineering Lecture 07: Requirements 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 Requirements Engineering

Slide 3

Slide 3 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 3 Where we are? Process Requirements Concepts Specification SRS Planning Modeling Coding Deployment

Slide 4

Slide 4 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 4 Concepts necessities requirements

Slide 5

Slide 5 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 5 Requirements are: § Clear, Comprehensible, Coherent, § Unambiguous § Consistent § Verifiable § Traceable § Prioritized

Slide 6

Slide 6 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 6 Concepts necessities requirements functional requirement non-functional requirement

Slide 7

Slide 7 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 7 Functional Requirement a) services the system should provide, b) how the system should react to particular inputs, and c) how the system should behave in particular situations. d) May state what (reactions, behaviours, or services) the system should not do.

Slide 8

Slide 8 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 8 Examples • Search option given to user to search from various invoices. • User should be able to mail any report to management. • Users can be divided into groups and groups can be given separate rights. What about • Pac-man? • Blackboard? • MyASU? • Recitation Project 1?

Slide 9

Slide 9 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 9 Non-functional Requirement Non-functional requirements a) Constraints on the services or functions offered by the system, such as Standards to apply, development platform, timing constraints, constraints on the development process, etc. a) Quality attributes, such as performance specifications, robustness, usability, etc.

Slide 10

Slide 10 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 10 Types of Non-Functional Requirements

Slide 11

Slide 11 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 11 Examples (Constraints) • Should comply business rules and administrative functions. • Software is developed keeping downward compatibility intact. What about • Pac-man? • Blackboard? • MyASU? • Recitation Project 1 (user-friendly)?

Slide 12

Slide 12 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 12 Examples (Quality) Property Measure Speed • Processed transactions/second • User/event response time • Screen refresh time Size • Mbytes • Number of ROM chips Ease of use • Training time • Number of help frames Reliability • Mean time to failure • Probability of unavailability • Rate of failure occurrence • Availability Robustness • Time to restart after failure • Percentage of events causing failure • Probability of data corruption on failure Portability • Percentage of target dependent statements • Number of target systems

Slide 13

Slide 13 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 13 to be continued… (read chapter 4)

Slide 14

Slide 14 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 14 Validating Requirements • Is each requirement bounded and unambiguous? • Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? • Is each requirement consistent with the overall objective for the system/product? • Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? • Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? • Do any requirements conflict with other requirements?

Slide 15

Slide 15 text

Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 15 Validating Requirements • Is each requirement achievable in the technical environment that will house the system or product? • Is each requirement testable, once implemented? • Does the requirements model properly reflect the information, function and behavior of the system to be built. • Has the requirements model been partitioned in a way that exposes progressively more detailed information about the system (correct use of generalization/specialization, include, and extends).

Slide 16

Slide 16 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.