SE UNIT 2.pdf

CS8494 – Software Engineering
III Year / V Semester

UNIT II REQUIREMENTS
ANALYSIS AND
SPECIFICATION
Software Requirements: Functional and Non-
Functional, User requirements, System
requirements, Software Requirements
Document – Requirement Engineering
Process: Feasibility Studies, Requirements
elicitation and analysis, requirements
validation, requirements management-
Classical analysis: Structured system Analysis,
Petri Nets- Data Dictionary.

Software Requirements
 Requirement Engineering:
 The process of establishing the services that the
customer requires from a system
 the constraints under which it operates and is
developed.
 Requirements specify what the system is supposed
to do, but not how the system is to accomplish its
task.

 Requirement - It may span a wide range of
statements:
from a high-level abstract statement of a service or
of a system constraint
to a detailed mathematical functional specification

 Requirement – Types:
 User Requirements
 System Requirements
 Software Specification

 Requirement – User Requirements:
 Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge
User requirements are defined using natural
language, tables, and diagrams

 Problems with natural language
Precision vs. understandability
Functional vs. non-functional requirements
confusion
Requirements mixture

 Guidelines:
 Prepare a standard format and use it for all requirements.
 Apply consistency in the language: ‘shall’ – mandatory
requirements, ‘should’ – desirable requirements.
 Avoid the use of computer terminologies. It should be
written in simple language.

 Requirement – System Requirements:
 More detailed specifications of user requirements
Serve as a basis for designing the system
May be used as part of the system contract
 The requirements specify what the system does
and design specifies how it does.

 Structured Language Specification:
 requirements are written in a standard way.
 The requirement become understandable and
expressive.
 Uniformity must be maintained.
 Graphical model: Sequence Diagram.

 Requirement – Domain Requirements:
 Requirements that come from the application
domain of the system and that reflect
characteristics of that domain.
 These requirements make use of domain
terminologies specific to the specific to the
existing domain concept.

 Requirement – Domain Requirements:
 These are the specialized requirements and hence
software engineers find it difficult to co-relate the
domain requirements with the system
requirements.
 It is important to specify the domain requirements
otherwise the system will not work properly.

Functional and non-functional
requirements
 Functional requirements
 Describe functionality or system services
 Statements of services the system should provide,
how the system should react to particular inputs
and how the system should behave in particular
situations.

requirements
 Functional requirements
 It is heavily dependent upon the type of software,
expected users and type of system where the
software is used.
 Functional user requirements may be high-level
statements of what the system should do.
 Functional system requirements should describe

requirements
 Functional requirements – Problems:
 Requirements imprecision:
 Problems arise when functional requirements are
not precisely stated.
Ambiguous requirements may be interpreted in
different ways by developers and users

requirements
 Functional requirements – Problems:
 Requirements completeness and consistency:
 Complete : They should include descriptions of all facilities
required.
 Consistent: There should be no conflicts or contradictions in the
descriptions of the system facilities
 In practice, because of system and environmental complexity, it
is impossible to produce a complete and consistent requirements
document.

requirements
 Non - Functional requirements:
 These define system properties and constraints.
 Process requirements may also be specified
mandating a particular IDE, programming
language or development method.
 Non-functional requirements may be more critical
than functional requirements. If these are not met,

requirements
 Non - Functional requirements:
 These define system properties and constraints.
 Process requirements may also be specified
mandating a particular IDE, programming
language or development method.
 Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system may be useless

Non-functional requirements -
Types

Types
 Product requirements:
 Requirements which specify that the delivered product must behave
in a particular way e.g. execution speed, reliability, etc.
 Organizational requirements:
 Requirements which are a consequence of organizational policies
and procedures e.g. process standards used, implementation
requirements, etc.

Types
 External requirements:
 Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.

Metrics
 Reliability: Generate all the updated information in
correct order.
 Availability: Any information must be quickly
available from computer to the authorized user.
 Security: The application must be password protected.
 Maintainability: Any change in requirement occurs
then it should be easily incorporated in an individual
module.

Metrics
 Extensibility: Any new requirement occurs then it
should be easily incorporated in an individual module.
 Portability: Portable on the desired OS.
 Reusability: A segment of source code can be used
again to add new functionalities.
 Resource Utilization: Use of resources to its maximum
capability.

Metrics
Property Measure
Speed Processed transactions/second, User/event response time
Screen refresh time
Size Mbytes, Number of ROM chips
Reliability Mean time to failure, Probability of unavailability
Rate of failure occurrence, Availability
Robustness Time to restart after failure, Percentage of events causing
failure, Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems

