Requirements Engineering
The 'essential' requirements process -
1. Understand the problem
2. Model and Analyze the problem
3. Attain agreement on the nature of the problem
4. Communicate the problem
5. Manage change as the problem evolves
Understand the problem -
• use data gathering techniques to elicit requirements
• Eg. Interviews, Questionnaires, Focus Groups, Prototyping, Observation,...
Model and Analyze the problem -
• use some modeling method(s)
• Eg. Structured Analysis, Object Oriented Analysis, Formal Analysis,...
Attain agreement on the nature of the problem -
• validation
• conflict resolution, negotiation
Communicate the problem -
• specifications, documentation, review meetings,
Manage change as the problem evolves -
• Requirements continue to evolve throughout software development
• (introducing new software changes the problem!!!)
• requirements management - maintain the agreement!
requirements should specify ___ but not ___ -
what, how
'What' -
refers to a system's purpose
• it is external to the system
• it is a property of the application domain
'How' -
refers to a system's structure and behavior
• it is internal to the system
• it is a property of the machine domain
Requirements only exist in the application domain -
- Distinguishing between the machine and the application domain is essential for
good requirements engineering
- Need to draw a boundary around the application domain
• I.e. which things are part of the problem you are analyzing and which are not?
1|Page
,What is a Requirement? -
• A requirement is a statement of one of the following:
- 1. What a system must do
- 2. A known limitation or constraint on resources or
design
- 3. How well the system must do what it does
Functional Requirements -
What a system must do
Non-
Functional Requirements (NFRs) -
- 2. A known limitation or constraint on resources or
design
- 3. How well the system must do what it does
Requirements engineering -
• The process of establishing the services that the customer requires from a system
and the constraints under which it operates and is developed.
• The requirements themselves are the descriptions of the system services and constraints that
are generated during the requirements engineering process.
requirement may range from a ___ of a service or of a ___ to a detailed mathematical
functional specification. -
high-level abstract statement, system constraint
Software Management is... -
• A systematic approach to eliciting, organizing, and documenting the requirements
of the system, and a process that establishes and maintains agreement between the customer
and the project team on the changing requirement of the system.
Types of requirement -
• User requirements
• System requirements
Stakeholders in the Mentcare system -
• Patients whose information is recorded in the system.
• Doctors who are responsible for assessing and treating patients.
• Nurses who coordinate the consultations with doctors and administer some treatments.
• Medical receptionists who manage patients' appointments.
• IT staff who are responsible for installing and maintaining the system.
Agile methods and requirements -
• Many agile methods argue that producing detailed system requirements is a waste
of time as requirements change so quickly.
• The requirements document is therefore always out of date.
• Agile methods usually use incremental requirements engineering and may express
requirements as 'user stories' (discussed in Chapter 3).
• This is practical for business systems but problematic for systems that require pre-delivery
analysis (e.g. critical systems) or systems developed by several teams.
2|Page
, Functional requirements -
- Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
Non-functional requirements -
- constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
Domain requirements -
- Requirements that come from the application domain of the system and that reflect
characteristics of that domain.
Functional requirements -
• Describe functionality or system services.
• Depend on the type of software, expected users and the type of system where the software is
used.
• Functional user requirements may be high- level statements of what the system should do
• Functional system requirements should describe the system services in detail.
functional requirements examples -
- E.g. mapping of inputs to outputs
- E.g. control sequencing
- E.g. timing of functions
- E.g. handling of exceptional situations
- E.g. formats of input and output data (and stored
data?)
- E.g. real world entities and relationships modeled by the system
- Add Participant
• "The software shall display an option to add a participant" - Summon Operator
• "The software shall summon the operator if the participant clicks the Operator Help icon.
A Functional Requirement... -
- is a statement of what a system must do (#1) - is measured in "yes" or "no" terms
- usually employs the word "shall"
The LIBSYS system -
• A library system that provides a single interface to a number of databases of
articles in different libraries.
• Users can search for, download and print these articles for personal study.
Examples of functional requirements -
The user shall be able to search either all of the
initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the document
store.
Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able
to copy to the account's permanent storage area.
Examples of functional requirements -
3|Page
The 'essential' requirements process -
1. Understand the problem
2. Model and Analyze the problem
3. Attain agreement on the nature of the problem
4. Communicate the problem
5. Manage change as the problem evolves
Understand the problem -
• use data gathering techniques to elicit requirements
• Eg. Interviews, Questionnaires, Focus Groups, Prototyping, Observation,...
Model and Analyze the problem -
• use some modeling method(s)
• Eg. Structured Analysis, Object Oriented Analysis, Formal Analysis,...
Attain agreement on the nature of the problem -
• validation
• conflict resolution, negotiation
Communicate the problem -
• specifications, documentation, review meetings,
Manage change as the problem evolves -
• Requirements continue to evolve throughout software development
• (introducing new software changes the problem!!!)
• requirements management - maintain the agreement!
requirements should specify ___ but not ___ -
what, how
'What' -
refers to a system's purpose
• it is external to the system
• it is a property of the application domain
'How' -
refers to a system's structure and behavior
• it is internal to the system
• it is a property of the machine domain
Requirements only exist in the application domain -
- Distinguishing between the machine and the application domain is essential for
good requirements engineering
- Need to draw a boundary around the application domain
• I.e. which things are part of the problem you are analyzing and which are not?
1|Page
,What is a Requirement? -
• A requirement is a statement of one of the following:
- 1. What a system must do
- 2. A known limitation or constraint on resources or
design
- 3. How well the system must do what it does
Functional Requirements -
What a system must do
Non-
Functional Requirements (NFRs) -
- 2. A known limitation or constraint on resources or
design
- 3. How well the system must do what it does
Requirements engineering -
• The process of establishing the services that the customer requires from a system
and the constraints under which it operates and is developed.
• The requirements themselves are the descriptions of the system services and constraints that
are generated during the requirements engineering process.
requirement may range from a ___ of a service or of a ___ to a detailed mathematical
functional specification. -
high-level abstract statement, system constraint
Software Management is... -
• A systematic approach to eliciting, organizing, and documenting the requirements
of the system, and a process that establishes and maintains agreement between the customer
and the project team on the changing requirement of the system.
Types of requirement -
• User requirements
• System requirements
Stakeholders in the Mentcare system -
• Patients whose information is recorded in the system.
• Doctors who are responsible for assessing and treating patients.
• Nurses who coordinate the consultations with doctors and administer some treatments.
• Medical receptionists who manage patients' appointments.
• IT staff who are responsible for installing and maintaining the system.
Agile methods and requirements -
• Many agile methods argue that producing detailed system requirements is a waste
of time as requirements change so quickly.
• The requirements document is therefore always out of date.
• Agile methods usually use incremental requirements engineering and may express
requirements as 'user stories' (discussed in Chapter 3).
• This is practical for business systems but problematic for systems that require pre-delivery
analysis (e.g. critical systems) or systems developed by several teams.
2|Page
, Functional requirements -
- Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
Non-functional requirements -
- constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
Domain requirements -
- Requirements that come from the application domain of the system and that reflect
characteristics of that domain.
Functional requirements -
• Describe functionality or system services.
• Depend on the type of software, expected users and the type of system where the software is
used.
• Functional user requirements may be high- level statements of what the system should do
• Functional system requirements should describe the system services in detail.
functional requirements examples -
- E.g. mapping of inputs to outputs
- E.g. control sequencing
- E.g. timing of functions
- E.g. handling of exceptional situations
- E.g. formats of input and output data (and stored
data?)
- E.g. real world entities and relationships modeled by the system
- Add Participant
• "The software shall display an option to add a participant" - Summon Operator
• "The software shall summon the operator if the participant clicks the Operator Help icon.
A Functional Requirement... -
- is a statement of what a system must do (#1) - is measured in "yes" or "no" terms
- usually employs the word "shall"
The LIBSYS system -
• A library system that provides a single interface to a number of databases of
articles in different libraries.
• Users can search for, download and print these articles for personal study.
Examples of functional requirements -
The user shall be able to search either all of the
initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the document
store.
Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able
to copy to the account's permanent storage area.
Examples of functional requirements -
3|Page
