REQUIREMENT ANALYSIS

MODELS AND VERIFYING

REQUIREMENTS
BY RACHIT MANN (2K19/SWE/09)
YANKIT KUMAR (2K19/SWE/16)
INTRODUCTION : REQUIREMENT
ANALYSIS MODELS

• Requirements analysis starts in parallel with requirements elicitation and involves refining and
modelling the requirements to identify inconsistencies, errors, omissions and other defects.
• Requirements analysis is usually done with the use of one or more system models that present an
abstract description of the system. These models also act as a bridge between the users, customers and
the developers as the models are easily understandable by the all parties.
PRINCIPLE
• The key objective of the requirements analysis is to describe the requirements in terms of relationships,
provide a basis for the design and to provide a basis for validation for the software after it is built.
• Activities that are performed in requirements analysis often overlap the requirement elicitation
activities.
• Typical activities that may be classified as requirement analysis are:
• Depiction of the scope of the system in the form of a diagram. This is often called the system context
diagram.
• Developing prototypes, which users evaluate and provide further requirements or refine the
requirements.
• Performing feasibility analysis.
• Modelling of the requirements, which usually consists of various graphical representations of the
functions, data entities, external entities and the relationships between them.
CASE STUDY : HOTEL MANAGEMENT SYSTEM
DATA FLOW DIAGRAMS - DFDs

• Data Flow diagrams are an integral part of the structured systems analysis and design techniques.
• DFDs are used to study the manner in which information enters a system and the manner in which it is
transformed as it flows through the systems.
• DFDs graphically represent the system data flow and data store.
SET OF SYMBOLS USED IN DFDs
DFD – LEVELS

• The first diagram also called “Context Diagram” or “Level – 0 Diagram” sets the context of the system
with respect to the major inflows and outflows from the system.
• The next level (Level - 1) of the diagram explodes the system into the high level processes and depicts
the interactions between these processes. Each process from the Level – 1 DFD can now be broken into
lower level DFDs.
• DFDs are considered complete when they are supported by a “data dictionary” containing:
 Contents of the data-flows
 Process Description
 Data store contents
 External entity descriptions
CONTEXT DIAGRAM (LEVEL – 0 DFD)
LEVEL – 1 DFD
LEVEL – 2 DFD
ADVANTAGES OF DFDs[1]

• It aids in describing the boundaries of the system.

• It is beneficial for communicating existing system knowledge to the users.
• A straightforward graphical technique which is easy to recognise.
• DFDs can provide a detailed representation of system components.
• It is used as the part of system documentation file.
• DFDs are easier to understand by technical and nontechnical audiences
• It supports the logic behind the data flow within the system.
DISADVANTAGES OF DFDs

• Cannot be used to depict “time-sequence” of activities.

• Cannot be used to perform data modelling.
ENTITY RELATIONSHIP DIAGRAMS – ERDs

• The ERD depicts the data entities of the system and the relationships between these data entities.
• During requirement analysis, ERD technique is used to represent high-level logical groups of information
and the connection between these logical groups of information.
• In design phase, ERD is used for depicting physical files and tables and the relationship between these
tables.
• An “Entity” is a real-world object within scope of system to be built.
• “Attributes” are the properties of that real-world object (entity).
• “Relationship” depict the relation between different entities (objects).
SET OF SYMBOLS IN ERDs
ER DIAGRAM OF CASE STUDY
ADVANTAGES OF ERDs[2]

• ER model is very simple because if we know relationship between entities and attributes, then we can
easily draw an ER diagram.
• ER model is a diagrammatic representation of any logical structure of database. By seeing ER diagram,
we can easily understand relationship among entities and relationship.
• It is an effective communication tool for database designer.
• ER model can be easily converted into relational model by simply converting ER model into tables.
• ER model can be easily converted into another data model like hierarchical data model, network data
model and so on.
DISADVANTAGES OF ERDs[2]

• ERD looks only at the relationships of data in the system, independent of the processing and cannot be
used of functional modelling.
• Limited constraints and specification.
• Some information be lost or hidden in ER model.
• ER model represents limited relationship as compared to another data models like relational model etc.
• No representation of data manipulation.
OBJECT-CLASS DIAGRAM

• Object-class diagrams show how object classed are related to each other, how objects can be combined
to form aggregate objects and how objects use services provided by other objects.
• An object class is an abstraction of a set of objects that have common attributes and services or
operations provided by that object.
SET OF SYMBOLS IN OBJECT CLASS DIAGRAMS
ADVANTAGES OF OBJECT CLASS DIAGRAMS [3]:

• It forces the programmer to think out the structure of his/her classes and how they will interact with
each other before actually writing any code. This may lead to a more robust application.
• It provides a blueprint for maintenance programmers to get an overview of how the application is
structured before examining the actual code. This may reduce maintenance time.
DISADVANTAGES OF OBJECT CLASS DIAGRAMS[3]:

• The programmer may need to learn UML to build the class diagram in the first place.
• The time spent building the class diagram may add to overall development time.
• If the class diagram is overcomplicated, then it may be difficult to correlate with the actual code.
STD - STATE TRANSITION DIAGRAMs

