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.

2. Software Requirements
Software Requirements: It is a field within software engineering that deals with establishing the
needs of stakeholders that are to be solved by software.
Requirements engineering:
 The broad spectrum of tasks and techniques that lead to an understanding of requirements is
called requirements engineering.
 It is a process of establishing the services that customer require from a system
 And it is the constraints under which it operates and it is developed.
4. Requirements engineering builds a bridge to design and construction.
Types of requirements:

Types of requirements

User requirements System requirements Software specification

(i) User Requirements:

 User requirements are statements, in a natural language plus diagrams, of what services the system
is expected to provide to system users and the constraints under which it must operate.
 It is written for customers.

(ii) System requirements:

 System requirements are more detailed descriptions of the software system’s functions, services,
and operational constraints.
 The system requirements document (sometimes called a functional specification) should define
exactly what is to be implemented.
 It may be part of the contract between the system buyer and the software developers.

CS8494-SE 1
(iii) Software specification:
It is a detailed software description that can serve as a basic for design and implementation. It is
written for software developers.

2.1 Functional and Non-Functional Requirements:

Software system requirements can be classified into Functional and Non-Functional requirements.
(i) Functional Requirements:
 A functional requirement describes what a software system should do.
 The functional requirement is describing the behavior of the system as it relates to the system's
functionality.
 Requirements depend on the type of software being developed, the expected users of the software,
and the general approach taken by the organization when writing requirements.
 When expressed as user requirements, functional requirements are usually described in an abstract
way that can be understood by system users.
 More specific functional system requirements describe the system functions, its inputs and outputs,
exceptions, etc., in detail.
For example,
a) Examples of functional requirements for the MHC-PMS system, used to maintain information
about patients receiving treatment for mental health problems:
1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who are expected to attend
appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her eight-digit employee
number.
b) Examples of functional requirements for the LIBSYS system
1. The user shall be able to search either all of the initial set of databases or select a subset from it.
2. The system shall provide appropriate viewers for the user to read documents in the document
store.
3. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy
to the account’s permanent storage area.
(ii) Non-Functional Requirements:
 The definition for a non-functional requirement is that it essentially specifies how the system
should behave and that it is a constraint upon the systems behavior.
 One could also think of non-functional requirements as quality attributes for of a system.

CS8494-SE 2
(a) Product requirements - These requirements specify or constrain the behavior of the software.
Examples include performance requirements on how fast the system must execute and how much
memory it requires, reliability requirements that set out the acceptable failure rate, security
requirements, and usability requirements.
(b) Organizational requirements - These requirements are broad system requirements derived from
policies and procedures in the customer’s and developer’s organization. Examples include
operational process requirements that define how the system will be used, development process
requirements that specify the programming language, the development environment or process
standards to be used, and environmental requirements that specify the operating environment of the
system.
(c) External requirements - This broad heading covers all requirements that are derived from factors
external to the system and its development process. These may include regulatory requirements that
set out what must be done for the system to be approved for use by a regulator, such as a central
bank; legislative requirements that must be followed to ensure that the system operates within the
law; and ethical requirements that ensure that the system will be acceptable to its users and the
general public.
Metrics for specifying non-functional requirements

CS8494-SE 3
(iii) Domain Requirements
 Derived from the application domain and describe system characteristics and features that reflect
the domain
 May be new functional requirements, constraints on existing requirements or define specific
computations
 If domain requirements are not satisfied, the system may be unworkable
Example: Library system domain requirements
 There shall be a standard user interface to all databases which shall be based on the Z39.50
standard.
 Because of copyright restrictions, some documents must be deleted immediately on arrival.
Depending on the user’s requirements, these documents will either be printed locally on the system
server for manually forwarding to the user or routed to a network printer.

Difference between Functional and Non-Functional Requirements

