Scribd
Upload
13 views9 pages

Unit 2-5

unit 2 part 5

Uploaded by

Chetan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
13 views9 pages

Unit 2-5

unit 2 part 5

Uploaded by

Chetan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 9

THE SOFTWARE REQUIREMENTS

Requirements analysis task is a process of discovery, refinement,


modeling, and specification.
Requirements analysis enables the system engineer to,
• Specify software function & performance,
• Indicate software’s interface with other system elements.
• Establish design constraints that the software must meet.
Requirements analysis allows the software engineer to,
• Refine the software allocation
• Build models of the process, data and domains
Requirements analysis provides the software engineer,
• Information of data, architectural and procedural design.
• Means to assess software quality, with the help of requirements
specification
The Format of a requirements specification document is presented in
the following Table.
Features of a good SRS
document
• Correctness: SRS is said to be perfect if it covers all the needs that are
truly expected from the system.
• Completeness: The SRS is complete if, and only if, it includes the
following elements:
(a) All essential requirements, whether relating to functionality,
performance, design, constraints, attributes, or external
interfaces.
(b) Definition of their responses of the software to all realizable
classes of input data in all available categories of situations.
(c) Full labels and references to all figures, tables, and diagrams in
the SRS and definitions of all terms and units of measure.
• Consistency: The SRS is consistent if, and only if, no subset of
individual requirements described in its conflict. There are three types
of possible conflict in the SRS:
(a) The specified characteristics of real-world objects may conflicts.
(b) There may be a reasonable or temporal conflict between the two specified
actions.
(c) Two or more requirements may define the same real-world object but use
different terms for that object.
• Unambiguousness: SRS is unambiguous when every fixed
requirement has only one interpretation.
• Ranking for importance and stability: The SRS is ranked for
importance and stability if each requirement in it has an identifier to
indicate either the significance or stability of that particular
requirement.
• Modifiability: SRS should be made as modifiable as likely and should
be capable of quickly obtain changes to the system to some extent.
Modifications should be perfectly indexed and cross-referenced.
• Verifiability: SRS is correct when the specified requirements can be
verified with a cost-effective system to check whether the final
software meets those requirements.
• Traceability: The SRS is traceable if the origin of each of the
requirements is clear and if it facilitates the referencing of each
condition in future development or enhancement documentation.
(a) Backward Traceability: This depends upon each requirement explicitly
referencing its source in earlier documents.
(b) Forward Traceability: This depends upon each element in the SRS having a
unique name or reference number.
• Design Independence: There should be an option to select from
multiple design alternatives for the final system. More specifically, the
SRS should not contain any implementation details.
• Testability: An SRS should be written in such a method that it is
simple to generate test cases and test plans from the report.
• Understandable by the customer: An end user may be an expert in
his/her explicit domain but might not be trained in computer science.
Hence, the purpose of formal notations and symbols should be
avoided too as much extent as possible. The language should be kept
simple and clear.
• The right level of abstraction: If the SRS is written for the
requirements stage, the details should be explained explicitly.
Whereas, for a feasibility study, fewer analysis can be used.

You might also like