UNIT II-REQUIREMENTS ANALYSIS AND SPECIFICATION

Requirement analysis and specification – Requirements gathering and analysis – Software

Requirement Specification – Formal system specification – Finite State Machines – Petrinets – Object
modelling using UML – Use case Model – Class diagrams – Interaction diagrams – Activity diagrams
– State chart diagrams – Functional modelling – Data Flow Diagram- CASE TOOLS.

1. Introduction
SOFTWARE REQUIREMENTS
The process of establishing the services that the customer requires from a system and the constraints
under which it operates and is developed Requirements may be functional or non-functional
➢ Functional requirements describe system services or functions
➢ Non-functional requirements are a constraint on the system or on the development process.
Types of requirements
1. User requirements
Statements in natural language (NL) plus diagrams of the services the system provides and its
operational constraints. Written for customers
2. System requirements
A structured document setting out detailed descriptions of the system services. Written as a contract
between client and contractor
3. Software specification
A detailed software description which can serve as a basis for a design or implementation. Written for
developers

FUNCTIONAL AND NON-FUNCTIONAL COMPONENTS:

a) Functional requirements:
Functionality or services that the system is expected to provide.
Functional requirements may also explicitly state what the system shouldn‘t do. Functional
requirements specification should be:
➢ Complete: All services required by the user should be defined
➢ Consistent: should not have contradictory definition (also avoid ambiguity don‘t leave room for
different interpretations)
b) Examples:
The LIBSYS system
A library system that provides a single interface to a number of databases of articles in different
libraries.
Users can search for, download and print these articles for personal study.
c) Non-Functional requirements
Requirements that are not directly concerned with the specific functions delivered by the system
typically relate to the system as a whole rather than the individual system features
Often could be deciding factor on the survival of the system (e.g. reliability, cost, response time)
d) Product requirements
e) Organizational requirements
k) Examples of process requirements
 1. Requirement Analysis and Specification

Definition:
➢ The process of defining user expectations to build a new software product or to modify an existing
one is known as requirement analysis.
➢ Sometimes known as requirement engineering requirements gathering, or requirements capture in
software engineering.
➢ The tasks that go into determining the needs or conditions to meet for a new or altered product,
taking into account the potentially conflicting requirements of the various stakeholders, and
analyzing, documenting, validating, and managing software or system requirements are all included
in requirements analysis.
➢ This exercise goes over all of the requirements and may provide a graphical representation of the
entire system. As a result, the project's understandability is predicted to improve significantly after
the study is completed.
➢ We may also leverage the contact with the customer to clear up any confusion and determine which
requirements are more crucial than others.

2. Requirements Gathering and Analysis

Requirements engineering (RE) refers to the process of defining, documenting, and maintaining
requirements in the engineering design process. Requirement engineering provides the appropriate
mechanism to understand what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system.Thus, requirement
engineering is the disciplined application of proven principles, methods, tools, and notation to
describe a proposed system's intended behavior and its associated constraints.

Requirement Engineering Process

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
2.1 Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified with the help of
customers and existing systems processes, if available.
Definition:
It is all about obtaining information from stakeholders. In other words, once the business analysis has
communicated with stakeholders for understanding their requirements, it can be described as
elicitation. It can also be described as a requirement gathering.
Requirement gathering can be done by communicating with stakeholders directly or by doing some
research, experiments. The activities can be planned, unplanned, or both.
➢ Planned activities include workshops, experiments.
➢ Unplanned activities happen randomly. Prior notice is not required for such activities.
➢ For example, you directly go to the client site and start discussing the requirements however there
was no specific agenda published in advance.

Following tasks are the part of elicitation:

➢ Prepare for Elicitation: The purpose here is to understand the elicitation activity scope, select the
right techniques, and plan for appropriate resources.
➢ Conduct Elicitation: The purpose here is to explore and identify information related to change.
➢ Confirm Elicitation Results: In this step, the information gathered in the elicitation session is
checked for accuracy.
We hope, you have got an idea about requirement elicitation by now. Let’s move on to the
requirements elicitation techniques.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and
also resolve conflicts if any.

Problems of Requirements Gathering and Analysis

• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system requirements.
 3. Software Requirement Specification
Software requirement specification is a kind of document which is created by a software analyst after
the requirements collected from the various sources - the requirement received by the customer
written in ordinary language. It is the job of the analyst to write the requirement in technical
language so that they can be understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements.
DFD shows the flow of data through a system. The system may be a company, an organization, a
set of procedures, a computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.
Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items
defined in DFDs. At the requirements stage, the data dictionary should at least define customer data
items, to ensure that the customer and developers use the same definition and terminologies.
Entity-Relationship Diagrams: Another tool for requirement specification is the entity-relationship
diagram, often called an "E-R diagram." It is a detailed logical representation of the data for the
organization and uses three main constructs i.e. data entities, relationships, and their associated
attributes.
3.1 Software Requirement Validation:
After requirement specifications developed, the requirements discussed in this document are validated.
The user might demand illegal, impossible solution or experts may misinterpret the needs.
Requirements can be the check against the following conditions -
• If they can practically implement
• If they are correct and as per the functionality and specially of software
• If there are any ambiguities
• If they are full
• If they can describe
3.2 Requirements Validation Techniques
Requirements reviews/inspections: systematic manual analysis of the requirements.
Prototyping: Using an executable model of the system to check requirements.
Test-case generation: Developing tests for requirements to check testability.
Automated consistency analysis: checking for the consistency of structured requirements
descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the requirements
engineering process and system development.
New requirements emerge during the process as business needs a change, and a better understanding of
the system is developed.
The priority of requirements from different viewpoints changes during development process. The
business and technical environment of the system changes during the development.
Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software development project. Hence they
should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements: Largely software requirements must be categorized into two

