Requirements Analysis in Software Engineering

IEEE defines requirements analysis as (1) the process of studying user needs to arrive at a definition of a system, hardware or software requirements. (2) The process of studying and refining system, hardware or software requirements.’ Requirements analysis helps to understand, interpret, classify, and organize the software requirements in order to assess the feasibility, completeness, and consistency of the requirements. Various other tasks performed using requirements analysis are listed below.

1. To detect and resolve conflicts that arise due to unclear and unspecified requirements
2. To determine operational characteristics of the software and how they interact with the environment
3. To understand the problem for which the software is to be developed
4. To develop an analysis model to analyze the requirements in the software.
   

Software engineers perform analysis modeling and create an analysis model to provide information of ‘what’ software should do instead of ‘how’ to fulfill the requirements in software. This model emphasizes information such as the functions that software should perform, behavior it should exhibit, and constraints that are applied on the software. This model also determines the relationship of one component with other components. The clear and complete requirements specified in the analysis model help the software development team to develop the software according to those requirements. An analysis model is created to help the development team to assess the quality of the software when it is developed. An analysis model helps to define a set of requirements that can be validated when the software is developed.

Let us consider an example of constructing a study room, where the user knows the dimensions of the room, the location of doors and windows, and the available wall space. Before constructing the study room, he provides information about flooring, wallpaper, and so on to the constructor. This information helps the constructor to analyze the requirements and prepare an analysis model that describes the requirements. This model also describes what needs to be done to accomplish those requirements. Similarly, an analysis model created for the software facilitates the software development team to understand what is required in the software and then they develop it.

In Figure the analysis model connects the system description and design model. System description provides information about the entire functionality of the system, which is achieved by implementing the software, hardware and data. In addition, the analysis model specifies the software design in the form of a design model, which provides information about the software’s architecture, user interface, and component level structure.   

The guidelines followed while creating an analysis model are listed below.

1. The model should concentrate on requirements in the problem domain that are to be accomplished. However, it should not describe the procedure to accomplish the requirements in the system.
2. Every element of the analysis model should help in understanding the software requirements. This model should also describe the information domain, function, and behavior of the system.
3. The analysis model should be useful to all stakeholders because every stakeholder uses this model in his own manner. For example, business stakeholders use this model to validate requirements whereas software designers view this model as a basis for design.
4. The analysis model should be as simple as possible. For this, additional diagrams that depict no new or unnecessary information should be avoided.

Also, abbreviations and acronyms should be used instead of complete notations. The choice of representation is made according to the requirements to avoid inconsistencies and ambiguities. Due to this, the analysis model comprises structured analysis, object-oriented modeling, and other approaches. Each of these describes a different manner to represent the functional and behavioral information. Structured analysis expresses this information through data-flow diagrams whereas object-oriented modeling specifies the functional and behavioral information using objects. Other approaches include ER modeling and several requirements specification languages and processors.

Structured Analysis

Structured analysis is a top-down approach, which focuses on refining the problem with the help of functions performed in the problem domain and data produced by these functions. This approach facilitates the software engineer to determine the information received during analysis and to organize the information in order to avoid the complexity of the problem. The purpose of structured analysis is to provide a graphical representation to develop new software or enhance the existing software.

IEEE defines a data-flow diagram (also known as bubble chart and work flow diagram) as, ‘a diagram that depicts data sources, data sinks, data storage andprocesses performed on data as nodes and logical flow of data as links between thenodes.’ DFD allows the software development team to depict flow of data from oneprocess to another. In addition, DFD accomplishes the following objectives.

1. It represents system data in a hierarchical manner and with required levels of detail.
2. It depicts processes according to defined user requirements and software scope.

A DFD depicts the flow of data within a system and considers a system as a transformation function that transforms the given inputs into desired outputs. When there is complexity in a system, data needs to be transformed using various steps to produce an output. These steps are required to refine the information. The objective of DFD is to provide an overview of the transformations that occur in the input data within the system in order to produce an output.

A DFD should not be confused with a flowchart. A DFD represents the flow of data whereas a flowchart depicts the flow of control. Also, a DFD does not depict the information about the procedure to be used for accomplishing the task. Hence, while making a DFD, procedural details about the processes should not be shown. DFD helps the software designer to describe the transformations taking place in the path of data from input to output

A DFD consists of four basic notations (symbols), which help to depict information in a system. These notations are listed in Table.

                                                      Table DFD Notations

