1. Requirements Engineering

2. Requirements Engineering Tutorial
Tutorial outline
Requirements engineering
Basic concepts
Requirements engineering process for ARENA
REQuest: Live Demonstration
REQuest: Guidelines
Summary & next steps
Another interesting issue with finding objects is to define which objects are inside the application domain and which ones are outside of it. Sometimes it helps you to get a clearer understanding of the overall system. Look at the figure in this slide. What does it show? A bunch of black and white dots? Given that I will tell you that it contains a system (that is an object model can be found) how would you start with looking for objects? Turn the slide around. Turn it upside down. Look at the “problem domain” from all angles. And suddenly you might experience what I would call the “gestalt experience”. You will see the application domain. Now there is no recipe for finding it. You might find a very low level object, such as an ear or you might find a high level object such as the shape of a dog. In fact, if you look carefully you will find a dalmatian dog. Once you understand that you are looking at a dog, a lot of the black and white pixels in the total figure are not part of your system and you can easily find the boundary of the system by trying to trace the outline of the Dalmatian.
However, don’t be lured into thinking that this is the system you have been looking for. Always be alert that the real system might be something totally different. For example, if you turn the dog upside down, you might be able to see an eagle taking off from a river, with a poor dead victim in its claws!
January 1, 2019
Requirements Engineering Tutorial

3. Problem Lifecycle of a software project
1.The client’s
needs
2. Requirements
Analysis
3. After system design
4. After implementation
Clients and developers often have different backgrounds and “speak another language”
Requirements have to be fulfilled to make a project successful
January 1, 2019
Requirements Engineering Tutorial

4. Solution Requirements Engineering Clients Developers
Analysis
Document
Requirements Engineering
Clients
Developers
Requirements Analysis Review
… can solve the communication problem …
January 1, 2019
Requirements Engineering Tutorial

5. Requirements Engineering
Application
Domain
Objects
Subsystems
class...
Solution Domain
Source
Code
Test
Cases ?
Expressed in Terms Of
Structured By
Implemented By
Realized By
Verified
System
Design
Object
Implemen-
tation
Testing
class....
Requirements
Elicitation
Use Case
Model
Analysis
A requirement is a feature that the system must have or a constraint that it must satisfy to be accepted by the client.
January 1, 2019
Requirements Engineering Tutorial

6. Requirements Analysis Document
A RAD includes 3 descriptions:
Requirements Elicitation:
Use case model
Requirements: What do users do?
Interactions: How do users use the system?
Requirements elicitation => output: specification that the client understands
Analysis => output: model that the developers can interpret
Analysis:
Requirements analysis model (object model)
Specification: What does the system do?
January 1, 2019
Requirements Engineering Tutorial

7. RAD: Levels of descriptions
User tasks describe domain Le v
el 2
el 1
el 3
el 4
Use Cases describe interactions
Services describe system
January 1, 2019
Requirements Engineering Tutorial

8. Requirements Engineering Tutorial
Tutorial outline
Requirements engineering
Basic concepts
Requirements engineering process for ARENA
REQuest: Live Demonstration
REQuest: Guidelines
Summary & next steps
Another interesting issue with finding objects is to define which objects are inside the application domain and which ones are outside of it. Sometimes it helps you to get a clearer understanding of the overall system. Look at the figure in this slide. What does it show? A bunch of black and white dots? Given that I will tell you that it contains a system (that is an object model can be found) how would you start with looking for objects? Turn the slide around. Turn it upside down. Look at the “problem domain” from all angles. And suddenly you might experience what I would call the “gestalt experience”. You will see the application domain. Now there is no recipe for finding it. You might find a very low level object, such as an ear or you might find a high level object such as the shape of a dog. In fact, if you look carefully you will find a dalmatian dog. Once you understand that you are looking at a dog, a lot of the black and white pixels in the total figure are not part of your system and you can easily find the boundary of the system by trying to trace the outline of the Dalmatian.
However, don’t be lured into thinking that this is the system you have been looking for. Always be alert that the real system might be something totally different. For example, if you turn the dog upside down, you might be able to see an eagle taking off from a river, with a poor dead victim in its claws!
January 1, 2019
Requirements Engineering Tutorial

