1

Requirements Modeling

What is it? Requirements modeling in software engineering is the process of representing and organizing the
software requirements visually or formally to aid in understanding, analysis, and communication. It helps
developers, stakeholders, and project managers understand what the system needs to do and how it should behave.
The models also serve as a foundation for system design, testing, and validation.

Requirements modelling uses a combination of text and diagrammatic forms to depict requirements in a way that is
relatively easy to understand, and more important, straightforward to review for correctness, completeness, and
consistency.

Who does it? A software engineer (sometimes called an “analyst”) builds the model using requirements elicited
from the customer.

Why is it important? To validate software requirements, you need to examine them from a number of different
points of view.

Requirements Analysis

Requirements Analysis results in specification of software’s operational characteristics, indicates software’s interface
with other system elements, and establishes constraints that software must meet.

The requirements modelling action results in one or more following types of models:
1) Scenario-based models of requirements from the point of view of various system “actors”
2) Data models that deplict the information domain for the problem
3) Class-Oriented models that represent object-oriented classes and the manner in which classes collaborate to
achieve system requirements.
4) Flow-Oriented models that represent the functional elements of the system and how they transform data as it
movies through the system
5) Behavioral model that depict how the software behaves as a consequence of external “events”

Figure: The requirements model as a bridge between the system description and the design model.

1
 2

1) Objectives
2) Analysis Rules of Thumb
3) Domain Analysis
4) Requirements Modeling Approaches

Objectives
The requirements model must achieve three primary objectives.
1) To describe what the customer requires
2) To establish a basis for the creation of software design and
3) To define a set of requirements that can be validated once the software is built.

Analysis Rules of Thumb

1) The model should focus on requirements that are visible within the problem of business domain. The level of
abstraction should be relatively high.
2) Each element of the requirements model should add to an overall understanding of software requirements and
provide insight into the formation domain, and behaviour of the system.
3) Delay consideration of infrastructure and other non-functional models until design
4) Minimize coupling through the system.
5) Be certain that the requirements model provides value to all stakeholders.
6) Keep the model as simple as it can be.

Domain Analysis

Domain analysis in software engineering refers to the process of identifying, analyzing, and modeling the common
requirements, features, and rules within a specific domain (a particular area of knowledge or activity). The domain
could be anything from banking, healthcare, education, to e-commerce. By understanding the domain, software
engineers can create systems that are tailored to the specific needs of that domain.

Figure: Input and output for domain analysis

Requirements Modeling Approaches

refer to the different methods or techniques used to represent and organize the requirements of a system
visually or formally. These approaches help ensure that the requirements are well-understood, unambiguous, and
clearly communicated among stakeholders, including developers, business analysts, and customers. They are used to
capture both the functional and non-functional requirements of a system, providing a structured way to understand
what the system must do and how it should behave.

2
 3

Senario Models:
Scenario-based elements depict how the user interacts with the system and the specific
sequence of activities that occur as the software is used.
Class Models:
Class-based elements model the objects that the system will manipulate, the operations that will
be applied to the objects to effect the manipulation, relationships between the objects, and the
collaborations that occur between the classes that are defined.
Behavioral Models:
Behavioral elements depict how external events change the state of the system or the classes that reside within it.
Flow Models:
flow-oriented elements represent the system as an information transform, depicting how data objects are
transformed as they flow through various system functions.

Data modeling concepts

Determining and structuring data elements and their connections in an ordered manner is called data modeling. It
gives developers insight into the storage, retrieval and manipulation of data in a system and acts as a guide for
database design.

A data model is an abstract view of the data referred to in the product being developed.
Data modelling explaining & visualizing how the data be used by the software and defining data objects that will be
stored in a database.

3
 4

Types of Models

1) Conceptual Data Model

2) Logical Data Model
3) Physical Data Model
Conceptual Data Model
This high level model defines the entities and also their attributes and the relationships between them. It focuses on
the business concepts and is independent of any specific database technology.

