Requirement Analysis (Requirement Engineering)

Requirement Analysis

• Starts after the feasibility study stage is completed

• And this phase ends when the requirements specification

document has been developed and reviewed.

• The requirements specification document is usually called as

the software requirement specification(SRS).

Cont..

❖It is a software engineering task that bridge the gap between

system level requirements and software design. It results the

specification of the operational software.

Cont..

• The person who undertakes requirements analysis and

specification:

• known as systems analyst.

Requirement Process

• The requirements analysis phase typically consist of four basic

activities.

• Requirement Elicitation

• Requirement Analysis

• Requirements Documentation

• Requirements Validation

Requirements Elicitation

• Also known as requirements gathering.

• Analyst gathers requirements through:

• discussion with the customer and end-users,

• analysis of what needs to be done(task scenario analysis),

• observation of existing systems,

• studying existing procedures, etc.

Requirement Analysis

• After gathering all the requirements:

• analyse it:

• Clearly understand the user requirements.

• Detect inconsistencies, anomalies, and incompleteness and

refine the gathered requirements.

• Indicates software’s interface with other system elements.

• Establishes constraints that software must meet.

Cont..

• Modeling techniques are used to analyse the requirements.

• analysis model provide description of

• Informational domain

• Functional domain

• Behavioral domain

Cont..

• the model changes dynamically as the developer learn more

about the system to built and other stakeholders understand

more about what they really require.

• The analysis model is a snapshot of requirements at any given

time.

• We should expect it to change.

Cont..

• The requirements modeling action results in one or more of the

following types of models:

➢Scenario-based model

✓System is described from the user’s point of view

✓e.g. Use-case diagrams

➢Data models

✓Define data entities and their attributes

✓Establishes relationship among data

✓e.g. Entity-relationship diagram

Cont..

➢Class-oriented model

✓Represents object-oriented classes

✓And the manner in which classes collaborate to achieve system requirements.

✓e.g. class diagram

➢Flow-oriented model

✓Represents the functional elements of the system

✓And how they transform data as it moves through the system

✓e.g. Data flow diagram

Cont..

➢Behavioral model

✓Depicts how the software behaves as a consequence of external

events.

✓e.g. State diagram, sequence diagram

Flow Oriented Modeling

• Information is transformed as it flows through a computer-based

system.

• The system accepts input in a variety of forms,

• Applies functions to transform it,

• And produces output in a variety of forms.

• The data flow diagram takes an input-process-output view of a

system.

Data flow diagrams (bubble chart)

• DFD is a hierarchical graphical model:

• shows the different processing activities (or functions)

of the system and

• data interchange among the processes.

• A Data Flow Diagram is graphical representation that

depicts information flow & the transformations that are

applied as data move from input to output.

Data flow diagrams

• Primitive Symbols Used for Constructing DFDs:

External entity Process Data store

Data flow

External Entity Symbol

• Represented by a rectangle

• External entities are physical entities those are

external to the software system and

• provide input data to the system or

• consume data produced by the system.

• e.g. librarian, a library member etc.

Function Symbol

• Represented by a circle

• This symbol is called a process or bubble.

• Bubbles are annotated with corresponding function names.

• Functions represent some activity.

• e.g. “search book”

Data Flow Symbol

• A directed arc or line.

• Represents data flow in the direction of the arrow.

• Data flow symbols are annotated with names of data they carry.

Data Store Symbol• Represented by two parallel lines.• Represents a logical file:

• A logical file can be:• a data structure • a physical file on disk.

• Each data store is connected to a process: • by means of a data flow symbol.

• Direction of data flow arrow:

• shows whether data is being readfrom or written into it.

DFD• A DFD model of a system graphically represents how

each input data is transformed to it’s output data through a hierarchy of DFDs.

• The DFD model of a problem consists of many of DFDs and a single data dictionary.

• Initially represent the software at the most abstract level:

• called the context diagram.

• the entire system is represented as a single bubble,

• this bubble is labelled according to the main function of the system.

Context Diagram

• A context diagram shows:

• data input to the system,

• output data generated by the system,

• external entities.

