0% found this document useful (0 votes)
17 views15 pages

Unit Ii

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views15 pages

Unit Ii

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

UNIT II

Requirement Analysis and Specification


• The Requirement Analysis and Specification phase starts after the
feasibility study stage is complete and the project is financially viable
and technically feasible.
• This phase ends when the requirements specification document has
been developed and reviewed.
• It is usually called the Software Requirements Specification
(SRS) Document.
• Divide the requirements gathering and analysis activity into two
separate tasks:
• Requirements gathering
• Requirements analysis
• Requirements Gathering:
• It is also known as Requirements Elicitation. The primary objective of the
requirements gathering task is to collect the requirements from the
stakeholders.
• A stakeholder is a source of the requirements and is usually a person or a
group of persons who either directly or indirectly are concerned with the
software.
• 1. Studying existing documentation: The analyst usually studies all the
available documents regarding the system to be developed before visiting the
customer site. Customers usually provide a statement of purpose (SoP)
document to the developers. Typically these documents might discuss issues
such as the context in which the software is required.
• 2. Interview: Typically, there are many different categories of users of the
software. Each category of users typically requires a different set of features
from the software. Therefore, it is important for the analyst to first identify
the different categories of users and then determine the requirements of
each.
• 3. Task analysis: The users usually have a black-box view of software and consider
the software as something that provides a set of services. A service supported by
the software is also called a task. We can therefore say that the software performs
various tasks of the users. In this context, the analyst tries to identify and
understand the different tasks to be performed by the software. For each identified
task, the analyst tries to formulate the different steps necessary to realise the
required functionality in consultation with the users.
• 4. Scenario analysis: A task can have many scenarios of operation. The different
scenarios of a task may take place when the task is invoked under different
situations. For different types of scenarios of a task, the behaviour of the software
can be different.
• 5. Form analysis: Form analysis is an important and effective requirement gathering
activity that is undertaken by the analyst when the project involves automating an
existing manual system. During the operation of a manual system, normally several
forms are required to be filled up by the stakeholders, and in turn, they receive
several notifications. In form analysis, the exiting forms and the formats of the
notifications produced are analysed to determine the data input to the system and
the data that are output from the system.
• Requirement Analysis and Specification:
• After requirements gathering is complete, the analyst analyses the gathered
requirements to form a clear understanding of the exact customer
requirements and to weed out any problems in the gathered requirements. It
is natural to expect the data collected from various stakeholders to contain
several contradictions, ambiguities, and incompleteness.
• The main purpose of the requirements analysis activity is to analyse the
gathered requirements to remove all ambiguities, incompleteness, and
inconsistencies from the gathered customer requirements and to obtain a
clear understanding of the software to be developed.
• During requirements analysis, the analyst needs to identify and resolve three
main types of problems in the requirements:
• Anomaly
• Inconsistency
• Incompleteness
• Anomaly: It is an anomaly is an ambiguity in a requirement. When a
requirement is anomalous, several interpretations of that requirement are
possible. Any anomaly in any of the requirements can lead to the
development of an incorrect system, since an anomalous requirement can be
interpreted in several ways during development.
• Inconsistency: Two requirements are said to be inconsistent if one of the
requirements contradicts the other.
• Incompleteness: An incomplete set of requirements is one in which some
requirements have been overlooked. The lack of these features would be felt
by the customer much later, possibly while using the software. Often,
incompleteness is caused by the inability of the customer to visualise the
system that is to be developed and to anticipate all the features that would be
required.
Software Requirement Specifications-SRS

• The production of the requirements stage of the software


development process is Software Requirements Specifications
(SRS) (also called a requirements document).
• This report lays a foundation for software engineering activities and is
constructing when entire requirements are elicited and analyzed.
• SRS is a formal report, which acts as a representation of software that
enables the customers to review whether it (SRS) is according to their
requirements.
• Also, it comprises user requirements for a system as well as detailed
specifications of the system requirements.
• The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment. It
serves several goals depending on who is writing it.
• First, the SRS could be written by the client of a system.
• Second, the SRS could be written by a developer of the system.
• The two methods create entirely various situations and establish different
purposes for the document altogether.
• The first case, SRS, is used to define the needs and expectation of the users.
• The second case, SRS, is written for various purposes and serves as a contract
document between customer and developer.
Characteristics of good SRS
• 1. Correctness: User review is used to provide the accuracy of requirements
stated in the SRS. SRS is said to be perfect if it covers all the needs that are truly
expected from the system.
• 2. 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.
• 3. 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:
• 4. Unambiguousness: SRS is unambiguous when every fixed requirement has
only one interpretation. This suggests that each element is uniquely
interpreted. In case there is a method used with multiple definitions, the
requirements report should determine the implications in the SRS so that it is
clear and simple to understand.
• 5. 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.
• Typically, all requirements are not equally important. Some prerequisites may
be essential, especially for life-critical applications, while others may be
desirable. Each element should be identified to make these differences clear
and explicit. Another way to rank requirements is to distinguish classes of
items as essential, conditional, and optional.
• 6. 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.
• 7. 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. The requirements are verified with the help of reviews.
• 8. 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.
• 9. 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.
• 10. Testability: An SRS should be written in such a method that it is simple to
generate test cases and test plans from the report.
• 11. 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.
• 12. 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. Hence, the level of abstraction modifies
according to the objective of the SRS.
Properties of a good SRS document

• Concise: The SRS report should be concise and at the same time, unambiguous,
consistent, and complete. Verbose and irrelevant descriptions decrease
readability and also increase error possibilities.
• Structured: It should be well-structured. A well-structured document is simple to
understand and modify. In practice, the SRS document undergoes several
revisions to cope up with the user requirements. Often, user requirements evolve
over a period of time. Therefore, to make the modifications to the SRS document
easy, it is vital to make the report well-structured.
• Black-box view: It should only define what the system should do and refrain from
stating how to do these. This means that the SRS document should define the
external behavior of the system and not discuss the implementation issues. The
SRS report should view the system to be developed as a black box and should
define the externally visible behavior of the system. For this reason, the SRS
report is also known as the black-box specification of a system.
• Conceptual integrity: It should show conceptual integrity so that the reader
can merely understand it. Response to undesired events: It should
characterize acceptable responses to unwanted events. These are called
system response to exceptional conditions.
• Verifiable: All requirements of the system, as documented in the SRS
document, should be correct. This means that it should be possible to decide
whether or not requirements have been met in an implementation.

You might also like