CS8494-SE 4
2.2 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
 Lack of clarity Precision is difficult without making the document difficult to read
 Requirements confusion Functional and non-functional requirements tend to be mixed-up
 Requirements amalgamation several different requirements may be expressed together
Guidelines for writing user requirements:
 Invent a standard format and use it for all requirements
 Use language in a consistent way. Use shall for mandatory requirements, should for desirable
requirements
 Use text highlighting to identify key parts of the requirement
 Avoid the use of computer jargon

2.3 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
Structured language specifications
 A limited form of natural language may be used to express requirements
 This removes some of the problems resulting from ambiguity and flexibility and imposes a
degree of uniformity on a specification
 Supported using a forms-based approach

Example:
 LIB system shall keep track of all data required by copyright licensing agencies In the Kingdom
and elsewhere. System Requirements Specification On making a request for a document from LIB
system, the requestor shall be presented with a form that records Details of the user and the
request made.
 LIB system request forms shall be stored on the system for five years from the date of the request.
CS8494-SE 5
2.4 Software requirement document:
 The software requirements document is the specification of the system.
 It should include both a definition and a specification of requirements.
 The software requirements provide a basis for creating the Software Requirements Specifications
(SRS).
 The SRS is useful in estimating cost, planning team activities, performing tasks, and tracking the
team’s progress throughout the development activity.
 Software designers use IEEE STD 830-1998 as the basis for the entire SRS.
Software Requirements Specification
<TITLE>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>
1. Introduction
1.1. Purpose
1.2.Scope
1.3.Overview
2. General description
3. Functional Requirements
4. Interface requirements
4.1 User interfaces
4.1.1 GUI
4.1.2 CLI
4.1.3 API
4.2 Hardware interfaces
4.3 Software interfaces
4.4 Communication interfaces
5. Performance requirements
6. Design requirements
7. Other non-functional requirements
7.1 security
7.2 Binary compatibility
7.3 Reliability
7.4 Maintainability
7.5 Portability
7.6 Extendibility
7.7 Reusability
7.8 Application compatibility
7.9 Resource utilization
CS8494-SE 6
 7.10 Serviceability
8. Operational scenarios
9. Preliminary schedule
10. Preliminary budget
11. Appendices
11.1 Definitions, Acronyms, Abbreviations
11.2 References
1. Introduction
1.1 Purpose
 Identify the product whose software requirements are specified in this document, including
the revision or release number.
 Describe the scope of the product that is covered by this SRS, particularly if this SRS describes
only part of the system or a single subsystem.
1.2 Scope
 Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals.
 Relate the software to corporate goals or business strategies. If a separate vision and scope
document is available, refer to it rather than duplicating its contents here.
2. General description:
3. Functional Requirements
 Itemize the detailed functional requirements associated with this feature.
 These are the software capabilities that must be present in order for the user to carry out the
services provided by the feature, or to execute the use case.
 Include how the product should respond to anticipated error conditions or invalid inputs
4. Interface requirements
 Describe the logical characteristics of each interface between the software product and the
users.
4.1 User Interfaces
 This may include sample screen images, any GUI standards or product family style guides that
are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that
will appear on every screen, keyboard shortcuts, error message display standards, and so on.
 Define the software components for which a user interface is needed.
4.2 Hardware Interfaces
 Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system.
 This may include the supported device types, the nature of the data and control interactions
 between the software and the hardware, and communication protocols to be used.
4.3 Software Interfaces
 Describe the connections between this product and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated
commercial components.
 Identify the data items or messages coming into the system and going out and describe the
purpose of each
 Identify data that will be shared across software components.

CS8494-SE 7
 If the data sharing mechanism must be implemented in a specific way (for example, use of a
global data area in a multitasking operating system), specify this as an implementation
constraint.
4.4 Communications Interfaces
 Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms.
 Define any pertinent message formatting. Identify any communication standards that will be
used, such as FTP or HTTP.
 Specify any communication security or encryption issues, data transfer rates, and