categories:
Functional Requirements: Functional requirements define a function that a system or
system element must be qualified to perform and must be documented in different
forms. The functional requirements are describing the behavior of the system as it
correlates to the system's functionality.
Non-functional Requirements: This can be the necessities that specify the criteria that
can be used to decide the operation instead of specific behaviors of the system. Non-
functional requirements are divided into two main categories:
Execution qualities like security and usability, which are observable at run time.
Evolution qualities like testability, maintainability, extensibility and scalability that
embodied in the static structure of the software system.

3.3 Requirements Gathering Techniques

There are several techniques available for elicitation, however, the commonly used techniques are
explained below:
1) Stakeholder Analysis
Stakeholders can include team members, customers, any individual who is impacted by the project or
it can be a supplier. Stakeholder analysis is done to identify the stakeholders who will be impacted
by the system.
2) Brainstorming
This technique is used to generate new ideas and find a solution for a specific issue. The members
included for brainstorming can be domain experts, subject matter experts. Multiple ideas and
information give you a repository of knowledge and you can choose from different ideas.
This session is generally conducted around the table discussion. All participants should be given an
equal amount of time to express their ideas.
Brainstorming technique is used to answer the below questions:
• What is the expectation of a system?
• What are the risk factors that affect the proposed system development and what to do to avoid that?
• What are the business and organization rules required to follow?
• What are the options available to resolve the current issues?
• What should we do so that this particular issue does not happen in the future?
Brainstorming can be described in the following phases:
There are some basic rules for this technique which should be followed to make it
a success:
• The time limit for the session should be predefined.
• Identify the participants in advance. One should include 6-8 members for the session.
• The agenda should be clear enough for all the participants.
• Clear expectations should be set with the participants.
• Once you get all the information, combine the ideas, and remove the duplicate ideas.
• Once the final list is ready, distribute it among other parties.
Benefits:
• Creative thinking is the result of the brainstorming session.
• Plenty of ideas in a short time.
• Promotes equal participation.
Drawbacks:
• Participants can be involved in debating ideas.
• There can be multiple duplicate ideas.
3) Interview
This is the most common technique used for requirement elicitation. Interview techniques should be
used for building strong relationships between business analysts and stakeholders. In this technique,
the interviewer directs the question to stakeholders to obtain information. One to one interview is
the most commonly used technique.
If the interviewer has a predefined set of questions then it’s called a structured interview.
If the interviewer is not having any particular format or any specific questions then it’s called an
unstructured interview.
For an effective interview, you can consider the 5 Why technique. When you get an answer to all your
Whys then you are done with your interview process. Open-ended questions are used to provide
detailed information. In this interviewee cannot say Yes or No only.
Closed questions can be answered in Yes or No form and also for areas used to get confirmation on
answers.
Basic Rules:
• The overall purpose of performing the interviews should be clear.
• Identify the interviewees in advance.
• Interview goals should be communicated to the interviewee.
• Interview questions should be prepared before the interview.
• The location of the interview should be predefined.
The time limit should be described.
The interviewer should organize the information and confirm the results with the interviewees as soon as
possible after the interview.
Benefits:
• Interactive discussion with stakeholders.
• The immediate follow-up to ensure the interviewer’s understanding.
• Encourage participation and build relationships by establishing rapport with the stakeholder.
Drawbacks:
• Time is required to plan and conduct interviews.
• Commitment is required from all the participants.
• Sometimes training is required to conduct effective interviews.
4) Document Analysis/Review
This technique is used to gather business information by reviewing/examining the available materials that
describe the business environment. This analysis is helpful to validate the implementation of current solutions
and is also helpful in understanding the business need.
Document analysis includes reviewing the business plans, technical documents, problem reports, existing
requirement documents, etc. This is useful when the plan is to update an existing system. This technique is
useful for migration projects.
This technique is important in identifying the gaps in the system i.e. to compare the AS-IS process with the TO-
BE process. This analysis also helps when the person who has prepared the existing documentation is no longer
present in the system.
Benefits:
• Existing documents can be used to compare current and future processes.
• Existing documents can be used as a base for future analysis.
Drawbacks:
• Existing documents might not be updated.
• Existing documents might be completely outdated.
• Resources worked on the existing documents might not be available to provide information.
• This process is time-consuming.
5) Focus Group
By using a focus group, you can get information about a product, service from a group. The Focus group
includes subject matter experts. The objective of this group is to discuss the topic and provide information. A
moderator manages this session.
The moderator should work with business analysts to analyze the results and provide findings to the
stakeholders.
If a product is under development and the discussion is required on that product then the result will be to update
the existing requirement or you might get new requirements. If a product is ready to ship then the discussion
will be on releasing the product.
How Focus groups are different than group interviews?
A Focus group is not an interview session conducted as a group; rather it is a discussion during which feedback
is collected on a specific subject. The session results are usually analyzed and reported. A focus group typically
consists of 6 to 12 members. If you want more participants then create more than one focus group.
Benefits:
You can get information in a single session rather than conducting one to one interview.
Active discussion with the participants creates a healthy environment.
One can learn from other’s experiences.
Drawbacks:
It might be difficult to gather the group on the same date and time.
If you are doing this using the online method then the participant’s interaction will be limited.
A Skilled Moderator is required to manage focus group discussions.
6) Interface Analysis
Interface analysis is used to review the system, people, and processes. This analysis is used to identify how the
information is exchanged between the components. An Interface can be described as a connection between two
components. This is described in the below image: The interface analysis focus on the below questions:
Who will be using the interface?
What kind of data will be exchanged?
When will the data be exchanged?
How to implement the interface?
Why we need the interface? Can’t the task be completed without using the interface?
Benefits:
• Provide missed requirements.
• Determine regulations or interface standards.
• Uncover areas where it could be a risk for the project.
Drawbacks:
• The analysis is difficult if internal components are not available.
• It cannot be used as a standalone elicitation activity.
7) Observation
The main objective of the observation session is to understand the activity, task, tools used, and events
performed by others.
The plan for observation ensures that all stakeholders are aware of the purpose of the observation session, they
agree on the expected outcomes, and that the session meets their expectations. You need to inform the
participants that their performance is not judged.
During the session, the observer should record all the activities and the time taken to perform the work
by others so that he/she can simulate the same. After the session, the BA will review the results and
will follow up with the participants. Observation can be either active or passive.
Active observation is to ask questions and try to attempt the work that other persons are doing.
Passive observation is silent observation i.e. you sit with others and just observe how they are doing
their work without interpreting them.
Benefits:
• The observer will get a practical insight into the work.
• Improvement areas can be easily identified.
Drawbacks:
• Participants might get disturbed.
• Participants might change their way of working during observation and the observer might not
get a clear picture.
• Knowledge-based activities cannot be observed.
8) Prototyping
Prototyping is used to identify missing or unspecified requirements. In this technique, frequent demos
are given to the client by creating the prototypes so that client can get an idea of how the product will
look like. Prototypes can be used to create a mock-up of sites, and describe the process using diagrams.
Benefits:
• Gives a visual representation of the product.
• Stakeholders can provide feedback early.
Drawbacks:
• If the system or process is highly complex, the prototyping process may become time-
consuming.
• Stakeholders may focus on the design specifications of the solution rather than the
 requirements that any solution must address.
