2.6 - Structure of a RASD document

---

The Requirements Analysis and Specification Document (RASD) serves multiple essential functions within the software development lifecycle. First and foremost, it articulates a comprehensive understanding of the system requirements, effectively bridging the gap between stakeholders and the development team. The document not only delineates the application domain—providing context for the software project—but also outlines the specifics of the system to be developed. This dual focus ensures that all parties have a clear grasp of both the operational environment and the functional needs of the system.

Moreover, the RASD often holds a contractual status, meaning it can be legally binding. This aspect emphasizes the need for precision and clarity in the document, as it can have significant legal implications should disputes arise regarding project deliverables. Additionally, the RASD acts as a foundational reference point for various project activities, including project planning and estimation. By detailing the scope of the requirements, it assists project managers in estimating size, cost, and schedule, which are crucial for resource allocation and timeline management.

The document also plays a vital role in software verification and validation (V&V) processes. It should encompass sufficient detail to facilitate rigorous system testing, verification, and validation activities, ensuring that the final product meets the specified requirements. This alignment between requirements and the delivered system is critical for stakeholder satisfaction. Lastly, the RASD provides a framework for change control, recognizing that requirements may evolve as the project progresses. By documenting requirements changes, the RASD helps manage software evolution systematically and transparently.

Audience of the RASD

The RASD is crafted with a diverse audience in mind, each with distinct interests and needs regarding the software project. Customers and users are typically most concerned with validating the overall system goals and understanding the high-level functionalities described in the document. They are usually less interested in the intricate details of software requirements, focusing instead on how the system will fulfill their needs and expectations.

Systems analysts and requirements analysts are another critical audience. They are responsible for creating various specifications that interrelate with the RASD, ensuring coherence across different systems and project phases. Their expertise helps in identifying dependencies and interactions among system components, which is crucial for holistic system design.

Developers and programmers are the next group directly impacted by the RASD, as they are tasked with implementing the documented requirements into functional software. Their understanding of the requirements is paramount to ensure that the end product aligns with stakeholder expectations.

Quality assurance teams are also significant stakeholders in the RASD process. Their role involves verifying that the documented requirements have been adequately met during the development process. They ensure that quality standards are maintained and that the system performs as intended.

Lastly, project managers utilize the RASD to measure and control the various processes involved in analysis and development. Their oversight ensures that the project remains on track, both in terms of timeline and budget, while facilitating effective communication among team members and stakeholders.

IEEE Standard for RASD

Section	Subsection	Description
1. Introduction	1.1 Purpose	Reasons motivating the existence of the product
	1.2 Scope	Identifies the product and application domain
	1.3 Product overview
	1.3.1 Product perspective	Defines system’s relationship to other products. Describes external interfaces: system, user, hardware, software
	1.3.2 Product functions	Summary of major functions
	1.3.3 User characteristics	General characteristics of the intended groups of users, including those that may influence usability (e.g., disabilities, expertise)
	1.3.4 Limitations	Anything that will limit the developer’s options (e.g., regulations, reliability, criticality, hardware limitations, interfaces, etc.)
	1.4 Definitions
2. References
3. Requirements		All the requirements go in here (i.e., this is the body of the document); the standard provides different strategies for the organization
	3.1 Functions
	3.2 Performance requirements
	3.3 Usability requirements
	3.4 Interface requirements
	3.5 Logical database requirements
	3.6 Design constraints
	3.7 Software system attributes
	3.8 Supporting information
4. Verification		Verification methods planned to qualify the software
5. Appendices	5.1 Assumptions and dependencies	Factors not under the control of the software that may affect requirements
	5.2 Acronyms and abbreviations

Section 3 — Requirements

3.1 Functions (Functional Requirements)

Functional requirements describe the essential actions and behaviors that the software must exhibit in response to specific inputs, facilitating the generation of appropriate outputs. These requirements are critical for ensuring that the system meets its intended purpose and provides the necessary functionality to users. Key elements of functional requirements include:

• Validity Checks: Mechanisms to ensure that input data is accurate and acceptable before processing. This may involve validation rules to prevent errors during operations.
• Sequence of Operations: The defined order in which operations must be performed to achieve desired outcomes. This is crucial for processes that require specific workflows.
• Responses to Abnormal Situations: Strategies for handling unexpected events, such as overflow errors, system failures, and other error-handling protocols. Ensuring robustness in the face of errors is vital for maintaining system integrity.
• Effect of Configuration Parameters: How varying configuration settings influence the behavior and performance of the system. These parameters may affect usability and system responsiveness.
• Input/Output Relationships: Clarification of how different inputs relate to specific outputs, including any transformations or processes involved.

Functional requirements can be organized based on various criteria, such as user class, feature set, or operational mode. This organization allows for clear communication of requirements and can be structured hierarchically, enabling complex requirements to be broken down into sub-requirements for easier management and tracking.

Example

For example, the hierarchy might look like this:

• User Class 1 (e.g., Administrator)
  • Requirement 1: The system shall allow administrators to manage user accounts.
    • Sub-requirement 1.1: Administrators shall be able to create new user accounts.
    • Sub-requirement 1.2: Administrators shall be able to delete user accounts.
• User Class 2 (e.g., Regular User)
  • Requirement 2: The system shall allow users to access their profiles.
    • Sub-requirement 2.1: Users shall be able to view their account details.
    • Sub-requirement 2.2: Users shall be able to update their personal information.

The closure property principle applies here, where the fulfillment of lower-level requirements guarantees the satisfaction of higher-level requirements. This hierarchical structure facilitates traceability and helps ensure that all aspects of user needs are addressed systematically.

3.2 Performance Requirements

Performance requirements specify the quantitative metrics that the system must meet regarding speed, responsiveness, resource consumption, and throughput. These requirements are essential for ensuring that the software performs efficiently under expected load conditions. Key areas to consider include:

• Response Times: Maximum acceptable time for the system to respond to user inputs or requests.
• Throughput: The number of transactions or operations the system can handle within a given timeframe.
• Resource Utilization: Constraints on CPU, memory, and bandwidth usage, ensuring that the system operates within acceptable limits.

3.3 Usability Requirements

Usability requirements focus on the user experience, ensuring that the software is intuitive, accessible, and user-friendly. These requirements are critical for ensuring that users can interact with the system effectively and efficiently. Considerations include:

• Ease of Use: The simplicity with which users can navigate the system and perform tasks.
• Accessibility: Features that enable users with disabilities to interact with the software effectively.
• User Documentation: Availability of help resources, tutorials, and manuals to support users in understanding and using the system.

3.4 Interface Requirements

Interface requirements define how the system interacts with external entities, including users, other systems, and hardware components. This section specifies the characteristics of user interfaces, APIs, and data exchange formats, ensuring compatibility and seamless integration.

3.5 Logical Database Requirements

This section outlines the requirements for data management, including data storage, structure, integrity, and security. Key elements may include:

• Database Schema: Description of data organization, including tables, fields, and relationships.
• Data Integrity Constraints: Rules ensuring data accuracy and consistency.
• Backup and Recovery Procedures: Strategies for data preservation and restoration in case of failures.

3.6 Design Constraints

Design constraints outline limitations imposed on the development process. These may stem from:

• Domain-Specific Standards: Regulatory and compliance requirements specific to the industry in which the software operates.
• Project Limitations: Constraints specified in earlier sections, including budgetary, technological, or time limitations that may influence design decisions.

3.7 Software System Attributes

This section describes the essential quality attributes that the software must exhibit at a system level. Important attributes include:

• Reliability: The expected reliability level of the system upon delivery, including metrics for fault tolerance and recovery.
• Availability: The required uptime and accessibility of the system, which may be critical for users relying on continuous service.
• Maintainability: The ease with which the software can be updated and modified to address issues or incorporate enhancements.

3.8 Supporting Information

Supporting information provides additional context and resources that enhance understanding of the requirements. This may include:

• Sample Input/Output Formats: Examples of expected data formats for inputs and outputs, facilitating clarity for developers and testers.
• Background Information: Contextual details about the problem domain, target audience, or market considerations that inform requirements.
• Problem Descriptions: Detailed descriptions of the specific problems the software aims to solve, ensuring that requirements are grounded in real user needs.

Target Qualities for a RASD