9. Requirements Engineering Tutorial
Process for ARENA (1)
REQuest for the requirements specification
Web-based tool
Actors, User Tasks, Use Cases, & Services
Constraints & Glossary
REQuest for review and negotiation
Questions, Options, Criteria, Assessments
Discussion
What’s new, what’s revised, conflict detection
January 1, 2019
Requirements Engineering Tutorial

10. Requirements Engineering Tutorial
Process for ARENA (2)
Instructors/coaches
Oct 23: RAD v.0 from coaches
Actors, user tasks & use cases
Nov 3: Feedback from
coaches
Nov 6: Requirements review
Teams
Before Oct 31:
Questions to coaches
Oct 31: RAD v.1 due
Use cases, Services, Constraints
Glossary
Nov 6: RAD v.2 due
Options, assessments
Decisions
Revised requirements elements
Analysis Object Models and sequence diagrams (Together)
January 1, 2019
Requirements Engineering Tutorial

11. Requirements elicitation activities (1)
Define the boundary of the system:
Identify and describe actors
Define the needs of the user
Describe one or more user tasks per actor
Describe the interactions between the actors and the system
Describe one or more use cases per user task
Exceptions & nonfunctional constraints
January 1, 2019
Requirements Engineering Tutorial

12. Requirements elicitation activities (2)
Describe the functionality of the system
Identify all services needed to realize the use cases
Each use case uses one or more services
Each service can be used by one or more use cases
Review the system specification with the client
January 1, 2019
Requirements Engineering Tutorial

13. Requirements Engineering Tutorial
Tutorial outline
Requirements engineering
Basic concepts
Requirements engineering process for ARENA
REQuest: Live Demonstration
REQuest: Guidelines
Summary & next steps
Another interesting issue with finding objects is to define which objects are inside the application domain and which ones are outside of it. Sometimes it helps you to get a clearer understanding of the overall system. Look at the figure in this slide. What does it show? A bunch of black and white dots? Given that I will tell you that it contains a system (that is an object model can be found) how would you start with looking for objects? Turn the slide around. Turn it upside down. Look at the “problem domain” from all angles. And suddenly you might experience what I would call the “gestalt experience”. You will see the application domain. Now there is no recipe for finding it. You might find a very low level object, such as an ear or you might find a high level object such as the shape of a dog. In fact, if you look carefully you will find a dalmatian dog. Once you understand that you are looking at a dog, a lot of the black and white pixels in the total figure are not part of your system and you can easily find the boundary of the system by trying to trace the outline of the Dalmatian.
However, don’t be lured into thinking that this is the system you have been looking for. Always be alert that the real system might be something totally different. For example, if you turn the dog upside down, you might be able to see an eagle taking off from a river, with a poor dead victim in its claws!
January 1, 2019
Requirements Engineering Tutorial

14. Requirements Engineering Tutorial
Live Demonstration
First step: login to REQuest
January 1, 2019
Requirements Engineering Tutorial

15. Requirements: What do users do? (1)
Player
Brief high-level descriptions
Actors represent roles, that is, a type of user of the system
Player
User tasks represent activities accomplished by the user, independently of the system.
Accomplish Mission
Accomplish Mission
January 1, 2019
Requirements Engineering Tutorial

16. Requirements: What do users do? (2): Examples
Actor Player
Person who is able to play one or more games.
User Task Accomplish Mission
The Player starts the game.
The Player sets her/his preferences.
The Player receives a certain mission.
The Player completes the mission.
January 1, 2019
Requirements Engineering Tutorial

17. Specification (1) : What does the system do?
Use cases describe sequences of interactions between the actors and the system
Services describe features provided by the system
Start SWORD
Complete description of the system including exceptions by developers
Set mode
Set
restrictions
Load
character
January 1, 2019
Requirements Engineering Tutorial

18. Specification (2): Example of use case attributes
Use Case Start SWORD
Initiatiating actor:
Player
Preconditions:
Player has installed SWORD on her/his computer.
Postconditions:
Player is able to enter the game.
January 1, 2019
Requirements Engineering Tutorial