While creating a DFD, certain guidelines are followed to depict the data-flow of system requirements effectively. These guidelines help to create DFD in an understandable manner. The commonly followed guidelines for creating DFD are listed below.

1. DFD notations should be given meaningful names. For example, verbs should be used for naming a process whereas nouns should be used for naming external entity, data store, and data-flow.
2. Abbreviations should be avoided in DFD notations.
3. Each process should be numbered uniquely but the numbering should be consistent.
4. ADFD should be created in an organized manner so that it is easily understood.
5. Unnecessary notations should be avoided in DFD in order to avoid complexity.
6. ADFD should be logically consistent. For this, processes without any input or output and any input without output should be avoided.
7. There should be no loops in a DFD.
8. ADFD should be refined until each process performs a simple function so that it can be easily represented as a program component.
9. A DFD should be organized in a series of levels so that each level provides more detail than the previous level.
10. The name of a process should be carried to the next level of DFD.
11. The data store should be depicted at the context level where it first describes an interface between two or more processes. Then, the data store should be depicted again in the next level of DFD that describes the related processes.

There are various levels of DFD, which provide details about the input, processes, and output of a system. Note that the level of detail of process increases with increase in level(s). However, these levels do not describe the system’s internal structure or behavior. These levels are listed below.

1. Level 0 DFD: This shows an overall view of the system. Level a DFD is also known as context diagram.
2. Level 1 DFD: This elaborates level a DFD and splits the process into a detailed form.
3. Level 2 DFD: This elaborates level 1 DFD and displays the process(s) in a detailed form.
4. Level 3 DFD: This elaborates level 2 DFD and displays the process(s) in a detailed form.

To understand various levels of DFD, let us consider an example of a banking system. This DFD represents how a ‘user’ entity interacts with a ‘banking system’ process and avails its services. The Level 0 DFD depicts the entire banking system as a single process. There are various tasks performed in a bank such as transaction processing, pass book entry, registration, demand draft creation, and online help. The data-flow indicates that these tasks are performed by both the user and the bank. When the user performs a transaction, the bank verifies whether the user is registered in the bank.

The Level a DFD is expanded in Level 1 DFD. In this DFD, the ‘user’ entity is related to several processes in the bank, which include ‘register’, ‘user support’, and ‘provide cash’. Transaction can be performed only if the user is already registered in the bank. Once the user is registered, he can perform a transaction by the processes, namely, ‘deposit cheque’, ‘deposit cash’ and ‘withdraw cash’. Note that the line in the process symbol indicates the level of process and contains a unique identifier in the form of a number. If the user is performing transaction ‘deposit cheque’, the user needs to provide a cheque to the bank. The user’s information such as name, address, and account number is stored in ‘user-detail’ data store, which is a database. If cash is to be deposited and withdrawn, then the information about the deposited cash is stored in ‘cash-detail’ data store. The user can get a demand draft created by providing cash to the bank. It is not necessary for the user to be registered in that bank to have a demand draft. The details of amount of cash and date are stored in ‘DD-detail’ data store. Once the demand draft is prepared its receipt is provided to the user. The ‘user support’ process helps users by providing answers to their queries related to the services available in the bank.

Level 1 DFD can be further refined into Level2 DFD for any process of a banking system that has detailed tasks to perform. For instance, Level2 DFD can be prepared to deposit a cheque, deposit cash, withdraw cash, provide user support, and to create a demand draft. However, it is important to maintain the continuity of information between the previous levels (Level0 and Level1) and Level2 DFD. As mentioned earlier, the DFD is refined until each process performs a simple function, which is easy to implement.

Letus consider the ‘withdraw cash’ process to illustrate Level2 DFD. The information collected from Level1 DFD acts as an input to Level 2 DFD.  To withdraw cash, the bank checks the status of balance in the user’s account (as shown by ‘check account status’ process) and then allots a token (shown as ‘allot token’ process). After the user withdraws cash, the balance in user’s account is updated in the ‘user-detail’ data store and a statement is provided to the user.

If a particular process of Level2 DFD requires elaboration, then this level is further refined into Level3 DFD. Let us consider the process ‘check account status’ to illustrate Level3 DFD. To check the account status, the bank fetches the account detail (shown as ‘fetch account detail’ process) from the ‘account-detail’ data store. After fetching the details, the balance is read (shown as ‘read balance’ process) from the user’s account. Note that the requirements engineering process of DFDs continues until each process performs a function that can be easily implemented as an individual program component.

