Unit 2

Requirements Engineering
1. User Requirements-
User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide to system users.
User requirements define the results and qualities the user wants.
A user requirement concerned with security, such as a statement limiting access to
authorized users, may appear to be a nonfunctional requirement.
2. System Requirements-
are more detailed descriptions of the software system’s functions, services, and
operational constraints.
The system requirements document (sometimes called a functional specification)
should define exactly what is to be implemented. It may be part of the contract
between the system buyer and the software developers.
Requirements Engineering
1. Functional requirements
The functional requirements for a system describe what the system should do. These
requirements depend on the type of software being developed, the expected users of
the software, and the general approach taken by the organization when writing
requirements.
When expressed as user requirements, functional requirements are
usually described in an abstract way that can be understood by system users.
However, more specific functional system requirements describe the system
functions, its inputs and outputs, exceptions, etc., in detail.
Functional system requirements vary from general requirements covering what
the system should do to very specific requirements reflecting local ways of working
or an organization’s existing systems.
2. Non-functional requirements
Metrics for specifying non-functional requirements
The software requirements document
Requirements specification
SRS Characteristics
1. Correctness
2. Completeness
3. Consistency
4. Unambiguousness
5. Ranking for importance and stability
6. Modifiability
7. Verifiability
8. Traceability
9. Design Independence
10. Testability
11. Understandable by the customer
12. Right level of abstraction
Requirements engineering processes
Requirements elicitation and analysis
Requirements discovery
Stakeholders range from end-users of a system through managers to external stakeholders such as
regulators, who certify the acceptability of the system. For example,
system stakeholders for the mental healthcare patient information system include:
1. Patients whose information is recorded in the system.

2. Doctors who are responsible for assessing and treating patients.
3. Nurses who coordinate the consultations with doctors and administer some
treatments.
4. Medical receptionists who manage patients’ appointments.
5. IT staff who are responsible for installing and maintaining the system.
6. A medical ethics manager who must ensure that the system meets current ethical guidelines for patient
care.
7. Healthcare managers who obtain management information from the system.
8. Medical records staff who are responsible for ensuring that system information
can be maintained and preserved, and that record keeping procedures have been
properly implemented.
Requirement Elicitation Techniques
1. Brainstorming
2. Interviewing
3. Surveys/Questionnaires
4. Prototyping
5. Scenarios
6. Use Cases
7. Ethnography
1. Brainstorming
Brainstorming, as a requirements elicitation technique, embodies a dynamic
group activity focused on generating a wide array of ideas, solutions, and
requirements for a project.
This technique is especially valuable in the initial phases of a project, where the
goal is to explore various possibilities and identify innovative solutions without
the constraints of criticism or feasibility considerations.
2. Interviewing
Formal or informal interviews with system stakeholders are part of most
requirements engineering processes. In these interviews, the requirements
engineering team puts questions to stakeholders about the system that they
currently use and the system to be developed. Requirements are derived from the
answers to these questions.
Interviews may be of two types:
1. Closed interviews, where the stakeholder answers a pre-defined set of questions.
2. Open interviews, in which there is no pre-defined agenda. The requirements

engineering team explores a range of issues with system stakeholders and hence
develop a better understanding of their needs.
3. Surveys/Questionnaires
Surveys and questionnaires stand as highly scalable and efficient
techniques for requirement elicitation, enabling data collection
from a broad audience in a relatively short period of time.
This method is particularly useful when the project stakeholders

are numerous or geographically dispersed, and there’s a need to
gather a wide range of opinions, preferences, and requirements for
the system under development.
4. Prototyping
Prototyping is a dynamic and interactive requirements
elicitation technique that involves creating preliminary
versions of a software system to explore ideas, uncover
requirements, and gather feedback from users and
stakeholders.
This approach allows for a tangible exploration of the

system’s functionality and design before developing the full
system.
5. Scenarios
• a scenario may include:

1. A description of what the system and users expects when the
scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the
same time.
5. A description of the system state when the scenario finishes.
6. Use cases
7. Ethnography
Requirements validation
• During the requirements validation process, different types of checks
should be carried out on the requirements in the requirements
document. These checks include:
1. Validity checks
2. Consistency checks
3. Completeness checks
4. Realism checks
5. Verifiability
Requirements validation
• There are a number of requirements validation techniques that can

be used individually or in conjunction with one another:
1. Requirements reviews
2. Prototyping
3. Test-case generation
Requirements management
1. The business and technical environment
2. The people
3. Large systems
1. Requirements management planning
1. Requirements identification
2. A change management process
3. Traceability policies
4. Tool support
2. Requirements change management
Data Flow Diagram
• A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an
information system.
• It is common practice to draw a System Context Diagram first which shows the interaction
between the system and outside entities.
• The DFD is designed to show how a system is divided into smaller portions and to highlight
the flow of data between those parts.
• Level 0 DFD i.e. Context level DFD should depict the system as a single.
• Primary input and primary output should be carefully identified.
•Information flow from continuity must be maintained from level to level
Data Flow Diagram
Types of DFD:
1) Logical DFD
It illustrates how data flows in the system
What system should do
2) Physical DFD
Physical data flow diagram shows how the data flow is
actually implemented in the system.
How system should work
Data Flow Diagram
Four basic symbols

1. External entity
2. Process
3. Transition
4. Data Store
Data Dictionary
A data dictionary is an alphabetic list of the names included in the system
models. As well as the name, the dictionary should include an associated
description of the named entity and, if the name represents a composite
object, a description of the composition.
• Other information such as the date of creation, the creator and the
representation of the entity may also be included depending on the type
of model being developed.
Data Dictionary
Data element- Order
Description- Record comprising fields

Order identification Customer name Customer address
..
Package name
Package price
Product Specification
A product specification is a document that outlines the characteristics,

features, and functionality of a product. It serves as a blueprint for
designing, developing, and testing the product.
The aim of a product specification document is to ensure that everyone

involved in the product development process understands what is required
and that the end product meets the customer’s needs and expectations.
Product specification document
•Planning
•Scope
•Product design
•Testing plan
•Release plan
•Managing the product
Structured English
Decision Tree
Decision Table

Unit 2

Uploaded by

Copyright:

Available Formats

Unit 2

Uploaded by

Document Information

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

Unit 2

Uploaded by

Copyright:

Available Formats

Requirements Engineering

1. Patients whose information is recorded in the system.

Interviews may be of two types:

1. Closed interviews, where the stakeholder answers a pre-defined set of questions.

2. Open interviews, in which there is no pre-defined agenda. The requirements

This method is particularly useful when the project stakeholders

This approach allows for a tangible exploration of the

• a scenario may include:

• There are a number of requirements validation techniques that can

Four basic symbols

Description- Record comprising fields

A product specification is a document that outlines the characteristics,

The aim of a product specification document is to ensure that everyone

You might also like