9) Joint Application Development (JAD)/ Requirement Workshops
This technique is more process-oriented and formal as compared to other techniques. These are
structured meetings involving end-users, PMs, SMEs. This is used to define, clarify, and complete
requirements.
This technique can be divided into the following categories:
Formal Workshops: These workshops are highly structured and are usually conducted with the
selected group of stakeholders. The main focus of this workshop is to define, create, refine, and reach
closure on business requirements.
Business Process Improvement Workshops: These are less formal as compared to the above one.
Here, existing business processes are analyzed and process improvements are identified.
Benefits:
• Documentation is completed within hours and is provided quickly back to participants for
review.
• You can get on the spot confirmation on requirements.
• Successfully gathered requirements from a large group in a short period.
• Consensus can be achieved as issues and questions are asked in the presence of all the
stakeholders.
Drawbacks:
• Stakeholder’s availability might ruin the session.
• The success rate depends on the expertise of the facilitator.
• A workshop motive cannot be achieved if there are too many participants.
10) Survey/Questionnaire
For Survey/Questionnaire, a set of questions is given to stakeholders to quantify their thoughts. After
collecting the responses from stakeholders, data is analyzed to identify the area of interest of
stakeholders.
Questions should be based on high priority risks. Questions should be direct and unambiguous. Once
the survey is ready, notify the participants and remind them to participate.
Two types of questions can be used here:
Open-Ended: Respondent is given the freedom to provide answers in their own words rather than
selecting from predefined responses. This is useful but at the same time, this is time- consuming as
interpreting the responses is difficult.
Close Ended: It includes a predefined set of answers for all the questions and the respondent has to
choose from those answers. Questions can be multiple choice or can be ranked from not important to
very important.

Benefits:
• Easy to get data from a large audience.
• Less time is required for the participants to respond.
• You can get more accurate information as compared to interviews.
Drawback:
• All the Stakeholders might not participate in the surveys.
• Questions may not be clear to all the participants.
• Open-ended questions require more analysis.
• Follow up surveys might be required based on the responses provided by participants.

A Software requirements specification document describes the intended purpose, requirements and
nature of a software to be developed. It also includes the yield and cost of the software.

4. Formal system specification

Need for Formal Specification:
Ambiguity: Natural language descriptions of software can be ambiguous, leading to
misunderstandings.
Completeness: Informal descriptions may not capture all requirements or behaviors.
Verification: Formal specifications can be used to verify properties of the software, such as
 correctness and consistency.
Types of Formal Specifications:
Model-based: Use of mathematical models (e.g., state machines, Petri nets) to describe the system's
behavior.
Logic-based: Use of logical expressions (e.g., predicate logic, temporal logic) to specify properties
and constraints.
Benefits of Formal Specifications:
Clarity: Provides a precise and clear description of the system's requirements and behavior.
Consistency: Helps identify inconsistencies and ambiguities early in the development process.
Verification: Facilitates formal verification techniques to ensure that the software meets its
requirements.
Documentation: Serves as comprehensive documentation for the software system.
Challenges of Formal Specifications:
Complexity: Formal specifications can be complex and require expertise to develop and understand.
Tool Support: Limited tool support for creating, analyzing, and maintaining formal specifications.
Cost: Developing formal specifications can be time-consuming and expensive compared to informal
methods.
Examples of Formal Specification Languages:
• Z: A formal specification language based on set theory and first-order logic. VDM (Vienna
Development Method): A formal method for the specification and development of software
systems.
• B: A method for specifying software systems using formal refinement techniques.
• TLA+ (Temporal Logic of Actions): A formal specification language for describing
concurrent and distributed systems.
Process of Formal Specification:
Requirements Elicitation: Gather and analyze requirements from stakeholders.
Specification Development: Develop formal specifications using appropriate languages and
techniques.
Specification Review: Review the formal specifications for correctness, completeness, and
consistency.
Verification: Use formal methods to verify that the specifications meet the requirements.
Maintenance: Update the specifications as the software system evolves.
Application of Formal Specifications:
Critical Systems: Used in the development of safety-critical and mission-critical
systems where correctness is paramount.
Concurrency: Useful for specifying and verifying concurrent and distributed systems.
Security: Helps in specifying and analyzing security properties of software systems.
 5. Finite State Machines
