1. Scenario 1: someone else hired you to build a system
Why do we need the requirements stage, what’s wrong with just starting designing a system?
Scenario 1: someone else hired you to build a system
Communication problem: the idea of what the system is going to be has to be communicated by one group of people to another
Often leads to misunderstandings
Users have implicit assumption about the environment in which the system will function
Developers often have superior technical knowledge
Domain expertise can dictate terms that the users are not aware of
Scenario 2: you have a cool idea of your own and want to implement it
Prepare an NDA
Draft a business plan
Start designing?
No, before designing you have to figure out what you want the system to do from the user perspective

2. Classes of requirements
User requirements
Describe the users’ expectations of the system and the environment in which it will operate
Usually informal
System requirements
A technical specification of what the system is going to do
Done from the point of view of the user
We will refer to it as software analysis

3. Requirements elicitation
The process of extracting the requirements for the system from the users
How do we take the users’ idea of what the system is supposed to be and formalize it?
The usual process is
The users write an informal description of what the system is supposed to do, what the UI has to look like, etc.
The developers read this description and ask questions
The developers produce a more formal model of the system and show it to the users
Repeat until everybody is satisfied

4. Types of requirements Functional requirements
Specify what actions the system has to perform
Specify what actions the system should not perform
Non-functional requirements
Performance
Timing constraints
Space constraints
Network constraints
Development process
E.g. use of formal methods
Use of standards
Reliability
Security
Domain requirements
Requirements specific to the domain of the system

5. Functional requirements
A very hard problem: how to describe something very complex?
Specifications done by users/customers are often imprecise
A multitude of specification formalisms exist
We will look at one of them --- use case diagrams of UML

6. Example: Scheduler Informal functional requirements:
The scheduler should be capable of supporting the following activities by the user:
Entering the tasks to be carried out during the day, including the planned start and end for each task
Modifying the information about the tasks, including the start and end times and the amount of time actually spent
Marking tasks as completed
Starting and stopping the timer to track the time spent on a task
Viewing certain productivity statistics based on the difference between the amount of time actually spent on the tasks and the planned time
Saving the information persistently, so that it can be retrieved and viewed at a later time

7. Example: Scheduler
Some of the things the informal requirements document says are
“Viewing certain productivity statistics based on the difference between the amount of time actually spent on the tasks and the planned time”
The users have some very specific things in mind, but don’t make them clear
“Marking tasks as completed”
How are completed tasks different from others?
Can a completed task be marked as incomplete?
Some of the things the informal requirement documents does not say are…
Can two different tasks be timed concurrently?
Can a task being timed be edited at the same time?
Can the elapsed time be edited?

8. Non-functional requirements
Driven not only by the characteristics of the system, but also by policies, politics, and economics of the user/customer organization
Product requirements
E.g. reliability
Organizational requirements
E.g. programming language used
External requirements
E.g. encryption strength
Non-functional requirements have to be measurable
E.g., “the amount of memory used by the program is never to exceed 33Mb”
So, what type of requirements are more important, functional or non-functional?
This question does not have a simple answer…

9. Can it be assumed that the requirements are set in stone?
How does the step of requirements elicitation relate to the rest of the development process
Can it be assumed that the requirements are set in stone?
It is rare that the users’ requirements don’t change throughout software development lifecycle
Better if those changes are early in the process
The purpose of the requirements elicitation process is to reduce the amount of requirements changes later on
Often, during analysis it becomes clear that requirements have to be modified
User perspective
Developer perspective
Req.
elicitation
Analysis
Implem.
Design

10. Steps that developers go through during requirements elicitation
Identifying actors
Different types of users of the system
Identifying scenarios
Examples of typical uses of the system
Identifying use cases
Formalized typical uses of the system
Refining use cases
Identifying relationships among use cases
There are similarities between different uses of a system
Identifying non-functional requirements
Performance, UI issues, security, etc.