Although data-flow diagrams contain meaningful names of notations, they do not provide complete information about the structure of data-flows. For this, a data dictionary is used, which is a repository that stores description of data objects to be used by the software. A data dictionary stores an organized collection of information about data and their relationships, data-flows, data types, data stores, processes and so on. In addition, it helps users to understand the data types and processes defined along with their uses. It also facilitates the validation of data by avoiding duplication of entries and provides the users with an online access to definitions.

A data dictionary comprises the source of data, which are data objects and entities as well as the elements listed below.

1. Name: Provides information about the primary name of the data store, external entity, and data-flow
2. Alias: Describes different names of data objects and entities used
3. Content description: Provides information about the content with the help of data dictionary notations (such as ‘=’, ‘+’, and ‘* *’)
4. Supplementary information: Provides information about data types, values used in variables, and limitation of these values.
5. Where-used/how-used: Lists all the processes that use data objects and entities and how they are used in the system. For this, it describes the inputs to the process, output from the process, and the data store.

Object-oriented Modeling

Nowadays, an object-oriented approach is used to describe system requirements using prototypes. This approach is performed using object-oriented modeling (also known as object-oriented analysis), which analyzes the problem domain and then partitions the problem with the help of objects. An object is an entity that represents a concept and performs a well-defined task in the problem domain. For this, an object contains information of the state and provides services to entities, which are outside the object(s). The state of an object changes when it provides services to other entities.

The object-oriented modeling defines a system as a set of objects, which interact with each other by the services they provide. In addition, objects interact with users through their services so that they can avail the required services in the system.

To understand object-oriented analysis, it is important to understand various concepts used in an object-oriented environment. Some of the commonly used concepts are listed in Table.

                                            Table Object-oriented Concepts

Generally, it is considered that object-oriented systems are easier to develop and maintain. Also, it is considered that the transition from object-oriented analysis to object-oriented design can be done easily. This is because object-oriented analysis is resilient to changes as objects are more stable than functions that are used in structured analysis. Note that object-oriented analysis comprises a number of steps, which include identifying objects, identifying structures, identifying attributes, identifying associations, and defining services.

While performing an analysis, an object encapsulates the attributes on which it provides the services. Note that an object represents entities in a problem domain. The identification of the objects starts by viewing the problem space and its description. Then, a summary of the problem space is gathered to consider the ‘nouns’. Nouns indicate the entities used in problem space and which will further be modeled as objects. Some examples of nouns that can be modeled as objects are structures, events, roles, and locations.

Structures depict the hierarchies that exist between the objects. Object modeling applies the concept of generalization and specialization to define hierarchies and to represent the relationships between the objects. As mentioned earlier, superclass is a collection of classes which can further be refined into one or more subclasses. Note that a subclass can have its own attributes and services apart from the attributes and services inherited from its superclass. To understand generalization and specialization, consider an example of class ‘car’. Here, ‘car’ is a superclass, which has attributes such as wheels, doors, and windows. There may be one or more subclasses of a superclass. For instance, a superclass ‘car’ has subclasses ‘Mercedes’ and ‘Toyota’, which have the inherited attributes along with their own attributes such as comfort, locking system, and so on.

It is essential to consider the objects that can be identified as generalization so that the classification of structure can be identified. In addition, the objects in the problem domain should be determined to check whether they can be classified into specializations. Note that the specialization should be meaningful for the problem domain.

Attributes add details about an object and store the data for the object. For example, the class ‘book’ has attributes such as author name, ISBN, publisher and author. The data about these attributes is stored in the form of values and are hidden from outside the objects. However, these attributes are accessed and manipulated by the service functions used for that object. The attributes to be considered about an object depend on the problem and the requirements for that attribute. For example, while modeling the student admission system, attributes such as age and qualification are required for the object ‘student’. On the other hand, while modeling for hospital management system, the attribute ‘qualification’ is unnecessary and requires other attributes of class ‘student’ such as gender, height, and weight. In short, it can be said that while using an object, only the attributes that are relevant and required by the problem domain should be considered.

Associations describe the relationships among the instances of several classes. For example, an instance of class ‘university’ is related to an instance of class ‘person’ by ‘educates’ relationship. Note that there is no relationship between the ‘class ‘university’ and class ‘person’. However, only the instance(s) of class ‘person’ (that is, student) is related to class ‘university’. This is similar to entity relationship modeling, where one instance can be related by 1:1, l: M, and M: M relationships.

