Requirements
Engineering
Defining Software Requirements
Requirements
Engineering (RE) is the
Requirements describe
process of finding,
what the system should
analyzing, documenting,
do and its constraints.
and checking
requirements.
Two Levels of Requirements:
User Requirements System Requirements
Statements in natural language – structured document setting out detailed
High-level, abstract statements (for descriptions of the system’s functions,
customers, managers, users). services and operational constraints –
Detailed descriptions for architects and
developers.
4
Types of Requirements
Functional Requirements (FRs)
• Describe services, reactions, and behaviors.
• Depend on software type and user needs.
• Imprecision can lead to engineering
problems.
Types of Requirements
Non-Functional Requirements (NFRs)
• Constraints on services or functions.
• Related to emergent system properties (reliability, security,
etc.).
• Should be measurable whenever possible.
The Software Requirements
Document (SRS)
• Official statement of what developers should
implement.
• Important when external contractors are
involved.
• Used by customers, managers, testers,
engineers, and maintenance staff.
• Typical IEEE structure includes:
1. Introduction
2. Glossary
3. User Requirements Definition
4. System Architecture
5. System Requirements Specification
6. System Evolution
7. Appendices and Index
Requirements
Specification
Activity of writing user and system requirements in
a document.
• Natural Language: Expressive but ambiguous.
• Structured Specifications: Template-based for
uniformity.
• Graphical Notations: Use case diagrams,
sequence diagrams.
• Mathematical Specifications: Finite-state,
unambiguous, for safety-critical systems.
Requirements Engineering Processes
Requirements Elicitation
Techniques
• Interviews
Understand stakeholder needs and system
interactions.
• Scenarios and Use Cases
Identify actors and interactions.
• Ethnography
Observe real work environments to discover
implicit requirements.
customers /system owners /investors (those who are
paying for the work) .
System
end users/ system users (people who will use the
Stakeholders system) .
A stakeholder is anyone
(person or organization)
who has a legitimate
interest in the project and government and public opinion / advisors/ regulatory
authorities (such as legal experts or regulators who have
anyone who will be relevant information about the requirements).
affected or influenced by
the proposed system in
some way.
system managers, maintenance and service staff
(project groups that are involved in developing the
system )
18
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
A Medical Ethics Manager who must ensure that the system meets current ethical guidelines for patient care
Health Care Managers who obtain management information from the system
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
19
Requirements Validation
Ensures requirements define the system the customer really
wants.
Types of Checks:
Validity Consistency Completeness Realism Verifiability
Validation Techniques:
Requirements Test-case
Prototyping
Reviews Generation