synchronization mechanisms.
5. Performance Requirements
 If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make
suitable design choices.
6. Design requirements
Describe about the basic design of the software using UML diagrams which include DFD
diagram, sequence diagram, ER diagram, Class diagram, Activity diagram.
7. Other non functional requirements
 Describe how the system should function rather than what should do. It includes following
functionalities.
7.1 securities
 Describe how secure the system should be.
7.2 Binary compatibility
7.3 Reliability
7.4 Maintainability
 Describe how the system can be serviced and in which time period.
7.5 Portability
Describe about how the application can be work in different platforms.
7.6 Extendibility
Describe about how the system can connect with the other external resources
7.7 Reusability
Describe about how the software can be reused for the future products.
7.8 Application compatibility
7.9 Resource utilization
7.10 Serviceability
8. Operational scenarios
9.Preliminary schedule
10. Preliminary budget
11. Appendices
11.1 Definitions, Acronyms, Abbreviations
11.2 References

CS8494-SE 8
Example:

CS8494-SE 9
CS8494-SE 10
CS8494-SE 11
CS8494-SE 12
Characteristics of SRS:
# Correctness # Unambiguous
# Specific # Completeness
# Traceable # Consistent
Users of a Requirements document:

CS8494-SE 13
2.5 Requirement Engineering Process:
Requirement engineering is a process in which various activities are concerned
 Feasibility studies
 Requirement elicitation and analysis
 Requirement validation
 Requirement management

Requirement Engineering Task

 Seven distinct tasks
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements Management
• Some of these tasks may occur in parallel and all are adapted to the needs of the project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and construction of the software
 Inception—Establish a basic understanding of the problem and the nature of the solution.
 Elicitation—Draw out the requirements from stakeholders.
 Elaboration—Create an analysis model that represents information, functional, and
behavioral aspects of the requirements.
 Negotiation—Agree on a deliverable system that is realistic for developers and customers.
 Specification—Describe the requirements formally or informally.
 Validation—Review the requirement specification for errors, ambiguities, omissions, and
conflicts.
 Requirements management—Manage changing requirements.
(a) Inception Task
During inception, the requirements engineer asks a set of questions to establish,
 A basic understanding of the problem
CS8494-SE 14
  The people who want a solution

 The nature of the solution that is desired

 The effectiveness of preliminary communication and collaboration between the customer and
the developer
Through these questions, the requirements engineer needs to…
 Identify the stakeholders
 Recognize multiple viewpoints
 Work toward collaboration
 Break the ice and initiate the communication
(b) Elicitation
It certainly simple enough, but..
Why difficult
– Problem of Scope
• The boundary of the system is ill-defined
– Problem of Understanding
• The customer/users are not completely sure of what is needed
– Problem of volatility
• The requirement change over time
• To help overcame this problem, requirement engineers, must approach the
requirement gathering activity in an organized manner
(c)Elaboration
• Expand requirement into analysis model
• Elements of the analysis model
– Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an “actor” and the system
– Class-based elements
• Implied by scenarios
– Behavioral elements
• State diagram
– Flow-oriented elements
• Data flow diagram
(d) Negotiation
• Agree on a deliverable system that is realistic for developers and customers
• SW team & other project stakeholders negotiate the priority, availability, and cost of each
requirement
• The Process are :
– Identify the key stakeholders
• These are the people who will be involved in the negotiation
– Determine each of the stakeholders “win conditions”
• Win conditions are not always obvious

CS8494-SE 15
 – Negotiate
• Work toward a set of requirements that lead to “win-win”
(e) Specification
• Final work product produced by requirement engineer.
• 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)
– A prototype
(e) Validation
Examine the specification to ensure that SW requirement is not ambiguous, consistent, error free etc.
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.
(f) Requirement management:
Requirement management is the process of managing changing requirements during the
requirements engineering process and system development.

