2.REQUIREMENTS Eee403

Requirements, Systems Engineering
Systems Engineering Course Notes
Do not copy or distribute without the author’s permission

SYSTEMS
3 REQUIREMENTS
ENGINEERING
Orkun Zorba, Ph.D., 2021
Contents
1. The Need for RE

2. Basic Definitions
3. Attributes of A Good Requirement
4.Development Lifecycles
5. Requirements Specifications
6. CMMI, metrics, tools
7. Some Clues
8.Example: A Library System
9. Example: Air Ticket Reservation System 2
The Need for

1 Requirements
Engineering
Why do we need it?
Reasons for project failure
* 2017 report of
Project
14% 32% 49% 50% Management
Fails
Exceed Scope
Late Institute (PMI)
budget problems
4
Reasons for project failure
* 2017 report of
Project
Management
Institute (PMI)
5
4 different systems
Tea machine Television
Radar Aircraft
6
Sample system requirements

System shall System shall
have two have an on/off
separate switch which
teapots for tea supplies the
and water electricity
System shall
System have a
shall detect communication
enemy subsystem to
targets in provide ground
rural area communication
7
Effects of project sizes

Tea machine Television Radar Aircraft
Size Tiny Small Medium Large
Design Engineers 2-3 10-15 30-40 100-150
Schedule 12 months 24 months 36 months 60+ months
Investment 3 m$ 30 m$ 100 m$ 1000 m$
States/modes 3 30 100 1000
Interface parameters 9 90 500 5000
Requirement pages 15 150 500 2000
Requirement numbers 150 1500 5000 20000
Requirement documents 1 3 10 200

8
Stakeholders
• Project leader
• Senior management
• Project team members
• Project customer
• Resource managers
• Line managers
• Project user group
• Product testers
• Group impacted by the project as
it progresses
• Group impacted by the project
after its completion
• Subcontractors to the project
• Consultants to the project
9
What are requirements for?

1. To show what results stakeholders want
2. To give stakeholders a chance to say what they want
3. To represent different viewpoints
4. To check the design
5. To measure the progress
6. To accept products against precise criteria
10
2 Basic
Definitions
What is a requirement?
What is «requirement»?
IEEE, 1998 INCOSE, 2015
• Requirement is a statement • Need is some capability of

that identifies a product or system desired or required
process operational, by a stakeholder.
functional or design Requirement is a formal
characteristic or constraint structured statement that can
which is unambiguous, be verified and validated
testable or measurable and within the life cycle of
necessary for product or product development.
process acceptability.
12
Requirements engineering process

Existing systems
information
Agreed
Stakeholder requirements
needs Requirements
System
Organizational engineering specification
standards process
System models
Regulations
Domain
information
Process: A series of actions or steps taken
in order to achieve a particular end.
13
Sources of requirements
Interviews Workshops Existing Prototypes Helpdesks Oberving

design users
Problem Trainers Consultants Customer Suggestions Improve-

reports complaints ments by
users
14
Classification of requirements
“what the “what the

system system shall
shall do in its be made of?”,
operation?”
“what kind of usage is

foreseen for this system?” 15
System vs. software engineering

System Analysis System System Testing
Engineering
System Design System Inte.Test
SW System
SW Req.Analysis Engineering SW System Test
Arch. SW Design SW Integr. Test
Detailed SW Design SW Subsystem Test

SW SW
Engineering Code&Unit Test Engineering
16
System vs. software engineering
System Software Main

requirements requirements difference
Involves partitioning The origin of system