11. Actors are external entities that interact with a system
Identifying actors
Actors are external entities that interact with a system
Don’t have to be human entities
E.g. printers, networks
Actors do not actually have to map onto physical objects
Instead, may represent roles
The same role may be played by different physical objects
One physical object may play different roles
The basic purpose is to define the boundary of the system

12. Example: Actors in the Scheduler system
Group member
A role played by each of the members of a software team
Creates the list of tasks to be performed and then carries out these tasks
Manager
A role played by the person (or people) in charge
Reviews task list and performance of group members
Persistent store
A system responsible for saving the task data in non-volatile storage

13. Identifying scenarios
Scenario is a narrative description of a specific type of the system functionality
Normally, a system will have several scenarios
It is important to keep things high-level
Concentrate on general functionality of the system, not the specifics
Does not have to be formal!
The purpose of scenarios is to give the developers some idea of how the users are going to use the system

14. Example: A scenario in the Scheduler
Name
EditTask
Participating actor instances
Group member, manager
Flow of events
The user highlights the task in the list
The user clicks the “Edit” button
The application opens an edit dialog window
The user changes the attributes of the task
The user clicks the OK button in the dialog
The new data is displayed in the task list

15. Identifying use cases Use cases combine groups of scenarios
In a sense, use cases are types of scenarios
Sometimes, there is a single scenario for a use case
Each scenario has to be represented by at least one use case!
A use case represents a complete flow of events through the system
Includes pre-conditions
conditions that need to hold for the events of the use case to take place
Includes post-conditions
conditions that are always true after all the events took place
May include alternative flow
If something exceptional (unexpected) happens

16. Example: A use case for the Scheduler
Name
EditTask
Participating actor instances
Group member, manager
Preconditions
The task exists in the UI
Flow of events
The user highlights the task in the list
The user clicks the “Edit” button
The application opens an edit dialog window
The user changes the attributes of the task
The user clicks the OK button in the dialog
Post-conditions
The new data is displayed in the task list
The task is positioned according to its scheduled time

17. What’s wrong with the description of the events in this example?
They are implicitly tied to a specific design of the user interface
E.g., maybe instead of (or in addition to) an “Edit” button, there is an “Edit” menu option
E.g., assumes that the edit dialog will have an OK button
Missed functionality
After the user clicks the “OK” button in the edit dialog, does this window remain on the screen?
Missed post-conditions
What happens to tasks other than the one being edited?

18. Aimed at making extra sure that for a given use case
Refining use cases
Aimed at making extra sure that for a given use case
The right functionality is captured
No desired functionality is missing
The functionality is stated on a high enough level
The users are aware of the alternatives for the functionality they originally suggested
As a process issue, forces the developers make another pass over the use cases

19. Example: A refined use case for the Scheduler
Name
EditTask
Participating actor instances
Group member, manager
Preconditions
The task exists in the UI
Flow of events
The user makes the task “current” in the list of all tasks
The user requests editing the current task through the GUI
An edit dialog window opens, with the data for the current task displayed
The user modifies the task data
The task edit dialog is removed
Post-conditions
The new data for the task is displayed in the task list
The task is positioned according to its scheduled time
Tasks other than the edited one are unchanged, except for their positions relative to the edited task

20. In this course, I’ll teach you those 20% Tools:
UML and This Course
You can model 80% of most (even complex) problems by using about 20% UML
In this course, I’ll teach you those 20%
Tools:
Rational Rose
TogetherJ (togethersoft.com)
Not clear if an evaluation version is still available
ArgoUML (argouml.org)
Open source
Some things are flaky

21. Relationships between use cases
Extend relationship
Use case A extends use case B if B is more general than A
Often is used to separate exceptional functionality from the normal functionality
A is a representation of B when some exceptional conditions hold
Include relationship
Use case A includes use case B if the functionality of B is part of the functionality of A
Example of reuse on a very high level

22. Use case diagram for the Scheduler

