Understanding Requirements Engineering

Requirements Engineering

• Requirements engineering is the process of defining the services a customer needs from a system.
• It also identifies the constraints under which the system will operate and be developed.
• Requirements can be functional, describing system services, or non-functional, setting constraints on the system or development process.

Functional vs. Non-Functional Requirements

• Functional requirements describe what a system should do, like business rules or administrative functions.
• Examples of functional requirements include transaction corrections, authentication, authorization levels, audit tracking, external interfaces, certification, reporting, historical data, and legal/regulatory needs.
• Non-functional requirements describe how a system works, like performance, scalability, capacity, availability, reliability, recoverability, maintainability, and serviceability.
• Functional requirements example: ability for a milk carton to contain fluid without leaking
• Non-functional requirements example: ability for a hard hat to not break under pressure of less than 10,000 PSI
• Functional requirement example: "The ability for the user to save a customer's personal record using the Customer Relationship Management system.”

Key Points for Writing Functional Requirements

• Describe only one piece of functionality in each functional requirement.
• Use a consistent sentence structure or styling for each functional requirement.
• Example of consistent structure: "The ability for the user to print a customer’s personal record using the Customer Relationship Management system.”
• Use active verbs and specific functions to ensure the requirement is testable.
• Make sure the reader knows what they must do when they test the system to ensure the functional requirements are implemented correctly
• Make sure the functional requirements are measurable in order to be testable

Requirements Definition vs. Specification

• Requirements definition is a statement in natural language plus diagrams of the services the system provides and its operational constraints, written for customers
• Requirements specification is a structured document detailing the system services, written as a contract between client and contractor.
• Software specification is a detailed software description that can serve as a basis for design or implementation, written for developers.

Wicked Problems

• Large software systems often address "wicked problems," which are highly complex and never fully understood.
• Understanding of these problems evolves during system development.
• Requirements for such systems are often incomplete and inconsistent.

Reasons for Inconsistency in Requirements

• Large software systems aim to improve the current situation, but anticipating the new system's effects on the organization is challenging.
• Different users have varying requirements and priorities.
• A shifting compromise must constantly be made in the requirements.
• System end-users and paying organizations have different requirements.
• Clarifying requirements often requires prototyping.

Requirements Document Structure

• Non-functional requirements definition sets constraints on the system and development process.
• System evolution defines the fundamental assumptions and anticipated changes.
• Requirements specification details functional requirements.
• Appendices may include system hardware platform description or database requirements (e.g., ER model).

Ethnographic Analysis

• This involves a social scientist observing and analyzing how people work.
• The people do not have to explain their work
• Social and organizational factors of importance get observed.
• Ethnographic studies show that work is more complex than simple system models suggest.

Social and Organizational Factors

• Software systems operate within a social and organizational context, influencing or dominating system requirements.
• These factors aren't a single viewpoint but influence all viewpoints.
• Good analysts consider these factors, but there's no systematic analysis method.

Writing Requirements Definitions

• Natural language with diagrams and tables is the standard for writing requirements definitions.
• This is universally understandable but problems can include a lack of clarity, with precision hard to achieve.
• Requirements confusion could occur, with functional and non-functional requirements mixed up.
• Requirements amalgamation could happen where several requirements are expressed together.

Requirements Rationale

• Providing a rationale with each requirement is important.
• This helps developers understand the application domain and why the requirement is stated as is.
• The rationale is crucial when requirements change.
• Rationale reduces the chance of unexpected effects from changes.

Requirements Specification Details

• Specifications add detail to the requirements definition and should maintain consistency.
• System models developed during requirements analysis usually present specifications.
• These models may delineate parts of the system for development.
• Specifications are often written in natural language, which can be problematic.

Problems with Natural Language

• Natural language relies on specification readers and writers using the same words for the same concept
• Natural language specification is over-flexible and subject to different interpretations
• Requirements are not partitioned by language structures

Natural Language Alternatives

• Structured English and Graphical notations
• Structured natural language

Non-Functional Requirements

• System properties and constraints are defined, like reliability, response time, and storage.
• Process requirements are specified, mandating a CASE system, programming language, or development method.
• If non-functional requirements are unmet, the system is useless

Non-Functional Classifications

• Product requirements specify how the delivered product must behave (e.g., execution speed, reliability).
• Organizational requirements derive from organizational policies/procedures (e.g., process standards).
• External requirements arise from factors external to the system and its development (e.g., interoperability, legal).

Non-Functional Examples

• Product: Communication between APSE and user must use the standard Ada character set.
• Organizational: System development conforms to XYZCo-SP-STAN-2015 processes and deliverables.
• External: The system allows users to check and correct personal data maintained within.

Requirements Verifiability

• Requirements should be objectively verifiable.
• Vague terms undermine verifiability.
• Example: Define error rates and training times for system functions.

Requirements Measures

• Speed: processed transactions/second, user/event response time, & screen refresh time
• Size: K Bytes, & number of RAM chips
• Ease of use: training time, & number of help frames
• Reliability: mean time to failure, probability of unavailability, rate of failure occurrence, & availability
• Robustness: time to restart after failure, percentage of events causing failure, & probability of data corruption on failure
• Portability: percentage of target dependent statements, & number of target systems

Requirements Separation

• Functional and non-functional requirements should be distinguished in a requirements specification.
• Expressing requirements as whole system requirements, rather than individual functions, can be hard.
• Distinguishing if a requirement is functional or non-functional can be difficult.
• Safety requirements involve non-functional properties, potentially adding functions to the system.

System-Level Requirements

• Some requirements constrain the system as a whole, not specific functions.
• Example: "The time required for training a system operator to be proficient in the use of the system must not exceed 2 working days.”

Requirements Validation

• This demonstrates that requirements define the system the customer wants.
• Requirements errors are costly, so validation is important.
• "Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error."
• Prototyping is an important technique for requirements validation.

Requirements Checking

• Validity checks if the system provides functions that support the customer's needs.
• Consistency checks for conflicting requirements.
• Completeness checks for all functions required by the customer.
• Realism checks if requirements are implementable within budget and technology.

Requirements Reviews

• Regular reviews should occur while formulating the requirements definition.
• Client and contractor staff should participate.
• Reviews can be formal (with completed documents) or informal.
• Communication between developers, customers, and users can resolve early-stage problems.

Review Checks

• Verifiability: Is the requirement realistically testable?
• Comprehensibility: Is the requirement properly understood?
• Traceability: Is the origin of the requirement clearly stated?
• Adaptability: Can the requirement be changed without large impact on other requirements?

Requirements Document Changes

• Organize the document to allow for easy changes without extensive rewriting.
• Minimize external references and modularize sections.
• Electronic documents facilitate changes.
• A lack of standards for electronic documents can complicate the process.

Key Points

• Formulating a complete and consistent requirements specification is challenging.
• The requirements definition, specification, and software specification are ways to specify software for different readers.
• The requirements document describes the project for customers and developers.