Introduction to Finite State Machines (FSMs):
FSMs are mathematical models used to represent and control the behavior of systems with a finite
number of states. They are widely used in modeling software, hardware, and other systems with
discrete behavior.
5.1 Types of Finite State Machines:
Deterministic Finite Automata (DFA): A type of FSM where each state has exactly one transition
for each possible input symbol.
Nondeterministic Finite Automata (NFA): A type of FSM where a state can have multiple
transitions for the same input symbol.
Components of FSMs:
States: Represent different configurations or conditions of the system.
Transitions: Define the rules for moving from one state to another based on input.
Input Alphabet: Set of symbols that can be used as inputs to the FSM.
Output Function: Specifies the output produced by the FSM in each state.
5.2 Applications of FSMs:
Software Modeling: Used to model the behavior of software systems, such as parsers, protocol
implementations, and user interfaces.
Hardware Design: Used in digital circuit design for control logic and sequential circuits.
Natural Language Processing: Used in language processing tasks like parsing and tokenization.
5.3 Finite State Machine Design:

State Diagram: Graphical representation of an FSM, showing states, transitions, and inputs.
State Table: Tabular representation of an FSM, showing transitions for each state and input
combination.
State Minimization: Technique to reduce the number of states in an FSM without changing its
behavior.
5.4 Practical Considerations:
State Explosion: Problem arising when the number of states in an FSM becomes too large, making it
difficult to manage.
Testing and Validation: Important steps in the design process to ensure that the FSM behaves as
expected.
Implementation: FSMs can be implemented using programming languages or specialized tools.
Advanced Topics:
Hierarchical FSMs: FSMs that can be decomposed into smaller, more manageable FSMs.
Mealy and Moore Machines: Variants of FSMs where the output depends on the current state
(Moore) or the current state and input (Mealy).
 6. Petrinets
Petri nets — Formal technique for describing concurrent interrelated activities .
Invented by Carl Adam Petri, 1962
Consists of four parts
• A set of places
• A set of transitions
• An input function
• An output function
Originally of interest to automata theorists
Found wide applicability in computer science
➢ Performance Evaluation
➢ Operating ystems
➢ Software Engineering
The Classical Petri Net Model:
A Petri net is a network composed of places (O) and transitions (∏)

Connections are directed and between a place and a transition, or a transition and a place (e.g.
Between “p1 and t1” or “t1 and p2” above)Tokens(.) are the dynamic objects. Another (equivalent)
notation is to use a solid bar for the transitions:

We may use either notation since they are equivalent, sometimes one makes the diagram easier to read
than the other.
The state of a Petri net is determined by the distribution of tokens over the places (we could represent
the above state as (1, 2, 1, 1) for (p1, p2, p3, p4))
Transition t1 has three input places (p1, p2 and p3) and two output places (p3 and p4). Place p3 is both
an input and an output place of t1.
Enabling Condition:
➢ Transitions are the active components and places and tokens are passive components.
➢ A transition is enabled if each of the input places contains tokens.

Transition t1 is not enabled, transition t2 is enabled.

Firing:
An enabled transition may fire.
Firing corresponds to consuming tokens from the input places and producing tokens for the output
places.

Firing is atomic (only one transition fires at a time, even if more than one is enabled)

7. Object Modelling using UML

The Unified Modelling Language, or UML, is a set of diagrammatic techniques, which are
specifically tailored for object-oriented development, and which have become an industry standard
for modelling object-oriented systems.
The UML grew out of the work of James Rumbaugh, Orady Booch and Ivor Jacobson, and has been
approved as a development standard by the Object Management Group.

Software Developers use specialized diagrams to model the system that they are working on
throughout the development process. Each model produced represents part of the system or some
aspect of it, such as the structure of the stored data, or the way that operations are carried out. Each
model provides a view of the system.

The principal UML diagrams with brief descriptions

Model View of the system

Use case How the system interacts with its users.

The data elements in the system and the relationships between
Class
them.
Interaction (sequence How the objects interact to achieve the functionality of a use
and collaboration) case.
How the different objects of a single class behave through all
State
the use cases in which the class is involved.
Activity The sequence of activities that make up a process.
The different software components of the system and the
Component
dependencies between them
 The software and hardware elements of the system and the
Deployment
physical relationships between them.

8. Use Cases:

Introduction

Once you have developed an initial set of functional requirements during the
Requirements Gathering phase you will have a good understanding of the intended
behavior of the system. This includes what functionality is desired, what constraints
are imposed, and what business objectives will be satisfied. However, one
shortcoming of a traditional 'laundry-list' of requirements is that they are static and
don't adapt to the different business processes that need to be supported by one
feature.

For example, in a fictitious online library system, the functionality for managing
returns would need to handle the separate situations where a borrower returns a book
early and when they return it late. Although the same functionality is involved, they
are different situations and the system would need to handle the separate conditions
in each use case.
Definition:
A use case diagram of a software system describes the functionalities to be implemented by the software
system. It is at a relatively higher level of abstraction compared to the other UML diagrams and will not include
implementation details. Hence, it could be considered as a schematic view of the requirements for the software
system. Together with the narratives for the use cases, the use case view provides a complete set of
requirements for the system.
What is a Use Case?
A use case is a definition of a specific business objective that the system needs to accomplish. They do this by
describing the various external actors (or entities) that exist outside of the system, together with the specific
interactions they have with the system to accomplish the business objective.
Why Are They Important?
The major benefits that come with the creation of use cases are in the planning stage of development. Factors
such as requirements gathering, defining scope, and roadmap creation are all improved through these use cases.
They also allow the team to determine the best possible outcome scenario, accurately depicting the intended
design and use of the system. When it comes to less-than-ideal use cases, the brainstorming of these alternative
possible outcomes helps developers identify potential problems before they happen.
How to Write a Use Case
Thankfully, writing a use case can be broken down into three basic steps or questions that need to be answered:

Who is going to use the product?

What will it be used for?

How are they going to use it?

