CSE 270: Software Testing - Reading Material

2.1 Gathering Requirements Using the SRS

A Software Requirements Specification (SRS) is a comprehensive document that outlines the functional and non-functional requirements of a software system. It serves as a blueprint for the development team, providing detailed information about what the software should achieve and how it should behave. The primary purpose of an SRS is to facilitate clear communication between stakeholders, including clients, project managers, designers, and developers, by specifying the features and functionalities of the software in a structured manner.

Example SRS Document

Key components of a Software Requirements Specification may include:

• Introduction
  • Overview of the document.
  • Purpose and scope of the software project.
  • Identification of stakeholders.
• Functional Requirements
  • Detailed descriptions of the system's functionalities.
  • Use cases or user scenarios, describing how the system will be used.
  • User interfaces and interaction with the software.
  • Data inputs and outputs.
• Non-functional Requirements
  • Performance requirements (for example, response time, throughput).
  • Security requirements.
  • Reliability and availability specifications.
  • Scalability and maintainability criteria.
• System Architecture
  • High-level overview of the system architecture.
  • Components and modules.
  • Interaction between system components.
• External Interfaces
  • Description of interfaces with external systems or third-party components.
  • Data formats and communication protocols.
• Data Requirements
  • Data models or database schema.
  • Data storage, retrieval, and manipulation requirements.
• Constraints
  • Limitations or constraints on the software development process.
  • Examples include budget constraints, time constraints, or technology constraints.
• Assumptions and Dependencies
  • Assumptions made during the requirements analysis.
  • Dependencies on external factors, such as hardware, software, or third-party services.

The first draft of the SRS should be completed early in the software development life cycle so that a line of communication can be established between the business stakeholders and the software development team before too much meaningful work has been done. On the other hand, it is important to not let development of a complete SRS hold up development on parts of the software that are well documented and well understood.

An effective SRS is characterized by requirements with clarity, completeness, and traceability, ensuring that each requirement can be traced back to the business goals and objectives of the software project. Regular reviews and updates to the SRS are often necessary as the project evolves and requirements are refined or changed.

Using the SRS - Pros and Cons

Although using the SRS is a common practice in software development, other methods are commonly found such as creating wiki pages, spreadsheets or documents. We can understand why this happens by considering the pros and cons of using SRS.

Pros

• Clarity and Precision: SRS provides a detailed and precise description of the system requirements, reducing ambiguity and ensuring a common understanding among stakeholders.
• Comprehensive Documentation: SRS includes both functional and non-functional requirements, covering various aspects such as user interactions, system behavior, performance, and security.
• Reference for Development: SRS serves as a reference point for the development team, guiding them in the implementation phase and ensuring that the final product aligns with the specified requirements.
• Basis for Testing: Testing teams use the SRS as a foundation for developing test cases, ensuring that testing efforts are aligned with the intended system behavior.
• Requirement Traceability: The SRS allows for traceability, linking each requirement to its source and enabling easy tracking of changes throughout the development life cycle.
• Communication Tool: SRS facilitates communication between different stakeholders, including project managers, developers, testers, and clients, fostering a shared understanding of project goals.
• Legal and Contractual Purposes: In contractual agreements, the SRS can serve as a legal document that defines the scope of work, minimizing disputes and providing a basis for project delivery.

Cons

• Time-Consuming: Creating a comprehensive SRS can be time-consuming, especially for large and complex projects. This may impact project timelines.
• Limited Flexibility: SRS documents may become outdated if not regularly updated. Changes in requirements can be challenging to accommodate without proper version control and change management.
• Potential for Misinterpretation: Despite efforts to be clear, there's still a risk of misinterpretation, especially if stakeholders have different levels of technical expertise.
• Difficulty in Handling Changes: Incorporating changes can be challenging, and late-stage modifications may lead to increased development costs and delays.
• Not Ideal for Agile Environments: In Agile development, where flexibility and responsiveness to change are prioritized, a traditional SRS may be perceived as too rigid.
• Complexity for Small Projects: For small projects with straightforward requirements, the level of detail in an SRS may be seen as excessive, potentially hindering agility.

In summary, while an SRS is a valuable tool for clearly documenting and communicating software requirements, its effectiveness depends on factors such as project size, complexity, and the development methodology employed. Striking a balance between detailed documentation and adaptability is crucial for successful requirement specification.

Standards for Requirements Gathering

Several commonly recognized standards exist for requirements specification, each tailored to different industries, project types, and regulatory environments. These standards provide guidelines and best practices to ensure consistency, clarity, and quality in documenting software requirements. Some of the well-known standards for requirements specification include:

• IEEE 830-1998: IEEE Recommended Practice for Software Requirements Specifications
  • Published by the Institute of Electrical and Electronics Engineers (IEEE), this standard provides guidelines for structuring and formatting a Software Requirements Specification (SRS). It outlines the essential elements and content that should be included in an SRS.
  • This standard was superseded by ISO/IEC/IEEE 29148:2018 but is still commonly referred to today.
• ISO/IEC/IEEE 29148:2018: Systems and Software Engineering - Life Cycle Processes - Requirements Engineering
  • This international standard, jointly published by ISO (International Organization for Standardization), IEC (International Electrotechnical Commission), and IEEE, addresses requirements engineering processes in the software development life cycle. It provides guidance on requirements elicitation, analysis, specification, verification, and management.
• ISO/IEC/IEEE 12207:2017: Systems and Software Engineering - Software Life Cycle Processes
  • This standard outlines the processes, activities, and tasks involved in the software life cycle. It includes requirements-related processes and serves as a broader framework for software development.