• Tic-tac-toe: Context Diagram

Human Player

Tic-tac-toe softwaredisplay

move

Context Diagram

• The context diagram is also called as the level 0 DFD.

• The context diagram establishes the context in which the system operates, that is –

• Who are the users,

• What data do they input to the system,

• What data they received by the system.

Level 1 DFD

• Examine the gathered requirements:

• Represent each function as a bubble.

• Represent data input to every function.

• Represent data output from every function.

Higher level DFDs

• Each function is separately decomposed into subfunctions:• identify the subfunctions of the function• identify the data input to each subfunction• identify the data output from each subfunction

• These are represented as DFDs.

• The refinement of DFDs continues until each bubble performs a simple function.

Example : RMS Calculating Software

• Consider a software called RMS calculating software: • reads three integers in the range of -1000 and +1000

• finds out the root mean square (rms) of the three input numbers

• displays the result.

cont..

• The context diagram is simple to develop:

• The system accepts 3 integers from the user

• returns the result to him.

Context Diagram

cont..

• From a cursory analysis of the problem description:

• we can see that the system needs to perform several things:

• Accept input numbers from the user:

• validate the numbers,

• calculate the root mean square of the input numbers

• display the result.

cont..

Level 1 DFD

RMS

Data-items

cont..

Level 2 DFD

• Calculation of root mean square

Data Dictionary• A DFD is always accompanied by a data dictionary.

• A data dictionary lists all data items appearing in a DFD.

• The data items listed include

• all data flows and the content of all data stores.

• A data dictionary lists the purpose of all data items and the

definition of all composite data items in terms of their

component data items.

• For example, a data dictionary entry may be:

• grossPay = regularPay + overtimePay

• For the smallest units of data items-

• The data dictionary simply lists their name and their type.

Cont..

• At the requirement stage, the data dictionary should at least

define customer data items, to ensure that the customer and

developer use the same definitions and terminologies.

Data Definition

• Composite data are defined in terms of primitive data

items using following operators:

• + : denotes composition of data items

• e.g. a+b represents data a and b.

• [,,] : represents selection,

• i.e. any one of the data items listed inside the square

bracket can occur.

• e.g. [a,b] represents either a occurs or b occurs.

Data Definition

• ( ): contents inside the bracket represent optional data

• which may or may not appear.

• e.g. a+(b) represents either a or a+b occurs.

• { }: represents iterative data definition,

• e.g. {name}5 represents five name data.

• {name}* represents zero or more instances of name

data.

Data Definition

• = represents equivalence,

• e.g. a=b+c means that a is a composite data item

comprising of both b and c.

• /* */: Anything appearing within /* */ is considered

as comment.

Data dictionary for RMS Software

• Data-items: {integer}3

• RMS: integer /* root mean square value */

• result: RMS

• Valid-data: Data-items

• a: integer /* input number */

• b: integer /* input number */

• c: integer /* input number */

• asq: integer

• bsq: integer

• csq: integer

• msq: integer

Importance of Data Dictionary➢Provides a standard terminology for all relevant data for

use by the developers working in a project.• a consistent vocabulary for data is very important

• different developers tend to use different terms to refer to the same data,

• causes unnecessary confusion.

➢Helps to determine the definition of different data structure in terms of their component elements.

➢Validate the data flow diagram

➢Helps to design the software and test cases.

Shortcomings of the DFD model

➢Imprecise (not accurate or exact) : In DFD model, we judge the function performed by a bubble from its label. However, a short label may not capture the entire functionality of a bubble.

• E.g. a bubble name “find-book” does not specify –

• Missing book, incorrect input etc.

➢Control aspects are not defined : A DFD model does not specify the order of the bubble execution.

Shortcomings of the DFD model

• Final level of DFD, up-to which the decomposition will be carried out is not fixed and it’s depend on the choice and judgment of the analyst.

• This technique does not provide any specific guidance as to how exactly to decompose a given function into its subfunctions.

Requirements Documentation

• After analyzing the requirements, requirements are systematically

documented.

• Requirements Document is called Software Requirements Specification

(SRS).

❖In context of computer based system the term specification describes the

