The Requirements Model

The Requirements Model
I. A use case model: Specify the the functionality the system has to offer from a users perspective. II. Interface descriptions: specify what the user interface will look like when the use cases are performed. III. A problem domain object model: to give a conceptual picture and better understanding of the system, objects are used to represent occurrences in problem domain.
I The Use Case Model

The use case model consists of actors and use cases. What interacts with the system?. Define the role a user can play. Represent everything that needs to exchange information with the system. They constitute anything that is external to the system we are to develop. Difference between actors and users. An actor can make a service request of the system, be requested to provide a service, and interact with the system.
What are Actors?
Example System 1- A Recycling Machine

The system controls a recycling machine for returnable bottles, cans and crates. Several customers can use machine at the same time and each customer can return all three types of items on the same occasion. Different types and sizes of bottle and can System has to check, for each item, what type has been returned. System will register how many items each customer returns When the customer asks for a receipt, the system will print out what he or she deposited, the value of the returned items and the total return sum that will be paid to the customer. An operator also uses system. The operator wants to know how many items of each type have been returned during the day. The operator should also be able to change information in the system, such as the deposit values of the items. If there is something amiss, e.g. if a can gets stuck or if the receipt roll is finished, the operator will be called by a special alarm signal.
Actors Contd..
Example System- Two actors:
Customer Operator Primary actors: The actors who are going to use the system directly are called primary actors. e.g. customer. Primary actors will govern the system structure. Secondary actors: The actors supervising and maintaining the system. They exist so that primary actor can use the system.
Why primary & secondary actors ?

System structure should decided in terms of the main functionality. Primary actors will govern the system structure. Identifying use cases- start with the primary actors. Changes to the system - mainly from primary actors .
Generalization/Specialization relationship among Actors

Actors may share common requests. A generalized actor can encompass common requests.
Why first identify actors?

Major tool for finding the use cases. Going through all the actors and defining everything they will be able to do, we define the complete functionality of the system
Use Cases
User performs a behaviorally related sequence of transactions in a dialogue with the system. Such a special sequence is called a use case. A use case class is a description, which specifies the transaction of the use cases. The set of all use case descriptions specifies the complete functionality of the system. When a user inputs a stimulus, the use case instance executes and starts a transaction belonging to the use case. Several use cases can begin in a similar way, it is not always possible to decide what use case has been instantiated until it is completed. Example A telephone exchange system. Use cases: A local telephone call, An Order a wakeup call.
Example System Use Cases

Customer Use cases:
Returning Item: return items, includes everything until a receipt is received. Generate Daily Report : Get a daily report of what items have been deposited today. Change Item: to modify information in the system (value and size of items).
Operator Uses Cases
Use Case Diagram Symbols

Actor : Stick figure Use case: oval labeled with name. Line: Interaction b/w actor and use case Line with arrow: Unidirectional association (requester to provider) Double headed arrow: Actor can generate request of the system or can request the actor to take some action. Use case and actor generalization / specialization: The line originates from the specialization and point with the triangle with the generalization.
Template for documenting Use cases

Description: a one or two sentences description of use case Actors: identify actors participating in the use case Includes: Identifies the use case that it may extend Extends: Identify the use case that it may extend Preconditions: The conditions that must be met to invoke this use case Details: how a system provides some service Post conditions: conditions that are assured to hold at the conclusion of use case. E.g. instance creation or destruction, relations (association and aggregation) formed or broken, value changes in variable, state changes. Exceptions: that may arise in execution of this use case. e.g. possible errors and specific action to be taken to recover. Constraints: that may apply on values being manipulated, resources allocated to it etc. Variants: that hold for this use case Comments: additional info. that might be helpful
Classification of Use Cases

Primary vs. secondary: primary functions constitute the functions for which the system exist. Secondary fns. deal with rare and exceptional case, necessary for robust system. Essential vs. concrete : Essential are business solutions independent of implementation. Concrete are design dependent. High level vs. low level: High level provide general description of business values provided. Low level provide details showing the exact order of activities
II. Interface description

When describing the use cases with the usersdescribe the interfaces in detail. Involve the users A prototype of the interface is also a perfect tool System interfaces such as communication protocols should also be standardized. If Man-Machine Interface (MMI) : use sketches of what the user will see on the screen on performing the use case or provide more sophisticated simulations using a User interface management system (UIMS).
Example System interfaces

Customer Interface
Customer panel including Buttons, Holes, Alarm devices Receipt layout
Operator interface:
For changing information, resetting alarm, requesting day summaries.
III. The Problem domain object model

When requirement specifications exist in vague form then it becomes difficult to define the task of the system and especially system boundaries. Problem domain objects help in developing a logical view of the system. PDOs are objects that have a direct counter part in the application environment and the system must know about these objects. PDO model helps in defining the concepts the system should be working with. It helps to develop a noun list which will help in specifying the use cases.
PDO Model of Example System
How Extensive should be PDO model?

Object name Logical Attributes Static instance associations Inheritance Dynamic instance associations operations
The main purpose is to form a common base of understanding for developing the system and not to define the system entirely Too much work here may result in it being hard to free from the structure while building stable and maintainable analysis model.
Refinement of Problem domain Objects
Advantages of the PDO model
Use Case Model and other models
References
Object Oriented Software Engineering : A use case driven Approach Chapter 6,7
Example System 2- A Safehome Security System

Safehome Security System is a microprocessor based home security system

The Requirements Model

Uploaded by

Copyright:

Available Formats

The Requirements Model

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Requirements Model

Uploaded by

Copyright:

Available Formats

The Requirements Model

I The Use Case Model

What are Actors?

Example System 1- A Recycling Machine

Why primary & secondary actors ?

Generalization/Specialization relationship among Actors

Why first identify actors?

Example System Use Cases

Operator Uses Cases

Use Case Diagram Symbols

Template for documenting Use cases

Classification of Use Cases

II. Interface description

Example System interfaces

III. The Problem domain object model

PDO Model of Example System

How Extensive should be PDO model?

Refinement of Problem domain Objects

Advantages of the PDO model

Use Case Model and other models

Example System 2- A Safehome Security System

You might also like