Creating a high-quality RASD necessitates adherence to several target qualities that ensure the document is effective, precise, and useful throughout the software development lifecycle. These qualities help in aligning stakeholder expectations, facilitating communication, and guiding development teams. Below is a detailed exploration of the target qualities for a RASD.

• Completeness ensures that all necessary requirements are covered to satisfy the intended goals within the specified domain. This encompasses several aspects:
• With respect to goals: All relevant goals must be correctly identified and articulated, including quality goals such as performance, security, and usability. The relationship can be denoted as , where the symbol means “model”. It’s essential to ensure that all potential behaviors, including incidental and malicious scenarios, are anticipated.
• With respect to inputs: The required behavior must be defined for all conceivable types of inputs, ensuring that the system is robust and handles edge cases effectively.
• With respect to structure: The document should be free of “to-be-determined” (TBD) elements, ensuring that every requirement is fully articulated and understood at the time of documentation.
• Precision is vital for ensuring that each requirement is detailed enough to facilitate software design, development, and verification. This means requirements should specify exactly what the system is expected to accomplish, reducing ambiguity that could lead to misunderstandings or misinterpretations during development.
• Pertinence refers to the relevance of each requirement and domain assumption in fulfilling a specific goal. This includes ensuring that:
  • Every goal articulated is genuinely needed by stakeholders, reflecting their needs and priorities.
  • The RASD does not contain irrelevant items that do not contribute to the definition of requirements, such as design choices or implementation strategies.
• Consistency is crucial to prevent contradictions within the document. There should be no conflicting formulations of goals, requirements, or assumptions, ensuring a unified direction for the development team. This coherence helps maintain clarity and supports effective communication among stakeholders.
• Unambiguity encompasses several aspects to ensure clarity:
  • Vocabulary: All terms used in the document must be clearly defined and consistently applied to prevent misunderstandings.
  • Assertions: Goals, requirements, and assumptions must be clearly articulated in a manner that precludes varying interpretations.
  • Responsibilities: It should be explicit where responsibilities lie between the software and its operational environment, clarifying what is expected from the system versus external entities.
  • Verifiability: There must be established processes for testing and confirming that each requirement has been met, ensuring accountability.
• Feasibility ensures that the outlined goals and requirements are technically realizable within the allocated budget and timeframe. This assessment helps mitigate risks associated with unrealistic expectations and project scope, enabling teams to create a more practical development plan.
• Comprehensibility The RASD must be written in a manner that is easily understandable by all stakeholders within the target audience. This includes avoiding overly technical jargon unless it is defined and relevant, ensuring accessibility for users with varying levels of expertise.
• Good Structuring of the RASD enhances clarity and usability. This includes:
  • Highlighting the relationships between goals, requirements, and assumptions, helping stakeholders see how each element connects within the overall framework.
  • Ensuring that every term and item is defined before use, promoting understanding and reducing confusion.
• Modifiability The document should be designed to facilitate easy adaptation, extension, or reduction of requirements through localized modifications. This includes having a clear process for assessing the impact of any changes, enabling teams to respond flexibly to evolving project needs.

Traceability

Traceability is a critical quality that allows for:

• Clear identification of the sources of goals, requirements, and assumptions, ensuring that all elements can be traced back to their origins.
• Linking requirements and assumptions to their underlying goals, which enhances accountability and supports requirement validation.
• Facilitating references to requirements in future documentation, such as design specifications and test cases, promoting coherence throughout the software development lifecycle.

Traceability is a critical aspect of requirements management in software development, ensuring that every use case is linked to specific requirements. This relationship facilitates the verification of system functionality against established goals, allowing stakeholders to track progress and ensure that all necessary requirements are addressed throughout the development process.

To maintain effective traceability, it is essential to use proper identifiers for both requirements and use cases. For instance, a requirement identified as RE.3 may be associated with use cases UC.3.1 and UC.3.2. This clear association helps teams understand how each requirement supports the corresponding use cases and vice versa.

Note

It’s also important to note that a single use case can refer to multiple requirements. For example, while UC.3.1 is primarily related to RE.3, it may also reference RE.2. This explicit presentation of relationships enhances clarity and supports better understanding among team members and stakeholders.

