Requirements Engineering: Elicitation, SRS, Use Cases and Requirement Modelling

In software development, understanding what the user actually needs is the most crucial first step. This process is called Requirements Engineering. It's like building a house: you first need to know how many rooms you want, what size they should be, and where the doors and windows go, before you even think about laying a brick. Requirements Engineering ensures that the software we build will actually solve the problem it's intended to solve and satisfy the stakeholders.

1. Requirements Elicitation

Requirements elicitation is the process of gathering and understanding the needs and constraints of the stakeholders for a system. It's about asking the right questions to the right people and actively listening to their responses. This is often the most challenging part of software development because user needs can be unclear, incomplete, or even contradictory.

1.1 Stakeholders

Stakeholders are individuals or groups who have an interest in the project or will be affected by the software. Identifying all relevant stakeholders is key to successful elicitation.

• Customers: Those who pay for the software.
• End-users: Those who will directly interact with the software.
• Developers: Those who will build the software.
• Managers: Those who oversee the project and its resources.
• Testers: Those who verify the software's quality.
• Regulators: Those who enforce standards and compliance.

1.2 Elicitation Techniques

Various techniques are employed to elicit requirements, depending on the project context, stakeholders, and the nature of the requirements.

• Interviews: One-on-one conversations with stakeholders to understand their needs, goals, and pain points. Open-ended questions are often best here. For example, instead of asking "Do you need a report?", ask "What information do you need to track your sales performance?".
• Questionnaires/Surveys: Used to gather information from a large number of stakeholders, especially when they are geographically dispersed. They are good for gathering quantifiable data or opinions on specific features.
• Workshops/Focus Groups: Bringing together a group of stakeholders to discuss requirements collaboratively. This can help resolve conflicts and build consensus. A facilitator guides the discussion.
• Observation (Ethnography): Observing users in their natural work environment to understand their tasks, workflows, and any implicit needs they might not articulate. For instance, watching a librarian manage book check-ins can reveal issues with the current system that they haven't mentioned.
• Document Analysis: Reviewing existing documentation, such as business process descriptions, user manuals for old systems, or policy documents, to understand current processes and constraints.
• Prototyping: Creating a preliminary version or model of the software to get feedback from stakeholders. This is particularly useful when requirements are vague or when users have difficulty visualizing the end product. A simple clickable wireframe can be a powerful prototype.

1.3 Challenges in Elicitation

Several challenges can hinder effective requirements elicitation:

• Incomplete Requirements: Stakeholders may forget to mention certain needs.
• Unclear Requirements: Ambiguous language can lead to misinterpretation.
• Conflicting Requirements: Different stakeholders may have opposing needs.
• Changing Requirements: Needs can evolve as the project progresses.
• Communication Barriers: Technical jargon vs. business language, cultural differences, or simply shyness can impede clear communication.
• Assumptions: Stakeholders and developers might make unstated assumptions about how things should work.

2. Software Requirements Specification (SRS)

The Software Requirements Specification (SRS) is a formal document that describes what the software system will do. It serves as a contract between the development team and the stakeholders, ensuring everyone has a common understanding of the system's functionality, performance, design constraints, and attributes. A well-written SRS is crucial for successful project management, development, and testing.

2.1 Characteristics of a Good SRS

An effective SRS should possess several key qualities:

• Correct: Every requirement stated must be accurate and reflect the actual needs.
• Unambiguous: Each requirement must have only one interpretation.
• Complete: All significant requirements must be included, covering functionality, performance, design constraints, and quality attributes.
• Consistent: Requirements should not contradict each other.
• Verifiable: It must be possible to check if the implemented software meets each requirement.
• Modifiable: The document should be structured so that changes can be made easily and consistently.
• Traceable: Each requirement should be traceable back to its source and forward to design elements and test cases.
• Prioritized: Requirements should be ranked according to their importance or urgency.

2.2 Structure of an SRS Document

While there's no single mandated format, a common structure for an SRS includes:

1. Introduction:
   • Purpose of the document.
   • Scope of the software product.
   • Definitions, acronyms, and abbreviations.
   • References to other documents.
   • Overview of the rest of the SRS.
2. Overall Description:
   • Product Perspective: How the software fits into the larger system or business context.
   • Product Functions: A summary of the major functions the software will perform.
   • User Characteristics: Description of the intended users.
   • Constraints: Any limitations on design or implementation (e.g., hardware, regulatory, programming language).
   • Assumptions and Dependencies: Factors that are assumed to be true or external elements the system relies on.
3. Specific Requirements: This is the core of the SRS, detailing all functional and non-functional requirements.
   • Functional Requirements: Describe the specific behaviors or functions the system must perform. For example, "The system shall allow users to search for products by name or category."
   • Non-Functional Requirements: Describe the qualities or constraints of the system, such as performance, security, reliability, usability, and maintainability. For example, "The search function shall return results within 2 seconds."
   • External Interface Requirements: Describe how the software interacts with other systems, hardware, or users.
   • Design Constraints: Specific design choices that are imposed.
4. Appendices (Optional): Glossary, analysis models, etc.

3. Use Cases

Use Cases are a technique used in the requirements analysis phase to describe the functional requirements of a system from the user's perspective. They capture the interactions between an actor (a user or another system) and the system itself to achieve a specific goal.

3.1 Actors

An actor is anything that interacts with the system. It can be a human user, another software system, or even a hardware device. Actors represent roles, not specific individuals. For example, "Customer" is an actor, not "John Doe".

3.2 The Use Case Diagram

A Use Case Diagram is a graphical representation of the system's functionality. It shows the actors, the use cases they interact with, and the relationships between them.

• Actors are typically represented by stick figures.
• Use Cases are represented by ovals.
• System Boundary is shown as a rectangle encompassing the use cases, separating the system from the outside world (actors).
• Associations (lines) connect actors to the use cases they interact with.

3.3 Use Case Description (Textual Format)

While diagrams provide a high-level view, a detailed textual description is needed for each use case to fully define its behavior. A typical use case description includes:

• Use Case Name: A concise, verb-noun phrase (e.g., "Place Order").
• Actor(s): The primary actor(s) who initiate or participate in the use case.
• Goal: The objective the actor wants to achieve.
• Preconditions: Conditions that must be true before the use case can start. (e.g., "User must be logged in").
• Postconditions: Conditions that must be true after the use case successfully completes. (e.g., "Order is placed and confirmed").
• Main Success Scenario (Basic Flow): A step-by-step description of the most common, successful path through the use case. This is usually numbered.
  1. Actor initiates the use case.
  2. System presents options.
  3. Actor selects an option.
  4. System performs an action.
  5. ...
• Alternative Flows: Variations on the main scenario, including error conditions or less common paths. (e.g., "If item is out of stock...").
• Exception Flows: Descriptions of what happens when errors occur. (e.g., "If payment fails...").
• Special Requirements: Any non-functional requirements related to this use case (e.g., performance, security).

3.4 Relationships between Use Cases

Use cases can be related to each other using specific UML notations:

• Include (<>): One use case (the base use case) incorporates the behavior of another use case (the included use case). This is used for common functionality that is shared across multiple use cases. For example, "Place Order" might <> "Validate Payment".
• Extend (<>): One use case (the extending use case) adds behavior to another use case (the base use case) under certain conditions. This is used for optional functionality. For example, "Submit Order" might be <>ed by "Apply Discount Code".
• Generalization: One use case can be a specialized version of another. For example, "Pay by Credit Card" and "Pay by PayPal" could generalize to a "Make Payment" use case.

4. Requirements Modelling

Requirements modelling is the process of creating abstract representations (models) of the requirements. These models help visualize, analyze, and communicate the system's intended behavior and structure. Various types of models are used, often employing notations from the Unified Modelling Language (UML).

4.1 Types of Requirements Models

Models can be broadly categorized based on what they represent:

• Behavioural Models: Describe the dynamic aspects of the system – what it does.
• Structural Models: Describe the static aspects of the system – its components and their relationships.

4.2 Key UML Models for Requirements Engineering

4.2.1 Use Case Diagrams

As discussed earlier, these provide a high-level overview of system functionality and actor interactions. They are excellent for defining the scope and boundaries of the system.

4.2.2 Activity Diagrams

These models represent the flow of control or activities within a system. They are similar to flowcharts but are more powerful, showing parallel activities, decision points, and the movement of data. Activity diagrams are useful for modelling business processes or complex operational flows within a use case.

• Start Node: Represents the beginning of the activity.
• Activity: Represents a step or action.
• Decision Node: Represents a point where the flow can diverge based on conditions.
• Merge Node: Represents the convergence of flows that have previously diverged.
• Fork Node: Splits a single flow into multiple parallel flows.
• Join Node: Synchronizes multiple parallel flows back into a single flow.
• End Node: Represents the end of the activity.

For example, an activity diagram could model the steps involved in processing an online order, showing parallel actions like "Pack Item" and "Generate Shipping Label".

4.2.3 State Machine Diagrams (Statechart Diagrams)

These models describe the different states an object or the system can be in and the transitions between those states triggered by events. They are useful for modelling the lifecycle of objects or the behavior of systems that have complex states.

• State: A condition or situation during which an object is waiting for something to happen.
• Transition: A change from one state to another, triggered by an event.
• Event: Something that happens at a specific point in time.
• Guard: A condition that must be true for a transition to occur.

Consider a "User Account" object. It might have states like "Active", "Suspended", and "Deleted". An event like "Admin suspends account" would trigger a transition from "Active" to "Suspended".

4.2.4 Class Diagrams (for Structural Modelling)

While primarily used in design, class diagrams can be introduced early in requirements to model the key entities (classes) in the problem domain and their relationships (associations, aggregations, compositions, inheritance). This helps clarify the static structure of the information the system will manage.

• Classes: Represent the main entities (e.g., "Customer", "Product", "Order").
• Attributes: Properties of a class (e.g., Customer's name, address).
• Operations (Methods): Actions a class can perform.
• Relationships: How classes are connected (e.g., a Customer places many Orders).

4.2.5 Sequence Diagrams (for Behavioural Modelling)

Sequence diagrams illustrate how objects interact over time, focusing on the order in which messages are sent between them. They are excellent for visualizing the flow of control for a specific scenario within a use case.

• Lifelines: Represent individual participants (objects or actors) in the interaction.
• Messages: Arrows indicating communication between lifelines.
• Activation Bars: Indicate the period during which an object is performing an action.

A sequence diagram for "Place Order" would show the Customer object sending a message to the Order object, which then sends messages to Product and Payment objects, detailing the specific sequence of interactions.

5. Elicitation, SRS, Use Cases, and Modelling: The Interplay

These activities are not isolated; they form a cycle. Elicitation provides the raw material. This material is then structured and refined into an SRS. Use cases and other UML models are created to clarify and visualize the requirements described in the SRS. Feedback from these models often leads back to further elicitation to clarify ambiguities or resolve conflicts.

For instance, during an interview (elicitation), a user might say, "I need to track my inventory." This vague statement leads to a requirement in the SRS: "The system shall manage inventory levels." To clarify this, a Use Case like "Manage Inventory" is created, detailing actions like "Add Stock," "Remove Stock," and "View Stock Levels." Activity diagrams might then model the process of receiving new stock, and state machine diagrams could track the status of individual inventory items (e.g., "In Stock," "Low Stock," "Out of Stock"). This iterative process ensures that the final SRS accurately reflects the user's needs.

Effective requirements engineering is a cornerstone of successful software development. By employing robust elicitation techniques, creating clear and comprehensive SRS documents, utilizing use cases for user-centric descriptions, and leveraging modelling tools to visualize complex requirements, development teams can ensure they build the right software, for the right reasons.