Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
The process of Requirements Engineering (RE) for a new transportation system aimed at addressing the problem of frequent missed flight connections and slow transportation between airport terminals. the identification and evaluation of objectives, elicitation and evaluation of requirements, and the documentation and consolidation of requirements. RE is crucial for getting the right system and software, and is concerned with real-world goals, functions, constraints, and evolution over time.
Typology: Lecture notes
1 / 45
This page cannot be seen from the preview
Don't miss anything!
SO URCE O F PP SLIDES :
L AMSW EERDE, A. V. 2 01 1. REQUIREMENTS ENGINEERING: F ROM SYSTEM GO ALS TO UML
MO DEL S T O SO FTWARE SPECIFICATION. 2
N D ED. W ILEY.
engineering
requirements
requirements engineering practice
processes and requirement engineering
RE is a set of activities producing the requirements on a software-
intensive system
constraints, assumptions
provided by new technologies
Requirements quality assurance is a key concern for software
quality assurance
elicitation, evaluation, specification,
analysis, evolution management
EXAMPLE: (LET’S DISCUSS…)
TRANSPORTATION BETWEEN
AIRPORT TERMINALS
Problem (system-as-is):
passengers frequently missing flight connections among different
terminals; slow & inconvenient transportation
number of passengers regularly increasing
Objectives, options (system-to-be):
support high-frequency trains between terminals
with or without train drivers?
Functionalities, constraints:
software-based control of train accelerations, doors opening etc. to
achieve prompt and safe transportation
RE deliverable:
Requirements Document (RD) for system-to-be
REQUIREMENTS IN THE SOFTWARE
LIFECYCLE
Requirements engineering
Software design
Software implementation
Software evolution
Getting
the
right
system
Getting
the
software
right
Objectives
WHY
a new system?
WHAT
services?
WHO
will be
responsible
for what?
satisfy
assign
requirements,
constraints,
assumptions
problems,
opportunities,
system knowledge
System-to-be
System-as-is
Identify, analyze, refine the system-to-be’s objectives
Example: airport train control
“Serve more passengers”
“Reduce transfer time among terminals”
Difficulties
Acquire domain knowledge
Evaluate alternative options (e.g. alternative ways of
satisfying the same objective)
implications, associated risks
Assign responsibilities for the objectives, services, constraints among
system-to-be components
Example: airport train control
(driverless option) or of driver following software indications?
tracking system or of preceding train?
Difficulties
EX: (LET’S DISCUSS …)
SCOPE OF RE : WHY , WHAT , WHO
DIMENSIONS FOR A LIBRARY SYSTEM
- constrain how such services should be provided - (^) Defines constrains on the way the software should satisfy its
(See definitions and examples in the book)
No clear-cut boundaries, possible overlaps …
related (non functional req)
performance and safety
Non-Functional Requirement
Quality of Service Compliance Architectural Constraint Development Constraint
ConfidentialityIntegrity (^) Availability
Safety Security Installation Distribution
Usability
Reliability Performance
Maintainability Cost
Time Space
Deadline Variability
Software
interoperability
Convenience
Interface
User
interaction
Device
interaction
Subclass link
Accuracy
Cost
17
- Product requirements - (^) Is a need or constraint on the software to be developed - (^) Eg: “The software shall verify that a student meets all pre-
requirements before he or she registers for a course”
- Process requirements - (^) Is essentially a constraint on the development of the software - (^) Eg: “The software shall be developed using Waterfall
Development Process”
start
domain understanding
& elicitation
alternative proposals