These questions form the basis of any successful use case, and should be used as a starting guide when writing
your own. Beyond that, use cases can be as high-level or detailed as they need to be for the audience and
system. The key to an effective and helpful use case is to carefully consider the flow of events for a typical user,
and use those to form the use case.
What to Include in a Use Case
As you’re writing your use case, there are several components that should typically be included. These range
from the identifier of the use case to who are involved and alternative solutions:
Use case number - assigning a number to each use case helps organize your records and can be sorted
in chronological order or by other criteria depending on how the developers decide to label them.
Use case name, description, and goal - giving a clear and concise name, description, and goal to each
use case also helps organize documentation while preventing scope creep.
Actor - this is someone or something that performs a behavior or action (can be a person or an object).
If we take an e-commerce site as an example, actors might include buyers, credit card companies,
shipping companies, and more.

Stakeholders - anyone with interests in the functionality and success of the system are called
stakeholders, and are often indirectly involved (not users but those that benefit from how the system
functions).

Primary actor - this is someone or something whose goals are fulfilled by the system in question, and
while they don’t always start the use case, it’s fairly common for them to do so.
Pre-conditions - the statements about what needs to happen before the use case starts.
Triggers - used to start a use case, triggers are events that initiate the steps of a scenario.

Post-conditions - the statements about the possible states that the system can be in after the use case
ends.

Basic flow - also called the main success scenario, this is a use case path that works perfectly and as
intended with no exceptions (this is often used as a base to create alternative paths).
Alternative path (or flow) -a variation of the main success scenario, these usually show what happens
when there’s an error or unexpected event in a use case.
Types of Use Case
Use cases can be described either at an abstract level (known as a business use-case) or at an implementation-
specific level (known as a system use case). Each of these is described in more detail below:

Business Use Case - also known as an "Abstract-Level Use Case", these use cases are written in a
technology-agnostic manner, simply referring to the high-level business process being described
(e.g. "book return") and the various external actors that take part in the process (e.g. "borrower",
"librarian", etc.). The business use case will define the sequence of actions that the business needs to
perform to give a meaningful, observable result to the external entity.

System Use Case - also known as an "Implementation Use Case", these use cases are written at a more
granular level of detail than the business use case and refer to specific processes that will be carried
out by different parts of the system. For example, a system use case might be "return
book when overdue". It would then describe the interactions of the various actors (borrower,
librarian, etc.) with the system in carrying out the end-to-end process.
Symbols in Use Case diagram :Actor:
An actor represents an external entity that interacts with a system. Since it is external to the system, the actor
itself is not fully modelled by the system.
User of a system is a typical example of an actor. Other types of actors include software systems that are being
integrated with the current system (e.g., a network protocol, a database system, a file system), external hardware
such as a sensor and so on.

Actors are classified into primary actors (also called active actors) and secondary actors (also called passive
actors)
5 relationship types in a use case diagram.
• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case

Use Case:
A use case represents a functionality (typically a requirement) that is expected to be implemented by
the system. The details of a use case, other than its unique name, are not represented visually in the
diagram; such details are given in use case narratives. Depending on the application domain and the
choice made by the designer, a use case may be broken down into several use cases which are
connected through <<include>> or <<extend>> relationships (described later in this document).
Generalization:
This represents a relationship between actors or between use cases. If two actors are related through this
relationship, then the actor (or use case) at the tail end of the arrow (connected to the base of the
triangle) is a specialized version of the actor (or use case) at the other end.

Association:
This represents a two-way communication between an actor and a use case and hence is a binary
relation. Since it is a two-way communication, for every use case initiated by a primary actor, the
actor must get a response back from the use case.

Extend relationship: The use case is optional and comes after the base use case. It isrepresented by a
dashed arrow in the direction of the base use case with the notation
<<extend>> .
Include relationship: The use case is mandatory and part of the base use case.

• error or unexpected event in a use case.

Example: ATM SYSTEM

Unified Modeling Language, Tools

UML

Unified Modeling Language (UML) is a general purpose modelling language. The main aim of UML is to
define a standard way to visualize the way a system has been designed. It is quite similar to blueprints used in
other fields of engineering.

UML is not a programming language, it is rather a visual language. We use UML diagrams to portray the
behavior and structure of a system. UML helps software engineers, businessmen and system architects with
modelling, design and analysis. The Object Management Group (OMG) adopted Unified Modelling Language
as a standard in 1997. Its been managed by OMG ever since. International Organization for Standardization
(ISO) published UML as an approved standard in 2005. UML has been revised over the years and is reviewed
periodically.

Do we really need UML?

Complex applications need collaboration and planning from multiple teams and hence require a clear and
concise way to communicate amongst them.
Businessmen do not understand code. So UML becomes essential to communicate with non programmers
essential requirements, functionalities and processes of the system.
A lot of time is saved down the line when teams are able to visualize processes, userinteractions and static
structure of the system.
UML is linked with object oriented design and analysis. UML makes the use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:
Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams include:
Component Diagrams, Object Diagrams, Class Diagrams and Deployment Diagrams.
Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior diagrams include: Use
Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.
The image below shows the hierarchy of diagrams according to UML 2.2

Object Oriented Concepts Used in UML –

Class – A class defines the blue print i.e. structure and functions of an object.
Objects – Objects help us to decompose large systems and help us to modularize our system.
Modularity helps to divide our system into understandable components so that we can build our
system piece by piece. An object is the fundamental unit (building block) of a system which is
used to depict an entity.
Inheritance – Inheritance is a mechanism by which child classes inherit the properties of their parent
classes.
Abstraction – Mechanism by which implementation details are hidden from user.
Encapsulation – Binding data together and protecting it from the outer world is referred to as
encapsulation.
Polymorphism – Mechanism by which functions or entities are able to exist in differentforms.
Additions in UML 2.0 –
Software development methodologies like agile have been incorporated and scope of original UML
specification has been broadened.
Originally UML specified 9 diagrams. UML 2.x has increased the number of diagrams from 9 to 13.
The four diagrams that were added are : timing diagram, communication diagram, interaction
overview diagram and composite structure diagram. UML 2.x renamed statechart diagrams to state
machine diagrams.
UML 2.x added the ability to decompose software system into components and sub-components.