Software Requirements Document
 The specification of the system.
 It should include both a definition and a specification
of requirements.
 It should set of what the system should do rather than
how it should do it.
 The SRS is useful in estimating cost, planning team
activities, performing tasks and tracking the team’s
progress.

Document Title
Author
Affiliation
Address
Date
Document Version

 1. Introduction
 1.1 Purpose of the document
 1.2 Scope of this document
 1.3 Overview

 General Description
 General functionality of the product: System information,
user characteristics, User objective, general constraints placed
on design team.
 The features of the user community, including their expected
expertise with software systems and the application domain.

 Functional requirements:
 It describes the possible effects of a software
system, what the system must accomplish.
 Short, imperative sentence stating highest ranked
functional requirements.

 Description: A full description of the requirement.
 Criticality: Describes how essential this
requirement is to the overall system.
 Technical Issues: Describes any design or
implementation

 Cost and Schedule: Describes the relative or
absolute costs of the system.
 Risks: Describes the circumstances under which
this requirement might not able to be satisfied.
 Dependencies with other requirements: Describes
interactions with other requirements.

 Interface requirements:
 It describes how the software interfaces with other
software products or users for input or output.
 User Interfaces:
 GUI: It should include a set of screen dumps user
interface features.
 CLI: For each command, a description of all

 Interface requirements:
 Hardware interfaces: interfaces to hardware
devices.
 Communication interfaces: Describes network
interfaces.
 Software interfaces: Describes the application
programming interfaces not included above.

 Performance requirements: Specifies speed
and memory requirements.
 Design constraints: Specifies any constraints
for the design team such as software or
hardware limitations.

 Other Non-functional Attributes:
 Security
 Reliability
 Maintainability
 Portability
 Extensibility
 Reusability

 Operational Scenarios:
 It describes a set of scenarios that illustrate, from
the user’s perspective, what will be experienced
when utilizing the system under various situations.

 Preliminary Schedule:
 It provides an initial version of the project plan,
including the major tasks to be accomplished, their
interdependencies, and their tentative start/stop
dates.
 Preliminary Budget:
 It provides an initial budget for the project.

 Appendices:
 Definitions, Acronyms, Abbreviations: Provides
definitions terms and acronyms can be provided.
 References: It provides complete citations to all
documents and meetings referenced.

Characteristics of SRS
 Correct: The SRS should be made up to date when
appropriate requirements are identified.
 Unambiguous – When the requirements are correctly
understood then only it is possible to write an
unambiguous SRS.
 Complete – To make the SRS complete, it should be
specified what a software designer wants to create a
software.

Characteristics of SRS
Consistent: It should be consistent with
reference to the functionalities identified.
Specific: The requirements should be
mentioned specifically.
 Traceable: What is the need for mentioned
requirement? This should be correctly
identified.

Requirement Engineering Process
 A Requirement Engineering is a process in
which various activities such as discovery,
analysis and validation of system requirements
are done.

Requirements
specif
ication
Requirements
validation
Requirements
elicitation
Systemrequirements
specif
ication and
modeling
System
requirements
elicitation
User requirements
specif
ication
User
requirements
elicitation
Business requirements
specif
ication
Prototyping
Feasibility
study
Review s
System requirements
document

 Functions:
 Inception: Specifying the beginning of the
software project. Most of the software projects
get started due to business requirements.
 Purpose:
 basic understanding of the problem
the people who want a solution and the nature of

 Functions:
 Elicitation – Requirements discovery
 Difficult to understand customer needs:
 Unable to specify the scope of the project.
 Difficult to understand the problem and Difficult to communicate with the
system engineer about their needs.
 The requirements of the customer changes. This creates a problem of
volatility(Instability).
 To overcome these problems, requirements are gathered systematically.

 Functions:
 Elaboration: The information about the
requirements is expanded and refined.
 The goal of elaboration activity is to prepare a
technical mode of software functions, features
and constraints.

 Functions:
 Negotiation:
Customer may demand for more than that is
achieved .
 Customer demands for something which cannot
achieved in limited resources.

 Functions:
 Specification - can be any one (or more) of the
following:
 A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)

 Functions:
 Validation—a review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies (a major problem when large products or
systems are engineered)
conflicting or unrealistic (unachievable) requirements

 Functions:
 Requirement Management:
 The process of managing changing requirements
during the requirements engineering process and
system development.

Feasibility Studies
A feasibility study is a study made to decide
whether or not the proposed system is
worthwhile

