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 read from 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 Tic-tac-toe display software

move Human Player 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..

RMS

Data-items

Level 1 DFD cont..

• Calculation of root mean square

Level 2 DFD 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