1. CS 281 Intro to Software Engineering Lecture 10b Understanding Requirements (1)

2. Chapter 8 Understanding Requirements
Slide Set to accompany Software Engineering: A Practitioner’s Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim
Slides copyright © 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman
For non-profit educational use only
May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 8/e. Any other reproduction or use is prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student use.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

3. Why Requirements Engineering?
Requirements engineering helps software engineers better understand the problems they are trying to solve
Building an elegant computer solution that ignores the customer's needs helps no one. Good requirements engineering helps in avoiding such situations

4. What is Requirements Engineering?
Begins during the communication activity and continues into the modeling activity
The intent of requirements engineering is to produce a written understanding of the customer's problem
Several different work products might be used to communicate this understanding (user scenarios, function and feature lists, analysis models, or specifications)
In some cases requirements engineering may be abbreviated, but it is never abandoned
The development team must understand the requirements before trying to solve the problem

5. Who does Requirements Engineering?
Software Engineers (sometimes referred as System Analysts)
Stakeholders from the software’s customer side
Managers
Customers
End-users

6. What happens when RE is done poorly?
What happens when RE is done poorly

7. Requirements Engineering Steps-I
1. Inception—ask a set of questions that establish …
basic understanding of the problem
the people who want a solution
the nature of the solution that is desired, and
the effectiveness of preliminary communication and collaboration between the customer and the developer
2. Elicitation—elicit requirements from all stakeholders
3. Elaboration—create an analysis model that identifies data, function and behavioral requirements
4. Negotiation—agree on a deliverable system that is realistic for developers and customers
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

8. Requirements Engineering Steps-II
5. Specification—can be one or more of the following:
A written document
A set of models
A formal mathematical model
A collection of user scenarios (use-cases)
A prototype
6. Validation—a review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies (a major problem with large systems)
conflicting or unrealistic (unachievable) requirements
7. Requirements management
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

9. CS 281 Intro to Software Engineering Lecture 11 Understanding Requirements (2)

10. First Midterm Exam Wednesday, 2 March (same time as the lecture)
75 minute duration
Will cover all lectures delivered before the exam date
Will consist of MCQ’s, fill-in-the-blanks, questions with short answers, and drawing of diagrams
If you miss this exam for any reason, you will have to appear for a makeup exam on the Thursday of the last week of teaching (5 May). That exam will cover all lectures delivered in the semester. It will consist of drawing of diagrams and answering questions having page answers

11. Inception Identify stakeholders Recognize multiple points of view
“who else do you think I should talk to?”
Recognize multiple points of view
Work toward collaboration
The first questions
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution?
Is there another source for the solution that you need?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

12. Eliciting Requirements
Meetings are attended by both developers & customer
Rules for preparation and participation are established
An agenda is suggested
A facilitator (customer, developer, or outsider) runs the meeting
A "definition mechanism" (can be worksheets, flip-charts, wall stickers, ebulletin board, chat room or virtual forum) is used
The goal is
to identify the problem
propose elements of the solution
negotiate different approaches, and
specify a preliminary set of solution requirements
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

13. Elicitation Work Products
A statement of need and feasibility
A bounded statement of scope for the system
A list of customers, users, and other stakeholders who participated in requirements elicitation
A description of the system’s technical environment
A list of requirements (organized by function) and the domain constraints that apply to each
A set of scenarios that provide insight into the use of the system under different operating conditions
Prototypes developed to better define requirements
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

14. Quality Function Deployment (QFD)
Qualitative Customer Needs
Qualitative Customer Needs
Detailed Software Requirements
Detailed Software Requirements

