Software Engineering and Application
Requirements Engineering
1. Introduction to Requirements Engineering
Requirements Engineering (RE) is the process of defining, documenting, and maintaining the
requirements of a software system. It plays a critical role in ensuring that the final product
meets user needs and expectations. Effective RE involves collaboration with stakeholders to
gather, analyze, and validate requirements throughout the software development lifecycle.
Key Objectives:
•
•
•
Understand stakeholder needs and expectations.
Translate needs into a clear set of requirements.
Establish a basis for design, development, and testing.
2. Types of Requirements
Understanding the different types of requirements is essential for successful RE.
•
•
Functional Requirements: Describe what the system should do. These requirements
detail specific functions, behaviours, or features that the system must perform.
o Examples:
▪ "The system shall allow users to register using their email address."
▪ "The application shall provide a search function for users to find
products by name or category."
Non-Functional Requirements: Specify how the system should perform its functions.
They address the quality attributes of the system, such as performance, usability,
reliability, and security.
o Examples:
▪ "The system shall handle up to 1,000 concurrent users."
▪ "The application shall encrypt user passwords using industry-standard
algorithms."
3. The Software Requirements Document (SRD)
The SRD is a formal document that captures all requirements and serves several critical
functions:
•
•
•
Communication: It ensures all stakeholders have a shared understanding of the
requirements.
Guidance: The SRD acts as a roadmap for design and implementation.
Reference: It serves as a basis for testing and validation.
Structure of the SRD:
1. Introduction: Purpose, scope, and intended audience.
2. Overall Description: System perspective, user needs, and assumptions.
3. Specific Requirements: Detailed functional and non-functional requirements.
4. Appendices: Glossary, references, and additional information.
Functional_Requirem
ents_Document.pdf
4. Requirements Specification
Requirements must be well-defined to ensure clarity and avoid misunderstandings. Key
characteristics of effective requirements include:
•
•
•
Clear: Avoid ambiguous language. Each requirement should be understandable.
Measurable: Requirements should be verifiable through testing or observation.
Feasible: Requirements must be achievable within project constraints such as time and
budget.
5. Requirements Engineering Processes
The RE process can be divided into several key activities:
•
•
•
•
Elicitation: The process of gathering requirements from stakeholders using various
techniques.
o Techniques:
▪ Interviews: One-on-one discussions to gather detailed insights.
▪ Surveys: Questionnaires that can reach a broader audience.
▪ Workshops: Group sessions that encourage collaborative requirement
gathering.
▪ Observation: Watching users interact with existing systems to identify
needs.
Analysis: Involves examining and prioritizing requirements. This may include creating
models to visualize relationships and dependencies.
o Tools: Use of diagrams (e.g., flowcharts, use case diagrams) to clarify
requirements.
Validation: Ensuring that requirements meet stakeholder needs and are feasible.
o Techniques:
▪ Reviews: Conducting formal reviews with stakeholders.
▪ Prototyping: Developing early versions of the system to gather
feedback.
▪ Testing: Verifying requirements against the final product.
Management: Ongoing tracking and adaptation of requirements throughout the
project.
o Tools: Requirement traceability matrices to monitor changes and ensure
alignment with project goals.
6. Requirements Elicitation Techniques
To effectively elicit requirements, various techniques can be employed:
•
•
•
•
Interviews: Conduct structured or semi-structured interviews with stakeholders.
Focus Groups: Gather diverse users to discuss and identify needs collaboratively.
Prototyping: Create mock-ups or wireframes to visualize functionality and gather
feedback.
User Stories: Collect short, simple descriptions of a feature from the user's perspective.
7. Requirements Validation Techniques
Validation is essential to ensure that the documented requirements are correct and agreed upon.
Common techniques include:
•
•
•
Requirements Reviews: Schedule meetings with stakeholders to discuss and validate
requirements.
Prototyping: Use prototypes to demonstrate functionality and gather user feedback.
User Acceptance Testing (UAT): Conduct tests with real users to validate that the
system meets their needs.
8. Requirements Management
Managing requirements is crucial as projects evolve. Effective management involves:
•
•
•
Tracking Changes: Maintain version control to document changes to requirements.
Managing Stakeholder Expectations: Communicate changes clearly to all
stakeholders.
Ensuring Traceability: Use traceability matrices to link requirements to design and
testing.
Week 8: System Modelling
1. Introduction to System Modelling
System Modelling involves creating abstract representations of a system to understand its
components and interactions. Models help in visualizing the system architecture and facilitate
communication among stakeholders.
2. Types of Models
Different types of models serve specific purposes in system design:
•
•
•
Context Models: Define the boundaries of the system and its interactions with external
entities. They help stakeholders understand what is inside and outside the system.
Interaction Models: Show how users will interact with the system. Common tools
include use case diagrams and sequence diagrams.
Structural Models: Describe the organization of the system, including classes and their
relationships. Class diagrams are frequently used to depict structures.
•
Behavioural Models: Represent the dynamic behavior of the system. Activity
diagrams and state diagrams illustrate how the system responds to various events.
3. Context Models
Purpose:
•
•
Provide a high-level view of the system's environment.
Identify external entities that interact with the system.
Example:
A context diagram for an online shopping system may include:
•
•
•
Users (customers, admins)
Payment systems (credit card processors)
Inventory databases
4. Interaction Models
Use Case Diagrams:
•
•
•
Illustrate user interactions with the system.
Capture functional requirements in a user-centered manner.
Show actors (users or other systems) and their interactions with use cases.
Sequence Diagrams:
•
•
Detail the order of interactions between system components.
Visualize the flow of messages over time during specific use cases.
5. Structural Models
Class Diagrams:
•
•
Depict the classes in the system and their relationships.
Help visualize the static structure of the system, including:
o Classes: Represent entities with attributes and methods.
o Relationships: Show associations, inheritance, and dependencies between
classes.
6. Behavioural Models
Activity Diagrams:
•
•
Represent workflows and the sequence of activities in a process.
Useful for modeling business processes and user interactions.
State Diagrams:
•
•
Show the states of an object and how it transitions from one state to another based on
events.
Useful for modeling the lifecycle of an object.
7. Importance of System Modelling
•
•
•
•
Enhances understanding of the system architecture.
Facilitates communication among stakeholders.
Helps identify potential issues early in the development process.
Supports documentation and future maintenance efforts.
8. Integrating Models
To create a comprehensive understanding of the system, integrate different models:
•
•
Use context models to define boundaries, interaction models for user behavior, and
structural models for organization.
This holistic approach ensures all aspects of the system are considered and documented.
Suggested Reading
1. Sommerville, I. (2011), Software Engineering (9th Edition). Pearson Education.
2. Booch, G., Rumbaugh, J., & Jacobson, I. (2005), The Unified Modeling Language
User Guide. Addison-Wesley.
3. Fowler, M. (2004), UML Distilled: A Brief Guide to the Standard Object Modeling
Language. Addison-Wesley.