Feasibility Studies
Focus:
 If the system contributes to organizational
objectives;
If the system can be engineered using current
technology and within budget;
If the system can be integrated with other systems
that are used

Feasibility Studies
Implementation:
 Based on information assessment (what is
required), information collection and report
writing.

Feasibility Studies
 Questions for people in the organisation
What if the system wasn’t implemented?
What are current process problems?
How will the proposed system help?
What will be the integration problems?
Is new technology needed? What skills?
What facilities must be supported by the proposed system?

Feasibility Studies
Types:
 Technical Feasibility: It is the measure of
technical resources such as hardware
components, software techniques and skilled
persons.
 Economical Feasibility: It is the measure
finances or funds are available for proposed

Feasibility Studies
Types:
 Operational feasibility: It is a measure of how
well the solution of problems or a specific
alternative solution will work in the
organization.

Feasibility Studies
Types:
 Schedule feasibility: It is the establishment of
time limit for completion of the project. It is
dependent upon available manpower and
economical support for the project.

Requirements Elicitation and
Analysis
 Sometimes called requirements elicitation or
requirements discovery.
 Software engineers communicate with customers
to find out about the application domain, the
services that the system should provide and the
system’s operational constraints.

Analysis
 Stakeholders:
 The person(s) who will affected by the system.
 Ex: End-user, Managers, System maintenance
engineers, Domain experts and trade union.

Analysis
 Problems of requirements analysis:
 Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting
requirements.
Organisational and political factors may influence the
system requirements.

Analysis- Process
Requ irem
en ts
class ificatio n an d
org anis ation
Requ irem
en ts
prioritizatio n an d
nego tiation
Requ irem
en ts
do cu m
entation
Requ irem
en ts
dis co very

Analysis- Process
Requirements discovery:
Interacting with stakeholders to discover their
requirements. Domain requirements are also
discovered at this stage.
Requirements classification and organisation:
Groups related requirements and organizes them
into coherent clusters.

Analysis- Process
Prioritisation and negotiation:
Prioritising requirements and resolving
requirements conflicts.
 If there are some unrealistic requirements then
negotiations are made.
Requirements documentation:
Requirements are documented and input into the

Analysis- Process
Requirement Discovery:
 The process of gathering information about the
proposed and existing systems and distilling the
user and system requirements from this
information.
 Sources of information include documentation,
system stakeholders and the specifications of

Analysis- Methods
 Interviewing
 Scenario
 View Point
Use Cases
 Ethnography

Analysis- Methods
 Interviewing:
 The requirement engineering team communicates
the stakeholders by asking them various questions
about the system and its use.
Types:
Closed interviews where a pre-defined set of
questions are answered

Analysis- Methods
 Interviewing:
 Interviews are good for getting an overall
understanding of what stakeholders do and how
they might interact with the system.

Analysis- Methods
 Interviewing - not good for understanding
domain requirements:
 Requirements engineers cannot understand specific
domain terminology;
Some domain knowledge is so familiar that people
find it hard to articulate or think that it isn’t worth
articulating.

Analysis- Methods
 Interviewing – Characteristics:
 The interviews should be conducted in a free environment
and they should be conducted with open minded approach.
 The requirement engineers should listen to stakeholders
with patience.
 Interviewee should start the discussion by asking questions
and the requirements should be gathered together.

Analysis- Methods
 Scenario:
 The sequence of interactions made by the user
with the software systems.
 To formulate actual system requirements.
The interaction sessions.

Analysis- Methods
 Scenario:
 A description of the starting situation;
A description of the normal flow of events;
A description of what can go wrong;
Information about other concurrent activities;
A description of the state when the scenario
finishes.

Analysis- Methods
 View point:
 Viewpoints are a way of structuring the
requirements to represent the perspectives of
different stakeholders.
 Stakeholders may be classified under different
viewpoints.

Analysis- Methods
 View point – Types:
 Interactor viewpoints: People or other systems that
interact directly with the system. In an ATM, the
customer’s and the account database are interactor
VPs.
 Indirect viewpoints: Stakeholders who do not use the
system themselves but who influence the
requirements. Ex: Security Staff

Analysis- Methods
 View point – Types:
 Domain viewpoints: Domain characteristics and
constraints that influence the requirements.
 Ex: In Library system, the rules that are to
followed for reserving the book.

Analysis- Methods
 View point – Examples:
Article
providers
Finance
Library
manager
Library
staff
Users
Interactor
Indirect
All VPs
Classification
system
UI
standards
Domain
External
Staff
Students Cataloguers
System
managers

