You are on page 1of 11

Documenting requirement

Mosab_2802
objectives

Define SRS document?


List the different names of the SRS?
List the audience relying on the SRS?
Discuss sequence number techniques to label each reqs?
Discuss user interface sketches and its relation to SRS and give examples?
Explain structure of SRS templates?
Define SRS document?
The SRS states the functions and capabilities that a
software system must provide, its
characteristics, and the constraints that it must respect. It
should describe as completely as
necessary the system’s behaviors under various
conditions, as well as desired system qualities such
as performance, security, and usability. The SRS is the
basis for subsequent project planning, design,
and coding, as well as the foundation for system testing
and user documentation
List the different names of the SRS?

● business requirements document (BRD),


● Functional specification
● product specification
● system specification
● requirements document.
List the audience relying on the SRS?

● Customers, the marketing department, and sales staff


● Project managers
● Software development teams
● Testers
● Maintenance and support staff
● Documentation writers
● Training personnel
● Legal staff
● Subcontractors
Discuss sequence number techniques to
label each reqs?

The simplest approach gives every requirement a unique sequence


number, such as UC-9 or
FR-26. Commercial requirements management tools assign such an
identifier when a user adds a
new requirement to the tool’s database. The prefix indicates the
requirement type, such as FR for
functional requirement. A number is not reused if a requirement is
deleted, so you don’t have to
worry about a reader confusing the original FR-26 with a new FR-26.
Discuss user interface sketches and its relation to SRS
and give examples?

● On the plus
side, exploring possible user interfaces with paper prototypes, working mock-ups, wireframes, or
simulation tools makes the requirements tangible to both users and developers.

● On the negative side, screen images and user interface architectures describe solutions and
might not truly be requirements. Including them in the SRS makes the document larger, and big
requirements documents frighten some people.

● Screen layouts don’t replace written user and functional requirements. Don’t expect developers
to deduce the underlying functionality and data relationships from screen shots. One Internet
development company repeatedly got in trouble because the team routinely went directly from
signing a contract with a client into an eight-hour visual design workshop.

● A sensible balance is to include conceptual images—I call them sketches, no matter how
nicely drawn they are—of selected displays in the requirements without demanding that the
implementation precisely follow those models.
Discuss user interface sketches and its
relation to SRS and give examples?

Every software development organization


should adopt one or more standard SRS
templates for
its projects. Various SRS templates are
available (for example: ISO/IEC/IEEE
2011; Robertson and
Robertson 2013). If your organization
tackles various kinds or sizes of projects,
such as new, large
system development as well as minor
enhancements to existing systems, adopt
an SRS template for
each major project class
Discuss user interface sketches and its relation to SRS
and give examples?

1.Introduction
The introduction presents an overview to help the reader understand how the SRS is organized and
how to use it.
2. Overall description
This section presents a high-level overview of the product and the environment in which it will be
used, the anticipated users, and known constraints, assumptions, and dependencies.
3. System features
The template in Figure 10-2 shows functional requirements organized by system feature, which is
just one possible way to arrange them. Other organizational options include arranging functional
requirements by functional area, process flow, use case, mode of operation, user class, stimulus, and
response.
4. Data requirements
Information systems provide value by manipulating data. Use this section of the template to describe
various aspects of the data that the system will consume as inputs, process in some fashion, or
create as outputs
5. External interface requirements
This section provides information to ensure that the system will communicate properly with users and
with external hardware or software elements.
Discuss user interface sketches and its relation to SRS
and give examples?

6. Quality attributes
This section specifies nonfunctional requirements other than constraints, which are recorded
in section 2.4, and external interface requirements, which appear in section 5.
7. Internationalization and localization requirements
Internationalization and localization requirements ensure that the product will be suitable for
use in nations, cultures, and geographic locations other than those in which it was created.
8. [Other requirements]
Define any other requirements that are not covered elsewhere in the SRS. Examples are
legal,
regulatory, or financial compliance and standards requirements; requirements for product
installation,
configuration, startup, and shutdown; and logging, monitoring, and audit trail requirements.
REFRENCES

● Software Requirements, Third Edition /Karl Wiegers Joy Beatty

You might also like