CP317 Software Engineering: Requirement Gathering

• CP317 Software Engineering covers requirement gathering.
• Requirement gathering is the most important part of software engineering.

Requirements

• A requirement is a singular, documented physical or functional need that a design, product, or process aims to satisfy.
• In software engineering, requirements are documented customer needs or features that a computer system aims to satisfy.

Importance of Requirements

• Important for understanding what needs to be done.
• Establishes accountability and responsibility.
• Ensures reputation and integrity when building software for customers.
• Accurate requirements are crucial, demanding earnestness, meticulousness, and no assumption.

Reasons for Software Project Failure

• Unclear project requirements are a top reason for failure.

Skills for Understanding Requirements

• Understanding requirements in software engineering requires both hard and soft skills.

Characteristics of Good Requirements

• Use Correct Terms:
  • Shall = requirement
  • Will = facts or declaration of purpose
  • Should = goal
• Example System Requirements:
  • The system "shall" operate at 12V.
  • The software "shall" acquire sensor data from the motor.
  • The data structure "shall" contain a linked list.
• Good Requirements:
  • Understandable, Correct/Precise, Unambiguous
  • Complete and Fully Documented
  • Consistent, not contradictory
  • Interoperable with known dependencies
  • Verifiable/Valid for testing
  • Singular, appearing once only
  • Traceable through design, test, and delivery
  • Prioritized for relative importance
  • Achievable with available capability and resources

Prioritizing Requirements

• MOSCOW Method:
  • Must have: vital things needed
  • Should have: important but not vital
  • Could have: "nice-to-haves"
  • Won't have: provide little to no value
• Prioritizing helps to:
  • Focus on important user and customer needs.
  • Focus on development effort.
  • Manage projects more effectively with staged delivery plans.
• Prioritization aids in making trade-offs and allocating resources.

Categorizing Requirements

• Requirement categorization involves grouping requirements into meaningful clusters.

• Business Requirements:

  • High-level goals that explain what the customer aims to achieve with the project.
  • Example: ATM - cash withdraw, deposit, a transfer of money, balance inquiry....

• User Requirements:

  • Describe how end users will use the software product. Example: ATMs requirement to insert card, enter pin, amount selection etc..

• System Requirements:

  • System requirements are the configuration that a system must have in order for a hardware or software application to run smoothly such that to achieve business requirements and user requirements.
  • Necessary configurations for hardware or software applications for smooth, efficient operation, to achieve business/user needs.
  • Example: touchscreen, computer language, size.

Relationships Between Business, User and System Requirements:

• Business requirements are at the highest level, concerning sponsor point of view, Scope of the project, and business objectives.
• User requirements at the intermediate Level, concerning user point of view, user goals, and user inputs & outputs
• Systems requirements are at the lower level , concerning what the system does (functional) and how well does the system do it (non-functional)

Functional Requirements

• Detailed statements about a project's desired capabilities.
• Authentication, Business Rules, External Interfaces, Audit Tracking etc Examples:
  • Authentication
  • Authorization levels
  • Audit tracking
  • Business rules
  • Transaction Types

Non-Functional Requirements

• Statements about the product's quality, behavior, or constraints on achieving results.
• Based on IEEE-Std 830-1993, includes performance, operational, resource, verification, acceptance, documentation, security, and portability requirements.
  • Performance
  • Security
  • Portability
  • Documentation
  • Operational requirements

Functional vs. Non-functional Requirements

• Functional: verb based, mandatory with use cases; defines product feature, easy to capture.
• Non Functional: attribute based, non mandatory defined by quality attribute scenario; defines product properties, difficult to capture

FURPS

• The categories are functionality, usability, reliability, performance and supportability.
• An acronym for categorizing system requirements and was developed by HP.

FURPS+

• Includes functionality, usability, reliability, performance, supportability, design constraints, implementation, interface, and physical requirements.

This content covers requirement gathering, the most important part of software engineering. Requirements are documented needs that a design or product aims to satisfy. Understanding requirements requires both hard and soft skills.