IEEE Std 830-1998
- •
def
- •
IEEE Recommended Practice for Software Requirements Specifications
- •
descrbes the content and qualities of a good software requirements specification (SRS) and presents several sample SRS outlines
- •
a product-oriented standard — the "product" being an SRS document
- •
sponsored by the Software Engineering Standards Committee of the IEEE Computer Society; approved 25 June 1998
- •
a revision of IEEE Std 830-1993
- •
- •
- •
key definitions
- •
contract — a legally binding document agreed upon by customer and supplier; includes technical and organizational requirements, cost, and schedule; may also contain informal commitments and expectations
- •
customer — the person(s) who pay for the product and usually decide the requirements; customer and supplier may be from the same organization
- •
supplier — the person(s) who produce a product for a customer
- •
user — the person(s) who operate or interact directly with the product; often not the same as the customer
- •
- •
benefits of a good SRS
- •
establishes the basis for agreement between customer and supplier on what the software must do
- •
reduces development effort — forces rigorous consideration of all requirements before design begins; reveals omissions, misunderstandings, and inconsistencies early when they are cheapest to fix
- •
provides a basis for estimating costs and schedules
- •
provides a baseline for validation and verification; allows development of V&V plans
- •
facilitates transfer — makes it easier to transfer software to new users, machines, or parts of an organization
- •
serves as a basis for later enhancement of the finished product
- •
- •
nature of the SRS — what it should address
- •
functionality — what is the software supposed to do?
- •
external interfaces — how does the software interact with people, hardware, and other software?
- •
performance — speed, availability, response time, recovery time of various software functions
- •
attributes — portability, correctness, maintainability, security, etc.
- •
design constraints — required standards in effect, implementation language, resource limits, operating environment
- •
- •
what the SRS should NOT contain
- •
design or implementation details — these belong in the design stage
- •
design items such as: partitioning software into modules, allocating functions to modules, describing information or control flow between modules, choosing data structures
- •
project requirements (cost, delivery schedules, reporting procedures, software development methods, QA, V&V criteria, acceptance procedures) — these belong in a software development plan, SQA plan, or statement of work
- •
note — a properly written SRS limits the range of valid designs, but does not specify any particular design
- •
- •
8 characteristics of a good SRS (Clause 4.3)
- •
- Correct — every requirement stated must be one that the software shall meet; no tool can ensure this; compare with superior specifications and confirm with customer
- •
- Unambiguous — every requirement has only one interpretation; each characteristic described using a single unique term; ambiguous terms defined in a glossary
- •
natural language pitfalls — natural language is inherently ambiguous; requires independent review
- •
requirements specification languages — avoids ambiguity through formal syntax; disadvantage: long learning curve, unintelligible to non-technical users
- •
representation tools — object-oriented, process-based, or behavioral approaches; always retain natural language alongside notations
- •
- Complete — includes all significant requirements (functionality, performance, design constraints, attributes, external interfaces); defines responses to all realizable input classes including invalid inputs; full labels and references to all figures, tables, and diagrams
- •
use of TBDs — "to be determined" makes an SRS incomplete; must be accompanied by: description of conditions causing the TBD, who is responsible for resolution, and the deadline for resolution
- •
- Consistent — no subset of individual requirements conflict with each other
- •
types of likely conflict — (a) conflicting characteristics of real-world objects (e.g., one requirement says output format is tabular, another says textual); (b) logical or temporal conflict between actions (e.g., one says "A must follow B," another says "A and B occur simultaneously"); (c) same real-world object described using different terms in different requirements (promotes inconsistency)
- •
- Ranked for importance and/or stability — each requirement has an identifier to indicate importance or stability
- •
degree of stability — expressed as number of expected changes based on experience or knowledge of forthcoming events
- •
degree of necessity — essential (software unacceptable without it), conditional (enhances but not critical if absent), optional (may or may not be worthwhile; gives supplier opportunity to propose something that exceeds the SRS)
- •
- Verifiable — every requirement is verifiable; a finite, cost-effective process exists to check that the software meets it; any ambiguous requirement is generally not verifiable
- •
non-verifiable examples — "works well," "good human interface," "shall usually happen" — terms like "good," "well," "usually" cannot be defined objectively
- •
verifiable example — "Output of the program shall be produced within 20s of event X 60% of the time; and shall be produced within 30s of event X 100% of the time"
- •
if no method can verify a requirement, it should be removed or revised
- •
- Modifiable — structure and style allow any changes to be made easily, completely, and consistently
- •
- Traceable — origin of each requirement is clear; each requirement can be referenced in future development or enhancement documentation
- •
- •
joint preparation of the SRS
- •
SRS should be jointly prepared by customer and supplier
- •
customers usually don't understand software design and development well enough to write a usable SRS alone
- •
suppliers usually don't understand the customer's problem and domain well enough to specify requirements for a satisfactory system alone
- •
therefore, customer and supplier must collaborate to produce a well-written and completely understood SRS
- •
- •
SRS evolution
- •
the SRS may need to evolve as development progresses; it is impossible to specify all details at project initiation
- •
requirements should be specified as completely and thoroughly as known at the time, with notes on what is incomplete
- •
a formal change process should be initiated to identify, control, track, and report changes
- •
approved changes should provide an accurate audit trail and permit review of current and superseded portions
- •
- •
prototyping
- •
prototypes are useful because
- •
customers are more likely to react to a prototype than to read an SRS — provides quick, actionable feedback
- •
prototypes reveal unanticipated aspects of system behavior and generate new questions — helps reach closure on the SRS
- •
an SRS based on a prototype tends to undergo less change during development, shortening development time
- •
- •
prototypes should be used as a way to elicit software requirements, not replace the SRS
- •
- •
parts of an SRS (Clause 5)
- •
Section 1 — Introduction
- •
1.1 Purpose — delineate the purpose of the SRS; specify intended audience
- •
1.2 Scope — identify software product name(s); explain what the software will and will not do; describe application, benefits, objectives, and goals; be consistent with higher-level specifications
- •
1.3 Definitions, acronyms, and abbreviations — all terms needed to properly interpret the SRS
- •
1.4 References — complete list of all referenced documents with title, report number, date, and publishing organization
- •
1.5 Overview — describe what the rest of the SRS contains and how it is organized
- •
- •
Section 2 — Overall Description (background context; does NOT state specific requirements)
- •
- •
2.2 Product functions — summary of the major functions the software will perform
- •
2.3 User characteristics — general characteristics of intended users: educational level, experience, technical expertise; explains why certain requirements are later specified
- •
2.4 Constraints — items limiting developer options: regulatory policies, hardware limitations, interfaces to other applications, parallel operation, audit functions, reliability requirements, safety and security considerations
- •
2.5 Assumptions and dependencies — factors that affect the stated requirements and may change them (e.g., assumed availability of a specific OS)
- •
2.6 Apportioning of requirements — requirements that may be delayed until future versions of the system
- •
Section 3 — Specific Requirements (main body; all requirements in detail sufficient to enable design and testing)
- •
every stated requirement should be externally perceivable by users, operators, or other external systems
- •
all requirements should be uniquely identifiable
- •
3.1 External interfaces — detailed description of all inputs and outputs, complementing Section 2 descriptions; includes name, purpose, source/destination, valid range/accuracy/tolerance, units, timing, formats, command formats
- •
3.2 Functions — fundamental actions the software must perform; written as "The system shall…" statements; includes validity checks, exact sequence of operations, error handling, input/output relationships and formulas
- •
3.3 Performance requirements — static (number of terminals, simultaneous users, data volume) and dynamic (transactions per time period) numerical requirements; all stated in measurable terms (e.g., "95% of transactions shall be processed in less than 1s")
- •
3.4 Logical database requirements — types of information, frequency of use, data entities and relationships, integrity constraints, data retention requirements
- •
3.5 Design constraints — constraints imposed by other standards or hardware; includes standards compliance (report format, data naming, accounting procedures, audit tracing)
- •
3.6 Software system attributes (quality attributes)
- •
reliability — factors required to establish required reliability at time of delivery
- •
availability — factors to guarantee a defined availability level (checkpoint, recovery, restart)
- •
security — factors protecting software from accidental or malicious access, use, modification, destruction, or disclosure; may specify cryptographic techniques, log data sets, function separation, data integrity checks
- •
maintainability — attributes relating to ease of maintenance; modularity, interfaces, complexity
- •
portability — attributes relating to ease of porting to other machines or OS; percentage of host-dependent code, use of portable language or standard compiler
- •
- •
- •
- •
organizing Section 3 — 8 approaches (Annex A templates)
- •
by system mode — different sets of functions depending on operating mode (e.g., training, normal, emergency)
- •
by user class — different sets of functions for different types of users (e.g., passenger, maintenance worker, fire fighter)
- •
by object — organized around real-world entities (e.g., patient, sensor, nurse); each object has attributes and functions/services
- •
by feature — externally desired services requiring a sequence of inputs; each feature described as stimulus-response pairs
- •
by stimulus — functions organized around types of inputs or triggers (e.g., loss of power, wind shear)
- •
by response — functions organized around types of outputs or results generated
- •
by functional hierarchy — hierarchies of functions organized by common inputs, common outputs, or common internal data; uses data flow diagrams and data dictionaries
- •
multiple organizations — combining two or more of the above (e.g., organizing by user class then by feature within each class)
- •
- •
supporting information
- •
table of contents and index — essential for navigability and cross-referencing
- •
appendixes — sample I/O formats, cost analysis studies, user survey results, background information, problem descriptions, packaging instructions; SRS should explicitly state whether appendixes are part of the requirements
- •
- •
compliance with IEEE/EIA 12207.1-1997
- •
IEEE Std 830-1998 maps to the Software Requirements Description (SRD) in IEEE/EIA 12207.1-1997
- •
terminology difference — IEEE uses "customer" where 12207 uses "acquirer"; IEEE uses "user" where 12207 uses "operator"
- •
an SRS complying with IEEE Std 830-1998 plus the additions shown in Annex B also complies with IEEE/EIA 12207.1-1997 SRD requirements
- •
- •