Analysis- Methods
 Use cases:
 To identify individual interactions with the
system.
 Use cases are extensively used for requirements
elicitation.

Analysis- Methods
 Use Case Diagram:
 Use case diagrams describe the functionality of a
system and users of the system. They contain the
following elements:
Actors - users of a system, including human users
and other systems
Use cases - functionality or services provided by a

Analysis- Methods

Analysis- Methods
 Class Diagram: It describes the static structure
of a system, or how it is structured rather than
how it behaves.
 Elements:
 Classes: Entities with common characteristics or
features. Attributes, Operations, and Associations
 Associations: relationships that relate two or more

Requirements Elicitation and Analysis-
Methods – Use Case

Analysis- Methods
 Sequence Diagram: Sequence diagrams
typically show the flow of functionality
through a use case, and consist of the
following components:
Actors , involved in the functionality
Objects , that a system needs to provide the
functionality

Analysis- Methods
Collaboration Diagrams:
 The focus of the collaboration diagram is on the
roles of the objects as they interact to realize a
system function.
 These links are labeled using appropriate
messages.
 Each message is prefixed with a sequence number

Analysis- Methods
 State Diagram:
 State transition diagrams provide a way to model
the various states in which an object can exist.
 State transition diagrams model the dynamic
behavior of a system in response to external
events.
 States - Possible situations in which an object can

Analysis- Methods
 Activity Diagram:
 It describes the activities of a class
 It describes the behavior/states of a class in
response to internal processing.

Analysis- Methods
 Activity Diagram – Elements:
 Swimlanes - delegate specific actions to objects
within an overall activity
 Action States - uninterruptible actions of entities, or
steps in the execution of an algorithm
 Action Flows - relationships between the different
action states on an entity

Analysis- Methods
 Ethnography:
 A technique of observation which is used to
understand social and organizational requirements.
 The system analyst imagines himself as a part of
the working environment in which the system will
be used.
 The analyst finds the implicit requirements of the

Analysis- Methods
 Ethnography - Types.
 Requirements obtained from working style of
people:
 Requirements can be identified from the sequence
of actions that user is performing.
 Valid card and Valid PIN must be entered for
getting the money from ATM

Analysis- Methods
 Ethnography - Types.
 Requirements obtained from inter-activities
performed by the people:
 Sometimes for finding the social requirements the
other people’s activities should be known.
 Ex: ATM system the operator can not shutdown the
system if some transaction is in processing.

Requirements Validation
A process in which it is checked that whether
the gathered requirements represent the same
system that customer really wants.

 Requirement Checking:
 Validity. Does the system provide the functions which best
support the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the customer
included?
 Realism. Can the requirements be implemented given available
budget and technology
 Verifiability. Can the requirements be checked?

 Techniques:
 Requirements reviews - Systematic manual
analysis of the requirements
 Regular reviews should be held while the
requirements definition is being formulated.
Both client and contractor staff should be involved
in reviews.

 Techniques:
Prototyping:
 Using an executable model of the system to check
requirements

 Techniques:
Test-case generation - Developing tests for
requirements to check testability
 Verifiability - Is the requirement realistically
testable?
Comprehensibility - Is the requirement properly
understood?

Requirements Management
The process of managing changing
requirements during the requirements
engineering process and system development

 Requirements are always incomplete and
inconsistent
New requirements emerge during the process
as business needs change and a better
understanding of the system is developed;
Different viewpoints have different
requirements and these are often contradictory.

 Enduring and volatile requirements:
 Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from
domain models
Volatile requirements. Requirements which

Volatile requirements:
 Mutable requirements – Change in the environment
 Consequential requirements – Changes due to CBS
 Emergent requirements – Customer’s understanding
of the system
 Compatibility requirements – depend upon the
specific system or business process.

Planning
 During the requirements engineering process,
you have to plan:
Requirements identification - How requirements
are individually identified;
A change management process - The process
followed when analysing a requirements change;

Planning
 Traceability policies - The amount of
information about requirements relationships
that is maintained;
CASE tool support - The tool support required
to help manage requirements change;

Planning
 Traceability policies – Types:
 Source Traceability: The links from requirement to
stakeholders who propose these requirements.
 Requirement Traceability: The links between
dependent requirements.
 Design Traceability: The links from requirements to
design.

Planning
 Traceability Matrix:
Requirement
Id
A B C D E F
A D R
B D
C R
D D R
E
F R D
D – Dependent Requirement R – Weak Requirement

