requirements analysis and specification · the software requirement specification(srs). cont.. it...
TRANSCRIPT
![Page 1: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/1.jpg)
Requirement Analysis (Requirement Engineering)
![Page 2: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/2.jpg)
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).
![Page 3: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/3.jpg)
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.
![Page 4: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/4.jpg)
Cont..
• The person who undertakes requirements analysis and
specification:
• known as systems analyst.
![Page 5: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/5.jpg)
Requirement Process
• The requirements analysis phase typically consist of four basic
activities.
• Requirement Elicitation
• Requirement Analysis
• Requirements Documentation
• Requirements Validation
![Page 6: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/6.jpg)
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.
![Page 7: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/7.jpg)
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.
![Page 8: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/8.jpg)
Cont..
• Modeling techniques are used to analyse the requirements.
• analysis model provide description of
• Informational domain
• Functional domain
• Behavioral domain
![Page 9: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/9.jpg)
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.
![Page 10: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/10.jpg)
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
![Page 11: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/11.jpg)
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
![Page 12: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/12.jpg)
Cont..
➢Behavioral model
✓Depicts how the software behaves as a consequence of external
events.
✓e.g. State diagram, sequence diagram
![Page 13: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/13.jpg)
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.
![Page 14: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/14.jpg)
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.
![Page 15: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/15.jpg)
Data flow diagrams
• Primitive Symbols Used for Constructing DFDs:
External entity Process Data store
Data flow
![Page 16: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/16.jpg)
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.
![Page 17: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/17.jpg)
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”
![Page 18: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/18.jpg)
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.
![Page 19: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/19.jpg)
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.
![Page 20: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/20.jpg)
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.
![Page 21: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/21.jpg)
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
![Page 22: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/22.jpg)
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.
![Page 23: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/23.jpg)
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.
![Page 24: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/24.jpg)
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.
![Page 25: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/25.jpg)
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.
![Page 26: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/26.jpg)
cont..
• The context diagram is simple to develop:
• The system accepts 3 integers from the user
• returns the result to him.
Context Diagram
![Page 27: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/27.jpg)
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.
![Page 28: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/28.jpg)
cont..
Level 1 DFD
RMS
Data-items
![Page 29: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/29.jpg)
cont..
Level 2 DFD
• Calculation of root mean square
![Page 30: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/30.jpg)
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.
![Page 31: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/31.jpg)
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.
![Page 32: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/32.jpg)
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.
![Page 33: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/33.jpg)
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.
![Page 34: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/34.jpg)
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.
![Page 35: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/35.jpg)
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
![Page 36: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/36.jpg)
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.
![Page 37: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/37.jpg)
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.
![Page 38: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/38.jpg)
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.
![Page 39: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/39.jpg)
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.
![Page 40: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/40.jpg)
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
![Page 41: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/41.jpg)
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.
![Page 42: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/42.jpg)
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.
![Page 43: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/43.jpg)
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.
![Page 44: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/44.jpg)
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.
![Page 45: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/45.jpg)
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.
![Page 46: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/46.jpg)
Components of SRS
Table of
content:
![Page 47: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/47.jpg)
Cont..
• The basic issues an SRS must address are:
✓External interfaces requirements
✓Functional requirements
✓Performance requirements
✓Design constraints
![Page 48: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/48.jpg)
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.
![Page 49: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/49.jpg)
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
![Page 50: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/50.jpg)
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.
![Page 51: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/51.jpg)
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
![Page 52: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/52.jpg)
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
![Page 53: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/53.jpg)
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.
![Page 54: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/54.jpg)
Cont..
• Dynamic Requirements: Specify the constraints on the
execution behavior of the system. E.g. Response time &
throughput constraints; transactional requirements
![Page 55: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/55.jpg)
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.
![Page 56: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/56.jpg)
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
![Page 57: Requirements Analysis and Specification · the software requirement specification(SRS). Cont.. It is a software engineering task that bridge the gap between system level requirements](https://reader035.vdocuments.site/reader035/viewer/2022062508/606f7661e210d4066274b306/html5/thumbnails/57.jpg)
THANK YOU