An association may have its own attributes, which mayor may not be present in other objects. Depending on the requirements, the attributes of the association can be ‘forced’ to belong to one or more objects without losing the information. However, this should not be done unless the attribute itself belongs to that object.

As mentioned earlier, an object performs some services. These services are carried out when an object receives a message for it. Services are a medium to change the state of an object or carry out a process. These services describe the tasks and processes provided by a system. It is important to consider the ‘occur’ services in order to create, destroy, and maintain the instances of a class. To identify the services, the system states are defined and then the external events and the required responses are described. For this, the services provided by objects should be considered.

Other Approaches

Many other approaches have been proposed for requirements analysis and. specification. These approaches help to arrange information and provide an automated analysis of requirements specification of the software. In addition, these approaches are used for organizing and specifying the requirements. The specification language used for modeling can be either graphical (depicting requirements using diagrams) or textual (depicting requirements in text form). Generally, the approaches used for analysis and specification include SADT, PSL/ PSA, RSL/REVS, and ER Modeling.

Structured Analysis and Design Technique (SADT) uses a graphical notation, and is generally applied in information processing systems. It comprises two parts, namely, Structured Analysis (SA) and Design Technique (DT). SA describes the requirements with the help of diagrams whereas DT specifies how to interpret the results.

The model of SADT consists of an organized collection of SA diagrams. These diagrams facilitate software engineers to identify the requirements in a structured manner by following a top-down approach and decomposing system activities, data, and their relationships. The text embedded in these diagrams is written in natural language, thus, specification language is a combination of both graphical language and natural language. The commonly-used SA diagrams include activity diagram (actigram) and data diagram (datagram). Both activity and data diagrams comprise nodes and arcs. Note that each diagram must consist of 3 to 6 nodes including the interconnecting arcs. These diagrams are similar to a data-flow diagram as they follow a top-down approach but differ from DFD as they may use loops, which are not used in a DFD.

An activity diagram is shown with nodes and arcs. The nodes represent the activities and the arcs describe the data-flow between the activities. Four different types of arcs can be connected to each node, namely, input data, control data, processor, and output data. Input data is the data that are transformed to output(s). Control data is the data that constrain the kind or extent of process being described. Processor describes the mechanism, which is in the form of tools and techniques to perform the transformation. Output data is the result produced after sending input, performing control activity, and mechanism in a system. The arcs on the left side of a node indicate inputs and the arcs on the right side indicate outputs. The arcs entering from the top of a node describe the control whereas the arcs entering from the bottom describe the mechanism. The data-flows are represented with the help of inputs and outputs while the processors represent the mechanism.

A data diagram is shown with nodes and arcs, which are similar to that of an activity diagram. The nodes describe the data objects and the arcs describe the activities. A data diagram also uses four different types of arcs. The arcs on the left side indicate inputs and the arcs on the right side indicate the output. Here, input is the activity that creates a data object whereas output is the activity that uses the data object. The ‘control activity’ (arcs entering from top) controls the conditions in which the node is activated and the ‘storage device’ (arcs entering from bottom) indicates the mechanism for storing several representations of a data object. Note that in both the diagrams, controls are provided by the external environment and by the outputs from other nodes.

Structured analysis and the design technique provide a notation and a set of techniques, which facilitate to understand and record the complex requirements clearly and concisely. The top-down approach used in SADT helps to decompose high level nodes into subordinate diagrams and to differentiate between the input, output, control, and mechanism for each node. In addition, this technique provides actigrams, datagrams, and the management techniques to develop and review an SADT model. Note that SADT can be applied to all types of systems and is not confined only to software applications.

Problem Statement Language (PSL) is a textual language, which is developed to describe the requirements of information systems. The Problem Statement Analyzer (PSA) is the processor that processes the requirements specified in PSL and then generates reports. PSL/PSA helps to document and communicate the software requirements. This approach is useful for requirements analysis as well as design. An advantage of PSA is that it allows the system to be customized according to a particular problem domain and particular solution methods because PSA is capable of defining new PSL constructs and format reports. PSL/PSA is used in commercial data processing applications, air defense systems, and so on.

PSL consists of a set of objects, where each object has properties and relationships with each other. The objective of PSL is to describe the information included in software requirements specification about the system. In PSL, this system description comprises several, namely, system input/ output flow, system structure, and data structure. System input/output flow describes the interaction of the system with its environment. It also provides information about the inputs received and outputs produced. System structure specifies the hierarchies among objects within the system. Data structure describes the relationships among the data used within the system and how data is manipulated by the system.