Requirements Change Management
A technique that can be applied to the
processes in which requirements may get
changed

- Process

 Problem Analysis and change specification:
 To validate the required change.
 Change Analysis and costing:
 The effect of change using traceability
information.
 The cost of such change is estimated
 The decision is made on whether to go for

 Change Implementation
 The requirement document has to be modified.
 The document has to either re-written or re-
organized.
 This can be achieved by making the modularity

Structured System Analysis
A technique in which the system requirements
are converted into specifications and then into
computer programs, hardware configurations
and related manual procedures.

 The system can be modeled using:
 Entity Relationship diagram are used to represent
the data model.
 Data flow diagram and control flow diagrams are
used to represent the functional model.

 Designing Data Flow Diagrams:
 It is used to model information and function
domain.
 Refinement of DFD into greater levels helps the
analyst to perform functional decomposition.

Structured System Analysis - Data
Flow Diagrams
 Guidelines:
 Level 0 DFD. Context level DFD should depict
the system as a single bubble.
 Primary input and primary output should be
carefully identified.
 While doing the refinement isolate processes, data
objects and data stores to represent the next level.

Flow Diagrams
 Symbols:
Symbols Description
External Entity: A source of data or a
destination for data.
A process transforms incoming data
flow into outgoing data flow

Flow Diagrams
 Symbols:
Symbols Description
Data in the system
The flow of information from one
entity to another

Flow Diagrams
 Rules:
 No process can have only outputs or only inputs.
The process must have both outputs and inputs.
 The verb phrases in the problem description can
be identified as processes in the system.
 There should not be a direct flow between data
stores and external entity. This flow should go

Data Flow Diagrams – Level 0

Petri Nets
 Invented by Carl Adam Petri in 1962
 It is used to define the system. It is used for
distributed systems and systems with resource
sharing.

Petri Nets
Components:
 Places – States of the system
 Transitions – Change in the states
 Arc – Connects a place with transition

Petri Nets
Components:
 Set of places P is {p1,p2,p3,p4}
 Set of transitions T is {t1,t2}
 Input function: I(t1) = {P2,P4}, I(t2) = {P2}
Output function: O(t1) = {P1}, O(t2) = {P3,P3}

Petri Nets
A marking of a Petri net is an assignment of
tokens to that Petri net.
.
..
.
P1
P2
P4
P3
t1
t2

Petri Nets
Four tokens: one in P1, two in P2, none in P3,
and one in P4.
Represented by the vector (1,2,0,1)

Petri Nets
Transition t1 is enabled (ready to fire)
If t1 fires one token is removed from P2, and
one from P4, and one new token is places in
P1
Transition t2 is also enabled.

Petri Nets
. .
.
P1
P2
P4
P3
t1
t2

Data Dictionary
An organized collection of all the data
elements of the system with precise and
rigorous definitions so that user and system
analyst will have a common understanding of
inputs, outputs, components of stores and
intermediate calculations

Data Dictionary
Field Name Description
Name Name of the data item.
Aliases Other name of the data item.
Description / Purpose A notation for representing its goal or
context.
Related data item Relevant data item.
Range of value Value between the item.
Data Structure Definition Form of the data item
Where used / How used Input to the process, output from the
process, as a store and external entity
Supplementary information Data types, preset values, restrictions or
limitations.

Data Dictionary
Field Name Description
Name Telephone_Number
Aliases Phone_Number, Mobile_Number
Description / Purpose First 2 digit indicates Country Code, Next
4 digits represents district code, Last 6
digit indicates your number, etc.
Where used / How used Address / Visiting Card / Display / read
the Telephone_Number
Format Numeric / Min 6 digit / max 10 digit /
Starts with +, etc..

Data Dictionary - Notations
Sl.No. Notation Meaning
1. X = a + b X consists of data elements a & b.
2. X = [a / b] X consists of either data elements a or b.
3. X = a X consists of an optional data element a.
4. X = Y{a} X consists of Y or more occurrence of data
element a.
5. X = {a}z X consists of Z or fever occurrences of data
element a
6. X = y {a} z X consist of some occurrence of data
element a which are between Y and Z.

Data Dictionary - Advantages
1. Mechanism for name management. The data
dictionary software can check for name
uniqueness and tell requirements analysts of
name duplications. The names should be used
consisting and should not clash.
2.It serves as a store of organizational
information that can link analysis, design,

SE UNIT 2.pdf

More Related Content

Similar to SE UNIT 2.pdf (20)

More from udhayaveenaa (6)

Recently uploaded (20)

SE UNIT 2.pdf