23. Is this use case diagram satisfactory?
What about connections of the actors to the use cases?
The roles of GroupMember and Manager seem to overlap a lot. Why?
Because we tied the actors to the actual types of users as communicated by the users
Think about logical actions on the system instead. What can be done to the tasks?
Defined
Timed
Observed

24. Example: use case diagram for the Scheduler, version 0.0.1

25. Hmm, speaking about missing functionality…
What about unplanned tasks?
Is it necessary to show their presence in the use case diagram?
Yes, because the actions that users perform on the unplanned task are different from their actions on planned tasks

26. Example: use case diagram for the Scheduler, version 0.0.2

27. Should scheduling be allowed only for the current date?
Are we done now?
Should scheduling be allowed only for the current date?
Probably not
Need to plan days in advance
May want to look at past performance
May want to produce statistics for a week, month, etc.
How to handle it in terms of use cases?

28. Example: use case diagram for the Scheduler, version 0.0.3

29. Identifying initial analysis objects
Why should users be concerned with the objects?
Helps to agree on terminology
The resulting objects may not actually be used for the design
Represents a glossary of terms and helps to understand use cases
Sometimes the same term is used to describe functionality of two different use cases, but the definitions of those terms are different
One or both should be renamed!
Usually done on a per use case basis followed by a refinement stage

30. Example: Initial analysis objects for the Scheduler
Task
A unit of work that is performed by group members
List of tasks
Contains all tasks for a specific date
Scheduled time
The time period during which the task is supposed to be performed; represented by the start and end times
Elapsed time
The actual amount of time spent on the task …

31. Identifying non-functional requirements
Aspects of the system not directly related to its functionality
UI aspects
Performance characteristics
Documentation requirements
Very common for safety-critical systems
Hardware compatibility requirements
Robustness issues
The anticipated scope of future changes
Etc.
Often the users have to be helped in identifying these

32. Has to be implemented in pure Java
Example: Scheduler
Has to be implemented in pure Java
The response time of the UI is <1sec
Is this clear enough?
The data for each task is shown in one line in the main window
The “current” task has to be visually distinguishable from other tasks
The completed tasks have to be visually distinguishable from other tasks
The Scheduler should handle unexpected user actions, displaying warning dialogs when a user performs an illegal action on the UI

33. Common problems with requirements
Incompleteness
Some important details are missing
Inconsistency
Some of the details are contradictory
Ambiguity
A requirement may be interpreted in several different ways on the high level
Imprecision
It is not clear what a requirement means
Infeasibility
A requirement is not realistic and so cannot be satisfied in practice
Unevenness
Different requirements are specified with different levels of detail

34. OK, can we go on to the design stage now?
The functionality, as specified in the requirements document is
Too high-level
In the Scheduler system, is there a limit on how many tasks can be created for a single day?
Too imprecise
Steps in the use cases are described in terms of natural language and so can be interpreted in different ways or misinterpreted
In the Scheduler system, what resources are used for timing tasks?
Need to continue looking at the system from the user’s standpoint and formalize it further

35. Role of the analysis stage
Formalizes the requirements
Refines the requirements
Produces an analysis model
Models the system from the user’s standpoint
But not necessarily on the level that a user would understand!
In a sense, tests the requirements specification

36. Composition of the analysis model
Functional model
Use cases and scenarios from the requirements spec
Analysis object model
Object diagrams
Dynamic model
Statechart diagrams
Sequence diagrams

37. Types of analysis objects
Entity objects
Persistent information used by the system
Does not include “helper” objects, which are usually transient
Control objects
Encapsulated functionality of various parts of the system
Boundary objects
Interaction between the actors and the system
Normally, the analysis objects are closely tied to use cases

38. Why do we need this distinction between object types?
Convenient for initial classification of the analysis objects
E.g., a dialog window is something that an actor uses and so is fundamentally different from data that the system manipulates
Helps define objects more clearly
E.g., by separating data from control
Note: this could change later, during design

