Requirement Analysis

Software Engineering
Requirement Analysis and
Specification
 Requirement
• WAP to print first N odd non-prime numbers
between given range.
• Client Needs in Mind  Formal Document (SRS)
– Imprecise
– Incomplete
– Inconsistent

• Output is SRS which describes “WHAT” a proposed system

should do without describing “HOW” the software will do it.

• Many Change Requests have their origin in incorrect

interpretation or specification of the requirements
– These changes can be reduced by performing RA
thoroughly.
Software Requirements – Difficult Task
 Software Requirements
• IEEE Definitions

– A condition or capability needed by a user to

solve a problem or achieve an objective.

– A condition or capability that must be met or

possessed by the system to satisfy a contract,
standard, specification or other formally imposed
document.
 Software Requirements
• Difficulties in RA
1. Scope & Size of the problem
2. Absence of manual process
3. Subjectivity
4. Requirements keep changing
 Need of SRS
• Client, User, and Developer
• A basic purpose is to bridge communication
gap (SRS should satisfy all parties)
• Help the client understanding their own need
 Need for SRS
An SRS establishes the basis for agreement
between the client and the supplier on what the
software product will do

An SRS
• Establishes the basis for agreement
• between the client and the supplier
• on what the software product will do.
 Need for SRS

An SRS provides a reference for validation of the

final product

An SRS
• Provides a reference for validation
• of the final product.
 Need for SRS
• A high-quality SRS is a prerequisite to high-
quality software

An SRS
• Is a prerequisite to high-quality software.
– As it is Input for next phases
 Need for SRS
A high-quality SRS reduces the development
cost

An SRS
• Reduces the development cost.
– Less Change & Rework Cost
 Requirement Analysis
• The Requirements Phase
– Input: Thoughts (needs) in Client Minds
– Output: SRS
• Specifies What and not How

Ideas/
Thoughts
in Client SRS (Formal)
Mind
(Informal)
 Requirement Analysis
• Process (3 basic activities)
– Requirement (Problem) Analysis
• Understanding the problem
• What is needed

– Requirement Specification
• Specify/Organizing the requirements in a document
• Representation, Specification Language, Tools (Issues)

– Requirement Validation
• Complete, Correct, Consistent
 Requirement Analysis
Iterative Process

• These three steps are

overlapped and may
provide feedback to
earlier stages

• Abstract v/s Detailed

Requirements
 Problem Analysis
• Problem/Requirement Analysis
– Aim is to obtain clear understanding of the needs
– What is desired from Software
– What are the constraints

• Methods
– Interview
– Questionnaire
– Record Inspection
– Observation
 Problem Analysis
• The analysts have to ensure that the real
needs of the clients are uncovered even if
they don’t know
– Not just collecting and organizing
– But, act as a Consultants
– Must “get in the shoes” of the clients and users
• Means they should acquire sufficient domain
knowledge
 Problem Analysis
• Issues
• How To obtain the necessary information
– sources and methods
• How To organize the information obtained
– To check for completeness and consistency
• To check consistency in final specifications
– To resolve contradictions
• To avoid internal design
– Focus on what

• Interpersonal skill is more important

• Solution
– Communication and Interpersonal Skill
– Divide and Conquer
• Partition the system into sub systems (Recusively)
• Relationship among sub systems
• Concepts of State and Projection
– Using tools and formal methods to organize
information
 Problem Analysis
• Three basic Approaches
1. Informal Approach
2. Conceptual Model Based
1. Structured analysis
2. Object-oriented modeling
3. Prototyping (Throughway or Evolutionary)
 Problem Analysis
Informal approach
• No defined methodology is used.
– A Chain of Meetings between Analyst and client
• The information is obtained by
– Interaction with the clients, end users
• Interview & questionnaires
– Study of existing documents (Record Inspection)
– Observation and brainstorming
– Series of meetings
• Understands, seeks Clarifications, explains, gets verified
• No formal model is built
– SRS is prepared from understanding of Analyst
• Widely used practical approach
– Not risky as SRS is any way going to be validated
 Model based Structured analysis
• Uses function-based decomposition while modeling the
problem
– E.g., Issue Book, Return Book, Calculate Fine
– Top-down refinement approach
– Uses tools like DFD and DD

• Object Oriented Modeling

– E.g., Book, Member, Author, Supplier
– Bottom-up approach
– Concept of Object
– ER Diagram, UML
 Problem Analysis
Structured Analysis
• Function-based Decomposition
– the problem is viewed as a set of functions
– It focuses on the functions performed in the
problem domain and data consumed and
produced by these functions
– A top-down approach
– Uses DFDs (Data Flow Diagrams) & Data dictionary
 DFD
• DFD shows flow of data in system
• It views a system as a function that transforms the inputs into
desired outputs
• However, it is not a Flow Chart
– Hence, should not include control information such as decisions and
loops
• DFD can be organized hierarchically
– Context Diagram/Zero-level is initial DFD which shows the entire system
as a single process with all its inputs, outputs, sinks, and sources
– DFD Level-1, Level-2, etc.
– Each level may refine process until a bubble is atomic (can be
understood easily)
– All levels must be consistent
 DFD