One effective way to visualize and manage these relationships is through a traceability matrix. This matrix acts as a mapping tool, allowing teams to see at a glance how various elements relate to each other. Here is a simple example of a traceability matrix:

Raw ID	Goal ID	Req ID	Use Case ID	Comments
r1	G.1	RE.3	UC.3.1	…
r2	G.1	RE.2	UC.3.1	…

In this matrix, each row represents a specific relationship between a goal, requirement, and use case. The Raw ID serves as a unique identifier for each entry, while the Goal ID, Req ID, and Use Case ID indicate the connections between these elements.

As the development process progresses, the traceability matrix can expand to include additional elements, such as test cases. For example, the matrix may evolve to the following structure:

Raw ID	Goal ID	Req ID	Use Case ID	Test Case ID	Comments
r1	G.1	RE.3	UC.3.1	TC.3.1.1	…
r2	G.1	RE.2	UC.3.1		…

In this expanded version, the Test Case ID column is added to track which test cases are associated with specific requirements and use cases. This comprehensive mapping not only provides insights into the development process but also ensures that all aspects of the system are covered during testing.

Comparison of IEEE Standard Structure and Our RASD Template

When developing a Requirements Analysis and Specification Document, it’s crucial to adopt a structured approach that facilitates clarity, consistency, and comprehensiveness. Both the IEEE standard and our RASD template provide frameworks for organizing requirements, but they differ in structure and focus. Below is a comparative analysis of the two formats.

Our RASD Template

Our RASD template is designed to focus on practical aspects relevant to the specific project while maintaining some of the essential elements from the IEEE standard. Below is an outline of our template:

1. INTRODUCTION

• Purpose: States the objectives of the RASD.
• Scope: Defines what is covered by the document.
• Definitions, Acronyms, Abbreviations: Combines terminologies with key definitions.
• Revision History: Tracks changes made to the document over time.
• Reference Documents: Lists documents referenced within the RASD.
• Document Structure: Provides an overview of how the document is organized.

2. OVERALL DESCRIPTION

• Product Perspective: Describes how the product fits within its operational context.
• Product Functions: Summarizes the main functionalities.
• User Characteristics: Details the expected user demographics and characteristics.
• Assumptions, Dependencies, and Constraints: Combines various factors affecting the requirements into one section.

3. SPECIFIC REQUIREMENTS

• External Interface Requirements: Covers interactions with external systems.
• Functional Requirements: Details the functions the system must perform.
• Performance Requirements: Specifies metrics for performance.
• Design Constraints: Highlights any limitations affecting design.
• Software System Attributes: Describes desired quality attributes of the software.

4. FORMAL ANALYSIS USING ALLOY: Includes a section on formal analysis, utilizing Alloy for specification and validation of requirements.
5. EFFORT SPENT: Documents the time and resources spent on developing the requirements.
6. REFERENCES: Lists all sources cited throughout the document.

While both structures aim to provide a thorough and systematic approach to documenting requirements, they differ in emphasis and organization. The IEEE standard focuses heavily on detailed categorizations of requirements and verification methods, providing a more formalized framework suitable for complex systems. In contrast, our RASD template streamlines certain sections and introduces practical components, such as formal analysis and effort tracking, which may be particularly useful for agile or iterative development processes.

Our template also merges related topics, such as assumptions and constraints, into single sections, thereby simplifying navigation and enhancing readability. The inclusion of a revision history and effort tracking can be particularly beneficial in dynamic project environments where requirements may evolve rapidly.

Comparison table

Aspect	IEEE Standard Structure	Our RASD Template
Introduction	Detailed sections including Purpose, Scope, Product Overview, and Definitions	Combines Purpose, Scope, Definitions, Acronyms, Abbreviations, Revision History, Reference Documents, and Document Structure
References	Separate section for references	Included in the Introduction section
Requirements	Detailed subsections for Functions, Performance, Usability, Interface, Database, Design Constraints, System Attributes, and Supporting Information	Specific Requirements section with External Interface, Functional, Performance, Design Constraints, and Software System Attributes
Verification	Separate section for verification methods	Not explicitly included
Appendices	Includes Assumptions and Dependencies, Acronyms and Abbreviations	Not explicitly included
Overall Description	Not explicitly included	Separate section for Product Perspective, Product Functions, User Characteristics, Assumptions, Dependencies, and Constraints
Formal Analysis	Not included	Separate section for Formal Analysis using Alloy
Effort Spent	Not included	Separate section for documenting effort spent
Traceability	Implied through detailed requirements and verification sections	Explicitly discussed with examples and traceability matrix