9. Structural UML Diagrams –

Class Diagram – The most widely use UML diagram is the class diagram. It is the building block of
all object oriented software systems. We use class diagrams to depict the static structure of a system
by showing system’s classes,their methods and attributes. Class diagrams also help us identify
relationship between different classes orobjects.
Composite Structure Diagram – We use composite structure diagrams to represent the internal
structure of a class and its interaction points with other parts of the system. A composite structure
diagram represents relationship between parts and their configuration which determine how the
classifier (class, a component, or a deployment node) behaves. They represent internal structure of a
structured classifier making the use of parts, ports, and connectors. We can also model collaborations
using composite structure diagrams. They are similar to class diagrams except they represent
individual parts in detail as compared to the entire class.
Object Diagram – An Object Diagram can be referred to as a screenshot of the instances in a system
and the relationship that exists between them. Since object diagrams depict behaviour when objects
have been instantiated, we are able to study the behaviour of the system at a particular instant. An
object diagram is similar to a class diagram except it shows the instances of classes in the system. We
depict actual classifiers and their relationships making the use of class diagrams. On the other hand,
an Object Diagram represents specific instances of classes and relationships between them at a point
of time.
Component Diagram – Component diagrams are used to represent how the physical components in
a system have been organized. We use them for modelling implementation details. Component
Diagrams depict the structural relationship between software system elements and help us in
understanding if functional requirements have been covered by planned development. Component
Diagrams become essential to use when we design and build complex systems. Interfaces are used by
components of the system to communicate with each other.
Deployment Diagram – Deployment Diagrams are used to represent system hardware and its
software.It tells us what hardware components exist and what software
components run on them.We illustrate system architecture as distribution of software artifacts over
distributed targets. An artifact is the information that is generated by system software. They are primarily
used when a software is being used, distributed or deployed over multiple machines with different
configurations.
Package Diagram – We use Package Diagrams to depict how packages and their elements have
been organized. A package diagram simply shows us the dependencies between different packages
and internal composition of packages. Packages help us to organise UML diagrams into
meaningful groups and make the diagram easy to understand. They are primarily used to organise
class and use case diagrams.

Behavior Diagrams –

State Machine Diagrams – A state diagram is used to represent the condition of the system or
part of the system at finite instances of time. It’s a behavioral diagram and it represents the
behavior using finite state transitions. State diagrams are also referred to as State machines and
State-chart Diagrams . These terms are often used interchangeably.Sosimply, a state diagram is
used to model the dynamic behavior of a class in response to time and changing external stimuli.
Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a system. We
can also use an activity diagram to refer to the steps involved in the execution of a use case. We
model sequential and concurrent activities using activity diagrams. So, we basically depict
workflows visually using an activity diagram.An activity diagram focuses on condition of flow and
the sequence in which it happens. We describe or depict what causes a particular event using an
activity diagram.
Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a system or a part
of a system. They are widely used to illustrate the functional requirements of the system and its
interaction with external agents(actors). A use case is basically a diagram representing different
scenarios where the system can be used. A use case diagram gives us a high level view of what the
system or a part of the system does without going into implementation details.
Sequence Diagram – A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place.We can also use the terms
event diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams describe how
and in what order the objects in a system function. These diagrams are widely used by
businessmen and software developers to document and understand requirements for new and
existing systems.
Communication Diagram – A Communication Diagram(known as Collaboration Diagram in
UML 1.x) is used to show sequenced messages exchanged between objects. A communication
diagram focuses primarily on objects and their relationships. We can represent similar information
using Sequence diagrams,however, communication diagrams represent objects and links in a free
form.
Timing Diagram – Timing Diagram are a special form of Sequence diagrams which are used to
depict the behavior of objects over a time frame. We use them to show time and duration
constraints which govern changes in states and behavior of objects.
Interaction Overview Diagram – An Interaction Overview Diagram models a sequence of actions
and helps us simplify complex interactions into simpler occurrences. It is a mixture of activity and
sequence diagrams.
Example: CONFERENCE MANAGEMENT SYSTEM(UML diagram)

AIM:
To implement a software for Conference management system

PROBLEM STATEMENT:
The Conference Management System is an online website in which candidate can
submit the paper and register themselves and then attend the conference. The paper will be reviewed. The details
of the conference, date and time will be made available to them through the website. After getting the
confirmation details the candidate should submit the revised and camera ready paper. Then the registration
process will be done.

SOFTWARE REQUIREMENT SPECIFICATION:

INTRODUCTION
This software specification document consist full set of features and function for online conference management
system. In this we give specification about the system requirements that are apart from the functionality of the
system to perform the candidate paper valuation. Ittells the usability, reliability defined in use case specification.

PURPOSE
The purpose of the conference management system is that the system can easily
review the process. The main process in this document is the submission of paper by the candidate, reviewing
process by the reviewer and sending of acknowledgement to the candidates whose paper is selected.

SCOPE
The scope of this conference management process is to select the best candidate fromthe list of candidates based
on their performance in the process.

DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

CANDIDATE - The candidate can login and submit the paper to the reviewer. After getting
acknowledgement the candidate will submit the revised and camera ready paper then registration
process will be carried out.
REVIEWER - Reviewer will reviews the paper and sending acknowledgement tothe candidate
DATABASE - Database is used to verify login and store the details of selected candidates.
HTML - Markup Language used for creating web pages.
J2EE – Java 2 Enterprise Edition is a programming platform java platform for developing and running
distributed java applications.
HTTP - Hyper Text Transfer Protocol.
TCP/IP – Transmission Control Protocol/Internet Protocol is the communication protocol used to
connect hosts on the Internet.
REFERENCES
IEEE Software Requirement Specification format.
TECHNOLOGIES TO BE USED
HTML
JSP
Java