• INCOSE (International Council on Systems Engineering) Systems Engineering Handbook
  • While not a strict standard, the INCOSE Systems Engineering Handbook provides guidance on systems engineering processes, including requirements engineering. It is widely used in the systems engineering community and emphasizes the importance of requirements in the broader context of system development.

• ISTQB (International Software Testing Qualifications Board) Standard Glossary of Terms Used in Software Testing

  • While not specifically a requirements specification standard, the ISTQB glossary provides standardized terminology used in software testing, including terms related to requirements and acceptance criteria.

This is only a subset of the available standards for requirements engineering and software process management. Depending on where you work, some of these standards may apply and others may not.

In a report published in 2021, the IEEE standards body acknowledged that standards such as the ones published above are either not widely known in the software engineering industry, or when they are known are not widely adopted. There are many reasons for this but it can be best summarized with the following quote from the text, “The low degree of knowledge of relevant RE standards is an indicator that many requirements engineers feel that standards do not add sufficient value in the context of their work.”

The study can be found here: https://ieeexplore.ieee.org/document/9449943

Creating Effective Functional and Non-Functional Requirements

Creating requirements is a critical step in the software development process, and various techniques are employed to capture and communicate what a system must accomplish. Here are explanations of different ways to create requirements, including bulleted lists, user stories, use cases and prototypes:

Bulleted Lists:

• Format
  • Bulleted lists present requirements in a simple and structured format, using bullet points to itemize individual requirements.
• Use Cases
  • Bulleted lists are effective for specifying functional and non-functional requirements in a concise manner.
• Pros
  • Clarity: Bulleted lists provide a clear and straightforward format, making it easy to read and understand.
  • Conciseness: They allow for concise expression of requirements without unnecessary details.
  • Accessibility: Easily accessible and familiar format for stakeholders.
• Cons
  • Lack of Context: Bulleted lists may lack the context provided by detailed narratives or scenarios.
  • Limited Detail: Sometimes insufficient for complex requirements that require detailed explanations.

User Stories

• Format
  • User stories are concise narratives that describe a specific feature or functionality from an end user perspective. They follow the template: "As a [user type], I want [an action] so that [benefit/value]."
• Use Cases
  • Commonly associated with Agile methodologies, user stories are particularly useful for iterative and incremental development.

Use Cases

• Format
  • Use cases describe specific interactions between a system and its users (actors) to achieve a particular goal. They typically include a description, preconditions, steps, and postconditions.
• Use Cases
  • Use cases provide a detailed understanding of how users interact with the system and are often used in systems engineering and requirements analysis.
• Pros
  • Comprehensive: Provides a detailed understanding of interactions and system behavior.
  • Structured Format: Follows a structured format with clear sections (preconditions, steps, postconditions).
  • Traceability: Supports traceability of requirements through the entire life cycle.
• Cons
  • Complexity: Can become complex for large systems with numerous use cases.
  • Time-Consuming: Developing detailed use cases may be time-consuming, especially for small projects.

Prototypes

• Format
  • Prototypes are visual representations of the system's user interface or certain functionalities.
  • They can be interactive or static and provide a tangible way to understand user interactions and design elements.
• Use Cases
  • Prototypes help stakeholders visualize the product, gather feedback, and refine requirements during the design phase.
• Pros
  • Visualization: Offers a tangible and visual representation of the system or features.
  • User Feedback: Facilitates early user feedback and validation.
  • Improved Communication: Enhances communication between stakeholders and development teams.
• Cons
  • Time and Resource Intensive: Creating interactive prototypes may require significant time and resources.
  • May Focus on UI: Prototypes may emphasize the user interface, potentially neglecting non-visual aspects.

Example

A clickable prototype illustrating the flow of a new feature in a mobile application.

These techniques can be used individually or in combination, depending on the project's needs and the preferences of the development team. The goal is to choose a method that effectively communicates the requirements to all stakeholders and provides a solid foundation for the development process.

Dealing with Missing Requirements:

While the ideal scenario involves a complete set of requirements, the reality often presents challenges with missing information. Effectively addressing missing requirements requires a proactive and collaborative approach.

• Initiate Communication: Actively engage with stakeholders, including business analysts, end users, and product owners, to uncover missing information. Schedule meetings or workshops to gather additional insights and ensure a comprehensive understanding of user needs.
• Explore Similar Projects: Draw on experiences from similar projects within the organization or industry standards. Analyze common requirements that might be applicable to the current project, providing a foundational starting point for discussions.
• Risk Analysis: Conduct a thorough risk analysis to identify potential gaps and their impact on testing and project success. Assess the severity of missing requirements and prioritize efforts based on the perceived risks.
• Document Assumptions: Clearly document any assumptions made during testing due to missing requirements. These assumptions serve as a reference point for the testing team and other stakeholders, fostering transparency and managing expectations.
• Iterative Feedback: Provide continuous feedback to the project team about the importance of obtaining missing requirements. Emphasize the impact on testing timelines, quality, and overall project success. Iterative communication encourages stakeholders to prioritize the resolution of missing requirements.

Conclusion: Navigating the Requirements Landscape

Mastering the art of requirements gathering, analysis, and specification sets the stage for a successful software development journey. From user stories to acceptance criteria and the creation of a Software Requirements Specification, the process demands collaboration, clarity, and adaptability. Testers, as crucial contributors, play a pivotal role in ensuring requirements are not only complete but also testable. By understanding the nuances of requirements and embracing a structured approach, teams can set the foundation for robust testing, effective development, and the delivery of software that aligns with stakeholder expectations.

Useful Links:  ←Unit 1.4 |  Unit 2.2→  | Table of Contents | Canvas