1. Feasibility studies:
 A feasibility study is a study made to decide whether or not the proposed system is worthwhile.
 Input to feasibility study: Outline description of the system.
 Output from feasibility study: Feasibility report.
Feasibility report:
CS8494-SE 16
 It is a document which recommends whether or not it is worth carry on with the requirement
engineering and system development process.
Feasibility studies focus on:
o Does the system contribute the overall objectives of the organization?
o Can the system be implemented using current technology?
o Can the system be implemented within the given budget and schedule?
o Can the system integrated with the other systems which are already in place?
2. Requirement elicitation and analysis
It includes following activities:
 Requirement discovery
 Requirement Classification
 Requirement Prioritization4.
 Requirement documentation

(a) Requirement discovery:

Requirement discovery is a process of Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage. Requirements are also discovered at this
stage.

CS8494-SE 17
 Requirement Requirement
checking specification

Domain Prioritization Requirement

understanding document
Process
entry Requirement elicitation
and analysis process

Requirement CONFLICT
collection RESOLUTION

Classification

Various methods of requirement discovery:

 Interviewing
 Viewpoints
 Scenarios
 Use cases
 Ethnography

Interviewing
In formal or informal interviewing, the RE team puts questions to stakeholders about the system that
they use and the system to be developed.
 There are two types of interview
 Closed interviews where a pre-defined set of questions are answered. Defined set of questions
are answered.
 Open interviews where there is no pre-defined agenda and a range of issues are explored
with stakeholders.
Scenarios
Scenarios are real-life examples of how a system can be used.
They should include
 A description of the system
 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.
Viewpoints:
Viewpoints are a way of structuring the requirements to represent the perspectives of different
CS8494-SE 18
stakeholders. Stakeholders may be classified under different viewpoints.

Use cases:
Use-cases are a scenario-based technique in the UML which identify the actors in an interaction and
which describe the interaction itself.
• set of use cases should describe all possible interactions the system.

Ethnography
It is a technique of observation which is used to understand social and organizational requirements.
Two types:
 Requirements obtained from working style of people
 Requirement obtained from interactivities performed by people.
(b) Requirements classification
• Groups related requirements and organizes them into coherent clusters.
(c) Requirements Prioritization
• Prioritizing requirements and resolving requirements conflicts.
(d) Requirements documentation

CS8494-SE 19
• Requirements are documented and input into the next round of the spiral.

3. Requirement validation
Requirement validation is a process in which it is checked that whether the gathered
requirements represent the same system the customer really wants.
 In requirement validation the requirement errors are fixed.
 Requirement error fixing cost is higher than the implementation error fixing cost.
Requirement checking can be done in following manner,
 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 according to budget and technology?
 Verifiability: can the requirements be checked?

Requirement validation techniques:

Test case Requirements

generation reviews
Requirement
validation techniques

Automated
consistency analysis Prototyping

Requirement review: Manual analysis of requirements.

Test case generation: various test cases are developed to verify the requirements.
Automated consistency analysis: CASE tools can be used to test the requirements.
Prototyping: The requirements can be checked using executable model of the system.
4. Requirement management
Requirement management is a process of managing the changing requirements during the
requirement engineering process and system development. Why the requirements gets changing:
 Requirements are always incomplete and inconsistent.
 Customer may specify the requirements from business perspective that may conflict with the
end user.
During the development of the system, its business and the technical environment may get
changed.
Enduring and volatile requirements:
Enduring requirements:
They are relatively stable requirements which derive from a core activity of the organization and
which relate directly to the domain.
EX: In Hospital management system, concerned with patients, doctors, nurse and treatments are
enduring requirements.

CS8494-SE 20
 Volatile requirements:
These are requirements which are likely to change during the system development or the system
becomes operational.
EX: In Hospital management system, Requirement may change after government health care policies
change.
Types of Volatile requirements:
Types Definition
Mutable Requirements get change due to the change in the
requirements environment.
Emergent Requirements get change due to the change in customer
requirements understanding.