39. Entity objects Often identified by analyzing nouns in the use cases
Have to be careful, because some of those may not be appropriate
E.g. fields, not separate objects
Real-world entities that the system has to deal with
Data repositories
But be careful not to use objects to represent actors
Additional terms that are used to clarify functionality in use cases
Some objects are not mentioned in the use cases because of the level of granularity
In all cases, it is important to use the user terminology
The developer terminology will come in during design stages

40. Example: entity objects in the Scheduler
Task – tasks that are scheduled and timed
UnplannedTask – task representing activities that are not planned for
TaskList – all tasks that are scheduled for a specific date, including the unplanned task
Date – a date
Time – a point in time
TimePeriod – duration between two Time points
Statistics – performance characteristics computed for all tasks for day, week, or a month
Week – representation of a week for statistics
Month – representation of a month for statistics
Timer – responsible for measuring time
CurrentTask – representation of the task activated by the user

41. Activity for removing unnecessary or incorrect objects
Refining objects
Activity for removing unnecessary or incorrect objects
Done by asking a lot of questions:
Are all objects cohesive?
Are any of the objects redundant?
Are any of the objects irrelevant?
Are any of the objects vague?
Are any of the objects really attributes of other objects?
Are there objects that do not correspond to entity objects?
Is the object a design or implementation construct?

42. Example: refining objects for the Scheduler
All objects seem cohesive
Week and Month objects are redundant
They represent very similar concepts, which characterize periods of time in terms of days they contain
Replace by DateRange
All objects seem relevant
Statistics object is vague
Replace by PerformanceSummary
Time object may seem like an attribute, but it is an attribute of many objects, so it’s important enough to be an object

43. Represent the interface between the actors and the system
Boundary objects
Represent the interface between the actors and the system
In other words, UI, without specifying the details and layout
At least one boundary object is needed for accessing each use case
But the same boundary object can be used to access several use cases
Identified by analyzing the ways the users are going to enter data into, give commands to, and get output from the system
As much as possible, the user’s terms must be used

44. Example: boundary objects in the Scheduler
CreateTaskDialog
EditTaskDialog
ErrorDialog
CreateTaskActivator
EditTaskActivator
DeleteTaskActivator
DateChooser
TaskCompletionActivator
TaskIncompletionActivator
TimerStarter
TimerStopper
ExitActivator
StatisticsDisplay
TaskActivator

45. Hey, aren’t there too many of them?
There is no way around it - there have to be user interface components to manipulate the tasks in all these different ways
During design, it may be possible to reduce the number of boundary objects
E.g., EditTaskDialog and CreateTaskDialog could be one object
But the number of boundary objects is as likely to increase…

46. That’s where the logic of the system resides
Control objects
That’s where the logic of the system resides
Coordinate the other types of objects
Often, a control object per use case
Because a use case represents a specific kind of functionality, which needs to be controlled
For complicated use cases, more than one control object may be needed
One control object may control several simple related use cases

47. Example: control objects in the scheduler
CreateTaskControl
EditTaskControl
DeleteTaskControl
ChooseDateControl
CompletionControl
Controls both completing and un-completing a task
TimingControl
Controls both starting and stopping timing a task
StatisticsDisplayControl
ExitControl
PersistenceControl

48. Hey, aren’t there too many of them?
Yes and no
Yes: some of these control objects are very closely related and so can be fused into one
E.g., CreateTaskControl, EditTaskControl, and DeleteTaskControl can be replaced by TaskControl object
E.g., ExitControl doesn’t have to do much except for saving the task data, so its functionality could be rolled into PersistenceControl
No: we are looking at the system from the user’s perspective
Having different control objects for creating, editing, and deleting tasks makes these operations explicit in the analysis model

49. Modeling relationships among objects with UML object diagrams
Need to analyze logical associations among objects
Inheritance
Aggregation
Other
Need to indicate the number of objects that participate in associations
Still view the system from the user’s standpoint
The associations have to make sense in the physical world
Most often, only use entity objects in these diagrams

50. Example: object diagram for Scheduler, v0.0.0