TOOLS TO BE USED
Eclipse IDE (Integrated Development Environment)
Rational Rose tool (for developing UML Patterns)
OVERVIEW
SRS includes two sections overall description and specific requirements – Overall Description will describe
major role of the system components and inter-connections.
Specific Requirements will describe roles & functions of the actors.

OVERALL DESCRIPTION

PRODUCT PERSPECTIVE
The process of the candidates is to login the conference system and submit the paper through online. Then the
reviewer reviews the paper and sends the acknowledgement to thecandidate either paper selected or rejected.

SOFTWARE INTERFACE
Front End Client - The exporter online interface is built using JSP and HTML.
Web Server – Apache Tomcat Server (Oracle Corporation)
Back End - Oracle 11g database

HARDWARE INTERFACE
The BPO system’s server is directly connected to the client systems via ftp. Theclient systems have access to the
database in the server.

SYSTEM FUNCTIONS
This process of on conference management system are described sequentiallythrough following steps,
The candidate login to the conference management system.
The paper title is submitted.
The paper is been reviewed by the reviewer.
The reviewer sends acknowledgement to the candidate.
Based on the selection, the best candidate is selected.
Finally the candidate registers all details

USER CHARACTERISTICS
Candidate - Logins the conference system and submits the paper then do the registration process.
Reviewer – Review the paper, select best candidate and send acknowledgementto them.

CONSTRAINTS
Although the security is given high importance, there is always a chance of intrusion in the web world
which requires constant monitoring.
The user has to be careful while submitting the information. Much care isrequired.
ASSUMPTIONS AND DEPENDENCIES
The candidate and reviewer must have basic knowledge of computers and EnglishLanguage.
Provide privacy and security for the documents and candidate information

USECASE DIAGRAM:
A use case is a methodology used in system analysis to identify, clarify, and
organize system requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goal. It is represented using ellipse.
Actor is any external entity that makes use of the system being modeled. It isrepresented using stick figure.
The conference management system use cases are:
Paper submission
Review the paper
Send confirmation details
Send revised paper
RegistrationACTORS:
Actors are as follows:
Candidate
Reviewer

ACTORS DOCUMENTATION:
Candidate - Logins the conference system and submits the paper then do theregistration process.
Reviewer – Review the paper, select best candidate and send acknowledgementto them.
Paper submission – Candidate submits the paper.
Review the paper– The paper is been reviewed by the reviewer and the paper is selected.
Paper confirmation details – The reviewer can send the confirmation details tothe candidate.
Revised and camera ready paper – After the paper is selected and the camera ready paper should be
submitted to the reviewer by candidate.
Registration – After submitting the revised paper the candidate wants to register.
 13. Functional Modelling
Functional Modelling gives the process perspective of the object-oriented analysis model and an overview of
what the system is supposed to do. It defines the function of the internal processes in the system with the aid of
Data Flow Diagrams (DFDs).
14. Data Flow Diagrams

Functional Modelling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a
system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as
the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects
or the system, and the external controls and objects that affect the transformation.

The four main parts of a DFD are

• Processes,
• Data Flows,
• Actors, and
• Data Stores.

The other parts of a DFD are

• Constraints, and
• Control Flows.

Processes
Processes are the computational activities that transform data values. A whole system can be visualized as a
high-level process. A process may be further divided into smaller components. The lowest-level process may
be a simple function.

Representation in DFD − A process is represented as an ellipse with its name written inside it and contains a
fixed number of input and output data values.

Example − The following figure shows a process Compute_HCF_LCM that accepts two integers as inputs and
outputs their HCF (highest common factor) and LCM (least common multiple).

Data Flows
Data flow represents the flow of data between two processes.
Representation in DFD − A data flow is represented by a directed arc or an arrow, labelled with the
name of the data item that it carries.
The output value is sent to several places as shown in the following figure. Here, the output arrows
are unlabelled as they denote the same value.
The data flow contains an aggregate value, and each of the components is sent to different places as
shown in the following figure. Here, each of the forked components is labelled.
Actors
Actors are the active objects that interact with the system by either producing data and inputting them
to the system, or consuming data produced by the system.
Representation in DFD − An actor is represented by a rectangle. Actors are connected to the inputs
and outputs and lie on the boundary of the DFD.
Example − The following figure shows the actors, namely, Customer and Sales_Clerk in a counter
sales system.

Data Stores
Data stores are the passive objects that act as a repository of data.
Representation in DFD − A data store is represented by two parallel lines containing the name of
the data store. Each data store is connected to at least one process. Input arrows contain information
to modify the contents of the data store, while output arrows contain information retrieved from the
data store. When a part of the information is to be retrieved, the output arrow is labelled. An
unlabelled arrow denotes full data retrieval. A two-way arrow implies both retrieval and update.
Constraints

Constraints specify the conditions or restrictions that need to be satisfied over time.

Representation − A constraint is rendered as a string within braces.

Control Flows
A process may be associated with a certain Boolean value and is evaluated only if the value is true,
though it is not a direct input to the process. These Boolean values are called the control flows.
Representation in DFD − Control flows are represented by a dotted arc from the process producing
the Boolean value to the process controlled by them.

Example − The following figure represents a DFD for arithmetic division. The Divisor is tested for
non-zero. If it is not zero, the control flow OK has a value True and subsequently the Divide process
computes the Quotient and the Remainder.
 15. UML CASE TOOLS:

ARGO UML:

✓ ArgoUML is the leading open source UML modeling tool.

✓ ArgoUML needs a reasonable amount of computing resource. Any PC which is

