Software Requirements Analysis

Definitions of Terms/Concepts

• Requirements specify the product's business needs/purposes at a high level
• They clarify the features, functionality, behaviors, and performance that stakeholders expect
• Requirements Engineering encompasses the tasks to be completed, problems to be solved, and ways of contributing to knowledge or system types
• Software Requirements Analysis involves elicitation, analysis, specification, and validation of software needs throughout the software product lifecycle
• Requirements management validates and meets the needs/requirements of clients, external, and internal stakeholders

The Requirement Problem - What is a Requirement?

• A requirement is a needed or wanted element
• Requirements pinpoint business needs/purposes at a high level

The Requirement Problem - Requirements Dimensions

• Good requirements rely on a balance between people, organization, and technology

The Requirement Problem - Gathering Requirements

• Effective gathering involves talking to users to understand their needs
• Ask for clarification and record views
• Clarify views by resolving inconsistencies and generating a consensus
• Stakeholder participation is crucial

The Requirement Problem - Requirement Issues

• Stakeholders may lack a clear vision or have unrealistic expectations
• Stakeholders' language usage introduces communication barriers
• Lack of clarity, requirements confusion, and requirements amalgamation can occur
• Varying stakeholder needs may arise
• Political and economic factors influence requirements
• Physical environment considerations are critical to project success

The Requirement Problem - More Requirement Issues

• Noise: Irrelevant or meaningless information
• Silence: Missing key elements
• Overspecification/implementation bias dictates design choices
• Contradiction: Conflicting descriptions of the same element
• Un-satisfiability: Unrealistic specifications
• Ambiguity: Lack of precision
• Wishful thinking: Unrealistic or unreasonable demands

The Requirement Problem - Characteristics of Software Requirements

• IEEE 830 outlines characteristics of good software requirements
• Correctness: The SRS should accurately reflect system behavior and align with user goals
• Unambiguous: Requirements should be clear, avoiding multiple interpretations through specific language
• Completeness: The software requirements document should comprehensively describe anticipated behaviors and features
• Consistency: Requirements should not contradict each other

The Requirement Problem - Bad Software Requirements

• Poor requirements include terms like "completely reliable," "maintainable," "fast," use "artificial intelligence," or "totally modular" without specifics

The Requirement Problem - Good Software Requirements

• Use "Shall" for mandatory requirements and "Should" for optional/nice-to-have items
• The response time must be less than 500ms
• 95% of all transactions must be processed in under 4s
• MTBF for the Controller shall be 5000 hours

The Requirement Problem - Role of Software Requirements

• Customers/clients use the requirements document to express their needs and expectations throughout the software development lifecycle
• Developers/programmers use it to design solutions that satisfy requirements
• QA personnel/testers it as a basis for testing
• Managers/project leaders use it as a contract and control the project
• System/Maintenance engineers use it as a guide for system evolution

Software Requirement Management

• Collection: gathering feedback and needs from both customers and internal teams
• Analysis: involves determining whether proposed features and requirements align with the company or product vision
• Definition: includes documenting requirements from the user perspective and detailing functional or technical aspects
• Prioritization: involves planning upcoming releases or sprints and deciding which features and requirements to include
• Validation and Maintenance: focuses on creating a definition of complete and planning ongoing enhancements

The Requirement Problem - Types of Software Requirements

• Business requirements outline the business's measurable goals, define the software project's purpose, and aligns it with stakeholder objectives
• User requirements reflect specific user needs and expectations and highlighting how users interact with the software
• Software requirements identify features, functions, non-functional needs, use cases

Business Requirements

• A BRD contains one or more statements aligning project goals with measurable stakeholder or business goals
• A BRD Statement format: "The [project name] software will [meet a business goal] in order to [realize a business benefit]."
• Example: Laser marking software will mark text and images on stainless steel to save chemical costs

User Requirements

• User requirements reflect the specific needs/expectations of customers
• Format of User Requirements is: "The [user type] shall [interact with the software] in order to [meet a business goal or achieve a result]."
• Example: The production floor manager should upload new marking files to have an updated library of laser marking images

Software Requirements Breakdown

• The team creates an SRS that lists the features, functions, nonfunctional items, and use cases
• Essentially, the SRS explains what the software will do and expands upon the BRD for developers
• Functional, Nonfunctional, and Domain Requirements