Software Requirements Analysis Quiz

Engineering Requirements

• Requirements are capabilities needed by a user to achieve an objective
• Requirements must be met by the system to satisfy a contract, standard, specification, or other formally imposed documents.
• System requirements apply to the entire system
• Software requirements apply to the software subsystem

Software Requirements Concepts & Process

• Functional Requirements describe functions the software performs.
  Example: A Traffic Management System can set the duration of individual traffic signal states. (Red 30-120 seconds, Green 30-120 seconds, Amber 5-10 seconds)
• Non-Functional Requirements constrain the solution. Example: The Traffic Management System software must not fail more than once in every 24,000 hours.
• Quality Attributes are characteristics related to performance and usability but unrelated to functionality. Examples include availability, reliability, usability, reusability, maintainability, efficiency, safety and security.
• Emergent Requirements cannot be addressed by a single component, instead require interactions between all components. Example: A system needs a specific increase in traffic throughput during a specific time period.

TMS Case Study

• Traffic Management Systems (TMS) use technologies to manage traffic flow.
• TMS address congestion caused by accidents, slow-moving vehicles, planned events, and extreme weather.

Documentation - Specifying Requirements - SRS Outline

• Introduction
• Team Project Information
• Overall Description
• Product Description and Scope
• Users Description
• Development Constraints
• Operational Environment
• Functional Requirements
• Performance Requirements
• Other Non-Functional Requirements
• Reliability
• Safety Requirements
• Security Requirements
• Maintenance Requirements
• Business Rules
• User Documentation
• References
• Appendix - Use Case Diagram

Software Requirements

• Correct: Every requirement must be satisfied by the software.
• Clear/Unambiguous: Requirements should be precise and easy to understand.
• Complete: All agreed-upon requirements should be included.
• Concise: Use clear and concise language.
• Consistent: No contradictory requirements.
• Feasible: Achievable within the given resources and schedule.
• Traceable: Requirements can be linked back to sources and forward to developed artifacts.
• Verifiable: Criteria for verification and a cost-effective way of checking implementation should exist.
• Prioritized: Requirements should be ranked by importance or stability.

Guidelines For Writing Requirements

• Use complete sentences and active voice.
• Be precise and avoid ambiguity.
• Requirements should be verifiable.
• Keep requirements concise, avoid wordiness.
• Use consistent terminology.
• Avoid compound statements; each statement should represent a single requirement.
• Avoid duplication.

Examples

• Avoid Non-Requirement Statements: Statements describing background information, relationships, negative scenarios, or the system's general design.
• Examples of Functional Requirements: Statements that describe specific system behavior (e.g., "The system must allow users to create and edit profiles").

Examples of Non-functional Requirements

• Pressing a switch to light up a room in less than one second.
• The light must switch off after two minutes when the room is empty.

Example of a Poorly Written Requirement

• The output of the program should usually be displayed within 10 seconds.
• Problems: Uses "usually," lacks specific conditions, undefined output, and unclear starting point for counting seconds.

Requirements Process

• Elicitation (gathering requirements from stakeholders).
• Analysis (studying data and modelling the problem).
• Specification (documenting and organizing the requirements).
• Validation (Confirming requirements meet the needs).
• Requirements Management (managing requirements throughout the entire software life cycle).

Analyzing Requirements

• Purpose of analysis: Understand stakeholder needs, define and specify requirements clearly, correctly and completely, and establish a solid foundation for design, construction, and testing.
• Develop a conceptual model for more effective communication.
• Elements of the Conceptual Model include Conceptual Design (initial system architecture view) and Use Case Model (describing user interactions with the system).

Outputs from Requirements Engineering - Use Case Model

• A model describing the ways users interact with the system.
• A use case actor represents a user or external entity interacting with the system.
• A use case includes a scenario, which details the interactions between the system and actors.
• Scenarios are used to clarify, expand, and correct functionality.
• Use cases are important for system test planning.
• Different approaches to use case modelling exist.

Use Case Model (UML)

• Use Case diagrams show actors, use cases and their relationships.
• Stick figures represent actors
• Ovals represent use cases
• Connectors show relationships between actors and use cases

Multiplicity (in Associations)

• The number of instances of one class potentially interacting with the instance of another class.
• Multiplicities define possible relationships between classes.
• Example: 0..* - Zero or more; 1 - Exactly one; 0..1 - Zero or one.

Use Case Activity

• Defines actors, actions (use cases), their relationships (include/extend), and the conditions for each activity.

Use Case Scenario

• Provides sequence of steps and describes the interaction between system and actors throughout a use case.
• Contains pre-conditions, post-conditions, main success scenarios, exceptions, and any other use cases that are referenced.

Example - DH Sequence Diagram

• Four objects in the given example: GeneralUser, DHServer, DHGateway, and Device Simulator.
• This scenario describes various method calls to update DH device status.

Why Not Just Code?

• Sequence diagrams can help understanding algorithms better than code.
• Sequence diagrams are language-agnostic.
• Easy to implement and understand them by the team, even for non-coders.
• Visual bandwidth (to see several objects/classes at once).

Representing Objects (in Sequence Diagrams)

• Represents objects using boxed shapes.
• Names clarified with object names are preceded by colons.

Messages Between Objects

• Horizontal arrows showing the method calls between objects.
• Write message name and possible arguments above the arrow.

Indicating Selection and Loops (in Sequence Diagrams)

• Boxes (frames) used for including selection and loop conditions in the diagram.

Linking Sequence Diagrams

• Use references or "ref" frames to avoid repeating or expanding sequence diagrams in a larger diagram.

Annotations

• Comments/annotations (additional details) to any part of the UML diagram.

Example - Digital Home

• New homeowners interested in Smart Homes.
• Emphasis on new technologies in home design, construction (e.g., distributed computing, web communications, and intelligent agents).

Basic Concepts of Object-Oriented Programming and UML

• Object
• Class
• Class name
• Attributes
• Operations

UML Diagram Overview

• Structural diagrams (Class, component, deployment, composite structure, package) are descriptions of the structure of a system.
• Behavioral diagrams (activity, state machine, use case) describe system behavior.
• Interaction diagrams (sequence, communication, interaction overview, timing) emphasize object interaction.

Example - Single Inheritance

• Child class (subclass) inheriting properties and methods from a base (parent) class.

Example - Multiple Inheritance

• Child class (subclass) inheriting properties and methods from multiple parent classes (with caution to avoid redundant code).

Association (for Relationships)

• Models semantic connections among classes.
• Multiplicity (defined for each class end and describes relationship cardinality).
• Navigation (specify direction of access).

Example - Library System

• A library system manages publications (books and journals).
• Books and journals inherit from a publications superclass.
• The relation between students and publications is an association with cardinality.
• Library and publication relation is aggregation.

SDS

• Engineering requirements from requirements to design (the specific topic of this presentation).

Test your understanding of requirements analysis in software development with this informative quiz. Covering essential concepts like use case scenarios and characteristics of effective software requirements, this quiz is designed for both beginners and advanced learners in the field.