19. Specification (3): Example of use case flow of events
System steps
Actor steps
The Player double clicks the SWORD icon on her/his computer
2. SWORD asks for the preferred game mode
3. The Player chooses the stop-watch mode and sets a deadline
4. SWORD asks if the player wants to set any restrictions
5. The Player restricts the game to her/his buddy list
6. SWORD loads the Player’s character
7. The Player can enter the game
January 1, 2019
Requirements Engineering Tutorial

20. Specification (4): Example services
Service Set mode
Inputs: one game mode and deadline
Output: message asking for restrictions
Service Set restrictions
Input: one or more players (from menu)
Output: message that restrictions are set
January 1, 2019
Requirements Engineering Tutorial

21. Specification (5): Exceptions
Actor steps
The Player double clicks the SWORD icon on her/his computer.
[invalid format]
SWORD displays a message box
and asks to use the valid format
for setting deadlines.
3. The Player chooses the stop-watch mode and sets a deadline. [invalid format]
[no buddy list defined]
SWORD announces the failure
and offers the possibility to set
the buddy list now as well as
canceling this step. If the Player
chooses the first option, a window
will pop up so that the Player can
compile her/his buddy list.
5. The Player restricts the game to her/his buddy list. [no buddy list defined]
7. The Player can enter the game
January 1, 2019
Requirements Engineering Tutorial

22. Nonfunctional requirements
Domain constraints
Domain facts
Applicable to user tasks
Global functional constraints
Functionality that is easier to describe in terms of constraints
Applicable to use cases
Quality constraints
Constraint on the attribute of a user task, use case, or service.
January 1, 2019
Requirements Engineering Tutorial

23. Requirements Engineering Tutorial
Tutorial outline
Requirements engineering
Basic concepts
Requirements engineering process for ARENA
REQuest: Live Demonstration
REQuest: Guidelines
Summary & next steps
Another interesting issue with finding objects is to define which objects are inside the application domain and which ones are outside of it. Sometimes it helps you to get a clearer understanding of the overall system. Look at the figure in this slide. What does it show? A bunch of black and white dots? Given that I will tell you that it contains a system (that is an object model can be found) how would you start with looking for objects? Turn the slide around. Turn it upside down. Look at the “problem domain” from all angles. And suddenly you might experience what I would call the “gestalt experience”. You will see the application domain. Now there is no recipe for finding it. You might find a very low level object, such as an ear or you might find a high level object such as the shape of a dog. In fact, if you look carefully you will find a dalmatian dog. Once you understand that you are looking at a dog, a lot of the black and white pixels in the total figure are not part of your system and you can easily find the boundary of the system by trying to trace the outline of the Dalmatian.
However, don’t be lured into thinking that this is the system you have been looking for. Always be alert that the real system might be something totally different. For example, if you turn the dog upside down, you might be able to see an eagle taking off from a river, with a poor dead victim in its claws!
January 1, 2019
Requirements Engineering Tutorial

24. Guidelines for use cases (1)
Name
Use a verb phrase to name the use case.
The name should indicate what the user is trying to accomplish.
Examples:
“Request Meeting”, “Schedule Meeting”
Length
A use case should not exceed 2 A4 pages. If longer, use include relationships.
A use case should describe a complete set of interactions.
January 1, 2019
Requirements Engineering Tutorial

25. Guidelines for use cases (2)
Flow of events
The active voice should be used. Steps should start either with “The Actor …” or “The System …”.
The causal relationship between the steps should be clear.
All flow of events should be described (not only the main flow of event).
The boundaries of the system should be clear. Components external to the system are described as such.
Define important terms in the glossary.
Negative example:
The driver arrives at the parking gate, the driver receives a ticket from the distributor, the gate is opened, the driver drives through.
January 1, 2019
Requirements Engineering Tutorial

26. Guidelines for use cases (3)
Exceptions
Exceptions should be attached to the step where they are detected.
If an exception can occur in any step, describe it only in the exception section.
Exception handling is described as flow of events.
At the end of the exception handling, it should be clear what happens next (if the use case is terminated or if it is resumed in a particular step).
Preconditions
If a case is excluded with a precondition, then it should not be handled as an exception.
January 1, 2019
Requirements Engineering Tutorial

