0% found this document useful (0 votes)
3 views3 pages

Lesson 2 Tutorial

Lesson 2 Tutorial

Uploaded by

2308313
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views3 pages

Lesson 2 Tutorial

Lesson 2 Tutorial

Uploaded by

2308313
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Study Session 2: Advanced Requirements Engineering

Introduction

Advanced Requirements Engineering (ARE) is the backbone of successful software projects. It


ensures that systems are built to meet stakeholder needs, comply with constraints, and remain
adaptable over time. Unlike basic requirements gathering, ARE emphasizes systematic
elicitation, precise specification, validation, and traceability, while introducing formal
methods for rigor in critical domains.

1.1 Elicitation Techniques

Elicitation is about discovering what stakeholders truly need often beyond what they initially
say. Advanced techniques include:

 Interviews Example: Interviewing doctors and nurses to understand workflows before


designing a hospital records system. Strength: Rich detail. Weakness: Time-consuming.
 Workshops Example: A fintech startup gathers developers, product managers, and
customers in a workshop to brainstorm features for a payment app. Strength: Builds
consensus. Weakness: Risk of groupthink.
 Prototyping Example: Building a clickable prototype of a mobile banking app to refine
UI requirements. Strength: Clarifies vague needs. Weakness: Can raise unrealistic
expectations.
 Observation Example: Watching airline staff check in passengers to identify bottlenecks
before designing a new system. Strength: Reveals tacit knowledge. Weakness: Observer
bias.
 Surveys Example: Collecting feedback from thousands of e-commerce users about
checkout pain points. Strength: Broad coverage. Weakness: Shallow insights.
 Document Analysis Example: Reviewing compliance regulations before designing a
healthcare system. Strength: Ensures regulatory alignment. Weakness: May miss
evolving practices.

1.2 Requirements Specification

Specification transforms raw needs into structured, testable artifacts:

 Software Requirements Specification (SRS) Example: A detailed SRS for an ATM


system listing functional requirements (withdraw, deposit, balance inquiry) and
non-functional ones (availability, security).
 Use Cases Example: “Customer withdraws cash” — actors: customer, ATM;
precondition: card inserted; flow: enter PIN → select amount → dispense cash.
 User Stories Example: “As a student, I want to upload assignments online so that I don’t
need to visit campus.”
Activity 1.2: Write one use case and one user story for a ride-sharing app. Compare their level of
detail.

1.3 Non-Functional Requirements

These define system qualities beyond functionality:

 Performance — A stock trading system must process 10,000 transactions per second.
 Security — A healthcare app must encrypt patient data using AES-256.
 Usability — A government portal must support accessibility standards (WCAG).
 Reliability — A cloud service must guarantee 99.99% uptime.
 Maintainability — A modular e-commerce platform allows easy updates.
 Portability — A mobile app runs on both Android and iOS.
 Scalability — A social media platform scales to millions of users.

Example Trade-off: Adding strong encryption improves security but may reduce performance.
Engineers must balance priorities.

1.4 Requirements Traceability and Validation

Traceability ensures every requirement is linked across the lifecycle:

 Forward Traceability — Requirement → Design → Code → Test. Example: “System


must support online payments” traced to payment gateway design, implementation, and
test cases.
 Backward Traceability — Code/test → Requirement. Example: A test case for
“multi-currency support” maps back to the requirement in the SRS.

Validation Techniques:

 Reviews & inspections (peer checking).


 Prototyping (stakeholder feedback).
 Acceptance testing (customer approval).

1.5 Formal Methods Introduction

Formal methods use mathematics to specify and verify requirements:

 Modeling Languages — Z notation, VDM, Alloy.


 Verification Techniques — Model checking, theorem proving.
 Example: In avionics, formal methods prove that “autopilot disengages when manual
controls are used.”
 Benefits: Eliminates ambiguity, ensures correctness in safety-critical systems.
 Limitations: Requires expertise, costly for small projects.
Case Study: NASA used formal methods in the Mars Rover software to prevent deadlocks in
communication protocols.

Summary

Advanced Requirements Engineering equips engineers with tools to capture, specify, validate,
and rigorously analyze requirements. By mastering elicitation, specification, non-functional
attributes, traceability, and formal methods, students can design systems that are not only
functional but also reliable, secure, and sustainable.

You might also like