PSA operates on the information stored in the database, which is collected from the PSL description of requirements.

The PSA generates the following reports.

1. Database modification report: Specifies the changes made since the last report including the warning messages. It also provides information about the changes that have occurred due to the correction of errors.
2. Reference report: Includes several reports such as name list report, formatted problem statement report, and dictionary report. Name list report describes all the objects in the database. Formatted problem statement report describes the properties and relationships of a specific object. Dictionary report provides the data dictionary.
3. Summary report: Specifies the information gathered from various relationships. It consists of several reports such as database summary report, structure report, and external picture report. Database summary report provides information about the total number of objects used within the system including their details. Structure report represents the information in the form of hierarchy. External picture report describes the data-flow in a graphical form.
4. Analysis report: Includes information about inputs and outputs and problems related to inconsistency within the system. Analysis report comprises various reports such as contents comparison report, data processing interaction report, and processing chain report. Contents comparison report compares the similarity of inputs and outputs. Data processing report helps to find inconsistency in information flow and unused data objects. Processing chain report specifies the dynamic behavior of the system.

The Requirements Statement Language (RSL) is developed for real-time control systems. The REquirements Validation System (REVS) processes and analyzes the RSL statements. Note that both RSL and REVS are components of Software Requirements Engineering Methodology (SREM). SREM helps to generate requirements for real-time systems as these systems perform critical tasks and hence require that the constraints applied on them be documented and tracked. Like PSL, RSL also uses basic concepts such as elements (describe objects), attributes (describe features of elements), relationships (describe relations between elements), and structures (consist of nodes and processing steps). RSL follows the flow-oriented approach to describe real-time systems. It represents the process control systems in terms of stimulus and response. Each flow in RSL starts with a stimulus and continues till the final response is achieved. When requirements are defined in such a sequence, processing steps are required. The execution of a processing step may involve various software and hardware components. REVS operates on the RSL statements. Generally, RSL comprises the following components.

1. Translator for RSL
2. Abstract system semantic model (ASSM), which is a centralized relational database and similar to PSL/PSA database
3. A set of automated tools, which is used for processing information in ASSM. Some examples of automated tools are interactive graphics package, static checker, and automated simulation package. Interactive graphics package facilitates in describing flow paths, static checker checks the completeness and consistency of the information within the system, and automated simulation package generates and executes simulation models of the system.

Note that REVS is a large and complex software tool. Due to this, its use is cost effective only for the specification of large and complex real-time systems. However, the RSL notation can be applied manually to describe the characteristics of a real time system.

IEEE defines ER diagram as ‘a diagram that depicts a set of real-world entities and the logical relationships among them.’ This diagram depicts entities, the relationships between them, and the attributes pictorially in order to provide a high-level description of conceptual data models. An ER diagram is used in different phases of software development.

Once an ER diagram is created, the information represented by it is stored in the database. Note that the information depicted in an ER diagram is independent of the type of database and can later be used to create database of any kind such as relational database, network database, or hierarchical database. An ER diagram comprises data objects and entities, data attributes, relationships, and cardinality and modality.

Data object is a representation of composite information used by software. Composite information refers to different features or attributes of a data object and this object can be in any of the following forms.

1. External entity: Describes the data that produces or accepts information. For example, a report.
2. Occurrence: Describes an action of a process. For example, a telephone call.
3. Event: Describes a happening that occurs at a specific place or time. For example, an alarm.
4. Role: Describes the actions or activities assigned to an individual or object. For example, a systems analyst.
5. Place: Describes the location of objects or storage area. For example, a wardrobe.
6. Structure: Describes the arrangement and composition of objects. For example, a file.

An entity is the data that stores information about the system in a database. Examples of an entity include real world objects, transactions, and persons.

Data attributes describe the properties of a data object. Attributes that identify entities are known as key attributes. On the other hand, attributes that describe an entity are known as non-key attributes. Generally, a data attribute is used to perform the following functions.

1. Naming an instance (occurrence) of data object
2. Description of the instance
3. Making reference to another instance in another table.

Data attributes help to identify and classify an occurrence of entity or a relationship. These attributes represent the information required to develop software and there can be several attributes for a single entity. For example, attributes of ‘account’ entity are ‘number’, ‘balance’, and so on. Similarly, attributes of ‘user’ entity are ‘name’, ‘address’, and ‘age’. However, it is important to consider the maximum attributes during requirements elicitation because with more attributes, it is easier for the software development team to develop the software. In case some of the data attributes are not applicable, they can be discarded at a later stage.