27. Guidelines for use cases (4)
Write one high-level use case per user task
If a use case includes only one or two steps, it should probably be a service, not a use case.
If a sequence of steps is identical in several use cases, it should be factored out into a separate use case and included in the original use cases (eliminate redundancy).
<<user task>>
<<use case>>
January 1, 2019
Requirements Engineering Tutorial

28. General guidelines: Use Rationale (1)
Question: Which restrictions are possible?
References: Service: Set restrictions
Decision: Buddy list + single persons
Criteria 1:
Flexibility
Criteria 2:
User
Friendliness
Opt. 1: Buddy list – +
Opt. 2: Single persons – +
Opt. 3: Buddy list + single persons +
January 1, 2019
Requirements Engineering Tutorial

29. Requirements Engineering Tutorial
Use Rationale (2)
Questions can be used to:
Request a clarification How can a Player restrict a game to her/his buddy list?
Indicate a defect Isn’t a second game mode missing?
Justify a use case or Which solution is the best? service
Questions are asked during review and consolidated into justifications during revisions.
January 1, 2019
Requirements Engineering Tutorial

30. Requirements Engineering Tutorial
Tutorial outline
Requirements engineering
Basic concepts
Requirements engineering process for ARENA
REQuest: Live Demonstration
REQuest: Guidelines
Summary & next steps
Another interesting issue with finding objects is to define which objects are inside the application domain and which ones are outside of it. Sometimes it helps you to get a clearer understanding of the overall system. Look at the figure in this slide. What does it show? A bunch of black and white dots? Given that I will tell you that it contains a system (that is an object model can be found) how would you start with looking for objects? Turn the slide around. Turn it upside down. Look at the “problem domain” from all angles. And suddenly you might experience what I would call the “gestalt experience”. You will see the application domain. Now there is no recipe for finding it. You might find a very low level object, such as an ear or you might find a high level object such as the shape of a dog. In fact, if you look carefully you will find a dalmatian dog. Once you understand that you are looking at a dog, a lot of the black and white pixels in the total figure are not part of your system and you can easily find the boundary of the system by trying to trace the outline of the Dalmatian.
However, don’t be lured into thinking that this is the system you have been looking for. Always be alert that the real system might be something totally different. For example, if you turn the dog upside down, you might be able to see an eagle taking off from a river, with a poor dead victim in its claws!
January 1, 2019
Requirements Engineering Tutorial

31. Putting everything together
Q: Which restrictions are possible
Set mode
Set restrictions
Load character
Player
Accomplish Mission
Start Sword
January 1, 2019
Requirements Engineering Tutorial

32. Requirements Engineering Tutorial
Summary
REQuest supports
Definition of requirements specification
Questions about the requirements elements
Discussion, negotiation, and resolution of questions
Finding out what others have done
ARENA deadlines
RAD v.1 October 30
RAD v.2 November 6
January 1, 2019
Requirements Engineering Tutorial

33. Important: Process for ARENA (1)
Instructors/coaches
Oct 23: RAD v.0 from coaches
Actors, user tasks & use cases
Nov 3: Feedback from
coaches
Nov 6: Requirements review
Teams
Before Oct 31:
Questions to coaches
Oct 31: RAD v.1 due
Use cases, Services, Constraints
Glossary
Nov 6: RAD v.2 due
Options, assessments
Decisions
Revised requirements elements
Analysis Object Models and sequence diagrams (Together)
January 1, 2019
Requirements Engineering Tutorial

34. Requirements Engineering Tutorial
Next steps
Meet with your development team as soon as possible
Login to REQuest with your Lotus Notes account
Add actors, use cases and services
Discuss, negotiate and resolve questions
Write one complete scenario per team (that is one possible example of the system in use)
January 1, 2019
Requirements Engineering Tutorial

35. Requirements Engineering Tutorial
Further readings
Bruegge B., Dutoit A.: Object-Oriented Software Engineering: Conquering Complex and Changing Systems, Prentice Hall, 2000
REQuest online help
January 1, 2019
Requirements Engineering Tutorial

36. Requirements Engineering Tutorial
Questions?
January 1, 2019
Requirements Engineering Tutorial