• Symbols
– Named/Labelled Circle/Bubble
• Represents Function/Process
– Labelled Rectangle
• Represents a source (originator of data) or sink (consumer of data)
– Labelled 1/2 parallel lines or Open Rectangle
• Represents data at rest (data storage/file formats)
– Labelled Arrow
• Represent data flowing
– + indicate OR
– * indicates AND
DFD Example
 DD
• Repository of various data flows in DFDs

• The associated data dictionary states/specifies the

precise structure of each data flow in the DFD

• To define the data structure of a data item, a regular

expression type notation is used.
– sequence or composition is represented by “+”
– selection by vertical bar “|” (means one OR the other), and
– repetition by “*”
 DD Example
• Weekly timesheet = employee name +
employee id + [Regular Hours + Overtime
Hours]*

• Pay rate = [hourly | daily | weekly ] + Amount

• Employee Id = digit + digit + digit

 DD
• non-exhaustive list of typical items found in a data dictionary for columns or fields
– Entity or form name or their ID (EntityID or FormID). The group (class/DB Table) this field belongs
to.
– Alias Names
– Displayed field title. May default to field name if blank.
– Format code, such as a regular expression
– Description or synopsis
– Field type (string, integer, date, etc.)
– Various event handlers or references to. Example: "on-click", "on-validate", etc.
– Dimension(s) such as min and max values, display width, or number of decimal places.
– Prompt type, such as drop-down list, combo-box, check-boxes, range, etc.
– Field display order or tab order
– Coordinates on screen (if a positional or grid-based UI)
– Default value
– Domain (Possible Values)
– Is-required (Boolean) - If 'true', the value can't be blank, null, or only white-spaces
– Is-read-only (Boolean)
– Field name, such as RDBMS field name
– Reference table name, if a foreign key. Can be used for validation or selection lists.
– Database index characteristics or specification
DFD and DD Example
 DFD Common Errors
• Unlabelled data flows
• Missing data flows
• Extraneous data flows
• Inconsistency in different levels
• Missing processes
• Contains control information
• Etc.
 More on DFD
• Physical DFD
– First step

• Logical DFD
– Second step

• DFD can be used in both Analysis and

Specification
– Even used in System Design
 Problem Analysis
Object based Modeling
• Object-oriented Modeling
– The problem domain is viewed as a set of objects.
– Uses an Object Model
• Each object has State and provides Services
– A bottom-up approach.
 Problem Analysis
Object Oriented Modeling
• OO Concepts
– Object,
• Identity
• Attributes/State
• Behaviours/Services/Operations
– Class
– Abstraction
– Message Passing
– Encapsulation
– Inheritance
– Polymorphism
– Etc.

• Uses the UML (Unified Modelling Language) Notations

– Class/Object Diagrams, Use Case Diagrams, etc.
 OO Analysis Process
• Identify Objects / Classes (Entities)
• Identify Structures (Hierarchy)
• Identify Attributes
• Identify Association (Relationship)
• Define Services
– Services required to create, destroy and maintain
instance of the class are called Occur Services and
are generally not shown in the Class
 Class Diagram
• are used to show the different objects in a
system, their attributes, their operations and
the relationships among them.

• Class is represented by box with 3 partitions

– The top partition contains the name of the class
– The middle part contains the class’s attributes
– The bottom partition shows the operations
Class Diagram Example
 Class Diagram Example
• Attributes
– Public +, Private -, Protected #, Package ~,
Derived /
• Relationship
• Multiplicity
0 No instances (rare)
0..1 No instances, or one instance
1 Exactly one instance
1..1 Exactly one instance
0..* Zero or more instances
* Zero or more instances
1..* One or more instances
 Use Case Diagram
• Represents user's interaction with the system
– shows the relationship between the Actor (User) and
the different Use Cases (System Functionality)

• The use cases are represented by ellipses

• An actor is shown as a stick figure

• The purpose of use case diagram is to capture the

dynamic aspect of a system
Use Case Diagram Example
Use Case – Text Representation
Other Modelling Tools can be used
• E-R Model
– Used for database applications/design

• PSL/PSA
– Problem Statement Language
– Problem Statement Analyzer
 Prototyping
• Partial implementation of system to get better
understanding

• Useful for novel system, to check GUI, etc.

• Requirements
– Known
• Clear (Well understood)
– Stable vs. Unstable
• Unclear (Poorly understood)
– Critical to Design vs. Not Critical
– Unknown
 Prototyping
• Two Approaches
– Throwaway (Unclear Requirements)
• Suitable if unclear requirements (critical) are more
– Evolutionary (Clear Requirements)

• Two Types
– Horizontal – e.g. to check GUI
– Vertical – e.g., if all logic of one module is
implemented
 Prototyping
• Whether to go for Prototype?
• Cost is 10% of Development
– but mostly not additional as it saves Development
Cost and Change and Rework associated cost
 Requirement Specification
• Requirement Analysis
• Requirement Specification
• V&V (Verification & Validation)