Consequent Requirements get change due to introduction of new

requirements computer system.
Compatibility Requirements get change due to the dependencies
requirements of system business.
Requirements management 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;
– Traceability policies
• The amount of information about requirements relationships that is maintained;
– CASE tool support
• The tool support required to help manage requirements change
Traceability
• Traceability is concerned with the relationships between requirements, their sources and the system
design
• Source traceability
– Links from requirements to stakeholders who proposed these requirements;
• Requirements traceability
– Links between dependent requirements;
• Design traceability
– Links from the requirements to the design;

D-Dependent
R-Weak Relationship

CS8494-SE 21
CASE tool support
• Requirements storage
– Requirements should be managed in a secure, managed data store.
• Change management
– The process of change management is a workflow process whose stages can be defined and
information flow between these stages partially automated.
• Traceability management
– Automated retrieval of the links between requirements.
Requirements change management
• Should apply to all proposed changes to the requirements.
• Principal stages
– Problem analysis: Discuss requirements problem and propose change;
– Change analysis and costing: Assess effects of change on other requirements;
– Change implementation: Modify requirements document and other documents to reflect
change.

2.6 STRUCTURED SYSTEM ANALYSIS:

DATA FLOW DIAGRAM:
 DFD is also known as bubble chart . Its main purpose is to clarify the system requirements
and identify major transformations that will become programs in system design.
 It is the starting point of the design phase. A DFD consist of a series of bubbles joined by lines.
 The bubbles represent data transformations and the line represents data flow in the system.
A DFD describes what data flow rather than how they are processed, so it does not depend on
hardware, software, data structure or file organization.
DFD symbols
There are mainly four symbols for DFD.

 A Square defines a source or destination of system data.

 An arrow identifies data flow, i.e.: data in motion. It is a pipeline through which information
flows.
 A circle represents a process that transforms incoming data flows into outgoing data.
 An open rectangle is a data store, ie: data at rest or a temporary repository of data.

CS8494-SE 22
Rules for constructing DFD:
 Processes should be named and numbered for easy reference.
 The direction of flow is from top to bottom and from left to right. Data flows from source to
the destination.
 Process should be numbered, if they are exploded into lower level details.
 The names of data stores, sources and destination should be in capital letters. Process and data
flow names first letter should be in capital letter.

Example 1: Data flow diagram for safe home system:

The SafeHome security function enables the homeowner to configure the security system when it is
installed, monitors all sensors connected to the security system, and interacts with the homeowner
through the Internet, a PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the system. Each sensor is
assigned a number and type, a master password is programmed for arming and disarming the
system, and telephone number(s) are input for dialing when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to the system.
After a delay time that is specified by the homeowner during system configuration activities, the
software dials a telephone number of a monitoring service, provides information about the location,
reporting the nature of the event that has been detected. The telephone number will be redialed every
20 seconds until telephone connection is obtained. The homeowner receives security information via
a control panel, the PC, or a browser, collectively called an interface. The interface displays
prompting messages and system status information on the control panel, the PC, or the browser
window.
DFD level 0: Context level:

CS8494-SE 23
CS8494-SE 24
Example 2: Automated Railway Reservation System
DFD level 0

DFD level 1

CS8494-SE 25
DFD level 2

Example 3:Library Information System

DFD level 0

CS8494-SE 26
DFD level 1

DFD level 2

CS8494-SE 27
Example 4:Food Orgering System
DFD level 0

DFD level 1

CS8494-SE 28
DFD level 2

Example 5:Online Hotel reservation System

DFD level 0

CS8494-SE 29
DFD level 1

DFD level 2

2.7 Petri Nets:

Petri nets are a well-known formal model which combines a rich mathematical theory with a useful
graphical notation.

Notations:

CS8494-SE 30
Consists of 4 types of components:

– Places represent possible states of the system;

