Requirements Engineering Chapter 4

Study Notes

Requirements pertain to overall system performance rather than individual features or services.
Domain requirements impose constraints based on the operational context of the system.

Focus on quality attributes and system constraints, not strictly on functionality.
Highlight how a function is performed rather than what the function entails.
Process requirements may dictate specific tools, languages, or methods for development.
Often more critical than functional requirements, as unmet non-functional needs can render a system ineffective.

Product requirements dictate the product's performance characteristics (e.g., speed, reliability).
Organisational requirements arise from company policies, such as process standards and implementation details.
Conflicting requirements may arise from differing stakeholder perspectives influenced by organisational dynamics.
Requirements evolve throughout the analysis, with new stakeholders and changing business needs.

Involves engaging stakeholders to gather insights about application domain and necessary system services.
Key stages consist of:
- Requirements discovery: Engaging with stakeholders to identify needs.
- Classification and organization: Grouping and structuring related requirements.
- Prioritization and negotiation: Resolving conflicts and determining importance.
- Specification: Documenting requirements for subsequent project phases.

Stakeholders may struggle to articulate precise wants.
Different expressions of requirements lead to potential misunderstandings.
Conflicts may exist between various stakeholder requests.
Changes to requirements can occur as analyses progress, influenced by new inputs or environment shifts.

Serves as the formal statement detailing what developers need to deliver.
Includes both user and system requirements, clarifying expectations without dictating design elements.
Should comprehensively define what the system is expected to accomplish.

Involves documenting user and system requirements for clarity and contractual purposes.
User requirements must be accessible to non-technical end-users.
System requirements tend to be more technical and detailed.

Natural language: Simple, numbered sentences capturing each requirement.
Structured natural language: Standard templated forms for consistency.
Graphical notations: Diagrams (like UML use case and sequence diagrams) complemented by text.
Mathematical specifications: Uses formal mathematical concepts for clarity but may be misunderstood by non-technical stakeholders.

Ensures that requirements align with customer expectations.
High cost of fixing post-delivery errors emphasizes the necessity of thorough validation.

Essential to manage changing requirements throughout the development lifecycle.
Keeping track of requirements and their interdependencies is vital for assessing impacts from changes.
Establishing formal procedures for change proposals helps maintain coherence throughout development.

Software system requirements define operational constraints and service expectations.
Functional requirements articulate necessary system services, while non-functional requirements shape system development.
The software requirements document serves as a mutual agreement between stakeholders and developers.
Requirements engineering is an iterative process encompassing elicitation, specification, and validation.
Various techniques, such as interviews, scenarios, use-cases, and ethnography, aid in the requirements gathering phase.