Why do we need the requirements stage, what’s wrong with just starting designing a system?

1. 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. Req. elicitation Analysis Implem. Design 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 Developer perspective User perspective

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. 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. 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. 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. 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. 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? • NO • 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. 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. 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. 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