It gives a front view of the each data entity and not a technical details of data.
It presents all the data entities referred to by the business and their characteristics called attributes and the
dependency or the connection between entities called Relationships.
It makes communication easy and clear as all stakeholders & reducing communication gaps.
Key characteristics of a Conceptual Data Model:
Entities: Represents key objects or concepts of interest (e.g., Customer, Order). An entity is any object or thing
that we want to store information about. It can be a physical object, a person, a concept, or an event that is
important to a business or system.
Attributes: Describes properties of each entity (e.g., Customer name, Order date).
Relationships: Defines how entities are related to one another (e.g., A Customer places Orders).
No technical details: The CDM doesn't specify data types, constraints, or storage details.

Logical Data Model

This model includes the information like data types, primary keys and constraints. It act as the bridge between the
conceptual model and the physical implementation.

It gives a detailed description of each data entity their attributes & relationship between two entities giving business
purpose to each data.

4
 5

The relationship is presented more explicitly with details like Primary key, Foreign key & Parent-child dependent
entity type.

Physical Data Model

This model deals with the actual implementation details on a specific database management system. It includes
considerations like indexing, partitioning and optimization for performance.

A physical data model is the layout of the actual database with all its components.
It gives a technical view of the data i.e the table name, column name, data type, constraints, indexes, primary key,
triggers, stored procedures, etc.
It is developed by using databases SQL,ORACLE etc.

Why Data Modeling

1) That helps in building the information system & database

2) Facilitates easy access to the business data.
3) Helps management to take decisions.
4) Facilitates business to function efficiently.
5) All the stakeholders to get a clear and easy understanding of what information is going to be stored.
6) The core rules and policies that will govern each entity.

5
 6

Data Modeling Techniques

Hierarchical Model
It has a root or a parent node and then follows a tree-like structures with other child nodes.
Only one parent is allowed for a child node, and a parent node can have multiple child nodes.
It Is very easy and simple to understand.
Simplex data models can be represented using this technique.

Network Model
This model advance of hierarchical model. Show the Graph of system.
Here a child node could have multiple parent nodes.
Navigation is faster in this model, as there are multiple paths to reach a child entity.
This model also gets very complex when data is large.

6
 7

Object Oriented Model

Object-oriented databases gained popularity with object-oriented programming
A real-world entity is represented as an object with attributes.
The model Presents a view as a collection of objects.
Each object has its methods and features.

Entity Relationship Model

This model represents the system at a very high level.
Real-world prblems can be represented through this model.
It is very easy for all technical and non-technical stakeholders to understand.
It is referred by database architects and developers to build the physical database.

7
 8

Relational Model
The relational model is the most popular model.
In this model, the Entity information is represented as a table.
All the attributes are represented as columns.
The primary key and foreignq key of each entity are alsomentioned.

Data Modeling Tools

1) Mysql workbench
2) ER/Studio
3) SQL Client
4) Lucid Chart

Flow-Oriented Modeling

Represents how data objects are transformed at they move through the system.

The flow of data in a system or process is represented by a Data Flow Diagram (DFD). It also gives insight into the
inputs and outputs of each entity and the process itself. Data Flow Diagram (DFD) does not have a control flow and
no loops or decision rules are present. Specific operations, depending on the type of data, can be explained by a
flowchart. It is a graphical tool, useful for communicating with users, managers and other personnel. it is useful for
analyzing existing as well as proposed systems.

It shows how data objects are transformed by processing the function.

Data flow diagram is graphical representation of flow of data in an information system.
It is capable of depicting incoming data flow, outgoing data flow and stored data.

Components of DFD

8
 9

Process — represents any transformative process of the incoming flow of information into the outgoing workflow.
The process receives input and generates an output;

Data flow — represents the movement of information within the system between external entities, data stores, and
processes. Reflects the nature of the data used in the system;

Datastore — represents repositories for data that is not moving at the moment. It may be either a just in case buffer
or queue for later use. Most commonly it is either database tables or membership forms;

External entity — represents sources or destination points of information outside the boundaries of the described
system. Entities either provide data to the system or receive from the processes. EE usually resides on the edges of
the diagram.

