Appendices
305
Appendix B
Essential Software Requirements Specifications (SRS)
Following are three examples of Essential SRS. The IEEE guideline
830 discussed in Chapter 6 Section 5 is the foundation for the
SRS.
Example 1: Essential SRS—Descriptive
System OverviewA.
This section should contain a brief description of what the soft-
ware system will do. It is intended as an introduction and should
be informal and concise.
Technical RequirementsB.
This section should describe the operational parameters of the
software product. It should contain information (if applicable to
the product) such as:
Functional requirements (this part could be done with use i.
cases)
Nonfunctional requirements such as performance and other ii.
constraints
User-interface specificationiii.
91998_APPX_Tsui.indd 305 1/11/13 8:45:51 AM
User task flowiv.
Input/output and other data specificationsv.
Interface specifications to other systemsvi.
Acceptance Criteria/Interaction ScenariosC.
This section should define the functionality the software must implement.
It can include interaction scenarios. The scenarios consist of the user inputs
and system responses. The low-fidelity prototypes are included. The type of
questions that should be asked include:
How-to: Questions ask how some action is performed.i.
Who: Questions ask who is responsible for a task.ii.
What-kind-of: Questions request further refinements of some con-iii.
cepts.
When: Questions ask about timing constraints.iv.
Relationship: Questions ask how one requirement is related to another.v.
What-if: Questions ask about cases in which an action could go wrong vi.
or its preconditions.
Follow-on: Questions stem from other pending questions.vii.
Validation/VerificationD.
This section will describe requirements for the system validation/verification.
The requirements and scenarios should help in this process. Validation will
determine whether the software satisfies the customer needs as were speci-
fied in the requirements and the scenarios. Verification will determine if the
software is functionally correct.
Requirements ConsiderationsE.
This section should contain the following:
Assumption made about the software.i.
End users: Describe each type of user.ii.
Existing systems: State any existing system and/or other related enti-iii.
ties.
Environment: State the environment in which the system will operate.iv.
Limitations: State what the system will not do.v.
Rationale: Describes how the requirements meet or exceed the needs vi.
of the customer.
Other InformationF.
Any pertinent information can be added to this document.
306 Appendices
91998_APPX_Tsui.indd 306 1/11/13 8:45:51 AM
Example 2: Essential SRS—Object Oriented
Initial Requirement Modeling 1.0
1.1. Usage model
1.2. Initial domain model
1.3. Initial user-interface model: Develop screen sketches or a user-interface
prototype
1.4. References
Modeling Requirements 2.0
2.1 System environment
2.2 Major usage requirements specification: Explore how users will work
with the system. Contains a collection of use cases on a Rational Unified
Process (RUP) project, a collection of features for a Feature Driven
Development (FDD) project, or a collection of user stories for an Extreme
Programming (XP) project.
2.2.1 XXXX Use case
Use case: Search XXXX
Preconditions; Postconditions; Actions
2.2.2 YYYY Use case
Use case: Submit YYYY
2.2.3 ZZZZ Use case
Use case: Update ZZZZ
Use case: Receive ZZZZ
Use case: Assign ZZZZ
Use case: Receive review
2.3 User characteristics
2.4 Nonfunctional requirements
Requirements Specification 3.0
3.1 External interface requirements
3.2 Functional requirements such as:
3.2.1 Search
3.2.2 Communicate
3.2.3 Add
3.2.4 Modify
3.2.5 Update
3.2.6 Status
3.2.7 Report
3.2.8 Assign
Appendices 307
91998_APPX_Tsui.indd 307 1/11/13 8:45:51 AM
3.2.9 Check
3.2.10 Set up
3.2.11 Publish
3.2.12 Remove
3.3 Detailed Nonfunctional requirements
3.3.1 Logical structure of the data
3.3.2 Security
3.3.3 Performance
3.3.5 Usability
Example 3: Essential SRS—IEEE Standard
1 Introduction
1.1 SRS purpose
1.2 Product scope
1.3 Intended audience
1.4 Definitions, acronyms, and abbreviations
1.5 Document conventions
1.6 References and acknowledgments
2 Overall Description
2.1 Product perspective
2.2 Product functionality
2.3 Users and characteristics
2.4 Operating environment
2.5 Design and implementation constraints
2.6 User documentation
2.7 Assumptions and dependencies
3 Specific Requirements
3.1 External interface requirements
3.2 Functional requirements
3.3 Behavior requirements
4 Other Nonfunctional requirements
4.1 Performance requirements
4.2 Safety and security requirements
4.3 Software quality attributes
5 Other Requirements
5.1 Data dictionary requirements
308 Appendices
91998_APPX_Tsui.indd 308 1/11/13 8:45:51 AM
Example 4: Essential SRS—Narrative Approach
A. Introduction
Contains an overview of the software development project and the planned new prod-
uct or upgrade. For upgrades, this section may be condensed to focus on the purpose
and objectives of the upgrade. For new software, this section typically includes:
i. Purpose and objectives: Describes the main objectives of the SRS.
ii. Software product overview: For both new software and upgrades, lists the most
important features and functional capabilities of the planned software. For a
software upgrade, lists the principal objectives of the upgrade, and the added
features and capabilities to be implemented.
iii. Business and financial objectives: For software with commercial potential out-
side the company, includes the key business objectives that customers expect
the software to address, and financial objectives such as market share, unit
shipments, and revenues.
B. Description of the Problem
For new software, describes why the software is needed, and identifies important unre-
solved questions. For software upgrades, this section may be condensed to focus on
open issues and questions.
i. Why software is needed: Gives reasons in terms of both management and user
needs.
Describes the existing current work practices used by customers, including alterna-
tive software products or manual processes.
Explains from a management per-
spective the benefits to be provided by the software, such as how it will solve
or improve a business problem. Examples:
a. Reducing inventory levels
b. Reducing time to process and ship an order
c. Achieving competitive advantage
d. Improving customer satisfaction
This section also explains from a user perspective how the software will improve
existing business processes such as data entry, report generation, decision making,
calculations, and usability issues.
ii. Open issues and questions: Lists the customer workflow processes, technol-
ogy, financial issues, and business concerns that must be addressed before the
software upgrade can be successfully developed and used.
C. Description of Software Solution
Summarizes the proposed software product: its capabilities and attributes. For both new
software and upgrades, this section typically includes:
i. Enhancement requests: Lists and prioritizes requests received regarding soft-
ware capabilities and features, such as from management, client, end users, or
user groups. These needs have been collected through meetings, interviews,
and other means.
Appendices 309
91998_APPX_Tsui.indd 309 1/11/13 8:45:51 AM
ii. Features and functional capabilities: Often presented as a table listing and pri-
oritizing features and their descriptions, with sufficient detail that developers
will easily understand how the software must work.
iii. Software attributes and general considerations: Lists items other than features
or functionality. Examples here are the need to interface with certain other
software, and the software or hardware platforms to be supported.
iv. Operational requirements: Lists other requirements that the software will meet
as it is used. Examples are business or decision rules, user workflows, usability
attributes, installation requirements, or required training for users.
v. Standards and regulatory considerations: Names any applicable standards that
the software will meet. Industry examples include EPA, IEEE, NRC, ASTM, ANSI,
and ISO. Company-specific examples include forms, work procedures, or data
formats.
vi. Long-term plans for future releases and features: Includes items such as future
customer needs and desires, and accommodation of future hardware or soft-
ware platforms.
vii. Maintenance and support costs: Describes plans for items such as customiza-
tion, patch releases, and ongoing support for users.
310 Appendices
91998_APPX_Tsui.indd 310 1/11/13 8:45:51 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.