– Transitions are events or actions which cause the change of state; And
– Every arc simply connects a place with a transition or a transition with a place.
– A change of state is denoted by state inside black dot.
Example:

Petri nets for traffic lights :

Advantages:
 Precise definition of problem
 Represent graphical overflow
 Useful in allocating resources to tasks

2.8 Data dictionary:

 A data dictionary is a collection of descriptions of the data objects or items in a data model for
the benefit of programmers and others who need to refer to them.
 Data dictionary contains the descriptions of all data objects consumed or produced by the
software.
It can store flowing information:
 Name the primary name of the data or control item, the data store or an external entity.
 Alias other names used for the first entry.
 Where-used/how-used a listing of the processes that use the data or control item and how it is
used (e.g., input to the process, output from the process, as a store, as an external entity.
 Content description a notation for representing content.
CS8494-SE 31
  Supplementary information other information about data types, preset values (if known),
restrictions or limitations, and so forth.

The notation used to develop a content description is noted in the following table:
Data Construct Notation Meaning
= is composed of
Sequence + and
Selection [|] either-or
Repetition { }n n repetitions of
() optional data
* ... * delimits comments
The notation enables a software engineer to represent composite data in one of the three fundamental
ways that it can be constructed:
 As a sequence of data items.
 As a selection from among a set of data items.
 As a repeated grouping of data items.
Each data item entry that is represented as part of a sequence, selection, or repetition may itself be
another composite data item that needs further refinement within the dictionary.

Example: Any reservation system:

Name : Passenger
Alias : none
Where used/how used : Passenger query (input),Ticket (ticket).
Description:
Passenger = Passenger_name + Passenger_address
Passenger _name = Passenger_last name + Passenger_First name + Passenger_Middlename
Passenger_address = Local _address + Community_address
Local _address = House_nmae + Street_nmae
Community_address = City_name + State_nmae
Advantages:
 Support name management and avoid duplication.
 Store of linking analysis, design and implementation
 Automated tools (CASE) can be used to maintain data dictionary.

CS8494-SE 32
 PART - A
1. Define software prototyping.[R]
Software prototyping is defined as a rapid software development for validating the
requirements.

2. What are the benefits of prototyping? [APR/MAY 2012] [R]

 Prototype serves as a basis for deriving system specification. ii. Design quality can be
improved.
 System can be maintained easily.
 Development efforts may get reduced.
 System usability can be improved.

3. What are the prototyping approaches in software process?[APR/MAY 2015] [U]

 Evolutionary prototyping – In this approach of system development, the initial prototype is
prepared and it is then refined through number of stages to final stage.
 Throw-away prototyping – Using this approach a rough practical implementation of the system
is produced. The requirement problems can be identified from this implementation. It is then
discarded. System is then developed using some different engineering paradigm.
4. What are the advantages of evolutionary prototyping? [APR/MAY 2012] [R]
Fast delivery of the working system.
User is involved while developing the system.
More useful system can be delivered.
Specification, design and implementation work in co-ordinated manner.
5. What are the various Rapid prototyping techniques?[[NOV/DEC 2014] [U]
Dynamic high level language development. ii. Database programming.
Component and application assembly.

6. What is the use of User Interface prototyping?[APR/MAY 2012] [U]

This prototyping is used to pre-specify the look and feel of user interface in an effective way.

7. What are the characteristics of SRS?[R]

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 software.
Complete – To make SRS complete, it should be specified what a software designer wants to
create software.
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.

8. What are the objectives of Analysis modeling? [U]

i. To describe what the customer requires.
ii. To establish a basis for the creation of software design.
iii. To devise a set of valid requirements after which the software can be built.
9. What is data modeling?[APR/MAY 2012] [R]
Data modeling is the basic step in the analysis modeling. In data modeling the data objects are
examined independently of processing. The data model represents how data are related with one
another.
CS8494-SE 33
 10. What is a data object? [R][NOV/DEC 2014]
Data object is a collection of attributes that act as an aspect, characteristic, quality, or descriptor of
the object.

11. What are attributes?[R]

Attributes are the one, which defines the properties of data object.

12. What is cardinality in data modeling?[R]

Cardinality in data modeling, cardinality specifies how the number of occurrences of one object is
related to the number of occurrences of another object.

13. What does modality in data modeling indicates? [APR/MAY 2015] [U]
Modality indicates whether or not a particular data object must participate in the relationship.

14. What is ERD? [R] [NOV/DEC 2014]

Entity Relationship Diagram is the graphical representation of the object relationship pair. It is
mainly used in database applications.

15. What is DFD?[R]

Data Flow Diagram depicts the information flow and the transforms that are applied on the data as it
moves from input to output.

16. What does Level0 DFD represent?[U]

Level0 DFD is called as „fundamental system model‟ or „context model‟. In the context model the
entire software system is represented by a single bubble with input and output indicated by incoming
and outgoing arrows

17. What is a state transition diagram?[R]

State transition diagram is basically a collection of states and events. The events cause the system to
change its state. It also represents what actions are to be taken on the occurrence of particular event.

18. Define Data Dictionary.[R]

The data dictionary can be defined as 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.

19. What are the elements of Analysis model?[R]

i. Data Dictionary
ii. Entity Relationship Diagram
iii. Data Flow Diagram
iv. State Transition Diagram v. Control Specification
v. Process specification

20. What is the purpose of a data dictionary? [APR / MAY 2017] [R]
Data dictionary is the centralized collection of information about data. It stores meaning and origin of
data, its relationship with other data, data format for usage, etc. Data dictionary has rigorous
definitions of all names in order to facilitate user and software designers. Data dictionary is often
referenced as meta-data (data about data) repository. It is created along with DFD (Data Flow
Diagram) model of software program and is expected to be updated whenever DFD is changed or
CS8494-SE 34
 updated.

21. What is the purpose of Petri Net? [APR / MAY 2017][R]

Petri nets are a well-known formal model which combines a rich mathematical theory with a useful
graphical notation. Consists of 4 types of components:
 Places represent possible states of the system;
 Transitions are events or actions which cause the change of state; And
 Every arc simply connects a place with a transition or a transition with a place.
 A change of state is denoted by state inside black dot.

22.What are the various types of traceability in software engineering?

[R] [APR / MAY 2018]
i. Source traceability – These are basically the links from requirement to stakeholders
ii. Requirements traceability – These are links between dependant requirements.
iii.Design traceability – These are links from requirements to design

23. What are the prototyping approaches in software process? [APR / MAY 2018] [R]

i. Evolutionary prototyping – the initial prototype is prepared and it is then refined through number
of stages to final stage.
ii. Throw-away prototyping – a rough practical implementation of the system is produced. The
requirement problems can be identified from this implementation.
Part-B
1. Explain in detail about Functional and nonfunctional requirements. [APR/MAY 2012] [U]
2. Explain in detail about user requirements. [APR/MAY 2015] [R]
3. Explain in detail elicitation and analysis. [NOV/DEC 2014] [R]
4. Explain about requirement validation and management. [APR/MAY 2012] [R]
5. Explain Petri nets and data dictionary. [R]
6. What are requirements engineering? Explain in detail the various processes in requirements
engineering. [APR / MAY 2017] [U]
7. Write a note on what are the difficulties in elicitation, requirement elicitation.
[APR / MAY 2017] [R]
8. Explain the feasibility studies. What are the outcomes? Does it have implicit or explicit on
software requirement collection? [APR / MAY 2017] [U]
9. What is requirement elicitation? Briefly describe the various activities performed in requirements
elicitation phase with an example of a watch system that facilitates to set time and alarm.
[APR / MAY 2018] [U]
10. What is SRS? Explain in detail the various components of an SRS. [APR / MAY 2018] [U]

CS8494-SE 35