Rules of DFD

1) Each process should have at least one input and one output.
2) Each datastore should have at least one data flow in and one data flow out.

3) All process in a DFD go to either another process or data store.

9
 10

DFD Levels

1) Context Diagram (Level-0)

2) Level-1-DFD
3) Level-2-DFD

Context Diagram (Level-0) :

The context diagram is the highest-level view of the system. It shows the entire system as a single
process and the external entities that interact with it.

Level-1-DFD:
The Level 1 DFD breaks down the single process from the context diagram into sub-processes.

Level-2-DFD:
Level 2 further breaks down a process from Level 1 into more detailed sub-processes.

Level-0-DFD

Level-1-DFD

10
 11

Scenario Based Modeling

Scenario based modelling is one of the sub stages of requirements modelling. Its also typically the first stage of
requirements modelling. Scenario based modelling identifies the possible use cases for the system and produces the
use case diagram, to which all the other stages of requirements modelling refer.

Use case: Shows how users (actors) interact with a system to achieve goals.

Scenario-based elements depict how the user interacts with the system and the specific
sequence of activities that occur as the software is used.

1) Creating a Preliminary use case

2) Refining Preliminary use case
3) Writing a formal use case

Creating a Preliminary use case:

Alistair Cockburn characterizes a use case as a “contract for behavior”, the “contract”
defines the way in which an actor uses a computer-based system to accomplish some goal. In
essence, a use case captures the interactions that occur between producers and consumers of
information and the system itself.
A use case describes a specific usage scenario in straightforward language from the point of view
of a defined actor. These are the questions that must be answered if use cases are to provide
value as a requirements modeling tool. (1) what to write about, (2) how much to write about it,
(3) how detailed to make your description, and (4) how to organize the description?
To begin developing a set of use cases, list the functions or activities performed by a
specific actor.

Refining a Preliminary Use Case

Each step in the primary scenario is evaluated by asking the following questions:

• Can the actor take some other action at this point?

• Is it possible that the actor will encounter some error condition at this point? If so, what
might it be?
• Is it possible that the actor will encounter some other behavior at this point (e.g.,behavior
that is invoked by some event outside the actor’s control)? If so, what might it be?

11
 12

Cockburn recommends using a “brainstorming” session to derive a reasonably complete set of

exceptions for each use case. In addition to the three generic questions suggested earlier in this
section, the following issues should also be explored:
• Are there cases in which some “validation function” occurs during this use case? This
implies that validation function is invoked and a potential error condition might occur.
• Are there cases in which a supporting function (or actor) will fail to respond appropriately?
For example, a user action awaits a response but the function that is to respond times
out.
• Can poor system performance result in unexpected or improper user actions? For example,
a Web-based interface responds too slowly, resulting in a user making multiple selects on
a processing button. These selects queue inappropriately and ultimately generate an
error condition.

Writing a Formal Use Case

The typical outline for formal use cases can be in following manner
• The goal in context identifies the overall scope of the use case.
• The precondition describes what is known to be true before the use case is initiated.
• The trigger identifies the event or condition that “gets the use case started”
• The scenario lists the specific actions that are required by the actor and the appropriate
system responses.
• Exceptions identify the situations uncovered as the preliminary use case is refined
Additional headings may or may not be included and are reasonably self-explanatory.
Every modeling notation has limitations, and the use case is no exception. A use case focuses on
functional and behavioral requirements and is generally inappropriate for nonfunctional
requirements
However, scenario-based modeling is appropriate for a significant majority of all situations thatyou will encounter as
a software engineer.

12
 13

Fig : Simple Use Case Diagram

UML MODELS THAT SUPPLEMENT THE USE CASE

Developing an Activity Diagram

The UML activity diagram supplements the use case by providing a graphical representation of
the flow of interaction within a specific scenario. Similar to the flowchart, an activity diagram uses
rounded rectangles to imply a specific system function, arrows to represent flow through the
system, decision diamonds to depict a branching decision (each arrow emanating from the
diamond is labeled), and solid horizontal lines to indicate that parallel activities are occurring. i.e
A UML activity diagram represents the actions and decisions that occur as some function is
performed.

