Requirement Document Overview

Writing Requirement Document

• A Writing Requirement Document (WRD) is a document that outlines the requirements for a writing project.

Types of Requirements

• User Requirements: Natural language statements and diagrams describing what services the system should provide and operational constraints.

• System Requirements: Detailed specifications of system functions, services, and operational constraints. A functional specification document, precise and defining what should be implemented.

• Software Specification: Detailed software description to serve as a basis for design and implementation, intended for developers.

Requirement Readers

• User requirements: Client managers, system end-users, client engineers, contractor managers, system architects.

• System Requirements: System end-users, clients engineers, system architects and software developers.

• Software specification: Client engineers(perhaps), system architects, and software developers.

Software Requirements Specifications (SRS) Document

• The SRS document is the output of requirements analysis.

• It should be consistent, unambiguous, complete, and correct.

• It's not a design document, but describes what the system should do, not how.

• It should only contain functional and non-functional requirements.

• It doesn't suggest or detail solutions, focusing only on understanding developers and customer needs.

Problems Without SRS Document

• Without an SRS, the system implementation may not meet customer needs.
• Developers may not understand the exact requirements of the customer.
• Maintenance engineers face difficulty understanding the system's functionality without the SRS document.
• User manuals become difficult to write correctly without an SRS document.

Goals of SRS Document

• Feedback to Customers: Ensures developers understand the problems to be solved; the SRS should be written in natural language, using data flow diagrams, charts and decision tables.

• Problem Decomposition: Breaks down the problem into components, defining boundaries, solidifying ideas and helping break the problem into manageable parts.

• Input to Design Specification: Serves as a guide to subsequent documents like Software Design Specification and Statement of Work; the SRS should contain details on the functional system requirements.

• Production Validation Check: Facilitates testing and validation strategies, serving as the parent document.

Who Writes SRS Documents

• Typically, system architects and programmers write SRS documents.
• The requirements gathering team (including programmers, product marketers, system analysis/architects, and project managers) contribute to the creation of the SRS document.

Properties of a Good SRS Document

• Concise and Structured: Should be easy to understand and modify, using a clear and well-organized structure.

• Black-box View: Focuses on what the system should do, not how, avoiding implementation details and specifics.

• Conceptual integrity: Supports a reader's ease of comprehension about the system.

• Responses to undesired events: Addresses reactions to error conditions and unforeseen circumstances.

• Verifiable: All requirements are verifiable so it can be determined if the requirements were met.

Parts of SRS Document

• Functional Requirements
• Non-Functional Requirements
• Goals of Implementation

IEEE Std 830-1998

• IEEE Recommended Practice for Software Requirements Specifications.
• Provides guidelines for creating SRS documents, covering key aspects.

SRS Table of Contents Example

Uses of SRS

• Project Management: Used by project managers for planning and resource allocation.

• Development: Used by developers to design, build, test the products.

• Testing: Used by testing groups to create the test plan, and run tests.

• Maintenance and Support: Helps maintenance and support staff understand system functionalities.

• Documentation: Used for customer manuals' content creation.

• Customers: Provides customers with expectations of the end product.

• Training: Used for training materials production.

SRS Validation

• Errors: Critical to identify and fix errors in the SRS document as early as possible to avoid issues in later development phases

• Omission: Errors may occur in case some requirements are not included.

• Inconsistency: May exist when user requirements clash with each other.

• Incorrect Facts: Need to identify incorrect facts in the document.

• Ambiguity: Ensuring requirements have clear and proper meanings.

Approaches to Requirement Representation

• Informal (natural language): 60% of respondents use this method.
• Formal: UML, class diagrams, sequence diagrams, Z, VDM, etc. are often used.
• Semi-Formal: Using a mix of formal and informal techniques.

Requirement Format

• Clear, concise and consistent: Form specifications are: -The [noun phrase] shall (not) [verb phrase]
• Identification: Important for tracking requirements with hierarchical numbering.
• Measurable constraints: Adding measurable constraints (e.g. time limits) enhances performance requirements.
• Command words: Use "shall" (for obligations/commands) and avoid ambiguous words like "should," "might," avoiding excessive detail on how to implement.

Shall or Shall Not?

• Using positive language ("shall") is preferred over negative ("shall not") in requirement statements.

Avoiding Imprecision in Requirements

• Use precise language: Replace vague words like "countless," "some," "approximately" with measured quantities.

Anatomy of a Good User Requirement

• Clear definition of system & the desired end result.
• Verb with correct identifier (shall or may).
• Positive end result.
• Quality criteria, measurable.

Example of a Bad User Requirement

• Incorrect identifier.
• Ambiguous and vague.
• Focuses on implementation details over the 'what'.

Standard of Writing a Requirement

• Characteristics: Feasible (realistic), Needed (necessary), Testable (measurable), Clarity, Unambiguity, Precision, and Prioritization with an ID. These characteristics are mandatory in some cases and are good for improving communication.

Writing Pitfalls to Avoid

• Avoid describing "how" something is achieved. focus on "what".
  • System design should not be done too early, potentially increasing costs.
  • Avoid mixing different levels (system, user, subsystems).
• Avoid overly technical terminology.
• Avoid vague indefinite terms (e.g., "user-friendly").
• Avoid multiple requirements in one sentence; it is critical to formulate requirements in a single sentence.
• Avoid adding suggestions or possibilities.
• Avoid wishful thinking (e.g., "fully upgradeable").

Data Flow Diagram (DFD)

• A graphical representation that illustrates the flow of information within a system.

• Clarifies system requirements and major transformations.

Symbols in DFDs

• The graphical elements used in Data Flow Diagrams: -Function: A circle / oval -File/Database: A set of horizontal lines -Input/Output: A rectangle -Flow: An arrow

Data Dictionary

• A catalog of all elements in a system.
• Represents the details of information, complementing the DFD flow diagram.
• Includes information like item name, aliases, descriptions, related items, ranges of values, and data structure definitions.

Entity Relationship (ER) Diagram

• A detailed, logical representation of data.

• Important components: -Data Entities -Entities relationships -Entities Attributes

Decision Table

• Used to express complex conditions and associated actions logically.

• Structures complex logic in a readable and systematic way.

• Contains 4 parts:

• Condition stub: conditions (inputs)

• Condition rules: combinations of conditions

• Action stub: actions (outputs)

• Action Rules: actions related to conditions and rules.