Академический Документы
Профессиональный Документы
Культура Документы
SRS
REQUIREMENT
A condition or a capability to
which the system must conform
Software Requirement
Specification
Requirement analysis is the first step in
software engineering process
Software scope refined into a concrete
specification
Foundation for all future activities
Requirements management
Documenting requirements
Documenting changes
Controlling changes in the baseline
Project plans current with requirements
Version control
Tracking status of requirements in
baseline
5
Requirements Management
Procedures
Version control of requirements
specification
Change control
Requirements trace ability
Role of SRS
Bridge the communication gap between
the client, the user and the developer
Help clients to understand their own needs
The SRS must correctly define all of the
software requirements but no more
The SRS should not describe any design,
verification or project management details
except design constraints
7
Complete
Consistent
Correct
Modifiable
Ranked
Testable
Traceable
Unambiguous
Valid
Usable during operation and maintenance phase
8
Complete
A complete requirements specification
must precisely define all the real world
situations that will be encountered and the
capability's responses to them
Consistent
A consistent specification is one where
there is no conflict between individual
requirement statements that define the
behavior of essential capabilities and
specified behavioral properties and
constraints do not have an adverse impact
on that behavior
10
Correct
For a requirements specification to be
correct it must accurately and precisely
identify the individual conditions and
limitations of all situations that the desired
capability will encounter and it must also
define the capability's proper response to
those situations
11
Modifiable
In order for requirements specifications be
modifiable related concerns must be
grouped together and unrelated concerns
must be separated
12
Ranked
Ranking specification statements
according to stability and/or importance is
established in the requirements
document's organization and structure
13
Testable
In order for a requirement specification to
be testable it must be stated in such as
manner that pass/fail or quantitative
assessment criteria can be derived from
the specification itself and/or referenced
information
14
Traceable
Each requirement stated within the SRS
document must be uniquely identified to
achieve traceability
15
Unambiguous
A statement of a requirement is
unambiguous if it can only be interpreted
one way
16
Valid
To validate a requirements specification all
the project participants, managers,
engineers and customer representatives,
must be able to understand, analyze and
accept or approve it
17
Software requirements
specification (IEEE 830)
The SRS is a specification for a particular
software product program or set of
programs that does certain things.
The SRS is a means of translating the
ideas in the minds of the client (the input)
into a formal document (the output) pf the
requirements phase
18
Performance
Requirements
Software Requirements
Specification document
Design
Constraints
External
Interfaces
19
Introduction
Purpose
Scope
References
Overview
General description
Product perspective
Product functions
User characteristics
General constraints
20
SPECIFIC REQUIREMENTS
Functional requirements
Functional requirements 1
Introduction
Inputs
Processing
Outputs
Functional requirements 2
Functional requirements 3
Functional requirement 4
User Interface
Hardware Interface
Software interfaces
Communication interface
21
SPECIFIC REQUIREMENTS
Performance requirements
Design constraints
Attributes
Standard compliance
Hardware limitations
Security
Maintainability
.
Other Requirements
Database
Operation
Site adaptation
Appendix
Glossary
22
Functional requirements
Introduction
Inputs
Processing
Outputs
23
Sources of inputs
Quantity
Units of measurement
Timing
Ranges of valid inputs to include accuracy
and tolerances
24
25
Performance Requirements
Static Performance Requirements
Design Constraints
Standard Compliance
Report Format
Data naming conventions.
Accounting procedures.
Audit tracing
28
Hardware Limitations
Hardware configuration characteristic (no
of ports, instruction sets. etc)
Limits on primary and secondary memory.
29
Attributes
Availability
Security
Restrictions on use of certain commands.
Control access to data
Provide different kinds of access requirements for different
people.
Require the use of pass words cryptography
Keep specific log or history data sets
Maintainability
Transferability / Conversion (from one environment to another)
30
Hardware Interfaces
Logical characteristics of each interface
between software product and the
hardware components of the system.
Devices supported and protocols.
31
Software Interfaces
Details of required software products to be
used i.e data management system and
operating systems and other applications.
Purpose of interfacing software.
Define in terms of message content and
format
32