13
 14

Fig : Activity Diagram for ATM

Swimlane Diagrams
The UML swimlane diagram is a useful variation of the activity diagram and allows you to
represent the flow of activities described by the use case and at the same time indicate which actor or
analysis class has responsibility for the action described by an activity rectangle. Responsibilities are
represented as parallel segments that divide the diagram vertically, like the lanes in a swimming pool.
The following figure represents swimlane diagram for ATM

14
 15

Fig : swimlane diagram for ATM

15
 16

Case study on requirements modeling for Web and Mobile Apps

Requirements analysis does take time, but solving the wrong problem takes even more
time.

How Much Analysis Is Enough?

The degree to which requirements modeling for WebApps is emphasized depends on the following
factors:

• Size and complexity of WebApp increment.

• Number of stakeholders
• Size of the WebApp team.
• Degree to which members of the WebApp team have worked together
• Degree to which the organization’s success is directly dependent on the success of the
design of a specific part of the WebApp.

It only demands an analysis of those requirements that affect only that part of the WebApp.

Requirements Modeling Input

The requirements model provides a detailed indication of the true structure of the problem and
provides insight into the shape of the solution. Requirements analysis refines this understanding by
providing additional interpretation. As the problem structure is delineated as part of the
requirements model.

Requirements Modeling Output

Requirements analysis provides a disciplined mechanism for representing and evaluating WebApp
content and function, the modes of interaction that users will encounter, and the environment and
infrastructure in which the WebApp resides. Each of these characteristics can be represented as a
set of models that allow the WebApp requirements to be analyzed in a structured manner. While
the specific models depend largely upon the nature of the WebApp, there are five main classes of
models:

• Content model—identifies the full spectrum of content to be provided by the WebApp.

Content includes text, graphics and images, video, and audio data.
• Interaction model—describes the manner in which users interact with the WebApp.

• Functional model—defines the operations that will be applied to WebApp content and
describes other processing functions that are independent of content but necessary to the end user.
• Navigation model—defines the overall navigation strategy for the WebApp.
• Configuration model—describes the environment and infrastructure in which the WebApp
resides.

16
 17

4. Content. Model for WebApps

The content model contains structural elements that provide an important view of content
requirements for a WebApp. These structural elements encompass content objects and all analysis
classes, user-visible entities that are created or manipulated as a user interacts with the Content can
be developed prior to the implementation of the WebApp, while the WebApp is being built, or long
after the WebApp is operational.

A content object might be a textual description of a product, an article describing a news event, an
action photograph taken at a sporting event, a user’s response on a discussion forum, an animated
representation of a corporate logo, a short video of a speech, or an audio overlay for a collection of
presentation slides. The content objects might be stored as separate files, embedded directly into
Web pages, or obtained dynamically from a database. Content objects can be determined directly
from use cases by examining the scenario description for direct and indirect references to content.
The content model must be capable of describing the content object Component.

Interaction Model for WebApps

Interaction model that can be composed of one or more of the following elements: (1) use cases, (2)
sequence diagrams, (3) state diagrams,16 and/or (4) user interface prototypes.

Functional Model for WebApps

The functional model addresses two processing elements of the WebApp, each representing a
different level of procedural abstraction: (1) user-observable functionality that is delivered by the
WebApp to end users, and (2) the operations contained within analysis classes that implement
behaviors associated with the class.

User-observable functionality encompasses any processing functions that are initiated directly by
the user.

Configuration Models for WebApps

The configuration model is nothing more than a list of server-side and client-side attributes.
However, for more complex WebApps, a variety of configuration complexities may have an impact
on analysis and design. The UML deployment diagram can be used in situations in which complex
configuration architectures must be considered.

Navigation Modeling

Navigation modeling considers how each user category will navigate from one WebApp element
(e.g., content object) to another. The mechanics of navigation are defined as part of design. At this
stage, you should focus on overall navigation requirements. The following questions should be
considered:

• Should certain elements be easier to reach than others? What is the priority for
presentation?
• Should certain elements be emphasized to force users to navigate in their direction?
• How should navigation errors be handled?
• Should navigation to related groups of elements be given priority over navigation to a
specific element?

17
 18

• Should navigation be accomplished via links, via search-based access, or by some other
means?
• Should certain elements be presented to users based on the context of previous navigation
actions?
• Should a navigation log be maintained for users?
• Should a full navigation map or menu be available at every point in a user’s interaction?
• Should navigation design be driven by the most commonly expected user behaviors or by
the perceived importance of the defined WebApp elements?
• Can a user “store” his previous navigation through the WebApp to expedite future usage?
• For which user category should optimal navigation be designed?
• How should links external to the WebApp be handled? Overlaying the existing browser
window? As a new browser window? As a separate frame?

These and many other questions should be asked and answered as part of navigation analysis.

Case Study: Requirements Modeling for a Web-Based E-Learning Platform

Project Overview:

An educational institution seeks to develop an e-learning web application where students can access
courses, watch video lectures, take quizzes, and track their progress. The platform will also allow
instructors to upload course materials, create assessments, and evaluate student performance.

Step 1: Requirements Elicitation

The first step is to gather requirements from various stakeholders, including students, instructors,
and administrators.

Stakeholders:

1. Students: Need to access courses, watch videos, take quizzes, and view grades.
2. Instructors: Need to upload materials, create quizzes, and grade students.
3. Administrators: Need to manage user accounts, monitor system performance, and maintain
course data.

Step 2: Functional Requirements

For Students:

- View and enroll in available courses.

- Access course materials (videos, PDFs).
- Take quizzes and submit assignments.
- Track progress and view grades.

18
 19

For Instructors:
- Create and manage courses.
- Upload video lectures and course materials.
- Create and grade quizzes and assignments.
- View students' performance and provide feedback.

For Administrators:
- Manage user roles (student, instructor, admin).
- Ensure data security and backups.
- Monitor system usage and performance.

Step 3: Non-Functional Requirements

Performance: The application should handle up to 1000 concurrent users.

Security: Only authenticated users can access the platform, and sensitive data (like grades) must be
encrypted.
Usability: The system should be easy to navigate for users with minimal technical knowledge.
Scalability: The system should support additional courses and users in the future without major
changes.

Step 4: Use Case Modeling

The next step is to create use case diagrams to visualize the interactions between users (actors) and
the system.

1. Student Use Case Diagram:

- Actors: Student

- Use cases:

- "Enroll in Course"
- "View Course Materials"
- "Take Quiz"
- "View Grades"

2. Instructor Use Case Diagram:

- Actors: Instructor

- Use cases:

- "Create Course"
- "Upload Materials"
- "Create Quiz"
- "Grade Quiz"

19
 20

3. Administrator Use Case Diagram:

- Actors: Administrator

- Use cases:

- "Manage Users"
- "Monitor System Performance"

Example Use Case Diagram:

Step 5: Data Modeling

Entity-Relationship Diagram (ERD): Entities for this system might include:

1. User (Student/Instructor/Admin): Has attributes like `userID`, `name`, `email`, `role`.

2. Course: Has attributes like `courseID`, `title`, `description`.
3. Quiz: Associated with courses, has attributes like `quizID`, `courseID`, `questions`.
4. Grade: Associated with students and quizzes, includes attributes like `studentID`, `quizID`, `grade`.

Example ERD:

20
 21

Step 6: Requirements Specification Document (SRS)

The final step is to write the Software Requirements Specification (SRS) document. This document
should include:

Introduction: Purpose, scope, definitions.

System Overview: High-level description of the system.
Functional Requirements: Detailed description of each use case.
Non-Functional Requirements: Performance, security, usability, and scalability constraints.
Data Model: Entity definitions and relationships.
Acceptance Criteria: Tests that will ensure the system meets the required functionality.

21