ableto run an operating system with a graphical user interface will suffice
✓ UML diagramming application written in Java and released under the open
sourceEclipse Public License.
✓ By virtue of being a Java application, it is available on any platform supported
byJava SE.
✓ It includes support for all standard UML 1.4 diagrams.
✓ It runs on any Java platform and is available in ten language
✓ ArgoUML 0.26 and 0.26.2 were downloaded over 80,000 times and are in use all
overthe world

✓ ArgoUML is written in 100% pure Java, it should run on any machine with Java
installed. Java version 5 or later is needed. You may have this in place, but if not
the latest version can be downloaded free from www.java.com. Note that you only
need the Java Runtime Environment (JRE), there is no need to download the whole
Java Development Kit (JDK).
✓ Platform: Java Platform, Standard Edition
✓ Initial release date: April 1999
✓ License: Eclipse Public License 1.0
✓ Programming languages: Unified Modeling Language, Java
LOGO:
Pros

• Open-source
• Runs on many different platforms, including the latest version of Windows
• Supports many programming languages

Cons

• Steep learning curve

• Java isn't always stable
Main UML Tool:

StarUML − StarUML is an open source project to develop fast, flexible, extensible,featureful, and
freely-available UML/MDA platform running on Win32 platform.
ArgoUML − ArgoUML is the leading open source UML modeling tool and includessupport for all
standard UML diagrams.
Umbrello UML Modeller − Umbrello UML Modeller is a Unified ModellingLanguage diagram
programme for KDE.
Acceleo − Acceleo is easy to use. It provides off the shelf generators (JEE, .Net, Php...) and template
editors for Eclipse.
GenMyModel − An online UML modeling tool

What is the best software for UML diagrams?

Lucidchart
Gleek.io
Diagrams.net
Cacoo
Gliffy
EdrawMax
Microsoft Visio Pro

StarUML

StarUML is an open-source software modeling tool, which is provided by MKLab. It has come up with eleven
different types of modeling diagrams. It also supports UML2.0 specifieddiagrams.

Features:
It let you create Object, Use case, Deployment, Sequence, Collaboration, Activity,and Profile
diagrams.
It is a UML 2.x standard compliant.
It offers multiplatform support (MacOS, Windows, and Linux).

Download link: http://staruml.io

Umbrello

Umbrello is a Unified Modeling language tool, which is based on KDE technology. Itsupports both reverse
engineering and code generation for C++ and Java.

Features:
It implements both structural and behavioral diagrams.
It imports C++ and can export up to a wider range of languages.

Download link: https://umbrello.kde.org

UML designer tool

The UML designer tool helps in modifying and envisioning UML2.5 models. It allows you tocreate all of the
UML diagrams.

Features:
It provides transparency to work on DSL as well as UML models.
With the UML designer tool, the user can reuse the provided presentations.
It implements Component, Class, and Composite structure diagrams.
To start working with DSL, you can use UML legacy models.
Download link: http://www.umldesigner.org/download/

Altova

Altova has provided UModel, which is another UML software modeling tool. It supports all types of 14 UML2
diagrams as well as SysML for the embedded systems. It also holds up forbusiness process modeling for
enterprise analysts. It generates visually designed software models by incorporating Java, C++, and C #or
Visual Basic .NET.

Features:
It provides a dedicated toolbar for an individual diagram.
It offers unlimited undo/redo, which inspires to discover new ideas.
In UML diagrams, you can easily add a hyperlink to any element.
It also provides an intuitive color-coding, icons, customized alignment grid, andcascading styles for
colors, fonts line size.
Download link: https://www.altova.com/umodel

Umple

Umple is an object-oriented and modeling language that textually supports state diagrams andclass diagrams. It
adapts JAVA, C++, and PHP, which results in more readable and short lines of code.

Features:
It includes Singleton pattern, keys, immutability, mixins, and aspect-oriented codeinjection, which
makes UML more understandable to the users.
It enforces referential integrity by supporting UML multiplicity.

Download link: https://cruise.eecs.uottawa.ca/umple/

Visual Paradigm

A visual Paradigm is a tool that supports SysML, UML2, and Business Process Modeling Notation from Object
Management Group. It involves report generation as well as code generation.

Features:
It supports all of the 14 UML2 diagrams.
It supports BPMN 2.0, ERD, ORMD, SysML.

Download link: https://www.visual-paradigm.com

WhitestarUML

Whitestar UML is a division of StarUML 5.0 that offers bug fixes and has improved its compatibility with the
latest operating systems, i.e., support of Unicode strings or simply being developed and tested on Windows 7 and
8.
Features:
o It offers a refreshed user interface.
o It completely handles the functioning of Unicode strings.
o It provides support on Windows 7, 8, and 10.
o On-demand upload and download of units.
o It directly integrates the ERD profile and extends to generate and parse the SQLtables.

Download link: http://whitestaruml.sourceforge.net

1. Draw.IO

Draw.io is an open-source modeling tool to create flowcharts, process diagrams, UML, ER,and
network diagrams.

Features:
o Since it is very easy to use, it provides an intuitive interface, drag& dropfunctionality, a
huge amount of templates, and also, it does not need to install.
o It offers security and reliability.
o It can be used anywhere, both online and offline.
o It is compatible with every browser.

Download link: https://www.draw.io

2. GenMyModel

GenMyModel is an online modeling platform that offers Business (Archimate, BPMN,

flowcharts support) as well as IT modeling (RDS, UML2.5 class diagrams).

Features:
o It provides an online platform.
o It generates online code.
o It provides a centralized repository for easy and simultaneous model collaboration.
o You can import or export as a PDF.

Download link: https://www.genmymodel.com

3. Latino

It is an online platform that offers UML tools for faster development of UML
diagrams. It isbased on UMLet, which is an eclipse plugin or work as a standalone
tool.

Features:
• It allows you to export the diagram as XML or any other image file such
as Gif,JPEG, or SVG format.
• It is an installation free web application.

Download link: http://www.umlet.com/umletino/umletino.html

Read Any 10 tools: