Software Requirements Specification

& Modeling
201980090170

2. Software Requirements Specification

2.1 Characteristics of 4 software requirment
statement

1. Complete
2. Correct
3. Feasible
4. Necessary

Complete: Each requirement must contain all the information necessary for
the reader to understand it. In the case of functional requirements, this means
providing the information the developer needs to be able to implement it correctly.
If you know you’re lacking certain information, use TBD (to be determined) as a
standard flag to highlight these gaps, or log them in an issue-tracking system to
follow up on later. Resolve all TBDs in each portion of the requirements before the
developers proceed with construction of that portion.

Correct: Each requirement must accurately describe a capability that will meet
some stakeholder’s need and must clearly describe the functionality to be built.
You’ll have to go to the source of the requirement to check its correctness. This
might be a user who supplied the initial requirement, a higher-level system
requirement, a use case, a business rule, or another document. A low-level
requirement that conflicts with its parent is not correct. To assess the correctness of
user requirements, user representatives or their close surrogates should review
them.

Feasible: It must be possible to implement each requirement within the

known capabilities and limitations of the system and its operating
environment. To avoid specifying unattainable requirements, have a
developer work with marketing or the BA throughout the elicitation process.
It must be possible to implement each requirement within the known capabilities
and limitations of the system and its operating environment, as well as within
project constraints of time, budget, and staff. A developer who participates during
elicitation can provide a reality check on what can and cannot be done technically
and what can be done only at excessive cost or effort. Incremental development
approaches and proof-of-concept prototypes are two ways to evaluate requirement
feasibility. If a requirement needs to be cut because it is not be feasible, understand
the impact on the project vision and scope

Necessary: Each requirement should document a capability that the

stakeholders really need or one that’s required for conformance to an
external system requirement or a standard.
Every requirement should originate from a source that has the authority to
specify requirements. Trace each requirement back to specific voice-of-the-
customer input, such as a use case, a business rule, or some other origin
of value.

2.2
For example, the client says: “I need an online store with a catalog of
products, an order form, a shopping cart, the ability to pay online,
information about the company, and contacts section”, while presenting an
image that has been formed in his or her mind. At the same time, the
developer can see the project 100% differently than the way the client sees
it. An SRS document helps develop a common vision of the project.

A software requirements specification is the basis for your entire project. It

lays the framework that every team involved in development will follow. It's
used to provide critical information to multiple teams — development,
quality assurance, operations, and maintenance.

To avoid disputes, frustration, unreasonable financial expenses, and loss of

time, take care to draw up software requirements specifications for your
future project. The requirements for the functionality of the project should
be consistently and systematically described in the SRS. A well-written
SRS document is the result of a detailed analysis of the market with the
help of the discovery phase. 

Below we will tell you how to write a software requirement specification

using the best methods.

3. Software Requirements Validation

3.1. Validation guarantees that
the necessities exhibit the perfect traits of brilliant requirement statements
(complete, accurate, possible, necessary, prioritized, unambiguous, and
verifiable) and of remarkable requirements specs (whole, steady,
modifiable, and traceable). Of path, you
could validate handiest necessities which have
been documented, not implicit necessities that
exist simplest in someone’s thoughts. this is why I propose honestly writing
down requirements info as opposed to relying on imperfect
human recollections.

Validation isn’t a single discrete section that

you perform after collecting and documenting all
the requirements. some validation activities, inclusive
of incremental critiques of the growing SRS, are threaded for the duration
of the iterative elicitation, analysis, and
specification techniques. different activities, such as formal SRS
inspection, offer a final first-class gate prior to baselining the SRS. consist
of necessities validation activities as discrete responsibilities on
your task plan.
3.2. As stated earlier, a use case describes a sequence of
interactions among a device and an outside actor
that consequences in some outcome that offers cost to the actor. An actor
is someone (or once in a while every other software program system or
a hardware device) that interacts with the machine to carry out a use
case. for example, the Chemical monitoring device’s “Request a Chemical”
use case includes an actor named Requester. there may be no
CTS person magnificence named Requester. each chemists
and members of the chemical stockroom group of workers might
also request chemical substances,
so members of either user elegance may additionally perform the
Requester role.

5. Requirment Modeling

Visual requirements models can help you identify missing, extraneous, and
inconsistent requirements. Given the limitations of human short-term
memory, analyzing a list of one thousand requirements for inconsistencies,
duplication, and extraneous requirements is nearly impossible. By the time
you reach the fifteenth requirement, you have likely forgotten the first few
that you read. You’re unlikely to find all of the errors simply by reviewing
the textual requirements. Visual requirements models described in this
book include:
■ Data flow diagrams (DFDs)
■ Process flow diagrams such as swimlane diagrams
■ State-transition diagrams (STDs) and state tables
■ Dialog maps
■ Decision tables and decision trees
■ Event-response tables
■ Feature trees (discussed in Chapter 5, “Establishing the business
requirements”)
 ■ Use case diagrams (discussed in Chapter 8, “Understanding user
requirements”)
■ Activity diagrams (also discussed in Chapter 8)
■ Entity-relationship diagrams (ERDs) (discussed in Chapter 13, “Specifying
data requirements”)

The notations presented here provide a common, industry-standard

language for project participants to use. Inventing your own modeling
notations presents more risk of misinterpretation than if you adopt
standard notations. These models are useful for elaborating and exploring
the requirements, as well as for designing software solutions. Whether you
are using them for analysis or for design depends on the timing and the
intent of the modeling.

A scenario is a very specific sequence of actions and responses that

detail how the system will interact with a user. It is useful for
pinpointing vague or missing requirements, and for verifying that the
system does what's expected. A complete system would have several top-
level scenarios, each showing a typical interaction with the system.

1. User logs on.

2. System displays welcome message and requests customer ID and
password.
3. User enters customer ID and password.
4. System validates the ID and password.
5. User searches for a title by browsing or keyword search
6. System displays information about the title.
7. User selects a title to buy
8. System adds title to the customer's shopping cart
9. [Repeat 5-8 until done]
10. User is done with shopping
11. System displays shopping cart, shipping address, and billing
address
12. User confirms order and payment method.
13. System processes order, notifies warehouse for shipping, and
issues an electronic receipt.
14. User logs off.

4.2