15. QFD Activities
Function deployment determines the “value” (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events
Task deployment examines the behavior of the system
Value analysis determines the relative priority of requirements
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

16. Non-Functional Requirements (NFR)
NFRs are the quality, performance, and security attributes, general system constraints (e.g. max available RAM), or process requirements (e.g. IDE)
Generally apply to the whole system rather than any particular feature
Often not easy for stakeholders to articulate
There is an overemphasis on functionality of the software, yet the software may not be useful or usable without the necessary non-functional characteristics
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

17. Use-Cases Scenarios that describe the threads of usage of a system
Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way
Each scenario answers the following questions:
Who is the primary actor, the secondary actor(s)?
What are the actor’s goals?
What preconditions should exist before the story begins?
What main tasks or functions are performed by the actor?
What extensions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

18. Actors
An actor is anything that communicates with the system and that is external to the system itself. Every actor has one or more goals when using the system
It is important to note that an actor and an end-user are not necessarily the same thing. A typical user may play a number of different roles when using a system
Primary actors interact to achieve required system function and derive the intended benefit from the system. They work directly with the system
Secondary actors support the system so that primary actors can do their work
Ref: Software Engineering: A Practitioner’s Approach, 8/e

19. Use Case Example for Operating the SafeHome Control Panel
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

20. Homeowner: observes control panel Homeowner: enters password
6. Scenario:
Homeowner: observes control panel
Homeowner: enters password
Homeowner: selects “stay” or “away”
Homeowner: observes read alarm light to indicate that SafeHome has been armed
1. Use case: InitiateMonitoring
2. Primary actor: Homeowner
3. Goal in context: To set the system to monitor sensors when the homeowner leaves the house or remains inside
4. Preconditions: System has been programmed for a password and to recognize various sensors
5. Trigger: The homeowner decides to “set” the system, that is, to turn on the alarm functions
7. Exceptions:
Control panel is not ready: homeowner checks all sensors to determine which are open; closes them
Password is incorrect (control panel beeps once): homeowner reenters correct password.
Password not recognized: monitoring and response subsystem must be contacted to reset password
Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated
Away is selected: control panel beeps three times and an away light is lit; all sensors are activated
8. Priority: Essential, must be implemented
9. When available: First increment
10. Frequency of use: Many times per day
11. Channel to actor: Via control panel interface
12. Secondary actors: Support technician, sensors
13. Channels to secondary actors:
Support technician: phone line
Sensors: hardwired and wireless interfaces
14. Open issues:
Should there be a way to activate the system without the use of a password or with an abbreviated password?
Should the control panel display additional text messages?
How much time does the homeowner have to enter the password from the time the first key is pressed?
Is there a way to deactivate the system before it actually activates?
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

21. Use Case: InitialMonitoring (1)
Use case: InitiateMonitoring
Primary actor: Homeowner
Goal in context: To set the system to monitor sensors when the homeowner leaves the house or remains inside
Preconditions: System has been programmed for a password and to recognize various sensors
Trigger: The homeowner decides to “set” the system, that is, to turn on the alarm functions
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

22. Use Case: InitialMonitoring (2)
Scenario:
Homeowner: observes control panel
Homeowner: enters password
Homeowner: selects “stay” or “away”
Homeowner: observes read alarm light to indicate that SafeHome has been armed
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

23. Use Case: InitialMonitoring (3)
Exceptions:
Control panel is not ready: homeowner checks all sensors to determine which are open; closes them
Password is incorrect (control panel beeps once): homeowner reenters correct password.
Password not recognized: monitoring and response subsystem must be contacted to reset password
Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated
Away is selected: control panel beeps three times and an away light is lit; all sensors are activated
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

24. Use Case: InitialMonitoring (4)
Priority: Essential, must be implemented
When available: First increment
Frequency of use: Many times per day
Channel to actor: Via control panel interface
Secondary actors: Support technician, sensors
Channels to secondary actors:
Support technician: phone line
Sensors: hardwired and wireless interfaces
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

25. Use Case: InitialMonitoring (5)
Open issues:
Should there be a way to activate the system without the use of a password or with an abbreviated password?
Should the control panel display additional text messages?
How much time does the homeowner have to enter the password from the time the first key is pressed?
Is there a way to deactivate the system before it actually activates?
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

26. Use-Case Diagram for the SafeHome System
Initial
Monitoring
Use-Case Diagram for the SafeHome System
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

27. Elements of the Analysis/Requirements Model
1. Scenario-based elements
Use-case diagram and use-case descriptions
2. Class-based elements
Class diagram
3. Behavioral elements
State diagram
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

28. Eliciting Requirements
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

29. Class Diagram For the SafeHome system …
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

30. State Diagram Reading Commands State name System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input
State activities
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

31. Analysis/Requirements Patterns
Are classes/functions/behaviors that reoccur across many projects in a particular application domain
They speed up the development of the analysis model by providing reusable analysis models with examples and descriptions of advantages and limitations
The facilitate the transformation of analysis to design by suggesting related design pattern and reliable solutions to common problems

32. Analysis/Requirements Patterns: Template
Pattern name: A descriptor that captures the essence of the pattern
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to address the problem
Forces and context: A description of external issues (forces) that can affect how the pattern is used and also the external issues that will be resolved when the pattern is applied
Solution: A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues
Consequences: Addresses what happens when the pattern is applied and what trade-offs exist during its application
Design: Discusses how the analysis pattern can be achieved through the use of known design patterns
Known uses: Examples of uses within actual systems
Related patterns: Patterns that are commonly used with this pattern, or are structurally similar, or are a variation of this pattern
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

33. CS 281 Intro to Software Engineering Lecture 12a Understanding Requirements (3)

34. Negotiating Requirements: Why?
Negotiate to balance customer’s functionality and performance requirements against available resources (time, people, budget, etc.)
Intent of negotiation is to agree upon a project plan that meets the needs of the customer while reflecting the real-world constraints of time, people, and budget
The best negotiation strives for a win-win result:
A majority of the customer’s needs are met
The developer gets to work to achievable deadlines within a realistic budget

35. Negotiating Requirements: How?
1. Identify the key stakeholders
These are the people who will be involved in the negotiation
2. Determine each of the stakeholders “win conditions”
Win conditions are not always obvious
3. Negotiate
Work toward a set of requirements that lead to “win-win”
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

36. Negotiating Requirements: Guidelines
It's not a competition
Map out a strategy
Listen actively
Focus on other party's interests
Don't let it get personal
Be creative
Be ready to commit

37. Requirements Monitoring: Especially Needed in Incremental Development
Requirements monitoring supports continuous validation by analyzing user goals against the system developed
Distributed debugging – uncovers errors and determines their cause
Run-time verification – determines whether software matches its specification
Run-time validation – assesses whether evolving software meets user goals
Business activity monitoring – evaluates whether a system satisfies business goals
Evolution and co-design – provides information to stakeholders as the system evolves
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

38. Validating Requirements - I
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?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

39. Validating Requirements - II
Is each requirement bounded and unambiguous?
Does each requirement have attribution? That is, is a source noted for each requirement?
Do any requirements conflict with other requirements?
Is each requirement achievable in the technical environment that will house the system or product?
Is each requirement testable, once implemented?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

40. Validating Requirements - III
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?
Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

41. Avoiding Common Mistakes
Fearturitis describes the practice of trading functional coverage for overall system quality. Some engineers equate the number of functions delivered at the earliest possible time with the overall quality of the end product Flexibilitis happens when engineers overload the product with adaptation and configuration facilities. The result is a system that is unnecessarily complex, more difficult to test, and more challenging to manage Performitis occurs when developers become overly focused on system performance at the expense of quality attributes, e.g. maintainability, reliability, security
Ref: Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)