• STD is a behavioural model of the system that indicates how the proposed system will behave in
response to external events.
• STD represents various “states” of the system and the manner in which transition will be made from
one state to another on receiving a stimulus.
• A “state” is one of the conditions that an object may satisfy during its lifetime.
• “State Transition” represent the change of an object from one state to another state.
ADVANTAGES OF STDs

• STD can be used for a whole system or a portion of a system.

• It is ideal for describing the behaviour of a single object.
• STD help the stakeholders understand the intended behaviour of the system, by providing a compact,
language-independent visual representation on certain aspects of the system.
DISADVANTAGES OF STDs

• STD do not show processing that is required, it shows only states and events that these events can
change in the state of a system.
• STD does not provide any processing logic for the developers to build software, thus inadequate
technique to model requirements.
SEQUENCE DIAGARMS[4]

• A sequence diagram simply depicts interaction between objects in a sequential order i.e. the order in
which these interactions take place.
• Sequence diagrams describe how and in what order the objects in a system function.
ADVANTAGES OF SEQUENCE DIAGRAM [5]

• It help you to envision what will happen during the execution of a use case.
• They are great to help developers and business analysts get to a common understanding.
DISADVANTAGES OF SEQUENCE DIAGRAM[6]

• Consumes horizontal space.

• Forced to extend to the right when adding new objects.
ACTIVITY DIAGRAM

• Activity diagrams are used to model the working of a process or an operation. The activities carried out
in a process/workflow or an operation are depicted in an activity diagram.
• Activity diagrams enable to visualize, understand and document the flow of activities in an operation or
process.
• Activity diagram represents executable computational steps in the system.
• Sequence diagram depicts interactions between objects whereas activity diagrams depict the steps
involved in a process or operation.
• An “Activity” represents execution of a step or a set of steps in a process or an operation. The activity
may be atomic or may consist of multiple steps.
SET OF SYMBOLS IN ACTIVITY DIAGRAM
ADVANTAGES OF ACTIVITY DIAGRAM[7]

• Activity diagrams are normally easily comprehensible for both analysts and stakeholders.
• Activity diagrams allow to display multiple conditions and actors within a work flow through the use of
swim lanes.
DISADVANTAGE OF ACTIVITY DIAGRAM[7]

• Activity diagrams have the potential to become overly complex because their user-friendly nature may
lend itself to an all-inclusive description.
• If you are using activity diagrams to define the structure of a work flow, you should not attempt to
explore several levels of activity graphs down to their most ‘atomic’ level.
USE CASE DIAGRAM

• A use-case is a description of the interactions between a “system” and an “actor” external to the
system.
• The “actor” could be a person, a group of persons, or another system that interacts with the proposed
system.
• The use-case describes all the steps that the actor and the proposed system will need to perfrom to
achieve a designed objective.
SET OF SYMBOLS IN USE CASE
ADVANTAGES OF USE CASES

• They provide users a clearer understanding of what they can expect from the proposed system and how
they are likely to interact with the system.
• They also help in generation of test cases, especially functional test cases.
• They also ensure that developers pay greater importance to the “task-orientation” of the system.
DISADVANTAGES OF USE CASES

• Use cases themselves cannot completely represent requirements. They need to be supported by other
analysis models and documentation of the non-functional requirements.
• Use cases are not object-oriented. Each use case captures a major functional abstraction that can cause
the numerous problems with functional decomposition that object technology was to avoid. [8]
• The lack of formality in the definitions of the terms use case, actor, extends, and uses.
APPLICATIONS OF REQUIREMENTS ANALYSIS MODELS
FUTURE SCOPE
VERIFYING REQUIREMENTS

• Verification ensures that the requirements conform to the characteristics of excellent requirement
statements (complete, correct, feasible, necessary, prioritized, unambiguous, verifiable) and of excellent
requirements specification (complete, consistent, modifiable, traceable).
• Involves following three activities:
• Continuous Review
• Phase End Review – Review at the end of each
• Requirements Sign-Off
 REFERENCES:
• [1] https://eternalsunshineoftheismind.wordpress.com/2013/02/20/advantages-vs-disadvantages-of-
dfds/
• [2] https://pctechnicalpro.blogspot.com/2017/04/advantages-disadvantages-er-model-dbms.html
• [3] https://www.c-sharpcorner.com/forums/advantages-and-disadvantages-of-class-diagrams-in-ooad
• [4] https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/
• [5] https://www.slideshare.net/nik1020/use-case-diagram-and-sequence-diagram
• [6] https://studylib.net/doc/7584664/34.-give-the-weaknesses-of-sequence-diagram
• [7] http://www.articlebiz.com/article/1051504997-1-activity-diagrams-advantages-disadvantages-and-
applications-of-use/
• [8] https://www.cs.hmc.edu/~mike/courses/mike121/readings/reqsModeling/firesmith.htm
• BOOKS:
• Software Requirements and Estimation – Swapna Kishore and Rajesh Naik
• Object-Oriented Software Engineering – Yogesh Singh and Ruchika Malhotra
THANK YOU!