written documents, a graphical working model, a formal mathematical

model, a collection of usage scenarios, a prototype or any combination of

these. All documents in these steps are accumulated in SRS.

Software Requirements Specification

• The SRS document is useful in various contexts:

• Forms an agreement between the customers and the developers

• Reduces future reworks

• Provides a basis for estimating costs and schedules

• Provide a base line for validation and verification

• Facilitates future extensions

Properties of a good SRS document

❖ Correct :

• An SRS is correct if every requirement stated in it is one that the software will meet.

❖ Unambiguous :

• Every requirements stated in it has only one interpretation. As a minimum this requires that each characteristic of the final product be described using single unique term.

• Understandable to both developer and user.

Properties of a good SRS document(cont..)

❖ Complete :

• It should include-

• All significant requirements

• Definition of the responses of the software to all classes of input data(valid and invalid).

• Full labels and references to all figures, tables, and diagrams in the SRS.

Properties of a good SRS document(cont..)

❖ Consistent:

It is internally consistent only if no subset of individual requirements described in it conflict.

❖ Ranked for importance and/or stability

• All of the requirements are not equally important.

• Necessity can be ranked as essential, conditional and optional.

• Stability can be expressed in terms of the number of expected changes to any requirements.

Properties of a good SRS document(cont..)

❖ Verifiable :

• Requirements should be verifiable.

• e.g. the requirements with statements “works well”, “good human interface”, “shall usually happen” are not verifiable.

❖Modifiable :

• Any changes to the requirements can be made easily, completely

and consistently.

• It is easy for a well-structured document.

Properties of a good SRS document(cont..)

❖ Traceable :

• We should be able to trace which part of the specification corresponds to which part of the design and code, etc. and vice versa.

Components of SRS

Table of

content:

Cont..

• The basic issues an SRS must address are:

✓External interfaces requirements

✓Functional requirements

✓Performance requirements

✓Design constraints

External interfaces requirements

• All the interactions of the software with people, hardware,

and other software should be clearly specified.

• This should be a detailed description of all inputs into and

outputs from the software system.

Cont..

It includes:

✓ Name of item

✓ Description of purpose

✓ Source of input or destination of output

✓ Valid range, accuracy, and/or tolerance

✓ Units of measure

✓ Timing

✓ Relationships to other inputs/outputs

✓ Screen formats/organization

✓ Window formats/organization

✓ Data formats

✓ Command formats

✓ End messages

Functional requirements

• Functional requirements should define the fundamental actions

that must take place in the software in accepting and

processing the inputs and in processing and generating the

outputs.

Cont..

It includes:

✓ Validity checks on the inputs

✓ Exact sequence of operations

✓ Responses to abnormal situations, including

1) Overflow

2) Communication facilities

3) Error handling and recovery

✓ Effect of parameters

✓ Relationship of outputs to inputs, including

1) Input/output sequences

2) Formulas for input to output conversion

Performance requirements

• All the requirements relating to the performance characteristics

of the system must be clearly specified.

• There are two types of Performance requirements:

• Static

• Dynamic

Cont..

• Static Requirement: Requirements do not impose constraint

on the execution characteristics of the software.

• Static numerical requirements may include a) The number of

terminals to be supported; b) The number of simultaneous

users to be supported; c) Amount and type of information to be

handled.

Cont..

• Dynamic Requirements: Specify the constraints on the

execution behavior of the system. E.g. Response time &

throughput constraints; transactional requirements

Design constraints

• This should specify design constraints that can be imposed by other

standards, hardware limitations, etc.

✓Standards Compliance: This specifies the requirements for the standards the

system must follow. e.g. Report format, Data naming, Accounting procedures,

Audit tracing.

• Other design constrains are:

✓hardware limitation

✓Reliability and fault tolerance

✓ Security.

Requirements Validation

• Requirements Validation examines the SRS to ensure

• that all software requirements have been stated Unambiguously

• that inconsistencies, incompleteness, errors have been detected and corrected

• The review team that validates requirements includes

• Software engineers

• Customers

• Users

• Other stakeholders

THANK YOU