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

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

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

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

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

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

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?

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…

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

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.

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

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

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

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

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

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

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?

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

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

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

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

Use case diagram for the Scheduler

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

Example: use case diagram for the Scheduler, version 0.0.1

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

Example: use case diagram for the Scheduler, version 0.0.2

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?

Example: use case diagram for the Scheduler, version 0.0.3

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

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 …

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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…

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

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

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

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

Example: object diagram for Scheduler, v0.0.0