Entities are linked to each other in different ways. This link or connection of data objects or entities with each other is known as relationship. Note that there should be at least two entities to establish a relationship between them. Once the entities are identified, the software development team checks whether a relationship exists between them. Each relationship has a name, optionality (the state when relationship can be possible but not necessary), and degree (how many). These attributes confirm the validity of a given relationship. Based on this, three types of relationships exist among entities.

1. One-to-one relationship (1:1): Indicates that one instance of an entity is related only to one instance of another entity. For example, in a database of users in a bank, each user is related to only one account number.
2. One-to-many relationship (I: M): Indicates that one instance of an entity is related to several instances of another entity. For example, one user can have many accounts in different banks.
3. Many-to-many relationship (M: M): Indicates that many instances of entities are related to several instances of another entity. For example, many users can have their accounts in many banks.

To understand entities, data attributes, and relationship, let us consider an example. Suppose in a computerized banking system, one of the processes is to use a saving account,’ which includes two entities, namely, ‘user’ and ‘account’. Each ‘user’ has a unique ‘account number’, which makes it easy for the bank to refer to a particular registered user. On the other hand, ‘account’ entity is used to deposit cash and cheque and to withdraw cash from the saving account. Depending upon the type and nature of transactions, it can be of various types such as current account, saving account, or overdraft account. The relationship between the user and the account can be described as ‘user has account in a bank’.

Entities are represented by rectangles, attributes are represented by ellipses, and relationships are represented by diamond symbols. A key attribute is also depicted by an ellipse but with a line below it. This line below the text in the ellipse indicates the uniqueness of each entity.

Although data objects, data attributes, and relationships are essential for structured analysis, additional information about them is required to understand the information domain of the problem. This information includes cardinality and modality. Cardinality specifies the number of occurrences (instances) of one data object or entity that relates to the number of occurrence of another data object or entity. It also specifies the number of entities that are included in a relationship. Modality describes the possibility whether a relationship between two or more entities and data objects is required. The modality of a relationship is a if the relationship is optional. However, the modality is 1 if an occurrence of the relationship is essential.

To understand the concept of cardinality and modality properly, let us consider an example. User entity is related to order entity. Here, cardinality for ‘user’ entity indicates that the user places an order whereas modality for ‘user’ entity indicates that it is necessary for a user to place an order. Cardinality for ‘order’ indicates that a single user can place many orders whereas modality for ‘order’ entity indicates that a user can arrive without any ‘order’.

Prototyping is an approach used for problem analysis. It is different from other modeling approaches such as structured analysis and object-oriented modeling. In this approach, a partial system is designed and used to understand the problem and requirements. Note that the partial system is not delivered to the user but used only for understanding the problem.

Generally, it is observed that users are unable to understand the software requirements specification document and thus find it difficult to visualize how the software will work when it is developed. In such a case, prototyping of a system is required as it facilitates users to determine the requirements when they see the working of the system, regardless of the fact that it is only a partial system. This approach is suitable when the system is entirely new and users have no idea about their requirements as well as the working of the software. Prototyping considers practical experience to be the best help to understand and determine user requirements, which may not be clarified with the help of requirements written on paper. Once the users operate the partial system, they are able to express the features and functions they require in the system along with the ones that they do not require.

While developing software, it is essential for the development team to consider user satisfaction as a top priority to make the software successful. For this, the development team needs to understand how users will interact with the system. This information helps the team to carefully characterize each user requirements and then create a meaningful and relevant analysis model and design model. For this, the software engineer creates scenarios in the form of use-cases to describe the system from the users’ perspective. In addition, use-cases describe the tasks or series of tasks in which the users will use the software under a specific set of conditions. Each use-case provides one or more scenarios in order to understand how a system should interact with another system to accomplish the required task. Note that use-cases do not provide descriptions about the implementation of software.

Use-cases are represented with the help of a use-case diagram, which depicts the relationships among actors and use cases within a system. A use-case diagram describes what exists outside the system (actors) and what should be performed by the system (use-cases). The notations used to represent a use-case diagram are listed in Table.

                                                    Table Use-case Notations

Let us consider the example of an online registration of a user with a bank to understand how users interact with the system. Use-case diagram represents two actors that interact within the system. These actors are user (who interacts with the system to register in the bank) and the bank staff (who provides facilities to the user). There are several use-cases in this diagram, namely, request for registration, display registration form, edit user database, add user name and date, and update.