Transforms an requirements lies in user
system requirements
operational need into needs
into major
a system description,
subsystems and The origin of software
system performance
tasks, then allocating requirements lies in the
parameters and a
those subsystems or system requirements
system configuration
tasks to software and/or specifications.
17
Requirements engineering phases
Elicitation Analysis Specification
Verification
Management
&Validation
18
Requirements elicitation
Verification
Elicitation Analysis Specification Management
&Validation
• The process through which the customers (buyers and/or

users) and the developer (contractor) of a system discover,
review, articulate and understand the users’ needs and
constraints on the software and the development activity.
• The various sources of domain knowledge include
customers, business manuals, the existing software of
same type, standards and other stakeholders of the
project.
• The techniques used for requirements elicitation include
interviews, brainstorming, task analysis, Delphi technique,
prototyping, etc.
19
Requirements analysis
Verification
&Validation
The process of analysing the customers’ and users’ needs to

arrive at a definition of software requirements. 20
Requirements specification
Verification
&Validation
• The development of a document that clearly and precisely records each of

the requirements of the software system.
• This activity is used to produce formal software requirement models. All
the requirements including the functional as well as the non-functional
requirements and the constraints are specified by these models in totality.
During specification, more knowledge about the problem may be required
which can again trigger the elicitation process.
• The models used at this stage include ER diagrams, data flow diagrams
(DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.
21
Requirements verification and validation

Verification
&Validation
• The process of ensuring that the software requirements specification is in

compliance with the system requirements, conforms to document standards of
the requirements phase and is an adequate basis for the architectural
(preliminary) design phase.
• If requirements are not validated, errors in the requirement definitions would
propagate to the successive stages resulting in a lot of modification and rework.
• The requirements should be consistent with all the other requirements i.e no two
requirements should conflict with each other. The requirements should be
complete in every sense. The requirements should be practically achievable.
• Reviews, buddy checks, making test cases, etc. are some of the methods used
for this.
22
Requirements management
Verification
&Validation
• Requirement management is the process of analysing, documenting, tracking,

prioritizing and agreeing on the requirement and controlling the communication to
relevant stakeholders.
• This stage takes care of the changing nature of requirements. It should be
ensured that the SRS is as modifiable as possible so as to incorporate changes in
requirements specified by the end users at later stages too.
• Being able to modify the software as per requirements in a systematic and
controlled manner is an extremely important part of the requirements
engineering process.
23
Attributes of
3 A Good
Requirement
What is there in a good requirement?
General attributes of a good requirement
25
Unambiguity
There should be only one way to interpret the requirement. Sometimes

ambiguity is introduced by undefined acronyms:
REQ1 The system shall be implemented using ASP.
Does ASP mean Active Server Pages or Application Service Provider? To fix
this, we can mention a full name and provide an acronym in parentheses:
REQ1 The system shall be implemented using Active Server Pages (ASP).
26
Testability
Some words can make a requirement untestable. Some adjectives (robust,

safe, accurate, effective, efficient, flexible, user-friendly), some adverbs
(quickly, safely, in a timely manner), nonspecific words (etc., and/or, TBD)
REQ1 The search facility should allow the user to find a reservation based
on Last Name, Date, etc.
In this requirement, all search criteria should be explicitly listed. The

designer and developer cannot guess what the user means by “etc.”
27
Conciseness
Requirements should not contain unnecessary verbiage or information. They should

be stated clearly and simply.
REQ1 Sometimes the user will enter Airport Code, which the system will understand,
but sometimes the closest city may replace it, so the user does not need to know
what the airport code is, and it will still be understood by the system.
This sentence may be replaced by a simpler one:
REQ1 The system shall identify the airport based on either an Airport Code or a City
Name.
28
Correctness
If a requirement contains facts, these facts should be true:
REQ1 Car rental prices shall show all applicable taxes (including 6% state
tax).
The tax depends on the state, so the provided 6% figure is incorrect.
29
Feasibility
The requirement should be doable within existing constraints such as time,

money, and available resources:
REQ1 The system shall have a natural language interface that will
understand commands given in English language.
This requirement may be not feasible within a short span of development

time.
30
Consistency
There should not be any conflicts between the requirements. Conflicts may be direct or
indirect. Direct conflicts occur when, in the same situation, different behaviour is expected:
REQ1 Dates shall be displayed in the mm/dd/yyyy format.

REQ2 Dates shall be displayed in the dd/mm/yyyy format.
They can be as follows:
REQ1 For users in the U.S., dates shall be displayed in the mm/dd/yyyy format.
REQ2 For users in France, dates shall be displayed in the dd/mm/yyyy format.
31
Completeness
A requirement should be specified for all conditions that can occur.
REQ1 A destination country does not need to be displayed for flights within
the U.S.
REQ2 For overseas flights, the system shall display a destination country.
What about flights to Canada and Mexico? They are neither “within the U.S.”
nor “overseas.”
32
Development
4
Life Cycles
Requirements engineering perspective
for life cycles
Development life cycles for RE
Waterfall
Prototyping
Incremental
Spiral
34
Waterfall
REQUIREMENTS CHANGED
ANALYSIS REQUIREMENTS
SYSTEM DESIGN
SUB-SYSTEM
DEVELOPMENT
INTEGRATION AND
QUALIFICATION
• First define requirements
• Then go to other steps OPEATIONAL MODE
• Don’t go back to requirements AND MAINTENANCE
35
Waterfall
1. It is difficult to define all requirements from start explicitly in
Waterfall model.
2. Waterfall model depends on capturing and freezing

requirements early in the life cycle.
3. Waterfall model depends on separating requirements from

design.
36
Prototyping
PROTOTYPING CHANGED
REQUIREMENTS
REQUIREMENTS
ANALYSIS
SYSTEM DESIGN
SUB-SYSTEM
DEVELOPMENT
INTEGRATION AND
• First prototype the system QUALIFICATION
• Then define the requirements OPEATIONAL MODE
• You can go back to previous steps AND MAINTENANCE
37
Prototyping
1. Prototyping model accommodates new or unexpected user
requirements.
2. Prototyping model satisfies user with software system.
38
Incremental
REQUIREMENTS
ANALYSIS
SYSTEM DESIGN Builds/ Increments/ Versions
SUB-SYSTEM
DEVELOPMENT
INTEGRATION AND
• Define the requirements QUALIFICATION
• Separate them for builds
• Develop the requirements OPEATIONAL MODE
you prefer first AND MAINTENANCE
39
Incremental
1. Incremental model reduces risks of requirements changes and
increases manageability.
2. Incremental model allows software team to defer development of
less well understood requirements to later releases after issues
have been resolved.
3. In incremental model, most if not all requirements must be
known up front, like the waterfall life-cycle model.
40
Spiral
• Develop requirements
in a spiral mode.
• Produce prototypes in
each spiral.
• Leave the other steps
to the last spiral.
41
Spiral
1. Spiral model highlights the progressive need for risk analysis
and prototyping.
2. Requirements can be re-considered during risk analysis in each

spiral.
42
Requirements
5
Specification
Document generation
Requirements and results
44
Requirements specification
• System/SW Requirements Specification specifies the requirements for a
system or software and the methods to be used to ensure that each

requirement has been met.
• Requirements specification is generally given a formatted document.
• But it can also be given in models, diagrams, figures, prototypes, use-
cases etc.
45
Users of a requirements specification
46
Characteristics of a good specification

Correct
Unambiguous
Complete (no TBDs)
Consistent
Ranked for importance and/or stability
Verifiable
Modifiable
Traceable (backward and forward)
47
Basic issues to be addressed

• What is the system/SW supposed to do?
Functionality
External interfaces • People, hardware, others, ...
• Speed, availability, response time, ...

Performance
• Portability, correctness, security, ...

Attributes
Design constraints • Standards, operating environment, ...

48
Standard sections of a specification
States and Capability

Scope References Interfaces
Modes Requirements
Other Quality Qualification Requirements

Requirements Factors Provisions Traceability
49
States and modes

• A system may be described in
idle ready active terms of states only, modes
only, states within modes,
modes within states, or any
postuse analysis training other scheme that is useful.
• The distinction between states
and modes is arbitrary.
• The difference between the two
degraded emergency backup
is that a change in state
happens from outside the
system and a change in mode
wartime peacetime happens from within the system.
50
System quality factors

Functionality The ability to perform all required functions
Reliability The ability to perform with correct, consistent results
Maintainability The ability to be easily corrected
Availability The ability to be accessed and operated when needed
Flexibility The ability to be easily adapted to changing requirements
Portability The ability to be easily modified for a new environment
Reusability The ability to be used in multiple applications
Testability The ability to be easily and thoroughly tested
Usability The ability to be easily learned and used
51
Qualification provisions
• The operation of the system, or a part of the system, that
relies on observable functional operation not requiring the
Demonstration use of instrumentation, special test equipment, or
subsequent analysis.
• The operation of the system, or a part of the system, using
Test instrumentation or other special test equipment to collect
data for later analysis.
• The processing of accumulated data obtained from other
Analysis qualification methods. Examples are reduction,
interpretation, or extrapolation of test results.
• The visual examination of system components,
Inspection documentation, etc.
Special • Any special qualification methods for the system, such as

qualification special tools, techniques, procedures, facilities, and
methods acceptance limits.
52
Traceability matrix example
53
Standards
• Systems and software engineering - System life
ISO/IEC/IEEE 15288:2015 cycle processes
• International Standard - Systems and software
IEEE 12207 engineering - Software life cycle processes
• IEEE Recommended Practice for Software
IEEE 830-1998 Requirements Specifications
• Guide for Developing System Requirements
IEEE 1233 Specifications
• Military Standard: Software Development and
DoD MIL-STD-498 Documentation
NATO AQAP160 • Allied Quality Assurance Publication
CMMI • Capability Maturity Modeling

54
Specification Template Examples

• MIL-STD-498 Standard
Department of Defence’s Data Item Descriptions on Systems and
Software Requirements
Systems Requirements Specification (SSS)
• IEEE Std 1233-1998 Standard

IEEE Guide for Developing System Requirements Specifications
55
Requirements
6 Measurements
and Tools
How to measure and manage
requirements
Capability Maturity Model Integration
57
Key Process Areas (KPAs)

Maturity Level Project Managment Engineering Process Management Support
5 Org. Innovation & Depl. Causal Analysis & Resolution
Optimizing
4 Quantitative Project Mngt Org. Process Performance
Quantitatively
Managed
3 Integrated Project Mngt Requirements Dvlp. Org. Process Focus Decision Analysis & Resolution
Defined Risk Management Technical Solution Org. Process Definition
Product Integration Org. Training
Verification
Validation
2 Project Planning Requirements Mngt Measurement & Analysis

Managed Project Monitoring & Ctrl Process & Product Quality Asnc.
Supplier Agreement Mngt Configuration Mngt
1
Initial
58
Requirement metric sample
59
Requirements management tools

CA Agile Central
Blueprint (v6.4) by (previously: Rally) (2015.2)
Agile Manager (2.50) by Caliber (11.4.11) by
Blueprint Software Systems, by CA Technologies
Hewlett-Packard Enterprise, Borland (Micro Focus),
Inc., Scope: RD, RM, UI (previously: Rally Software
Scope: RM, Agile Scope: RM, Visual Modeling
Mockup, Visual Modeling Development Corp.), Scope:
RM, Agile
HPE ALM/Quality Center

codeBeamer Cognition Cockpit (7.4) by
(12.50) by Hewlett-Packard
Requirements Cognition Corporation, Enterprise Architect (12.1)
Enterprise, Scope: RM,
Management (7.8.0) by Scope: RM, Product by Sparx Systems, Scope:
Testing, Project
Intland Software GmbH, Management, Testing, Visual Modeling, RM
Management, Issue
Scope: RM Project Management
Management
JIRA Software (7.1.0) by

IBM Rational DOORS Next Polarion Requirements
IBM Rational DOORS Atlassian, Scope: Issue
Generation (6.0.1) by IBM, (2015 SR3) by Polarion
(9.6.1.4) by IBM, Scope: RM Management, Agile, Project
Scope: RM Software, Scope: RM
Management, RM
60
Requirements attributes
61
Some Clues on
7 Requirements
Engineering
What to do for the good requirements
Guidelines for writing requirements

• Define standard templates for describing
requirements.
• Use language simply, consistently and
concisely.
• Use diagrams appropriately.
• Supplement natural language with other
descriptions of requirements.
• Specify requirements quantitatively.
63
Guidelines for good requirements

1. Use simple direct sentences
▹ Example: “The pilot shall be able to view the air speed.”
2. Use a limited vocabulary
▹ Example: “The airline shall be able to change the aircraft’s
seating from business to holiday charter use in less than 12
hours.”
3. Focus on stating results
▹ Example:“... view storm clouds by radar.”
4. Define verifiable criteria
▹ Example: “... at least 100 kilometres ahead.” 64

5. Avoid ambiguity (or)
▹ Example: “The same subsystem shall also be able to generate a visible
or audible warning signal for the attention of the co-pilot or navigator”
6. Don’t make multiple requirements (and, or, with, also)
▹ Example: “The battery low warning lamp shall light up when the
voltage drops below 3.6 volts and the current workspace.”
7. Don’t build in let-out clauses (if, when, but, except, unless,
although)
▹ Example: “The forward passenger doors shall open automatically when
the aircraft has halted, except when the rear ramp is deployed.”
65

8. Don’t speculate (usually, generally, often, normally, typically)
▹ Example: “Users normally require early indication of intrusion into the
system.”
9. Don’t express possibilities (may, might, should, ought, could,
perhaps, probably)
▹ Example: “The reception subsystem probably ought to be sensitive,
enough to receive a signal inside a steel-framed building.”
10. Don’t use vague, indefinable terms (user-friendly, versatile,
flexible, approximately, as possible, efficient, improved, modern)
▹ Example: “The print dialog shall be versatile and user-friendly.”
66

11. Avoid wishful thinking (100% reliable, safe, all run on platforms,
upgradable to all future situations)
▹ Example: “The network shall handle all unexpected errors without
crashing.”
12. Don’t mix requirements and design (reference to system, design,
testing, installation)
13. Don’t mix requirement and plans (reference to dates, project
phases, development activities)
14. Don’t design the system (name of components, materials, software
objects, database fields)
67
Example: A
8
Library System
Generic requirements for a simple
system
Requirement-1
▸ REQLIB1. The system shall maintain records of all library
materials including books, serials, newspapers, video and
audio tapes, reports, disks and CDROMs.
•Very general requirement.

•Sets out in broad terms what the system should do.
69
Requirement-2
▸ REQLIB2. The system shall allow users to search for an item
by title, author or ISBN.
•Functional requirement.
•Defines part of the system’s functionality.
70
Requirement-3
▸ REQLIB3. The system’s user interface shall be implemented
using a World-Wide-Web browser.
•Implementation requirement.
•States how the system must be implemented.
71
Requirement-4
▸ REQLIB4. The system shall support at least 20 transactions
per second.
•Performance requirement.
•Specifies a minimum acceptable performance of the system.
72
Requirement-5
▸ REQLIB5. The system facilities which are available to public
users shall be demonstrable in 10 minutes or less.
•Usability requirement.
•Specifies the maximum acceptable time to demonstrate the
use of the system.
73
Example: Air
9 Ticket Reservation
System
Different level of requirements for
another example.
Sample system
75
Sample system
76
Sample system
77
Different requirement levels

▸ User requirement (UR-x): General system functionality. May not have
a structure. May be incompatible with requirements writing rules.
▸ System requirement (SysR-x-y): Starts mostly with «system» subject. Indicates
what the system does (not what the user does). Includes «shall» modal verb
especially in official documents.
▸ Software requirement (SwR-x-y-z): May use the software component of the system as
the subject of the sentence. May give the software functionality. Sometimes may adress
the solution/design (but not preferred mostly). One system requirement mostly traced
to more than one software requirements (3, 5, 10,...)
78
Main user requirements

▪ User will be able to add the required information. There
will be a user login page. Users may contact the
company if required. There will be instructions for
booking and other processes. Airline tickets and models
can be booked. Motels can be booked. Touring packages
can be selected. System will respond to the user quickly.
System will always be open to access on the Internet.
79
Main system requirements

▪ Write down at least 7 functional system requirements.
▪ What can be the non-functional system requirements

and system quality attributes? System
Requirements
▪ What are the external system requirements?
▪ Think of the software requirements corresponding to

each system requirements.
80
User registration
▸ UR-1: User will be able to add the required information.
▸ SysR-1-1: System shall enable the user to enter reservation details
including flights, motels and special packages.
▸ SwR-1-1-1: User enterance page shall provide user to enter the flight
information including «from», «to», «date» and «# of passengers» data.
▸ SwR-1-1-2: Flight database shall display the required flight information in
which user entered the basic data.
▸ …
81
User login
▸ UR-2: There will be a user login page.
▸ SysR-2-1: System shall enable the user to log into the application, with
the username and password he/she provided while registering
to the system.
▸ SwR-2-1-1: Login page shall provide user to enter the user name and password.
▸ SwR-2-1-2: Login page shall have an edit box to enter 15 letters maximum.
▸ SwR-2-1-3: Login page shall provide user to enter password with at least 8 characters
including upper and lower cases.
▸ …
82
Contact the company

▸ UR-3: Users may contact the company if requested.
▸ SysR-3-1: System shall enable the user to contact the company for any
information.
▸ SwR-3-1-1: An envelope icon shall be used to open the contact information.
▸ SwR-3-1-2: Contact box shall provide user to write messages with 512 characters
maximum.
▸ SysR-3-2: System shall provide an email system to send and receive the
messages.
83
Booking instructions
▸ UR-4: There will be instructions for booking and other
processes.
▸ SysR-4-1: System shall enable the user to view the instructions for
booking flights, packages or motels.
▸ SwR-4-1-1: Instruction files shall include booking flights, packages or motels.
▸ SwR-4-1-2: System database shall include information about motels for the
selected destination.
▸ …
84
Book flights
▸ UR-5: Airline tickets can be booked.
▸ SysR-5-1: System shall enable the user to book airline tickets.
▸ SwR-5-1-1: Booking pages shall include ticket, user and credit card information.
▸ …
85
Book motels
▸ UR-6: Motels can be booked.
▸ SysR-6-1: System shall enable the user to book motels at the time of
airline ticket reservation.

▸ SwR-6-1-1: Ticket reservation pages shall include a link for motel reservaion
pages.
▸ …
86
Booking pages
▸ UR-7: Touring packages can be selected.
▸ SysR-7-1: System shall enable the user to book different touring
packages at the airline ticket reservation.

▸ SwR-7-1-1: Ticket reservation pages shall include links to touring packages.
▸ …
87
Other functional requirements
▸ Login/Logout ▸ Email confirmations
▸ Add/delete or modify ▸ Modifying details of web page
customer information ▸ Add/delete or modify motel
▸ Add/delete or modify flight information

information ▸ Add/delete or modify package
▸ Cancellation of reservations information
88
Non-functional requirements
▸ Performance requirements
▸ UR-N-1: System will respond to the user quickly.
▸ SysR-N-1: Responses to queries shall take no longer than 10 seconds to
load onto the screen after the user submits the query.
▸ SysR-N-2: The system shall display confirmation messages to users
within 4 seconds after the user submits information to the system.
89
Quality attributes
▸ Availability
▸ UR-Q-1: System will always be open to access on the
Internet.
▸ SysR-Q-1: The system shall be available to users on the Internet 99.9% of
the time.
90
External interfaces
User
Interface
Reser-
vation
System
Hardware Software Windows 10, MySQL,

None
Interface Interface Visual Studio 2015
91
Some references
▸ Software Requirements Engineering
R.H.Thayer, M.Dorfman; IEEE Computer Society Press, 1999.
▸ Requirements Engineering
G.Kotonya, I.Sommerville; John Wiley & Sons Ltd, 1998.
▸ Software Requirements Specification

DI-IPSC-81433; DOD, 1994.
92
Summary
✓ We have seen the importance and necessity of requirements
engineering.
✓ Basic definitions for requirements engineering are given.
✓ We saw the attributes of a good requirement.
✓ We discussed the development lifecycles in the scope of
systems engineering.
✓ We saw the requirements specifications.
✓ We learned the relationships of requirements and CMMI,
metrics, tools
✓ Some clues were given for the requirements.
✓ We have seen example like a library system and air ticket
reservation system.
Systems Engineering Course, Lecture-3: Systems Requirements Engineering, Orkun Zorba, Ph.D., 2021 93

2.REQUIREMENTS Eee403

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2.REQUIREMENTS Eee403

Uploaded by

Copyright:

Available Formats

Requirements, Systems Engineering

Systems Engineering Course Notes

Do not copy or distribute without the author’s permission

1. The Need for RE

The Need for

Reasons for project failure

Reasons for project failure

Tea machine Television

Sample system requirements

Effects of project sizes

Design Engineers 2-3 10-15 30-40 100-150

Schedule 12 months 24 months 36 months 60+ months

Investment 3 m$ 30 m$ 100 m$ 1000 m$

States/modes 3 30 100 1000

Interface parameters 9 90 500 5000

Requirement pages 15 150 500 2000

Requirement numbers 150 1500 5000 20000

Requirement documents 1 3 10 200

What are requirements for?

2. To give stakeholders a chance to say what they want

3. To represent different viewpoints

4. To check the design

5. To measure the progress

6. To accept products against precise criteria

IEEE, 1998 INCOSE, 2015

• Requirement is a statement • Need is some capability of

Requirements engineering process

Interviews Workshops Existing Prototypes Helpdesks Oberving

Problem Trainers Consultants Customer Suggestions Improve-

“what the “what the

“what kind of usage is

System vs. software engineering

Arch. SW Design SW Integr. Test

Detailed SW Design SW Subsystem Test

System vs. software engineering

System Software Main

Involves partitioning The origin of system

Requirements engineering phases

Elicitation Analysis Specification

• The process through which the customers (buyers and/or

The process of analysing the customers’ and users’ needs to

• The development of a document that clearly and precisely records each of

Requirements verification and validation

• The process of ensuring that the software requirements specification is in

• Requirement management is the process of analysing, documenting, tracking,

General attributes of a good requirement

There should be only one way to interpret the requirement. Sometimes

REQ1 The system shall be implemented using ASP.

Some words can make a requirement untestable. Some adjectives (robust,

In this requirement, all search criteria should be explicitly listed. The

Requirements should not contain unnecessary verbiage or information. They should

This sentence may be replaced by a simpler one:

If a requirement contains facts, these facts should be true:

The tax depends on the state, so the provided 6% figure is incorrect.

The requirement should be doable within existing constraints such as time,

This requirement may be not feasible within a short span of development

REQ1 Dates shall be displayed in the mm/dd/yyyy format.

They can be as follows:

A requirement should be specified for all conditions that can occur.

Development life cycles for RE

2. Waterfall model depends on capturing and freezing

3. Waterfall model depends on separating requirements from