Sections for Including Requirements Knowledge

To effectively integrate all the learned aspects of requirements into the RASD, each section of the document should serve a specific purpose. Here’s how to include various types of information related to requirements:

1. INTRODUCTION
   • A. Purpose: Clearly articulate the goals of the project, emphasizing the significance of the requirements in achieving these goals. Include high-level objectives that the project intends to meet.
   • B. Scope: Provide an analysis of the project context and the shared phenomena within the domain. Discuss how the requirements will address specific challenges or needs identified during the analysis.
   • C. Definitions, Acronyms, Abbreviations: Define key terms and acronyms that will be used throughout the document. This ensures clarity and prevents misinterpretation of requirements later in the document.
   • D. Revision History: Document changes made to the requirements over time, helping to track the evolution of the project and its requirements.
   • E. Reference Documents: Include any documents that inform or support the requirements, such as industry standards, previous project documentation, or research studies.
   • F. Document Structure: Provide an overview of the document’s organization, guiding readers on where to find specific information related to requirements.
2. OVERALL DESCRIPTION
   • A. Product Perspective: Include scenarios and detailed insights into the shared phenomena and domain model, possibly through class diagrams and state diagrams. This helps in understanding how requirements relate to real-world applications.
   • B. Product Functions: Summarize key requirements and categories of use cases. This section serves as a high-level overview of what the product is expected to do, guiding further detailed specifications.
   • C. User Characteristics: Present relevant information about user groups, including their needs, capabilities, and constraints. This section should reflect insights gathered about user requirements and usability considerations.
   • D. Assumptions, Dependencies, and Constraints: Document domain assumptions that underpin the requirements. Address how these assumptions influence the design and development process.
3. SPECIFIC REQUIREMENTS This section should elaborate on all relevant details discussed in Section 2, providing the development team with comprehensive information necessary for implementation.
   • A. External Interface Requirements: Specify requirements related to user, hardware, software, and communication interfaces. Clearly outline how the product will interact with other systems and components.
     • A.1 User Interfaces: Detail user interface requirements, including accessibility considerations.
     • A.2 Hardware Interfaces: Describe interactions with hardware components.
     • A.3 Software Interfaces: Specify relationships with other software systems.
     • A.4 Communication Interfaces: Outline communication protocols and standards.
   • B. Functional Requirements: Provide use case diagrams, detailed use cases, and related sequence and activity diagrams. Map these to requirements to show how each function aligns with user needs.
   • C. Performance Requirements: List metrics and expectations for performance, ensuring that all non-functional requirements (NFRs) are addressed.
   • D. Design Constraints: Discuss constraints that may limit design decisions.
     • D.1 Standards Compliance: Specify any relevant standards that must be adhered to.
     • D.2 Hardware Limitations: Outline limitations posed by the hardware environment.
     • D.3 Any Other Constraint: Include any additional constraints identified during the analysis.
   • E. Software System Attributes: Detail the required quality attributes of the software, such as:
     • E.1 Reliability: Expectations for reliability levels.
     • E.2 Availability: Required availability metrics.
     • E.3 Security: Necessary security features and requirements.
     • E.4 Maintainability: Requirements for system maintainability.
     • E.5 Portability: Expectations for portability across platforms.
4. FORMAL ANALYSIS USING ALLOY: Provide a brief overview of the objectives behind formal modeling and its relevance to the requirements. Include the formal model and explain what aspects can be verified, along with the importance of these verifications for addressing the identified problems. Demonstrate the model’s soundness and correctness by presenting results obtained through running the model and checking meaningful assertions.
5. EFFORT SPENT: Document the number of hours each team member has contributed to creating the RASD. This information can help assess project resource allocation and team dynamics, providing insights into the effort invested in understanding and defining requirements.
6. REFERENCES: Compile a comprehensive list of all sources cited throughout the document, including academic papers, industry standards, and other relevant literature that supports the requirements discussed in the RASD.